From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 0IDJKwyQlGZppAAAe85BDQ:P1 (envelope-from ) for ; Mon, 15 Jul 2024 02:57:16 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 0IDJKwyQlGZppAAAe85BDQ (envelope-from ) for ; Mon, 15 Jul 2024 04:57:16 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AQ48Gt5x; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1721012236; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=WHm7U8Pj+lN8kCfIjxHjGr6j74J2ei7aMgTEasmTCmA=; b=hJwKqAhPEfSGCrc4gjbDKSIAfz25f7sxarcmq11NesBaqwraeaJplJXpNjMUJtWnyshBw4 NPv+1IjBfL+fR5xX0bkiMRARACDq1t6NHY9e1zqjdCMHRI7oDAtWE6ewKEa1O9N1vQ/bKK UO/8WBh5O7s2T/OYYQ8LaB50AR1b5Le10kwxlZ1bhzbko3usAm5SHE7BeP4gipn8sWj7TG jZfqzY+ef9/gSgOlICqzIV0/UuXfFm04B6bJCtoxesDSAOmirj7jO8VNV2VDjZTPKvBil4 rvQdJl3PAoJ+P3MzXPddiHY6Tf0HiU9z1pCgYd4GQOquqttPwGcumxc1O46Ipw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1721012236; a=rsa-sha256; cv=none; b=Fpux1nE5eWKnJ3tn7qvAB3dwzL1FwFSRIshibv5ZSyJFYAb/ccT/nF0dR8lrVvl60XHQFE 8+4rVPB+QJumTZxhhPTwzvyz0TAouJmqUHBe7vqD+LE5hPGz/uWnMV8BQRQ2RNP79gde57 LIQ+8lpFqLu2244TcSaCFFNrWmPenubZdkD41v8z0BsLwditXSulEidP7/asnk9AR26Bt9 4su+NEET4XU8BsH4OF+2VTL4T1ohu5h6LFcvCYZZJ21SNeYSYZL7ldd54+mivq6+zWcaPu gF0Iz//IaZlphKYebn0UkAkt/XLTBgY4F1iqWubIfJFvM0/kJJJWpMmXh0xHJw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AQ48Gt5x; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4B248658E5 for ; Mon, 15 Jul 2024 04:57:15 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sTBsp-0006Nj-KR; Sun, 14 Jul 2024 22:56:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sTBso-0006Mu-7b for emacs-orgmode@gnu.org; Sun, 14 Jul 2024 22:56:10 -0400 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sTBsj-0006fe-CR for emacs-orgmode@gnu.org; Sun, 14 Jul 2024 22:56:09 -0400 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-52ea333534cso502007e87.3 for ; Sun, 14 Jul 2024 19:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721012162; x=1721616962; darn=gnu.org; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=WHm7U8Pj+lN8kCfIjxHjGr6j74J2ei7aMgTEasmTCmA=; b=AQ48Gt5xjDAGIJ4T6iuinrie8GkBpSyeTkUHljIwcelNmJCojs7zr5FyACTvSCe2yV 9eEKDgLv2QazNLI3/Zhmb1kaYBDd2Li48LK6gmSw2KmntC9Lc2DEl8EGS+dFpYyRs6Il x/pzf0J+kEmTk8mbGdcwd1/Y4jOeKRvYJZCVyppq9ARIlq/0UbUxmG/jBXMOHQYWgl6Z nyMaAgHRgqZFDR2BwsT4vpIo1ccG4blo7yr0FPAIVW5yAkgVr5G2rSubkzLnRHF2WT9Q 7Hb0Z+b8+rvGYLGogAOjc2gaO3v4EAhb5WgQzpDNP74u/eelpnyKcPl8z+UVBWOKN3xm D+0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721012162; x=1721616962; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WHm7U8Pj+lN8kCfIjxHjGr6j74J2ei7aMgTEasmTCmA=; b=OBs3RJEBtDTB3KgWJa0lrwmoy1osufBb0SAt5TIiAnMCTQ0G7gjHWvEHP201MHoIb5 TgCj9cgSgaltu3WmGUfVyYXG3/21w3ZFxGJBupd2oj5iTYDBhVZDteqoKoWqwycXIq8X KQnYR3qTP6YTD5+03ZOL2WkEPMohwF6v/8AEoiNBkveIwjWfb/rEA9Ao7p8fOaXISDEa C7xgfpECdB+n+rqiMi+PmHmT/Tjol62+QfH3BZwYKwrdJwxc41HERhSPVI1oBt1sdra9 +0VweZYG+ziou/GZkVXgy8NA4I05l+zHIppb/MvZ5pZme/Zd6Pmb066vxr2EwbXjorgm timQ== X-Gm-Message-State: AOJu0Yzf3zsKSBlwM0acUg0CTQ6oZ+7MvBCcg/xB9mvqNEdhuYclhGZv 7KrhqwD4k1s3wP0QIM+5z2x5Y4vKlSPvbantPe8KfHaLNVI4jtJw9rtZo97rE+4Mq9cEMSx51gn sMapz1Dazh7+zsLRfFN/1hkEb6fcTj1/GMb/U7w== X-Google-Smtp-Source: AGHT+IGDxHnPQIaMuN8xPNJBpekATPJm3xW5URNSWc3K5Yo7wYWcEbqJRO8aT4aFiAA0yGo8OLcH+NhuzselYfzkjkA= X-Received: by 2002:a05:6512:128f:b0:52e:9989:66cb with SMTP id 2adb3069b0e04-52ec3e14876mr6566388e87.0.1721012161886; Sun, 14 Jul 2024 19:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6520:2ad5:b0:299:8c4:60f2 with HTTP; Sun, 14 Jul 2024 19:56:00 -0700 (PDT) In-Reply-To: References: <87v81iilop.fsf@localhost> <87a5ilqux4.fsf@localhost> <87v818jnsi.fsf@localhost> From: Samuel Wales Date: Sun, 14 Jul 2024 19:56:00 -0700 Message-ID: Subject: [fr] refile goto: push mark in the target buffer first To: "emacs-orgmode@gnu.org" Content-Type: multipart/alternative; boundary="0000000000009041f3061d405e0e" Received-SPF: pass client-ip=2a00:1450:4864:20::12d; envelope-from=samologist@gmail.com; helo=mail-lf1-x12d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 4B248658E5 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.74 X-Spam-Score: -9.74 X-TUID: EvmkarjnhyQX --0000000000009041f3061d405e0e Content-Type: text/plain; charset="UTF-8" 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 --0000000000009041f3061d405e0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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&#= 39;s mark ring as primarily and usually a reliable back button, like a brow= ser's.=C2=A0 mainly for links and link-like navigating actions.=C2=A0 e= specially for use cases like this: refile goto to a target heading in any f= ile, whether same or not, then pop back to where you were using org-mark-ri= ng-goto.=C2=A0 it's quick, pretty much certain to go to the spot you we= re when you followed the link, and rather convenient.=C2=A0 i use it for wh= en 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.= =C2=A0 commands like m-< that move point save mark there automatically.<= /div>

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 targ= et heading.=C2=A0 this is analogous to m-< pushing mark so that you do n= ot lose your place.

