Xref oddness

Xref oddness

[Patrick Mahan]

We have just recently upgraded some of our development machines to Ubuntu
18.04 which includes emacs 25.2 (we were on Ubuntu 16.04 and emacs 24.5).
I notice that emacs 25 brings with it changes to TAGS handling that have
been moved under Xref.  But I am now seeing some odd behavior

Our sysadmins have setup where our home directories and development
directories are on multiple drives but are all symlinked through the same
top-level directory.  For example, my actual home directory is on
/home2/patrick but it is access via /home/patrick (patrick under /home is
sym-linked to /home2/patrick).  The same occurs for our development
directories (/development/patrick is sym-linked to /development5/patrick).
Now since our development directories are setup as multiple directories, I
was using the following  method for finding TAGS files -

(setq tags-table-list (list "./" "../"
                                (concat (getenv "WORK") "/src/lib")
                                (concat (getenv "WORK") "/src/bin")
                                (concat (getenv "WORK") "/src/include")
                                (concat (getenv "WORK") "/src")))

WORK is defined as the top of my current development sandbox and changes as
I jump between sandboxes.

This worked great in 24.5, but now in 25.2 I am seeing multiple definitions
everytime I try to find a tag (M-.) (which is 'xref-find-definitions').
One for '/development5/..." and one for "/development/...".

Now that documentation mentions something about 'xref-etags-mode' as a
minor mode, but I cannot seem to invoke that mode in emacs.  Is there a way
to fix this in Xref? Or should I just go back to redefining those keys to
the old 'find-tag' et.al.?

Thanks,

Patrick

Re: Xref oddness

[Eli Zaretskii]

> From: Patrick Mahan <plmahan@gmail.com>
> Date: Wed, 29 Apr 2020 12:00:27 -0700
> 
> Our sysadmins have setup where our home directories and development
> directories are on multiple drives but are all symlinked through the same
> top-level directory.  For example, my actual home directory is on
> /home2/patrick but it is access via /home/patrick (patrick under /home is
> sym-linked to /home2/patrick).  The same occurs for our development
> directories (/development/patrick is sym-linked to /development5/patrick).
> Now since our development directories are setup as multiple directories, I
> was using the following  method for finding TAGS files -
> 
> (setq tags-table-list (list "./" "../"
>                                 (concat (getenv "WORK") "/src/lib")
>                                 (concat (getenv "WORK") "/src/bin")
>                                 (concat (getenv "WORK") "/src/include")
>                                 (concat (getenv "WORK") "/src")))
> 
> WORK is defined as the top of my current development sandbox and changes as
> I jump between sandboxes.

I don't think I understand how the symlinks come into play here.
Could you please tell more?  How do you get from $WORK to
/home/patrick and /home2/patrick? or maybe its /development/patrick
and /development5/patrick?  I'm confused.

> Or should I just go back to redefining those keys to the old
> 'find-tag' et.al.?

Not recommended: you'll be fighting an uphill battle.  Perhaps there's
a bug, or there's a way to configure your Emacs a bit differently.

Re: Xref oddness

[Patrick Mahan]

On Wed, Apr 29, 2020 at 12:21 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Patrick Mahan <plmahan@gmail.com>
> > Date: Wed, 29 Apr 2020 12:00:27 -0700
> >
> > Our sysadmins have setup where our home directories and development
> > directories are on multiple drives but are all symlinked through the same
> > top-level directory.  For example, my actual home directory is on
> > /home2/patrick but it is access via /home/patrick (patrick under /home is
> > sym-linked to /home2/patrick).  The same occurs for our development
> > directories (/development/patrick is sym-linked to
> /development5/patrick).
> > Now since our development directories are setup as multiple directories,
> I
> > was using the following  method for finding TAGS files -
> >
> > (setq tags-table-list (list "./" "../"
> >                                 (concat (getenv "WORK") "/src/lib")
> >                                 (concat (getenv "WORK") "/src/bin")
> >                                 (concat (getenv "WORK") "/src/include")
> >                                 (concat (getenv "WORK") "/src")))
> >
> > WORK is defined as the top of my current development sandbox and changes
> as
> > I jump between sandboxes.
>
> I don't think I understand how the symlinks come into play here.
> Could you please tell more?  How do you get from $WORK to
> /home/patrick and /home2/patrick? or maybe its /development/patrick
> and /development5/patrick?  I'm confused.
>
>
I use the sym-linked name.  For example I would 'cd /home/temp' instead of
'/home2/temp'.  WORK is defined to '/development/patrick/current' or
'/development/patrick/release5'.  It is never defined to
'/development5/patrick/...'.

I have commands to switch between different development sandboxes (and
redefine WORK).

I realized I forgot to describe the problem I am seeing.  If I am editing a
file in a sandbox, for example, emacs $WORK/src/bin/app1/main.c, then need
to find a tag (M-.) under 25.2 it always gives me two choices, both are
same, except one shows the sym-linked directory and the other shows the
realpath directory.  Forcing me to have to chose.  This is rather annoying,
especially if I do a (M-4 .) for finding a tag in another window or (M-5 .)
for finding a tag in another frame.  It gives me the list of choices, but
then takes over the original buffer.

If I use the original 'find-tag' command in 25.2 it works as it does under
24.5.


