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

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

[zhengfish]

Hi, I'm a newbie for emacs+etags.
when i read source in emacs with etags: M-. jump to the tag(called
func), but then how can i jump BACK to the where the calling line?

THX

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

[Ian Zimmerman]

zhengfish> Hi, I'm a newbie for emacs+etags.  when i read source in
zhengfish> emacs with etags: M-. jump to the tag(called func), but then
zhengfish> how can i jump BACK to the where the calling line?

I don't think there is one way that always works.  You have to notice if
jumping to the tag you switched to a different buffer or not.  If yes,
just switch to the original buffer with C-x b.  If not, use the fact
that Emacs leaves a mark at the original spot, and do pop-mark (C-u
C-SPC).

-- 
Optimist: We're only two weeks behind schedule.
Pessimist: The schedule is a whole two weeks ahead of us.

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

[Peter Lee]

>>>> zhengfish  writes:

    zhengfish> when i read source in emacs with etags: M-. jump to the tag(called
    zhengfish> func), but then how can i jump BACK to the where the calling line?

M-* works for me.

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

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
zhengfish
<zhengfish@gmail.com>], who wrote in article <1126436508.461480.28080@z14g2000cwz.googlegroups.com>:
> Hi, I'm a newbie for emacs+etags.
> when i read source in emacs with etags: M-. jump to the tag(called
> func), but then how can i jump BACK to the where the calling line?

This is a gaping hole in the Emacs UI.  I wrote a package,
imenu-go.el, which behaves "as expected".

Let me know if you can't find it on the net.

Ilya

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

[David Kastrup]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> [A complimentary Cc of this posting was sent to
> zhengfish
> <zhengfish@gmail.com>], who wrote in article <1126436508.461480.28080@z14g2000cwz.googlegroups.com>:
>> Hi, I'm a newbie for emacs+etags.

>> when i read source in emacs with etags: M-. jump to the tag(called
>> func), but then how can i jump BACK to the where the calling line?
>
> This is a gaping hole in the Emacs UI.  I wrote a package,
> imenu-go.el, which behaves "as expected".

Hardly.

M-* runs the command pop-tag-mark
   which is an interactive compiled Lisp function in `etags'.
It is bound to M-*.
(pop-tag-mark)

Pop back to where M-. was last invoked.

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.

[back]


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
David Kastrup 
<dak@gnu.org>], who wrote in article <85d5nfe3oy.fsf@lola.goethe.zz>:
> > This is a gaping hole in the Emacs UI.  I wrote a package,
> > imenu-go.el, which behaves "as expected".
> 
> Hardly.
> 
> M-* runs the command pop-tag-mark
>    which is an interactive compiled Lisp function in `etags'.
> It is bound to M-*.
> (pop-tag-mark)
> 
> Pop back to where M-. was last invoked.
> 
> 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.

a) Can't parse your last paragraph;

b) I vaguely remember indeed somebody wanting to propagate the code
   from imenu-go back into etags; it may be that pop-tag-mark has the
   functionality of imenu-go (at least when imenu-go works with tags;
   it can get info where-to-jump from other sources too).

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

Hope this helps,
Ilya

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

[David Kastrup]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> [A complimentary Cc of this posting was sent to
> David Kastrup 
> <dak@gnu.org>], who wrote in article <85d5nfe3oy.fsf@lola.goethe.zz>:
>> > This is a gaping hole in the Emacs UI.  I wrote a package,
>> > imenu-go.el, which behaves "as expected".
>> 
>> Hardly.

This means the "gaping hole".

