@Roman Z
Good points why full-blown regular expressions don't make sense for
:travel. However, my current plans for 1.6 are conservative:
That makes sense, considering time scales.
For :travel, all characters except ^ and $, respectively at the start
or end, are escaped before they are shoved into the regex. This fixes
the crash that you described and ensures that additional letters always
reduce the number of matches.
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.
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?
Since these commands are all very similar, maybe it's a good thing to
add flags like in the :shell command. For example, ":find -kfs" would
be the same as :travel ("k" for "keep console open", "f" for filtering,
"s" for letter-skipping). :narrow could be implemented with
":find -fsA" (filtering, letter-skipping, *no* automatic opening), etc.
You could then mix your own commands with ":alias travel find -kfs".
That's a very nice idea, much like.
But I really want to get 1.6 out soon, and I don't want too much
experimental stuff in there.
@Miodrag Milic
OK, Joshua is probably right that RegEx is overkill.
*mischievous grin*
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
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 know it happened before on Total Commander forum (which does have lots of users so this issue popped up fast) and author of the plugin solved the problem with 3 modes as described. That is a fact and Joshuas observations are theoreticall.
Theoretical observations, eh?
Jokes aside, if there's a link to an archive of this discussion, I'd love to see it.
But as long as it works as described, I really think any solution will suffice.
@Michishige Kaito
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.
As an experienced programmer, I'm fairly
comfortable with regexp anyway, so at least the simpler ones I can see
myself typing in right at the prompt.
Again, you have the problem with :travel being automatic, so you'd want a non-automatic version for that. The -flags mode for :find would do this brilliantly, though.
(But why would you ever use even just [ab]? Surely if you know where you want to go, you wouldn't want to spend extra time adding ambiguity. If you'd use :travel for a different purpose which would benefit from it, what is it?)
I think the only two realistic options here are dmenu-style token
matching, and proper PCRE.
Using the directory.filter* hypothetical as above:
#Dmenu-style
directory.filter = lambda string: string.__in__
and
#Regex
directory.filter = lambda string: re.compile(string).search
would be those two modes. Hence there's no problem in a non-regex implementation.
The only time you need Regex is when you're using Regex. So why put Regex everywhere else?
PS: dmenu-style matching is actually more limited than what's currently here today (fuzzy with ^$).
-----------------------------------
I think you're all misunderstanding my initial dislike of Regex. I disliked it because you used Regex behind the scenes and you reaped none of the rewards of actually having Regex. Not because I hate Regex.
And then you kept suggesting "well, you need both Regex and letter skipping". That's basically impossible, so I said so. I feel you took this to mean "no Regex". I didn't mean that.
I'm also unconvinced that pure Regex is needed as a mode, but that's beside the point. I'm happy for it to be a mode, I just won't use it much. It's still beside the point.
-----------------------------------
* directory.filter(search)(target) -> bool deciding whether target should be kept in view