vile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vile] ANN: vile-9.8s


From: j. van den hoff
Subject: Re: [vile] ANN: vile-9.8s
Date: Sun, 18 Dec 2016 15:37:57 +0100
User-agent: Opera Mail/12.12 (MacIntel)

thanks for explaining. I understand it's not easy, too :-). just out of curiosity;

* why does it not happen with `[1A', too? because it thinks it's a hex number?

* the problem with `proc 1g {return bla}' (showing the proc name as a reserved word) is still a slightly different problem I guess? I concede it's a stupid procedure name but tcl simply allows next to everything (at least a lot) here ;-).

in any case it sure is not a big deal ...

On Sun, 18 Dec 2016 15:23:40 +0100, Thomas Dickey <address@hidden> wrote:

On Sun, Dec 18, 2016 at 01:20:26PM +0100, j. van den hoff wrote:
thanks a lot for the new version. regarding the (k)sh syntax filter
I can confirm that the reported problems are gone.

:-)

while testing a bit further I noted that there persists (a so far
seemingly unreported) minor glitch in the tcl syntax filter, it
seems:

I see strange spurious highlighting by reverse video in constructs like

[1G

(the `1G' shows up in reverse video (red in my case))

strangely this happens ony if _not_ in line one. even more strangely
it does also not happen in, e.g.,

[1A

I have encountered the problem when defining constants containing
escape sequences, e.g. like

set gobol  {^[[1G}

yes...  tcl is harder to parse reliably than it looks, since its
designers chose to use curly-braces to mean (from the user's point of
view) different things.  That makes it hard to parse with a lex-based
filter, since matching curly-braces has to be recursive - something
that lex can only approximate with a stack of different states.

For this chunk, my filter tries to see that as a regular expression
because of the "^", and then sees the doubled "[" and decides it can't
be that because the closing curly brace (and end of line) comes before
it finds a valid regex.  So it treats the "[" characters specially,
and falls into the "1G" not being a number.

Rather than showing it as an error, I could modify that to just
treat it as a literal (but the downside is that if it were meant
to be a regex, then it would have been an error).

I _could_ rewrite that in C (as I did for perl and ruby) and get
proper recursion...

to move cursor to beginning of line (^[ denoting escape (octal
033)). you can also see the problem with this silly example:

proc 1G {return bla}
puts [1G]

This case is a little different, but again, the leading "1" makes it
think that should be a number, but the "G" tells it that it's not.

note that the reverse video might only appear after deleting and
reinserting the line containing the `[1G' construct.
as an aside: in this example the proc name is furthermore
highlighted as a reserved word (like proc). maybe both problems are
related?

thanks for `vile'

joerg

On Sun, 18 Dec 2016 03:15:10 +0100, Thomas Dickey <address@hidden> wrote:



--
Using Opera's revolutionary email client: http://www.opera.com/mail/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]