From: Yuchen Pei <id@ypei.org>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode mailing list <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] Fixing refile cache use for org-goto in indirect buffers.
Date: Tue, 20 Sep 2022 22:44:07 +1000 [thread overview]
Message-ID: <87h712tduw.fsf@ypei.org> (raw)
In-Reply-To: <7b2b5134-46c4-2db2-1322-a2d1257cbf30@gmail.com> (Max Nikulin's message of "Mon, 19 Sep 2022 22:48:34 +0700")
Thanks for the reply.
On Mon 2022-09-19 22:48:34 +0700, Max Nikulin wrote:
> On 19/09/2022 12:16, Yuchen Pei wrote:
>> To reprod:
>> - make sure the org-refile-targets generates a big enough list where
>> the refile cache makes a difference
>> - visit an org file in org-refile-targets
>> - M-x clone-indirect-buffer-other-window
>> - C-0 C-c C-w to clear cache
>> - M-: (org-refile-get-targets)
>
> Have you tried to execute this command in the indirect buffer?
Yes, and it would be instant (assuming (org-refile-get-targets) has been
run in the original buffer). This is because the code path from
org-goto has an overriding local binding of org-refile-targets to `((nil
. (:maxlevel . ,org-goto-max-level)) before calling
org-refile-get-location which calls org-refile-get-targets.
>
>> - org-goto in the original buffer takes no effort
>> - but, org-goto in the indirect buffer takes time, which is unexpected.
>
>> diff --git a/lisp/org-refile.el b/lisp/org-refile.el
>> index 16cff25bd..7189ef595 100644
>> --- a/lisp/org-refile.el
>> +++ b/lisp/org-refile.el
>> @@ -306,7 +306,10 @@ converted to a headline before refiling."
>> (dolist (f files)
>> (with-current-buffer (if (bufferp f) f (org-get-agenda-file-buffer f))
>> (or
>> - (setq tgs (org-refile-cache-get (buffer-file-name) descre))
>> + (setq tgs (org-refile-cache-get
>> + (buffer-file-name (when (bufferp f)
>> + (buffer-base-buffer f)))
>> + descre))
>
> Thank you for the attempt to improve handling of indirect buffers.
>
> I am afraid, more serious refactoring is required to reuse result of
> `buffer-base-buffer', for the previous attempt to avoid issues with
> `buffer-file-name' see
> satotake to emacs-orgmode… [PATCH] org-refile.el: Fix the case of
> *scratch* buffer. Sat, 15 May 2021 19:38:39
> +0900. https://list.orgmode.org/20210515103839.8574-2-doublequotation@gmail.com
>
> There are several corner cases with `org-refile-cache', `org-goto',
> and buffers.
> - Perhaps buffer name, not file name should be used as the cache key
> if some buffer is not associated with any file. Alternatively cache
> should not be used at all.
It seems there may be problem with this idea. If buffer name is the
key, that will mean a buffer and its indirect clone will generate two
caches, which duplicates the work, no?
> - When an indirect buffer is narrowed down to some region
> (e.g. created using `org-tree-to-indirect-buffer') jump targets
> should be filtered to the displayed range.
>
> So the change is an improvement (I would prefer `and' instead of
> `when' in such expression, but it does not really matter). Leaving
> aside other issues and more serious refactoring, it seems, storing
> results to the cache requires a similar fix, so perhaps it is possible
> to move "(setq f ...)" code above of "(or ...)" and reuse f as the
> cache key.
Sure, I will update my patch when I get around to it again.
>
> Please, send patches produced by "git format-patch" command.
>
I guess you had some problem applying the patch? I did use
(ma)git-format-patch, but had some difficulty of getting gnus to send
the formatted patch (I basically visited the patch file and ran
(message-mode), but it was missing a few header fields compared to
composing a new mail from gnus, so I manually copied over these fields).
This was why I sent two emails. The first one[1] had an odd extra bit
of Message-ID at the bottom of the message. Is this the one you were
referring to as not being "standard", or is the other one[2] also not
quite right?
[1] https://lists.gnu.org/archive/html/emacs-orgmode/2022-09/msg00322.html
[2] https://lists.gnu.org/archive/html/emacs-orgmode/2022-09/msg00323.html
Best,
Yuchen
--
PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0
<https://ypei.org/assets/ypei-pubkey.txt>
next prev parent reply other threads:[~2022-09-20 15:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-19 5:16 [PATCH] Fixing refile cache use for org-goto in indirect buffers Yuchen Pei
2022-09-19 15:48 ` Max Nikulin
2022-09-20 12:44 ` Yuchen Pei [this message]
2022-09-20 17:33 ` Max Nikulin
-- strict thread matches above, loose matches on Subject: below --
2022-09-19 5:16 Yuchen Pei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h712tduw.fsf@ypei.org \
--to=id@ypei.org \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).