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

[j. van den hoff]

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 ;)

> 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'...

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

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)
...

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)?

thanks again,
joerg


>


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