136290Re: trouble with pattern, character collections
- Feb 20, 2013On 20.02.13 13:32, Bram Moolenaar wrote:
> Christian Brabandt wrote:Bram, is that meant to be "There are NL characters which are stored as
> > Bram, here is a patch, making [^\n] not match NL within the text and
> > that also documents, that '.' matches CR and LF within the text.
> > This makes both  and  behave the same and seems to better match
> > the users expectations.
> This isn't right, there are no NL characters in the text. There are NUL
> characters which are stored as NL characters.
NUL characters"? Because if "there are no NL characters in the text",
then nothing can be stored as them, can it?
> That's an implementation detail, which sometimes becomes visible toOK, but the actual problem is corruption of a regex syntax snippet in
> the user.
one quoting context. Letting "[^\n]" not be the same as '[^\n]' is the
mark of a broken regex implementation. Other regex engines manage \n
without their syntax breaking, so it is possible with Vim too.
Vim has '.' to represent "any character", and so does not require a
second representation for that. But if [^\n] is the same as '.', because
there are no newlines present, then that must _always_ be the case,
regardless of a bit of quoting flim-flam.
> It's good to explain this in the docs.Yes, knowing that there are no newlines can help us avoid looking for
Another fix is needed, though, for the problem that quote flavour is
allowed to corrupt the regex in one case, causing behaviour contrary to
the quoted regex syntax. That is an illogicality boobytrap to torment
> I'm not sure we actually should change the behavior, it might notExcuse me, Bram but removing the broken behaviour of "[^\n]" not being
> really take away much confusion.
the same as '[^\n]' does remove a mind boggling logical nonsense, and so
does do away with major confusion.
Deep knowledge if Vim internals is an asset when it fosters effective
and robust fixes, but tends toward a liability if it blinds one to the
failings of a self-contradicting user interface, I think.
In all that we construct, it is _what_ should happen which guides _how_
it is made to happen. Arguments defending the current broken status
repeatedly refer to _how_ usurping _what_, as an implementational
side effect, and accepting that as a justification. That is not
intelligent design, and has here led to impaired functionality.
Vim's supremacy would be improved by removing the user interface
You have all eternity to be cautious in when you're dead.
- Lois Platford
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
For more options, visit https://groups.google.com/groups/opt_out.
- << Previous post in topic