> > Or should I just go back to redefining those keys to the old
> > 'find-tag' et.al.?
>
> Not recommended: you'll be fighting an uphill battle.  Perhaps there's
> a bug, or there's a way to configure your Emacs a bit differently.
>
> Not something I would like to do as my .emacs is complicate enough with
all the platforms I work upon.

I hope that is clearer,

Thanks,

Patrick

Re: Xref oddness

[Eli Zaretskii]

> From: Patrick Mahan <plmahan@gmail.com>
> Date: Wed, 29 Apr 2020 12:32:30 -0700
> Cc: help-gnu-emacs@gnu.org
> 
> I realized I forgot to describe the problem I am seeing.  If I am editing a file in a sandbox, for example, emacs
> $WORK/src/bin/app1/main.c, then need to find a tag (M-.) under 25.2 it always gives me two choices, both
> are same, except one shows the sym-linked directory and the other shows the realpath directory.  Forcing
> me to have to chose.

What do you see in the TAGS file in this case?  Are there 2 entries
there for each function/variable, one for the real directory and
another for the symlink, or is there only one entry?

Re: Xref oddness

[Patrick Mahan]

On Sat, May 2, 2020 at 2:39 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Patrick Mahan <plmahan@gmail.com>
> > Date: Wed, 29 Apr 2020 12:32:30 -0700
> > Cc: help-gnu-emacs@gnu.org
> >
> > I realized I forgot to describe the problem I am seeing.  If I am
> editing a file in a sandbox, for example, emacs
> > $WORK/src/bin/app1/main.c, then need to find a tag (M-.) under 25.2 it
> always gives me two choices, both
> > are same, except one shows the sym-linked directory and the other shows
> the realpath directory.  Forcing
> > me to have to chose.
>
> What do you see in the TAGS file in this case?  Are there 2 entries
> there for each function/variable, one for the real directory and
> another for the symlink, or is there only one entry?
>
>
Sorry, IRL is intruding here.

In all TAGS files I only see 1 entry for the tag and the file is shown as
/home/pmahan/... not /home2/pmahan.

But again, when I attempt to xref-find-tag-other-window, it is giving me
two options to choose from and then it bounces back to the original window
and displays the output there instead of just using the new window (or
creating a new window).  This is becoming annoying because it is breaking
finding a tag that exists inside the current source file.

If I override these settings back to the original 'find-tag' and
'find-tag-other-window' it works as expected.

Patrick

Re: Xref oddness

[Eli Zaretskii]

> From: Patrick Mahan <plmahan@gmail.com>
> Date: Wed, 6 May 2020 16:17:37 -0700
> Cc: help-gnu-emacs@gnu.org
> 
> Sorry, IRL is intruding here.

Here as well.

> In all TAGS files I only see 1 entry for the tag and the file is shown as /home/pmahan/... not /home2/pmahan.
> 
> But again, when I attempt to xref-find-tag-other-window, it is giving me two options to choose from and then
> it bounces back to the original window and displays the output there instead of just using the new window (or
> creating a new window).  This is becoming annoying because it is breaking finding a tag that exists inside the
> current source file.

I looked at the relevant code, and couldn't spot where we could make
two tags out of just one due to your use of symlinks.  So I suspect
there's some other factor at work here.  I therefore suggest that you
submit a bug report, using "M-x report-emacs-bug RET", with all the
details, and preferably also a small test case that could be used to
reproduce the problem.  Then we could use those details to debug this
more thoroughly.

Thanks.

Re: Xref oddness

[Patrick Mahan]

On Tue, May 19, 2020 at 8:37 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Patrick Mahan <plmahan@gmail.com>
> > Date: Wed, 6 May 2020 16:17:37 -0700
> > Cc: help-gnu-emacs@gnu.org
> >
> > Sorry, IRL is intruding here.
>
> Here as well.
>
> > In all TAGS files I only see 1 entry for the tag and the file is shown
> as /home/pmahan/... not /home2/pmahan.
> >
> > But again, when I attempt to xref-find-tag-other-window, it is giving me
> two options to choose from and then
> > it bounces back to the original window and displays the output there
> instead of just using the new window (or
> > creating a new window).  This is becoming annoying because it is
> breaking finding a tag that exists inside the
> > current source file.
>
> I looked at the relevant code, and couldn't spot where we could make
> two tags out of just one due to your use of symlinks.  So I suspect
> there's some other factor at work here.  I therefore suggest that you
> submit a bug report, using "M-x report-emacs-bug RET", with all the
> details, and preferably also a small test case that could be used to
> reproduce the problem.  Then we could use those details to debug this
> more thoroughly.
>
>
Thanks, I will do so.  Though I believe the hint is due to the symlinked
directory.  Is there anything doing something similar to 'readlink'?

Thanks,

Patrick

Re: Xref oddness

[Eli Zaretskii]

> From: Patrick Mahan <plmahan@gmail.com>
> Date: Tue, 19 May 2020 12:14:14 -0700
> Cc: help-gnu-emacs@gnu.org
> 
> Thanks, I will do so.  Though I believe the hint is due to the symlinked directory.  Is there anything doing
> something similar to 'readlink'?

I didn't find it while reading the relevant code, so I probably missed
something.