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

[Joshua Landau]

On 19 February 2013 00:27, Roman Z. <address@hidden> wrote:

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?

Something was weird on my end. I've no clue what, though.

 

> > 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...")

Apologies. I was quoting properly within GMail, and it had always seemed to send a properly-formatted plain-text version before. It seems it doesn't work if I'm copy-pasting rather than editing around the default quote.

I'll make a point to convert to plain-text manually when I'm doing so.

If this is formatted badly, I'll reconsider trusting GMail at all ;).

 

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.

In the context I was speaking, I think I was talking about :travel particularly. But yes, I see and accept your point. 

> > 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.

That's a fair choice. I don't disagree, really. It's just submitting a compiled Regex is no harder than submitting its ".search", and the second way makes it less hacky to support other filtering methods.

So:

self.fm.thisdir.temporary_filter = self.build_regex(self.rest(1))

would "change" to

self.fm.thisdir.temporary_filter = self.build_regex(self.rest(1)).search

I'm reluctant to use your custom Matcher class because I don't think
it's needed.

I don't blame you. Matcher wasn't made "for production", btw. It was made to show that there were genuinely useful* things that were hard to do with Regex.

I did make the original (pre-Matcher, without "^$") as "pre-production", made like it was because I don't think in Regex. I have no qualms if you prefer it in Regex.

 

* I like special characters in my file names, so I don't ever like not matching them by making them "special". But I do like special characters. By doing both, Matcher let me have my cake and eat it too.

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.

I was happy with :travel for years and it was exactly the same ;).

When letter skipping was suggested, I realised I prefered it.

When "^" and "$" were suggested (not really, 'cause I just copied you) I liked the tool but didn't like not matching those characters. Hence Matcher.

 

Letter skipping,
globbing and ^$ is nice, but do we really need more?  I doubt that.

 

If you mean more complex, you've already asked for plain Regex.

If you mean more choices, then yes. MOAR! Matcher's a class that pretends it's Regex although it's not to get around the implementation, and I think Matcher's useful even if just for me.

Do you want another non-trivial, but useful, example? In my Downloads folder, shows that I've watched are tagged. I might want a search that doesn't match tagged files if proceeded with "!" and recognises shorthand (so that "ts" might only match "This Show" and not "That Show"). That'd be useful for me, especially with -m.

When you first made Ranger it'd have been awful if you thought "we already have <list>, do we really need more?" and not made mods so easy. Same applies here.

 

> 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. ;)

Don't take me wrong, I was asking because I wanted to do this. It sounds cool and I want to know if he has a way to make it work :).

 

> 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?

Probably more as a glob replacement, I think. It's an order-ignoring glob using space.

So instead of:

"s*.png"

you'd do a slightly more lax

"s .png"

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?

"automatic_open":

self.fm.move(right=1)

"automatic directory traversal":

if is_a_directory:

    self.fm.move(right=1)

 

> > 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.

That makes sense, then.

 

> 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.

:)

I still rather both match+special (á la Matcher), but even I don't have many files that austerely named. So this seems good.

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.

Fair 'nuf. How about globbing vs dmenu-style? Would you use both?

 

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

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