Re: etags: M-. jump to the tag(called func), but then how can i jump BACK(the calling line)?

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

[A complimentary Cc of this posting was sent to
Kevin Rodgers 
<ihs_4664@yahoo.com>], who wrote in article <mailman.6922.1126632664.20277.help-gnu-emacs@gnu.org>:
>  >>This is distinct from invoking M-. with a negative argument
>  >>since that pops a stack of markers at which tags were found, not from
>  >>where they were found.

> That last paragraph is part of pop-tag-mark's doc string.  To me it
> means that if at buffer/point A you move to tag X, then at buffer/point
> B you move to tag Y, then at buffer/point C you move to tag Z, then at
> buffer/point D:
> 
> M-- M-. will take you back to Z, Y, then X
> M-*     will take you back to C, B, then A

Thanks for a clear explanation.

>  > c) My experience with my code propagated back to Emacs is very
>  >    negative: a lot of times the resulting code has only subset of
>  >    the original functionality.  So I have no incentive to check how
>  >    well pop-tag-mark behaves...

> According to etc/NEWS, pop-tag-mark was introduced in Emacs 20.4, but I
> can't find any reference to imenu-go in the etc/*NEWS files.  Absent any
> evidence in the lisp/ChangeLog* files that pop-tag-mark was derived from
> your imenu-go, I think you have plenty of incentive to find out whether
> it meets your requirements (and thus obviates your complaint about a
> "gaping hole in the Emacs UI").

Let me repeat it more clear than I did it the last time: I see no
incentive for me to check this new feature for sanity:

 a) I already have code which does what users want,

 b) IMO, the probability that the Emacs code does WUW is not
    overwhelming;

 c) The code in "a" has many more features than what etags will ever
    have (per old discussions of me with RMS about merging imenu-go
    into etags).

Hope this helps,
Ilya