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

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

[Samuel Wales]

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

at least for my use case, refile goto should push mark in the target buffer
after visiting the buffer, before jumping.  rationale: it can be a big
jump.  m-< pushes mark for that reason.  i think i saw that in the manual
years ago.  :)

i am often in my-big-subtree, someplace, and go someplace else.  i want to
return to that place in my-big-subtree.  refile goto loses the previous
position.  i want to c-u c-spc to get to where i was.

completely unrelated: global mark ring is orthogonal, as i know exactly
where i want to go, but it could take me anywhere.  also, i've never gotten
global mark ring to work for me.  i think maybe global marks should work
like vundo or undo-tree, where you have up down right left and i don't
think it should be a ring but a tree.  when i jump, i often don't know that
i want to return so do not set the mark.  to me, the big jump of refile
goto in the target buffer is the reasonable automatic mark setter like
m-<.  also unrelated is switching buffers; i think in terms of headings.



-- 
The Kafka Pandemic

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

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

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

[Ihor Radchenko]

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

Samuel Wales <samologist@gmail.com> writes:

> at least for my use case, refile goto should push mark in the target buffer
> after visiting the buffer, before jumping.  rationale: it can be a big
> jump.  m-< pushes mark for that reason.  i think i saw that in the manual
> years ago.  :)
>
> i am often in my-big-subtree, someplace, and go someplace else.  i want to
> return to that place in my-big-subtree.  refile goto loses the previous
> position.  i want to c-u c-spc to get to where i was.

See the attached tentative patch.
This is an easy addition.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-refile-Push-point-to-Org-mark-ring-before-jumpin.patch --]
[-- Type: text/x-patch, Size: 2312 bytes --]

From b3a80c70bfca02287ca8ecdcba98cea170d9783b Mon Sep 17 00:00:00 2001
Message-ID: <b3a80c70bfca02287ca8ecdcba98cea170d9783b.1720279651.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Sat, 6 Jul 2024 17:26:08 +0200
Subject: [PATCH] org-refile: Push point to Org mark ring before jumping

* lisp/org-refile.el (org-refile):
(org-refile-goto-last-stored): Save position to the Org mark ring if
we are about to jump to a different position.
* etc/ORG-NEWS (~org-refile~ now saves current position to Org mark
ring when jumping to heading): Document the new feature.

Link: https://orgmode.org/list/CAJcAo8vYLJ3YGH0+nZs1rgtdq2iRKzJ8tuGxJKRD-XyEwEm4FA@mail.gmail.com
---
 etc/ORG-NEWS       | 8 +++++++-
 lisp/org-refile.el | 2 ++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b9f51667d..4e9d1bf8d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -93,8 +93,14 @@ Runtime error near line 2: attempt to write a readonly database (8)
 [ Babel evaluation exited with code 1 ]
 #+end_example
 
-
 ** Miscellaneous
