Re: find-tag and partial completion mode -- Francisco, urgent!

Re: find-tag and partial completion mode -- Francisco, urgent!

[A Soare]

> Francisco, what do you think of this issue?
> 
> 
>     in TAGS there is a line 
> 
>     ../lwlib//TAGS,include
> 
>     and from here the error was born.
> 
> Please try changing that line to
> 
>     ../lwlib/TAGS,include
> 
> Does that make it work?

It does not.

I repeat.

I use a LINK to TAGS file from src/TAGS.

More precisely, look ls -al in ./emacs directory

lrwxrwxrwx  1 root root      8 2007-04-18 05:56 TAGS -> src/TAGS
lrwxrwxrwx  1 root root     13 2007-04-18 05:56 TAGS-LISP -> src/TAGS-LISP

I do so:

M-. re-fr-st <TAB> insert here the path to TAGS file FROM EMACS DIRECTORY, NOT FROM ./EMACS/SRC.

In this case it does not work.

If I complete the path to the TAGS file from ./emacs/src/TAGS , it works.

So the only problem is that etags does not work if we work to a sym-link to the TAGS file. We must use the path to the original TAGS file. This is the but. This is the same bug as that one reported by me here:

<<lwlib>>.


http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg01293.html

Re: find-tag and partial completion mode -- Francisco, urgent!

[Stefan Monnier]

> I use a LINK to TAGS file from src/TAGS.

And that's the bug.  If it hurts, why do it?


        Stefan

Re: find-tag and partial completion mode -- Francisco, urgent!

[Francesco Potorti`]

>So the only problem is that etags does not work if we work to a
>sym-link to the TAGS file. We must use the path to the original TAGS
>file.

The problem is that the TAGS file is built using relative file names
(the usual way to do it), like this:
 etags *.[ch]

Consequently, if you make a link to TAGS from a different dir, the
relative names break.

Solutions have been mentioned:
- create one more TAGS file in your preferred dir and include the
  src/TAGS file with option -i
- create a TAGS file using absolute file names

However, in principle one could change etags.el so that, when the TAGS
file is in fact a symbolic link, it resolves relative file names with
respect to the base directory of the file, rather than the link.  I am
not sure that this is in fact a good idea but, if it is, it should be
eay to implement.

So: either we implement the change to etags.el that I suggest above, or
else I can add a couple of lines in the manual such as:

 Notice that, in the usual case of using relative file names, you should
 not use a symbolic link to a tags file in a different directory.

Re: find-tag and partial completion mode -- Francisco, urgent!

[Stefan Monnier]

> So: either we implement the change to etags.el that I suggest above, or
> else I can add a couple of lines in the manual such as:

>  Notice that, in the usual case of using relative file names, you should
>  not use a symbolic link to a tags file in a different directory.

That seems like the better option.  After all, it's very unusual to make
such symlinks to TAGS files, and it's not clear exactly what is the
motivation for such a thing: depending on the motivation the current
behavior can be wrong or right, and if we change it as you suggest, it will
still be sometimes right and sometimes wrong.  Better keep things dumber, so
it's easier for the user to predict.


        Stefan

Re: find-tag and partial completion mode -- Francisco, urgent!

[Richard Stallman]

    However, in principle one could change etags.el so that, when the TAGS
    file is in fact a symbolic link, it resolves relative file names with
    respect to the base directory of the file, rather than the link.  I am
    not sure that this is in fact a good idea but, if it is, it should be
    eay to implement.

    So: either we implement the change to etags.el that I suggest above, or
    else I can add a couple of lines in the manual such as:

     Notice that, in the usual case of using relative file names, you should
     not use a symbolic link to a tags file in a different directory.

Please update the manual.  I am not sure which behavior is better,
and if it isn't clear, we may as well leave it unchanged.

Re: find-tag and partial completion mode -- Francisco, urgent!

[Francesco Potorti`]

>Please update the manual.  I am not sure which behavior is better,
>and if it isn't clear, we may as well leave it unchanged.

Done.  I added this to maintaining.texi:

================================================================
  Notice that, in the usual case of using relative file names, you
should not use a symbolic link pointing to a tags file in a different
directory, because this would generally render the file names invalid.

Re: find-tag and partial completion mode -- Francisco, urgent!

[A Soare]

> 
> > I use a LINK to TAGS file from src/TAGS.
> 
> And that's the bug.  If it hurts, why do it?
> 

Now I do not use any more a soft link.

