On Sun, Mar 11, 2018 at 09:38:09PM +0100, j. van den hoff wrote:
On Sun, 11 Mar 2018 18:40:26 +0100, Thomas Dickey <address@hidden>
wrote:
>
>no problem - I see what's going on now. The reason it's been working
for
>me was that (I'd forgotten of course) one of my fixes from last year
of course. good to see that I am not the only one forgetting about
stuff ;)
I have to use to-do lists to remind me what I'm working on.
wc -l says this:
10649 /users/tom/NOTES/ncurses
10705 /users/tom/NOTES/other
6543 /users/tom/NOTES/xterm
27897 total
>allows
>dots in the names.
>
> 20170820 (t)
> > Tom Dickey:
> + modify character class assumed for tags, to check for graphic
> characters. Previously that used qident (cf: 9.7g), which did not
> allow for dots in filenames which could be present in a ctags file
if
> it were generated using "ctags --extra=+f *" (Savannah #51774).
>
>The actual change is small:
>
>REV:1.150 tags.c 2017/08/20 23:08:32
tom
>tags: v9_8s6
>
> allow tags (read from a tags file) to be any graphic character. It
>turns out
> that Hiebert's ctags can point to filenames vs identifiers.
>
>--- tags.c 2013/09/20 23:00:36 1.149
>+++ tags.c 2017/08/20 23:08:32 1.150
>@@ -212,7 +212,7 @@
> return; /* ignore super-long identifiers */
> }
> c = lgetc(lp, got);
>- if (!isqident(c))
>+ if (!isGraph(c))
> break;
> my_name[got] = (char) c;
> }
>
indeed... with this patch it is working perfectly. really thanks a lot!
regarding your changelog comment: in fact it (the appearance of `.' or
whatever in the tagnames) can also occur more generally -- as in my
case --
if one uses ctags `--regex' for handling of some language unknown to
ctagss
- such as `R'...
yes - I suppose I should make the command-line and screen-mode tags
closer together. The screen-mode function is shared with the search
command, which may not be the right thing.
>I've been working on lynx for the past few weeks,
>thinking to get vile up to date after that's done.
that would be great. as far as I am concerned `vile' remains by far the
most
likeable `vi' look-alike around. --
sounds good. I was working on lynx and vile last year to update the
Windows port (for 64-bit support), but got distracted with a pile of
work in ncurses/xterm. That's stable, but I got behind somewhat on
the other large programs.
FYI, I've just noted that at the end of the `make' run the output reads
...
make[1]: `libvlflt.a' is up to date.
mv vile ovile
mv: rename vile to ovile: No such file or directory
make: [vile] Error 1 (ignored)
...
that's a detail that was leftover from Paul Fox's makefile, that
I never thought important enough to change. I could fix that...