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

[Thomas Dickey]

On Sun, Mar 11, 2018 at 01:09:48PM +0100, j. van den hoff wrote:
> On Sun, 11 Mar 2018 01:41:54 +0100, Thomas Dickey <address@hidden> wrote:
> 
> >On Sat, Mar 10, 2018 at 11:09:29PM +0100, j. van den hoff wrote:
> >>On Fri, 09 Mar 2018 22:24:16 +0100, Thomas Dickey <address@hidden>
> >>wrote:
> >>
> >>>On Fri, Mar 09, 2018 at 05:37:24PM +0100, j. van den hoff wrote:
> >>>>I have a "tags" file of function definitions in the `R' language
> >>>>(https://www.r-project.org). function names can contain periods, so I
> >>>>have
> >>>>lines such as
> >>>>
> >>>>disp.array      fzrutils/R/disp.array.R /^disp.array <- function ($/;"
> >>>>f
> >>>>
> >>>>in the "tags" file. my `.vilerc' contains
> >>>>
> >>>>set tags {path_to_the_tags_file}
> >>>>set tagrelative
> >>>>
> >>>>`vi -t disp.array' does not work as expected but reacts the same way
> >>it
> >>>>does
> >>>>when a non-existent tag is specified (just reporting the read-in
> >>config
> >>>>files: "Reading ~/vile.rc" etc.). tags not containing a `.'  in the
> >>>>function
> >>>>name work just fine. `vim -t disp.array' does the expected even if the
> >>>>`.'
> >>>>is present in the name.
> >>>>
> >>>>Am I missing something or is this a bug?
> >>>
> >>>When doing ^]], vile's using a function checks only the character
> >>class,
> >>>and stops when a character isn't an "identifier":
> >>>
> >>>int
> >>>screen_to_ident(char *buf, size_t bufn)
> >>>{
> >>>    int rc = FALSE;
> >>>    CHARTYPE mask = vl_ident;
> >>>    int whole_line = adjust_chartype(&mask);
> >>>
> >>>    TRACE((T_CALLED "screen_to_ident\n"));
> >>>    rc = read_by_regex(buf, bufn, b_val_rexp(curbp,
> >>VAL_IDENTIFIER_EXPR),
> >>>whole_line);
> >>>    if (rc == FALSE)
> >>>   rc = read_by_ctype(buf, bufn, mask, whole_line);
> >>>    returnCode(rc);
> >>>}
> >>>
> >>>:show-printable shows that it's not (by default) an "id" character:
> >>>
> >>>45 -        -   -   -   -  -   prn pun -   -  path -   arg -  nsp -   tmp 
> >>>sh
> >>>46 .        -   -   -   -  -   prn pun -   -  path -   arg -  nsp -   tmp 
> >>>sh
> >>>47 /        -   -   -   -  -   prn pun -   -  path -   -   -  nsp -   tmp 
> >>>sh
> >>>48 0        -   -   num -  -   prn -   -   id path -   arg -  nsp qid tmp 
> >>>sh
> >>>49 1        -   -   num -  -   prn -   -   id path -   arg -  nsp qid tmp 
> >>>sh
> >>>
> >>>You could change that with
> >>>
> >>>   set-char-class id=[.]
> >>>45 -        -   -   -   -  -   prn pun -   -  path -   arg -  nsp -   tmp 
> >>>sh
> >>>46 .        -   -   -   -  -   prn pun -   id path -   arg -  nsp -   tmp 
> >>>sh
> >>>47 /        -   -   -   -  -   prn pun -   -  path -   -   -  nsp -   tmp 
> >>>sh
> >>>48 0        -   -   num -  -   prn -   -   id path -   arg -  nsp qid tmp 
> >>>sh
> >>>49 1        -   -   num -  -   prn -   -   id path -   arg -  nsp qid tmp 
> >>>sh
> >>
> >>thank you -- didn't know of the `show-printable' command... anyhow, your
> >>suggested solution does not work for me: I put the
> >>
> >>   set-char-class id=[.]
> >>
> >>into my .vilerc but nothing has changed. `vi -t disp.array' (in my
> >>example)
> >>does still not work.
> >
> >ah... I was answering the scenario that I used for a quick test.
> >
> >The short answer is that there's more than one case used for tags.
> >
> >From the command-line, the -t option adds the value as part of a startup
> >script:
> >
> >                 add_cmdarg(opts_bp, "tag %s\n", GetArgVal(param));
> >so you should get the same result using
> >     :tag disp.array
> 
> ok... but that's exactly what is _not_ happening here... from within the
> editor and when using `:tag disp.array' vile correctly recognizes the tag
> just fine and opens the corresponding file. only when doing `vile -t
> disp.array' (apology for stating previously that I issued `vi -t disp.array'
> -- I admit that I've aliased `vile' to `vi' ;)) vile chokes...
> 
> >
> >Reading from the screen is different.
> 
> you mean when using `^]' or also with `:tag'?