Re: find-tag and partial completion mode -- Francisco, urgent!

[A Soare]

> >     in TAGS there is a line 
> >
> >     ../lwlib//TAGS,include
> >
> >     and from here the error was born.
> 
> The "issue" is just that if you have a file which contains a line
> like:
> 
>   include ../foo
> 
> and you access the file through a symlink from a different directory,
> then ../foo (probably) does not exist.

You did understand. That's it.


> 
> The solution is just to not access the TAGS file through a symlink
> (something which there is no need to do). Or put the absolute path in
> the TAGS file (which is then fragile if you want to move the sources
> somewhere else). That means changing the TAGS target in src/Makefile
> to specify an absolute path to lwlib rather than a relative one. No
> point, IMO.
> 
> For some reason, this has turned back into Alin's previous "lwlib"
> thread, but now disguised as a partial-completion issue.
> 

Yes, today's find-tags bug is due to the fact that in case of error the TAGS file is not used at all.

Re: find-tag and partial completion mode -- Francisco, urgent!

[A Soare]

> >>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:
> 
> >> in TAGS there is a line 
> >> ../lwlib//TAGS,include
> >> and from here the error was born.
> 
> GM> The "issue" is just that if you have a file which contains a line
> GM> like:
> GM>   include ../foo
> GM> and you access the file through a symlink from a different directory,
> GM> then ../foo (probably) does not exist.

That is. True.

> 
> GM> The solution is just to not access the TAGS file through a symlink
> GM> (something which there is no need to do).

Or to write in TAGS file the complete path, not a relative path.

> 
> The original poster's problem can be solved by using the etags -i
> feature instead of making a symlink.  I.e., rather than:
> 
>     ln -s src/TAGS TAGS
> 
> use
> 
>     etags -i src/TAGS
> 

ok.

Re: find-tag and partial completion mode

[A Soare]

> A Soare wrote:
> 
> > 1. Emacs -Q
> >
> > 2. M-x partial-completion-mode
> >
> > 3. M-. re-fr-st <M-TAB> Insert the path to your TAGS of emacs. <RET>
> >
> > No symbol found. However there is read-from-string.
> 
> Press TAB, not M-TAB.
> 
> 

That is. I solved it. I have emacs installed in /gnu/emacs/ and I used a soft link from /gnu/emacs/src/TAGS to /gnu/emacs/TAGS.

in TAGS there is a line 

../lwlib//TAGS,include

and from here the error was born.


Now it is clear.

So in the actual form if we can try to use a soft-ling to the TAGS files, tags do not work any longer.


Alin Soare.

Re: find-tag and partial completion mode -- Francisco, urgent!

[Richard Stallman]

Francisco, what do you think of this issue?


    in TAGS there is a line 

    ../lwlib//TAGS,include

    and from here the error was born.

Please try changing that line to

    ../lwlib/TAGS,include

Does that make it work?

Remember that in Emacs // has a special meaning.
Perhaps etags.el should remove the duplicate / to prevent
that Emacs meaning from being applied.

Re: find-tag and partial completion mode -- Francisco, urgent!

[Glenn Morris]

>     in TAGS there is a line 
>
>     ../lwlib//TAGS,include
>
>     and from here the error was born.

The "issue" is just that if you have a file which contains a line
like:

  include ../foo

and you access the file through a symlink from a different directory,
then ../foo (probably) does not exist.

The solution is just to not access the TAGS file through a symlink
(something which there is no need to do). Or put the absolute path in
the TAGS file (which is then fragile if you want to move the sources
somewhere else). That means changing the TAGS target in src/Makefile
to specify an absolute path to lwlib rather than a relative one. No
point, IMO.

For some reason, this has turned back into Alin's previous "lwlib"
thread, but now disguised as a partial-completion issue.

Re: find-tag and partial completion mode -- Francisco, urgent!

[Tom Tromey]

>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:

>> in TAGS there is a line 
>> ../lwlib//TAGS,include
>> and from here the error was born.

GM> The "issue" is just that if you have a file which contains a line
GM> like:
GM>   include ../foo
GM> and you access the file through a symlink from a different directory,
GM> then ../foo (probably) does not exist.

GM> The solution is just to not access the TAGS file through a symlink
GM> (something which there is no need to do).

The original poster's problem can be solved by using the etags -i
feature instead of making a symlink.  I.e., rather than:

    ln -s src/TAGS TAGS

use

    etags -i src/TAGS

Tom