Re: [Ranger-users] ranger 1.6.0 on the horizon

[Roman Z.]

On Mon, Feb 18, 2013 at 08:22:32PM +0000, Joshua Landau wrote:
> TYPED IN -> RESULTING REGEXP
> > "foo" -> "f.*o.*o"
> > "^foo$" -> "^f.*o.*o$"
> > "$[ab]" -> "\$.*\[.*a.*b.*\]"
> 
> 
> Is this in git? It's not the case for me yet.
Yep, see 
https://github.com/hut/ranger/blob/798c94a/ranger/config/commands.py#L1108
Perhaps your commands.py is outdated?


> The command :find will remain the same, and :narrow will be removed.
> 
> 
> I'm curious as to why (not disagreeing). Is it because of the semi-planned
> merge into find?

Yes.


> > But, the elephant is already in the room and performance is not in
> > question, so whatever type of implemenation is done is not important for
> > the end user. The one that gives the most extensiblity and the least code
> > should be hence prefered one, hence the RegEx in the first place.
> 
> 
> A Regex implementation gives the _least_ extensibility (or massive codez).
> Python is trivially turing-complete. If you show me a way to simply edit
> Regex to be powerful (more than "^$.") *with* letter skipping I'll quickly
> accept otherwise, but I don't think it'll happen ;P.
> 
> The problem is that Regex's power is long-form, which *doesn't work* when
> acting dynamically without lots of problem.
> 
> Not to mention that people expect RE everywhere now days.
> 
> 
> :( ... :P

I'd like to point out that your mails are difficult to read if you don't
quote properly.  There should be (at least) one ">" in front of every
line that is not yours.  (such as the line "Not to mention that people...")

On topic:  One use case for regular expressions is if you want to match
all files that end with either jpg, jpeg or png, you can simply ":search
(jpe?|pn)g$".  Everybody that is somewhat used to regular expressions
can come up with that instantly, while it is not possible with any of
the other modes.  Of course this doesn't make sense for :travel, but
I want to remind you that :travel is not the only use case.

 
> > Also, my experience with open source users is that people almost certainly
> > find good uses for stuff you didn't think of, and somebody will eventually
> > ask for full RE in travel.
> 
> 
> They've already done so ;).
> 
> But fine, so what? If you implement it with a python function, using Regex
> is ~3 lines. Using edited Regex as above is ~10 lines. Using a custom mode
> will be from ~10 to ~100 lines.
> 
> Using Regex *implementation* will make these 0 lines, ~10 lines and from
> ~10 lines to impossible (because not all Python can be expressed in Regex).
> 
> Some things Regex just can't do, but Python *can* do Regex.
> 
> Hence, implementation wise, Regex shouldn't be a "required step".

I used a regex for the letter-skipping stuff in the current :travel
implementation because this makes the code easy to understand and
to maintain.

I'm reluctant to use your custom Matcher class because I don't think
it's needed.  I get the point that regular expressions don't mix with
:travel or :find because adding characters to the search string may
increase the number of matches.  But so what?  I was happy with :find
for years and all it does is a substring check.  Letter skipping,
globbing and ^$ is nice, but do we really need more?  I doubt that.


> I can absolutely see a simplified pattern system working well,
> > especially if we *always* type it in on the fly. But what prevents me
> > from creating binds to often used patterns? I can see full blown
> > regexp being useful there.
> 
> 
> It sounds interesting. How would it work? You can't use shortcuts (other
> than tab) in a command, so it could only be done at launch.

A mode with regular expressions will be implemented either way, so
there's no need to discuss it. ;)


> I think the only two realistic options here are dmenu-style token
> > matching, and proper PCRE.

dmenu-style token matching is something like this, right?
1. Split search string at spaces into tokens
2. Match all entries that contain all the tokens as a substring

Maybe this is worth an extra option, or maybe this could be the default
algorithm?


On Mon, Feb 18, 2013 at 08:37:27PM +0000, Joshua Landau wrote:
> > 1. -a for automatic opening, as soon as there is only 1 match left
> >
> 
> I think there should be a separation between "automatic open" and
> "automatic directory traversal". I like the second of the two most of the
> time, the first some of the time.

What exactly do you mean?


> > 2. -e for automatic opening when the user presses enter
> >
> 
> Can't you just use ESC and have this always-on? It's mostly pointless to
> have -k without -e, like this.

I added this because :search is currently implemented like that.  When
you :search foo and press enter, it doesn't run foo.


> 1. ^ and $ are useful with -s and -g, even without proper Regex.
> 2. Do we need globbing really though?
> 
> I'd probably go:
> 
> -s for letter skipping
> -r for ^ and $ (and maybe * if not -s)
> -R for FULL REGEX (no letter skipping allowed)

To 1: It is safe to assume IMO that very few file names will have ^ and
$ in them, so I would just add the special keys ^ (at the start only)
and $ (at the end only) to every mode, no extra option needed.

To 2: I think globbing is a good compromise between simple substring
checking and regular expressions.  I'd probably use it for travel
instead of letter skipping which is a bit too aggressive for me.


------------------------------------

In any case, I'd like to thank you guys for discussing this thoroughly.
I certainly like where this is going :)

Roman