so in this formula, with using= local mark, refile goto works like this:=C2=A0 after doing refile goto, or= g-mark-ring-goto takes you back to where you were before you did refile got= o, just as it does now.=C2=A0 no modification of code is necessary for this= .=C2=A0 and c-u c-spc takes you to the loation in the buffer where point wa= s before refile goto went to the target heading [after it went to the buffe= r].=C2=A0 what is necesary for this is pushing mark after visiting the targ= et buffer but before visiting the target heading.

<= div>so that would be an alternate implementation.=C2=A0 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.=C2=A0 ei

=
other commands set local mark as part of their operation or so that yo= u can go back because they might be interesting or distant.=C2=A0 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.=C2=A0 i ha= ve found packages for local ring, but nothing i use.

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

then ther= e is the emacs global ring, which makes sense in principle because emacs is= multi-buffer, but which i have never gotten to be useful.=C2=A0 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, per= haps even with visualizer, with a consistent interface.=C2=A0 if you think = of info's navigation commands like l and r, you can imagine various thi= ngs you can do.=C2=A0 in undo-tree and vundo you can switch branches for th= e next place you might want to go to.=C2=A0 point locs could use the same t= ype of navigation commands.

in principle org&#= 39;s mark ring could even be generalized to more kinds of links, such as pa= ths or tses, and org could grow a global minor mode for links [expanded id= ea of].


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

the spec a= pplies to local, global, and link oriented, with an expanded idea of links = to include such things, if desired by user, as identifiers, timestamps, bar= e 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.=C2= =A0 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 fo= rward
in history of point, regardless of
buffer.=C2=A0 Thus, dispatch= er RET then
dispatcher l returns to point, even if
point was not on a= link.=C2=A0 The bindings
are modeled on l and r in info or help.
Dispatcher n and p change at branching
points, cycling you to the diffe= rent
places r might go and back.

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

Th= ese commands apply to marks anywhere
in Emacs, not only ones related to<= br>links.=C2=A0 Thus they are more general than
link commands.=C2=A0 You= can use them for
finding interesting places in your use
of Emacs, su= ch as where you set mark.
^^^

this isn&#= 39;t the complete idea but just gives a flavor.=C2=A0 the idea is that poin= t locations, whether local, global, or link-oriented, are worth having a co= nsistent or at least analogous ui.



--
T= he Kafka Pandemic

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




--
The Kafka Pandemic

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

--0000000000009041f3061d405e0e--