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 <dic...@his.com> 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 <dic...@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net
signature.asc
Description: Digital signature
_______________________________________________ vile mailing list vile@nongnu.org https://lists.nongnu.org/mailman/listinfo/vile
