[fr] refile goto: push mark in the target buffer first

[Samuel Wales <samologist@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4597 bytes --]

i didn't do reply to all for some reason so sending to list.


idk if useful, but fwiw, for me at least, i think of org's mark ring as
primarily and usually a reliable back button, like a browser's.  mainly for
links and link-like navigating actions.  especially for use cases like
this: refile goto to a target heading in any file, whether same or not,
then pop back to where you were using org-mark-ring-goto.  it's quick,
pretty much certain to go to the spot you were when you followed the link,
and rather convenient.  i use it for when i have a link to something and
want to use it as reference for what i am doing locally.

nothing new but i think of the local mark ring as holding interesting point
locs that you can go back to.  commands like m-< that move point save mark
there automatically.

hence my suggestion to use the local mark ring for the case where you
refile goto a heading so as not to lose where you were in the target
buffer, after going to target buffer but before going to target heading.
this is analogous to m-< pushing mark so that you do not lose your place.

so in this formula, with using local mark, refile goto works like this:
after doing refile goto, org-mark-ring-goto takes you back to where you
were before you did refile goto, just as it does now.  no modification of
code is necessary for this.  and c-u c-spc takes you to the loation in the
buffer where point was before refile goto went to the target heading [after
it went to the buffer].  what is necesary for this is pushing mark after
visiting the target buffer but before visiting the target heading.

so that would be an alternate implementation.  either one will get me what
i want, which is to not lose the location, but the above preserves the
link-oriented back button idea also.  ei

other commands set local mark as part of their operation or so that you can
go back because they might be interesting or distant.  also you can set
mark to a location you might want to go back to.

i use org's ring and the local ring all the time.  i have found packages
for local ring, but nothing i use.

org's ring is global, which enhance's org's ability to be file-agnostic and
heading-centric.

then there is the emacs global ring, which makes sense in principle because
emacs is multi-buffer, but which i have never gotten to be useful.  in
reality i think all 3 could perhaps use redesigning.


a redesign: i think it would probably be great if all three rings stopped
being rings and started being trees, much like undo-tree, perhaps even with
visualizer, with a consistent interface.  if you think of info's navigation
commands like l and r, you can imagine various things you can do.  in
undo-tree and vundo you can switch branches for the next place you might
want to go to.  point locs could use the same type of navigation commands.

in principle org's mark ring could even be generalized to more kinds of
links, such as paths or tses, and org could grow a global minor mode for
links [expanded idea of].


draft spec: here is a draft spec i wrote for a point history ui.

the spec applies to local, global, and link oriented, with an expanded idea
of links to include such things, if desired by user, as identifiers,
timestamps, bare fs paths, and many other things.

dispatcher f and b go to next and prev point loc in buffer, much like m-tab
in org.  it is settable on the fly whether it navigates local, global, or
link, or it can use different prefixes or initial key sequences.

vvv draft spec
Dispatcher l and r go back and forward
in history of point, regardless of
buffer.  Thus, dispatcher RET then
dispatcher l returns to point, even if
point was not on a link.  The bindings
are modeled on l and r in info or help.

Dispatcher n and p change at branching
points, cycling you to the different
places r might go and back.

Dispatcher l and r are repeatable as l
and r; dispatcher n and p are repeatable
as n and p.

These commands apply to marks anywhere
in Emacs, not only ones related to
links.  Thus they are more general than
link commands.  You can use them for
finding interesting places in your use
of Emacs, such as where you set mark.
^^^

this isn't the complete idea but just gives a flavor.  the idea is that
point locations, whether local, global, or link-oriented, are worth having
a consistent or at least analogous ui.



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com




-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

[-- Attachment #2: Type: text/html, Size: 5413 bytes --]