From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OHRiLTZMKmNi/QAAbAwnHQ (envelope-from ) for ; Wed, 21 Sep 2022 01:26:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 8DduLTZMKmM7RgAA9RJhRA (envelope-from ) for ; Wed, 21 Sep 2022 01:26:46 +0200 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 461182CD7B for ; Wed, 21 Sep 2022 01:26:46 +0200 (CEST) Received: from localhost ([::1]:33996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oamdZ-0003Ih-23 for larch@yhetil.org; Tue, 20 Sep 2022 19:26:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oah87-0005nD-VP for emacs-orgmode@gnu.org; Tue, 20 Sep 2022 13:34:02 -0400 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:46958) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oah85-0003XL-4q for emacs-orgmode@gnu.org; Tue, 20 Sep 2022 13:33:55 -0400 Received: by mail-lf1-x136.google.com with SMTP id a8so4945615lff.13 for ; Tue, 20 Sep 2022 10:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date; bh=Hyx0CNy7w8XbdGBbDx61nCAOC8Ngr6tuybTUmiV+HEs=; b=Ze5ZjvHZuwEIvRDS6SnS6qH5mYsNqbKRGp/4lCUzoKdPXohRZTvY4cuspVhUS6sBiv 0wsEoML58gCX8ixuWLKxDX1Q6pJPM+jts799X+Nqrw28h8yfWHVBMRvxNy/ILVysrGGc a5if1cpc/QAFRR7I+wrk5CZo4CNQeH/UPB2aok1hjF2B5nCP0w4rO+uYfmlziwLx7yn4 04Ai6BZUdz1nXGQsi/Q6utIVHA65F9bQJhx94Q7hBvPUVw5DXw7cBI7Q14+HSmeaKf74 /p+k7gqVd2oX/kJwDFt7b43UztXfmRjjD9voGKQB6vRyEerUTXNRY9iLSD6DqdSdlGGZ k9uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date; bh=Hyx0CNy7w8XbdGBbDx61nCAOC8Ngr6tuybTUmiV+HEs=; b=xzWeMv4toNt3KrfOeyAICsG7XVjZ/xGhlGnobqVdQ2m2gt19ObpgIExEIrYw40f2Xw yAIPnJU199ugv7Qv76xJT1RLHi3SaaogIEKnQDrj9mxjHHYGzPX8JRCbdxHqapm/N0Xs YZUXO+JvgXS3AkBFNfophmytcXdq9bVYlAs+VCraoaZz51GbvsRkd7sHJZzW2ckifVW8 DqNadaXA+evsaBrVwoVbpvL9687VHPMau+g+2JnMOi9wxjzv4FSgSlmGGcYfVljZI+Wu W1Xn3uUyl3yF+yTlFBz8L/JiUjns36iMfRiWBgRODEUJsWXnO0KmkZBqY/0OP7tbnNlt hw7w== X-Gm-Message-State: ACrzQf1xFYFV+qq45NiOk2zUP7uApAQf5kLo98A1QiNLqEQdh0nDXyby BNgVK8FN1gifkzywABHgvt3pl+lm+Rg= X-Google-Smtp-Source: AMsMyM48LjyPzwZYv2kEg4vvRrmyLt/kKpmshGrn6HpNN80glzXO3YMK/+Xd4u5HQXDH+EZi96MnzA== X-Received: by 2002:a05:6512:2201:b0:492:f874:39fa with SMTP id h1-20020a056512220100b00492f87439famr8466925lfu.365.1663695229042; Tue, 20 Sep 2022 10:33:49 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id z2-20020a2e7e02000000b00267232d0652sm58276ljc.46.2022.09.20.10.33.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Sep 2022 10:33:48 -0700 (PDT) Message-ID: Date: Wed, 21 Sep 2022 00:33:46 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Fixing refile cache use for org-goto in indirect buffers. Content-Language: en-US To: Yuchen Pei Cc: emacs-orgmode mailing list References: <87zgevvs6e.fsf@ypei.org> <7b2b5134-46c4-2db2-1322-a2d1257cbf30@gmail.com> <87h712tduw.fsf@ypei.org> From: Max Nikulin In-Reply-To: <87h712tduw.fsf@ypei.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::136; envelope-from=manikulin@gmail.com; helo=mail-lf1-x136.google.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 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, NICE_REPLY_A=-2.182, 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1663716406; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Hyx0CNy7w8XbdGBbDx61nCAOC8Ngr6tuybTUmiV+HEs=; b=SoJzVHB1yFPNULGK7TTXjDPLH6x8q5MmBcQ+yeBL7Y6B/oG1gsHf/Fy+CyyblrpaPyUpFV L+3dh9icIJsVjLE/xTMmM89NHlyaiFX5jtFwtiM2fSRSBfImr7acTN7J8ddeBOi0PQlZKD Gs5RnQlGoXUo8ia3UtclWuh7iPLmUyf0xvcq7zZalChn9J6Vh4lZoanwpz6owtU2M0Drmv O5xOroIArJJAJG4p9C1w4Zn/8pkJQ4fjq3Q3UIpNvuhZ2V5YGWQoXh51h04mHVkgICuvKc M/2LLOhzV4M1uu/0syk0H1O42xp1gnbtt8MDLrMLJPSPyuq7wTVljWQ1AK/tFA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1663716406; a=rsa-sha256; cv=none; b=NIAhVSu4uf2P2h55HNsZ4DMEg7r2AaN0fpUcC390ur6oSr+ouAyipwcAMx70Wtyl7bJpcR dPH6+q9B5WeS7ed5AwrV9zpCaO6mx0eqF6aozeavMUncCu2EhovNyskWOi+c+xH3XQTts7 nxVBjToEBWJqJDNVcqsChxFriHvFZmup5rWtj1dGk6yW87/6iI8a90WKRwohgoNp9CBedi yG1K+n2Cqbe0sguy2JFs+wfz0YdLd8n4EX8hmihCB0cwicthiOCn1XgXF3l/oJ2YCLJKg5 wgJ40Y90HTAisoVuxz2O/90Ml1UJ/cOUvQDECDiSPrQ3PBVwi0Imqqhp1kwPoQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=Ze5ZjvHZ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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" X-Migadu-Spam-Score: 11.17 X-Spam: Yes Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=Ze5ZjvHZ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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" X-Migadu-Queue-Id: 461182CD7B X-Spam-Score: 11.17 X-Migadu-Spam: Yes X-Migadu-Scanner: scn1.migadu.com X-TUID: NqHWkX/owDRy On 20/09/2022 19:44, Yuchen Pei wrote: > 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). My hypothesis is that if refile targets are requested from an indirect buffer at first then next attempt from the base buffer causes recalculation because of previous result is not properly stored. The code at the end of the function requires a similar fix. >>> 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? Certainly if a buffer has its base buffer then file name associated with the base buffer should be tried at first. However besides indirect buffers, buffers not associated with any files at all may exist. I am not sure that using buffer name is a good idea for them since temporary buffers may be discarded and new ones with same names may be created. My point is that refile targets for temporary buffers should not be cached at all or buffer name should be used as the key. Behavior should be deterministic. I do not request such change from you, but maybe it is just an additional couple of lines at the location you are changing anyway. >> 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. Great! >> Please, send patches produced by "git format-patch" command. > > I guess you had some problem applying the patch? No, I missed commit message in the expected format https://orgmode.org/worg/org-contribute.html#commit-messages Just send the patch as an attachment.