>> M-* runs the command pop-tag-mark
>>    which is an interactive compiled Lisp function in `etags'.
>> It is bound to M-*.
>> (pop-tag-mark)

This is why it isn't a "gaping hole": the desired function is
available and bound to a key.

[...]

> a) Can't parse your last paragraph;

It was just the online help.

> b) I vaguely remember indeed somebody wanting to propagate the code
>    from imenu-go back into etags; it may be that pop-tag-mark has the
>    functionality of imenu-go (at least when imenu-go works with tags;
>    it can get info where-to-jump from other sources too).
>
> 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...

So you want to claim a deficiency in Emacs because you don't want to
try out the function and keybinding which it provides for that
purpose?

Wow.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kevin Rodgers]

Ilya Zakharevich wrote:
 > <dak@gnu.org>], who wrote in article <85d5nfe3oy.fsf@lola.goethe.zz>:
 >>M-* runs the command pop-tag-mark
 >>   which is an interactive compiled Lisp function in `etags'.
 >>It is bound to M-*.
 >>(pop-tag-mark)
 >>
 >>Pop back to where M-. was last invoked.
 >>
 >>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.
 >
 > a) Can't parse your last paragraph;

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

 > b) I vaguely remember indeed somebody wanting to propagate the code
 >    from imenu-go back into etags; it may be that pop-tag-mark has the
 >    functionality of imenu-go (at least when imenu-go works with tags;
 >    it can get info where-to-jump from other sources too).
 >
 > 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").

Thanks,
-- 
Kevin Rodgers

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

[Ilya Zakharevich]

[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

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

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
David Kastrup 
<dak@gnu.org>], who wrote in article <85acih4cmy.fsf@lola.goethe.zz>:
> >> > This is a gaping hole in the Emacs UI.  I wrote a package,
> >> > imenu-go.el, which behaves "as expected".

> >> Hardly.

> This means the "gaping hole".

Sorry that I was not clear enough: I understood this.

> > a) Can't parse your last paragraph;
> 
> It was just the online help.

Kevin Rodgers provided a very nice roundup; can it replace this
cryptic paragraph?

> So you want to claim a deficiency in Emacs because you don't want to
> try out the function and keybinding which it provides for that
> purpose?

Again, sorry that I was not clear enough.  On the contrary, I'm very
glad that finally, after more than a decade of bitching (while having
the working code available!) this feature is finally available in the
standard distribution.  A lot of thanks for including it!

So my "gaping hole" comment is due to my illiteracy.

All that I said is that

  a) I have no incentive to check whether the Emacs 21.4
     implementation is sane; and

  b) that my prior experience does not allow for a lot of hope in "a"
     (I remember there was *some* tricky stuff to code in imenu-go;
     but the only thing which immeditely jumps to mind is not related
     to return-back functionality; so, contrary to what I wrote, it is
     quite possible that there is no pitfall to avoid...).

Hope this helps,
Ilya

P.S.  Now, when End key finally does what users want, and there is a
      way to invert jump-to-tag, what about "the other stuff"?  What
      immediately comes to mind is "redo" functionality.  Is it
      available in 21.4?

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

[David Kastrup]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> [A complimentary Cc of this posting was sent to
> David Kastrup 
> <dak@gnu.org>], who wrote in article <85acih4cmy.fsf@lola.goethe.zz>:
>> >> > This is a gaping hole in the Emacs UI.  I wrote a package,
>> >> > imenu-go.el, which behaves "as expected".
>
>> >> Hardly.
>
>> This means the "gaping hole".
>
> Sorry that I was not clear enough: I understood this.
>
>> > a) Can't parse your last paragraph;
>> 
>> It was just the online help.
>
> Kevin Rodgers provided a very nice roundup; can it replace this
> cryptic paragraph?
>
>> So you want to claim a deficiency in Emacs because you don't want to
>> try out the function and keybinding which it provides for that
>> purpose?
>
> Again, sorry that I was not clear enough.  On the contrary, I'm very
> glad that finally, after more than a decade of bitching (while having
> the working code available!) this feature is finally available in the
> standard distribution.  A lot of thanks for including it!

You could have cut your decade of bitching short.  The function was
provided in 1998, more than 7 years ago.

> All that I said is that
>
>   a) I have no incentive to check whether the Emacs 21.4
>      implementation is sane; and

Well, then you should also have no incentive to bitch about it.

>   b) that my prior experience does not allow for a lot of hope in
>   "a" (I remember there was *some* tricky stuff to code in imenu-go;
>   but the only thing which immeditely jumps to mind is not related
>   to return-back functionality; so, contrary to what I wrote, it is
>   quite possible that there is no pitfall to avoid...).

