Re: [vile] vile does not understand certain entries in "tags" files generated by `ctags'.

[Thomas Dickey]

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...
 
> it seems the Makefile tries to mv a previously build binary to the side, but
> after a preceding `make clean' it simply isn't there? this sure is innocuous
> but should the warning not better be silenced (or tested for existence of
> `vile' before trying to mv it)?

I could do "mv -f" (which may quiet things).
That wasn't standard 20 years ago :-)

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: Digital signature