From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id uBVbNmhqjWDWgQAAgWs5BA (envelope-from ) for ; Sat, 01 May 2021 16:49:12 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id uCYIMmhqjWD0LgAAB5/wlQ (envelope-from ) for ; Sat, 01 May 2021 14:49:12 +0000 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 4BAAC137C9 for ; Sat, 1 May 2021 16:49:12 +0200 (CEST) Received: from localhost ([::1]:56540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcqvf-0000rV-9S for larch@yhetil.org; Sat, 01 May 2021 10:49:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50006) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcqvI-0000rP-8q for emacs-orgmode@gnu.org; Sat, 01 May 2021 10:48:48 -0400 Received: from ciao.gmane.io ([116.202.254.214]:33154) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcqvG-00036L-Lh for emacs-orgmode@gnu.org; Sat, 01 May 2021 10:48:48 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lcqvE-0003xT-GJ for emacs-orgmode@gnu.org; Sat, 01 May 2021 16:48:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Maxim Nikulin Subject: Re: [PATCH] Bug: fragile org refile cache Date: Sat, 1 May 2021 21:48:39 +0700 Message-ID: References: <87v98598un.fsf@localhost> <87k0olxjpz.fsf@localhost> <877dklxecq.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <877dklxecq.fsf@localhost> Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619880552; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=5bC7LqnsP0QXPshabCVIDAr6LIZjX0aDu8WMcN5E8rE=; b=MtFq3Q+PY7BMH8u61Zvgw2esMnCPELADodJtfV74Q9cR92AJSjephmMgGwUNNS+Gz55LWM K6TgbpBO2E6+3u8LrpcfrhGsccWHvvKEKdr8Gp9ycV9pWsg0RByRMIP9m4sg1PpL/Tu21V AqMdpwQVJZp86tUncEuSLyFIFxako7Bx6SalYw7oPq7psKs7IRMXlOy9dcPHY01jkvqxNo l3OxqhZyNPSINDngkv/AtO/MVsZTDrXY1Q8t6FRKSU5M/SHj7zGTBAejgLj7Y+K6MWLNyP b/RcPyw7sCUNFO/tqI6Cuf3KQOsGUkMU9Iwq7qMdjGb731EH3/A0I3F+oxhbiQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619880552; a=rsa-sha256; cv=none; b=RkfghxXptymPIsKl+QlQuY786G7EXkWx4e/O4j/7RuE1MDnq0C3oBbVwRZad8nt1D/x1So zL0zMyX0iqVL1Fg++9nsf5asmtCiqYmcl25sZKjdogpijG4KCLAbWy01lEOEzPgpnjGXfR 5LSsPWj9tfcyyeHqKZKOCCXu9v6UZc4OVSsnLIZmFqzFo4d4WgkJ4+igIOX6KTmA0pp3Yw WHFszIpg0K3/jaso60MKXooFy38v3IhICC0sFlo0aBRJrzJ4Xl+6fyDZ8oUvmada+sxItf l+Cw7EJaiiLo6iePBOjqvfgpVosGwGmdCHWNieD+Yr47QnHd+8hMjkw3aPFnDA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -1.86 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 4BAAC137C9 X-Spam-Score: -1.86 X-Migadu-Scanner: scn0.migadu.com X-TUID: ejbycHwzMciH On 29/04/2021 23:08, Ihor Radchenko wrote: > > My experience is exactly opposite. Or maybe I miss something. Can you > elaborate? Some additions. org-outline-path-cache is used solely by org-refile-get-targets (maybe there are some calls in other packages) but it efficiency is questionable. It was not clear for me earlier that the cache is reset before each scan through a buffer. So if org-refile-use is disabled, org-outline-path-cache from previous run of org-refile or org-goto is not used as well. A query to org-outline-path-cache requires at least one backward search and hash lookup. During sequential scan in org-refile-get-targets it is enough to have previous heading path to update it when new heading is found. I think, org-outline-path-cache should be deprecated. > Just cleanup heading text: I have realized what is wrong with this benchmark. It runs so fast because it matches no headings, so it never spent time for cleaning them up. > (benchmark-run 1 > (goto-char (point-min)) > (while (re-search-forward "^\\*+" nil t) > (let ((case-fold-search nil)) (beginning-of-line) should be added before next call and (end-of-line) somewhere later in while body. > (looking-at org-complex-heading-regexp) > (if (not (match-end 4)) "" > ;; Remove statistics cookies. > (org-trim > (org-link-display-format > (replace-regexp-in-string > "\\[[0-9]+%\\]\\|\\[[0-9]+/[0-9]+\\]" "" > (match-string-no-properties 4)))))))) => (0.013364877 0 0.0) On 29/04/2021 21:12, Ihor Radchenko wrote: > For the cleaned heading text, I do not think that re-calculating the > heading text on each change is a good idea. It may degrade typing > latency. Yet, an acceptable approach could be simply invalidating cache > for the changed headings. Then, outline paths can be re-calculated on > changed headings when needed. I agree that it is enough to invalidate cleaned heading on edit to refresh it in org-refile-get-targets. On the other hand, I still prefer text properties since they could be fetched even if some lines have been added or removed before. Position-based cache is useless in such cases. Concerning typing latency, it should be postponed and resumed when no new edits is performed for certain period of time (~1s). However I am unsure if it is possible to accurately track all affected lines since later changes can add/remove lines before the line scheduled for invalidation. On 30/04/2021 02:17, Tim Cross wrote: > I suspect the reason it is not done automatically is that getting that > right for all use cases is very hard to do without adding adverse impact > to performance. A cache which is marked as 'dirty' too often results in > too frequent cache refresh operations, but at the same time, determining > what changes in an org file actually invalidate the cache can be a > process intensive operation. I believed that idea risen in this thread was to regenerate cache instead of spitting "Please regenerate the refile cache with `C-0 C-c C-w'" leaving more tricky cases for the user.