Re: trouble with pattern, character collections

On 20.02.13 13:32, Bram Moolenaar wrote:
> Christian Brabandt wrote:
> > 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 [1] and [2] 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.

Bram, is that meant to be "There are NL characters which are stored as
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 to
> the user.

OK, but the actual problem is corruption of a regex syntax snippet in
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
them.

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

> I'm not sure we actually should change the behavior, it might not
> really take away much confusion.

Excuse me, Bram but removing the broken behaviour of "[^\n]" not being
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
deficiency.

Erik

--
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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.