The former: vile has "always" handled `^]' by calling a function which
reads data directly from the screen rather than on the colon-line with `:tag'

> 
> >
> >From a command-line (or script), the code's not limited by the character
> >class exactly - it's ended with whitespace, newline, etc.  It accepts
> >a tab for name-completion of course.
> 
> for me, `:tag disp.array' recognizes the tag but TAB completion on this name
> does not work (due to the `.' it seems). TAB completion only works for names
> w/o the `.'.
> 
> >
> >But I'm puzzled because a few cases that I set up for answering the mail
> >worked for me, e.g.,
> >
> >PACKAGES.arch        package/debian/rules    /^PACKAGES.arch  = vile 
> >vile-filters
> >xvile$/;"    m
> >
> >and now, using your example (and a suitable file for the target of
> >course):
> >
> >disp.array   fzrutils/R/disp.array.R /^disp.array <- function ($/;"  f
> 
> you mean, that example works for you, too?

yes - I made a file with this content -- indented here for clarity
(the extra lines were to verify that it didn't simply read the file):

        #
        #
        disp.array <- function (
        )

> 
> >
> >Perhaps there's something related to your locale settings.  I'm using
> >en_US.UTF-8, and recall that "." is treated differently in the European
> >locales.  But a quick test with de_DE.UTF-8 gives me consistent results.
> 
> in fact, I usually (and right now) use en_US.UTF-8...

There might be something in your ".vilerc" which I'd not considered.

> >>what I _have_ learned in the meantime: when being already in the editor
> >>`:ta
> >>disp.array' works just fine (w/ or w/o the `set-char-class id=[.]' in
> >>`.vilerc'). this is good and suffices as a working solution but I would
> >>of
> >>course be grateful for any further hint how to make `vi -t' work for
> >>`foo.bar' type names.
> >>
> >>another observation: when using `:ta {tagname}' from within `vile', TAB
> >>completion of tagname works, but only for tagnames _not_ containing a
> >>`.'
> >>(again, independent of whether `set-char-class id=[.]' has been issued
> >>or
> >>not).
> >>
> >>>
> >>>>seen with vile version 9.8o for darwin14.3.0.
> >>>>
> >>>>thank you
> >>>>
> >>>>joerg
> >>>>
> >>>>PS: I also presume, there is a small `ctags' bug here. the search
> >>>>pattern
> >>>>probably should backslash-protect the period in order to actually only
> >>>>match
> >>>>`disp.array' verbatim rather than
> >>>>disp{any-single-character}array, no? otherwise one might jump to the
> >>>>wrong
> >>>>tag/file/position.
> >>>
> >>>hmm - I think it's correct, since "magic" is normally set.
> >>
> >>ah., I see. maybe it's time to spend some time with the (really good)
> >>vile
> >>help file again: I was not aware of the 'magic' feature of vi and vile
> >>at
> >>all. sorry for the noise...
> >
> >no problem - actually reading the mail, I made a note to verify whether
> >vile's doing the right thing
> 
> I've played around with this in the meantime and, yes, it seems `vile' does
> what you explained (when using `:tag' I can jump to `foo.bar' and adding a
> further line to the tags file with name `fooabar' before `foo.bar' does not
> confuse the lookup of `foo.bar').
> 
> so to summarize what I still see here:
> 
> * using vile version 9.8s for darwin15.6.0
> 
> * "en_US.UTF-8" locale
> 
> * tags file contains entries of the form `disp.array
> fzrutils/R/disp.array.R /^disp.array <- function ($/;"  f'
> 
> * `vile -t disp.array' does not work from the command line (other tags
> (incidentally there is a `disp' tag as well, e.g.) do work)
>    - `vim -t disp.array', OTOH, works
> 
> * from within vile:
> 
>    - `:tag disp.array' does work
> 
>    - TAB completion on such tag names do _not_ work (TAB completion on tag
> names w/o `.' works fine)
> 
> * the `.' is not really that special: the problem is the same when replacing
> the dot by several other punctuation characters (although those will hardly
> ever be really part of an identifier, I presume...)
> 
> if there is anything else I can try to make it (vi -t foo.bar) work please
> let me know. although I am of course afraid that my locale setup is somehow
> the culprit. but I don't see anything obviously pathological about it ...

If you're able to compile vile, then its debug-trace can be helpful.
In a quick check just now, I did that, e.g.,

        ./configure --with-trace --with-builtin-filters && make

and made an empty ".vilerc" (to keep the trace small), then

        ./vile -t disp.array

went to the file as expected.  That created a trace file "Trace.out",
which I'll attach, as an example.

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

Trace.out
Description: Text document

signature.asc
Description: Digital signature