So you reserve the right for bitching without checking whether it is
warranted?

> Hope this helps,

I don't see how this helps with anything except giving a good idea how
serious to take any of your bitching in future.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
David Kastrup 
<dak@gnu.org>], who wrote in article <85r7bonqpl.fsf@lola.goethe.zz>:

> You could have cut your decade of bitching short.  The function was
> provided in 1998, more than 7 years ago.

I see.  I tested 21.3, and could not find it there; obviously it was
an operator error, but I can't reproduce this now...

And given the useless docs, the function is not as visible as it
should have been.

> > All that I said is that
> >
> >   a) I have no incentive to check whether the Emacs 21.4
> >      implementation is sane; and

> Well, then you should also have no incentive to bitch about it.

Please allow me judge my incentives myself.  Thanks.

> So you reserve the right for bitching without checking whether it is
> warranted?

Depends on my prior experience with the package and its maintainers.
The situation with maintainers of Emacs became significantly better
during the last 5 years.

And judging from your reply, still no 'redo' functionality, right?

Thanks,
Ilya

Re: Redo/Undo (was: etags: M-. jump to the tag(called func), ...)

[B. Smith]

On Sep 18, 2005, at 03:05, Ilya Zakharevich wrote:

>
> And judging from your reply, still no 'redo' functionality, right?

Redo, as in the opposite of Undo, yes? (i.e. not as in repeat-complex- 
command.)

There is redo functionality it just doesn't present itself as a  
separate action. If you interrupt a series of undo operations with an  
editing operation, you'll find that the behavior of undo changes: it  
first undoes the interrupting edit, then undoes the undo operations  
(i.e. "redo"). Once it's reached the end of the undo history, it  
reverts to "normal" undo behavior.  Give it a try.  It's easier to  
observe than explain.

I've gotten so used to it that I don't even notice it when I'm using  
emacs anymore, though I confess I don't have as clear a mental model  
of what's going on as I'd like --  at least not clear enough to be  
able to draw a little ascii-art diagram.  Might be a nice addition to  
emacs info. Perhaps someone can explain the idea behind this behavior  
to me in such a way that I can draw a picture.


// Ben

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

[Stefan Monnier]

> And judging from your reply, still no 'redo' functionality, right?

No, indeed.


        Stefan

Re: Redo/Undo (was: etags: M-. jump to the tag(called func), ...)

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
B. Smith
<bpsm@aon.at>], who wrote in article <mailman.7386.1127026972.20277.help-gnu-emacs@gnu.org>:
> There is redo functionality it just doesn't present itself as a  
> separate action. If you interrupt a series of undo operations with an  
> editing operation

Sigh...  This was most probably beaten to death thousands times
already.  Of course I know of this poor-man workaround for missing
redo.  It is NOT A REPLACEMENT as far user-interface is concerned.  It
requires an exponential amount of keypresses w.r.t. situation when
redo is present.

With redo you can do the following (and I do it all the time):

  a) go back in time;

  b) Maybe I overshoot?  go forward in time a little bit.  No I did not;

  c) So I go back in time some more.

  d) Jump to b.

With emacs poor-man-workaround the undo-history starts snaking out
back-and-forth over the "real state history" so that the distance
between two points in "real history" grows exponentially in
"undo-sequence".

> I've gotten so used to it that I don't even notice it when I'm using  
> emacs anymore

They say that if all you have is a hammer, everything starts looking
like a nail

> though I confess I don't have as clear a mental model of what's
> going on as I'd like

Thanks for pointing out this.  This is *in addition* to the "logical"
problem above.  When you go linearly over the "snake" described above,
the direction of your "actual movement" is not predictable (am I
redoing or undoing now???).

(Even with simple undo/redo sequences, this strikes when undo hits the
start of the buffer; immediately you've lost whether you are undoing
or redoing.)

Hope this helps,
Ilya

Re: Redo/Undo (was: etags: M-. jump to the tag(called func), ...)