+*** ~org-refile~ now saves current position to Org mark ring when jumping to heading
+
+When ~org-refile~ is called with =C-u= or =C-u C-u= prefix argument
+(to jump to heading or to jump to the last refiled heading), it saves
+point to Org mark ring before jumping. Then, the user can return back
+via ~org-mark-ring-goto~.
+
 *** Trailing =-= is now allowed in plain links
 
 Previously, plain links like
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index c8e64903c..44361c143 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -544,6 +544,7 @@ (defun org-refile (&optional arg default-buffer rfloc msg)
 	  (setq nbuf (find-file-noselect file 'nowarn))
 	  (if (and arg (not (equal arg 3)))
 	      (progn
+                (org-mark-ring-push)
 		(pop-to-buffer-same-window nbuf)
 		(goto-char (cond (pos)
 				 ((org-notes-order-reversed-p) (point-min))
@@ -634,6 +635,7 @@ (defun org-refile (&optional arg default-buffer rfloc msg)
 (defun org-refile-goto-last-stored ()
   "Go to the location where the last refile was stored."
   (interactive)
+  (org-mark-ring-push)
   (bookmark-jump (plist-get org-bookmark-names-plist :last-refile))
   (message "This is the location of the last refile"))
 
-- 
2.45.2


[-- Attachment #3: Type: text/plain, Size: 224 bytes --]


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Samuel Wales]

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

thank you!  this would definitely meet my need.

i was thinking of the local mark, but i use org-mark-ring-goto all the time
also.

On Saturday, July 6, 2024, Ihor Radchenko <yantar92@posteo.net> wrote:

> Samuel Wales <samologist@gmail.com> writes:
>
> > at least for my use case, refile goto should push mark in the target
> buffer
> > after visiting the buffer, before jumping.  rationale: it can be a big
> > jump.  m-< pushes mark for that reason.  i think i saw that in the manual
> > years ago.  :)
> >
> > i am often in my-big-subtree, someplace, and go someplace else.  i want
> to
> > return to that place in my-big-subtree.  refile goto loses the previous
> > position.  i want to c-u c-spc to get to where i was.
>
> See the attached tentative patch.
> This is an easy addition.
>
>

-- 
The Kafka Pandemic

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

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

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

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> thank you!  this would definitely meet my need.
>> ...
>> See the attached tentative patch.
>> This is an easy addition.

Applied, onto main.
Done.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=486ebe118

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Samuel Wales]

[-- 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 --]

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

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

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

I can see what you mean, although I am not sure if there is a good UI
for tree-like navigation in this scenario. At least, I can't think of
one. I am not sure how undo-tree-like interface would work here.

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

This is not like mark ring though - just search across specific object
types in buffer. Something akin next/previous-button.

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

This part about branching is not very clear.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Samuel Wales]

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

On Monday, July 15, 2024, Ihor Radchenko <yantar92@posteo.net> wrote:

> Samuel Wales <samologist@gmail.com> writes:
>
> This is not like mark ring though - just search across specific object
> types in buffer. Something akin next/previous-button.
>

correct.  f and b are for forward and backward.  for the local mark ring,
it will go to the next or prev mark in the buffer by position in the
buffer.  not a history command per se.

>
> > 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.
>
> This part about branching is not very clear.
>
> in undo-tree and i think vundo, you have a tree.  in the case of point
locs, suppose you were in one place, 0, and then you went to a, then back
to 0 with l, then went to b.  now you have a branching point at 0.  you can
do n and p to choose between a and b -- actually  moving to them with a
message is an option here as is showing their lines in a visualizer.   n
and p could also cycle through 0 for convenience if that's not too
confusing [a message can notify]. a command like l can also be used to go
back to it.

so the f and b thing has nothing to do with history; it is just navigation
in the buffer [if local ring] according to the sequence in the buffer, akin
to m-tab in org for links.

l and r are like in info, navigating history. n and p choose different r
locations for the case where there is more than one r.


-- 
The Kafka Pandemic

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

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

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

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> in undo-tree and i think vundo, you have a tree.  in the case of point
> locs, suppose you were in one place, 0, and then you went to a, then back
> to 0 with l, then went to b.  now you have a branching point at 0.  you can
> do n and p to choose between a and b -- actually  moving to them with a
> message is an option here as is showing their lines in a visualizer.   n
> and p could also cycle through 0 for convenience if that's not too
> confusing [a message can notify]. a command like l can also be used to go
> back to it.
>
> so the f and b thing has nothing to do with history; it is just navigation
> in the buffer [if local ring] according to the sequence in the buffer, akin
> to m-tab in org for links.
>
> l and r are like in info, navigating history. n and p choose different r
> locations for the case where there is more than one r.

buffer-undo-list actually supports storing point positions.
So, if one wants to implement what you want, it is certainly possible by
doing something like

(let ((buffer-undo-list special-point-history))
  <... move point>)

Then, one can hack on existing packages like vundo to get the tree-like
interface.

I am not sure if it would be something we need in Org mode though.
Maybe ELPA package or something.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>