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 ms11 with LMTPS id MMLpGbpDSV+/fQAA0tVLHw (envelope-from ) for ; Fri, 28 Aug 2020 17:49:46 +0000 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 2BTGFbpDSV8AGwAAB5/wlQ (envelope-from ) for ; Fri, 28 Aug 2020 17:49:46 +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 BB8649403D2 for ; Fri, 28 Aug 2020 17:49:45 +0000 (UTC) Received: from localhost ([::1]:33202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kBiVT-0004vd-Js for larch@yhetil.org; Fri, 28 Aug 2020 13:49:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kBiUv-0004vV-Te for emacs-orgmode@gnu.org; Fri, 28 Aug 2020 13:49:10 -0400 Received: from mout02.posteo.de ([185.67.36.66]:55429) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kBiUt-0000NU-K2 for emacs-orgmode@gnu.org; Fri, 28 Aug 2020 13:49:09 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id DE1DF2400FB for ; Fri, 28 Aug 2020 19:49:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1598636944; bh=2yf3MpS2o1l7RbVgi/B+R52mhHEPlryr1Y3bICGnJRw=; h=From:Subject:To:Cc:Date:From; b=Q5hU0PaEiWTVl7/CDFAnL51cQjrJXBMdIlBdM4ayXwyKlLsK1rO3L61RMEZRSy58x 6xvyehYBxAAEWOke5YL3niyU8fefTUy7XFERgDJgea0Hoemin+SUd+svoC5DCwMDr4 PKCW18qRpB26BKfWxTlHvo5H/BBRGqrDmhdqT5rihZwwEoY4Bi8X1WbGmYbp9WaBh6 zeAHcpJmTQC9xKo3x4NHC7NjBx8t7z1u4KqBc1Kgn+9FFokVWYSoEYxLrzq/bwHUBS mGTget1HO3iplw2qtkYeJImCvDuJeztU9jZ90zKI/xtSf6QdElTwrA9XSoRaKbJZaa HdjmnJ/SSMV+g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BdRt838CDz9rxY; Fri, 28 Aug 2020 19:49:04 +0200 (CEST) From: D Subject: Re: [PATCH] Re: Re: org-forward-heading-same-level and the invisible-ok argument To: Ihor Radchenko References: <87a6yi42ie.fsf@localhost> <61342cad-ed4c-59ef-d2fe-685de58df5de@posteo.net> <87tuwo2tr3.fsf@localhost> <67d953fc-3396-8038-4302-6e1ad4cde72c@posteo.net> <87tuwm7uo3.fsf@localhost> Message-ID: <8e63089c-ba3e-788a-f80f-c05b14d3228d@posteo.net> Date: Fri, 28 Aug 2020 19:49:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <87tuwm7uo3.fsf@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=185.67.36.66; envelope-from=d.williams@posteo.net; helo=mout02.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/28 13:49:05 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 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, NICE_REPLY_A=-0.809, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Q5hU0PaE; dmarc=pass (policy=none) header.from=posteo.net; 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-Spam-Score: -1.71 X-TUID: CbDdSeNYn/Q7 >> + (mapcar #'org-invisible-p >> + (number-sequence (line-beginning-position) >> + (1- (line-end-position))))) > > This is a bad idea. org--line-visible-p will be called for every single > invisible headline. If you check every single point at every single > invisible headline, it can be extremely slow. Hm, of course it would only check invisible headlines of the same level, thanks to the logic of the navigation command. However, I do see the concern. > Better do something like below (or maybe even without narrow-to-region, > not sure if that may cause significant overhead): > > (defun org--line-visible-p () > "Return t if the current line is partially visible." > (save-restriction > (narrow-to-region (line-beginning-position) (1- (line-end-position))) > (let ((visible t) > (p (point-min))) > (while (and visible (< p (point-max))) > (when (org-invisible-p p) > (setq visible nil)) > (setq p (next-single-char-property-change p 'invisible))) > visible))) The issue with that is that it reintroduces the thing the patch is trying to fix, as it considers any partially invisible line as fully invisible (while the opposite should be the case). I also don't see much of a difference when profiling, unless I severely screwed up. I just manually prepared a buffer with 10k invisible headings (each 83 chars long) and plugged a visible one of the same level above and below the huge invisible block. C-c C-f does take a second plus change in that case for both cases. The main issue is that a hot-circuit approach would only ever optimize navigating across many visible blocks, if we want a partially visible heading to be treated like a visible one (instead of an invisible one like it is at the moment). However, we could use a similar hack as the original implementation and only check a couple of characters, if performance really is a concern there. In that case, I think it would be best to check the *last* few characters (as it makes more sense that the stars at the beginning are hidden than the actual title at the end). That would mean to replace the original implementation with something like (defun org--line-visible-p () "Return t if the current line is partially visible." (let ((min-pos (max (line-beginning-position) (- (line-end-position) 3))) (max-pos (1- (line-end-position)))) (and (memq nil (mapcar #'org-invisible-p (number-sequence min-pos max-pos))) t))) which basically removes any relevant slowdown. But I'd really only recommend going that far if necessary, given it adds a random magic number. Thoughts? Cheers, D.