[David Kastrup]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> [A complimentary Cc of this posting was sent to
> B. Smith
> <bpsm@aon.at>], who wrote in article
> <mailman.7386.1127026972.20277.help-gnu-emacs@gnu.org>:

Your practice of "complimentary copies" is a pain in the ass, in
particular when sent from a spam-address.  There is no reason for you
to assume that people replying to you on a mailing list do not
actually read the mailing list.

>> There is redo functionality it just doesn't present itself as a  
>> separate action. If you interrupt a series of undo operations with an  
>> editing operation
>
> Sigh...  This was most probably beaten to death thousands times
> already.  Of course I know of this poor-man workaround for missing
> redo.  It is NOT A REPLACEMENT as far user-interface is concerned.
> It requires an exponential amount of keypresses w.r.t. situation
> when redo is present.
>
> With redo you can do the following (and I do it all the time):
>
>   a) go back in time;
>
>   b) Maybe I overshoot?  go forward in time a little bit.  No I did not;
>
>   c) So I go back in time some more.
>
>   d) Jump to b.

There is no clear notion about when to abandon history, and which
parts of "going back in time" are actually intended as a forward
change.  If you want to ignore this, there is redo.el, and apart from
that CVS-Emacs has undo-only which just goes backwards without
destroying the undo history when you add new changes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Redo/Undo (was: etags: M-. jump to the tag(called func), ...)

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
David Kastrup 
<dak@gnu.org>], who wrote in article <85mzm8rwer.fsf@lola.goethe.zz>:
> > [A complimentary Cc of this posting was sent to
> > B. Smith
> > <bpsm@aon.at>], who wrote in article
> > <mailman.7386.1127026972.20277.help-gnu-emacs@gnu.org>:
> 
> Your practice of "complimentary copies" is a pain in the ass, in
> particular when sent from a spam-address.  There is no reason for you
> to assume that people replying to you on a mailing list do not
> actually read the mailing list.

  a) What makes you think it is a spam-address?

  b) What makes you think I send it to a mailing list?

If you actually read the headers, you can see that your assumptions
are both wrong.

> > With redo you can do the following (and I do it all the time):
> >
> >   a) go back in time;
> >
> >   b) Maybe I overshoot?  go forward in time a little bit.  No I did not;
> >
> >   c) So I go back in time some more.
> >
> >   d) Jump to b.
> 
> There is no clear notion about when to abandon history, and which
> parts of "going back in time" are actually intended as a forward
> change.

Of course there is.  If you want to keep the maximum amount of state,
and allow "linear access" to all these states, then "redoing an undo"
should not add states to undo stack, but remove them:

 Current logic of having the stack of states after doing undo,
 overshooting and redoing, then editing:

  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\
								    |
               /<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<</
               |
	       \>>>>>>>>>>|
			  | new branch
			  |
			  |>>>>>>>>>>>>>>>>>>>>>>


 This has the same set of stored states, but avoids the "exponential
 growth" effect:

  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\
								    |
                   B -->  /<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<</
			  | new branch
			  |
			  |>>>>>>>>>>>>>>>>>>>>>>


One can also keep the information about what are branch points (like B
above), and let the users choose what they want to do at point B when
they start to undo the whole diagram above: they may want either

  a) go to the right branch, where they would effective "redo the dead
     end";

  b) go directly to the left branch (which is similar to what the
     other editors with undo/redo functionality do - they forget about
     dead ends).

> If you want to ignore this, there is redo.el

Is it in the distribution now?

Thanks,
Ilya

Re: Redo/Undo

[Stefan Monnier]

>> I've gotten so used to it that I don't even notice it when I'm using  
>> Emacs anymore
> They say that if all you have is a hammer, everything starts looking
> like a nail

This is really silly.  Both styles of undo/redo have their merit.
Claiming that one of the two is a "poor man's workaround" is not going to
get you anywhere, especially since plain undo/redo (like redo.el offers) is
just as simple to implement as the default undo/redo system.

Emacs doesn't come bundled with redo.el.  In Emacs-CVS I've added a command
`undo-only' which provides your notion of undo.  It doesn't offer your
notion of redo yet, tho.


        Stefan