From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qLPlHRnkSV8tKwAA0tVLHw (envelope-from ) for ; Sat, 29 Aug 2020 05:14:01 +0000 Received: from aspmx2.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id AA3KGRnkSV8deQAAbx9fmQ (envelope-from ) for ; Sat, 29 Aug 2020 05:14:01 +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 aspmx2.migadu.com (Postfix) with ESMTPS id 143AB680A67 for ; Sat, 29 Aug 2020 05:12:39 +0000 (UTC) Received: from localhost ([::1]:38010 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kBt9L-0005S2-4J for larch@yhetil.org; Sat, 29 Aug 2020 01:11:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41136) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kBt8z-0005Ru-Na for emacs-orgmode@gnu.org; Sat, 29 Aug 2020 01:11:13 -0400 Received: from mail-pg1-x544.google.com ([2607:f8b0:4864:20::544]:46397) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kBt8x-00086U-By for emacs-orgmode@gnu.org; Sat, 29 Aug 2020 01:11:13 -0400 Received: by mail-pg1-x544.google.com with SMTP id 31so1412179pgy.13 for ; Fri, 28 Aug 2020 22:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=AuBPP0UugfNdlGVVEgNFX7AvM1r+nNOn29v6qDgf6fw=; b=GDsXaBTiQqbg4LXaMFQ3WhuE8BcEycBlohaNQ2d0MoHboxsPTfhCpX+XW8idbcl76a YiFxK55ScJ+1cFYapvXCPoiTuPiD4IVYyeyKWMFPWoqJKAUzrh+gTU/F7+CiAES0CjKd LW2ipNEORnEIDUITJ7AYHQTf0pQs36rNrt490fV6sNz6EooPfKJKUv6nM6CfgEcfdT6H PC7qwvmn2a0QonNM3mfuiMmQHuwDEhzyvfuZrZzzc+T4+F/unP2ysYpHDrCsuebVMmVI D6gQU0Vt0Bb96u02C0zfYHl2KA1QlBhetAP9gMiXk7Zc/gRc2bfl85oY4NPdqeFPPMuq GnLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=AuBPP0UugfNdlGVVEgNFX7AvM1r+nNOn29v6qDgf6fw=; b=uWaGD5tI3Y+Ahhcp+XE+P0EZvr0Y2iJtOlhpY7fFmosXotAQt0mcV0Uf/Fq90/Bgr+ 0++2aYkHZ1IB13ooRk8WXqWqUtbDRKlTbRbyVoc/guR2RFZogDc7xsrQhKBqXzuZrMY3 D4kMNqDiWUqGIpKBcvx2jADpiwvTJmKwczFdRu+W3yEO25egRR9pJbZNVruDoTT9YczF L98yqKG82J/B4crnmqyRMgappySmppft/pZJUvDxz45V5zYaeR0mYMYSYImhjFCs7QLe qOkFyhsZShNjh032GNIiRl06FF3TRBkE2P72NR20eIgnv6XPgDke/bE4v6qrHTyQmYTK zTmQ== X-Gm-Message-State: AOAM531sxYXxY7o7meOTaPW0+j8Q+mtGAAQvlEA8r8Ko53D6MIG0akfI L0l4862haOUZUDwc1PVIutBnZSh/5ROpwQ== X-Google-Smtp-Source: ABdhPJyYlZec5K91PKEEwJNtJGAVxCMuW1iKAtkNaeLv6J/eST8LRWJITAOl/zdWR/jrHplUrYesUA== X-Received: by 2002:a62:2cc2:: with SMTP id s185mr1924829pfs.10.1598677869746; Fri, 28 Aug 2020 22:11:09 -0700 (PDT) Received: from localhost ([104.250.131.79]) by smtp.gmail.com with ESMTPSA id f24sm841699pjt.53.2020.08.28.22.11.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Aug 2020 22:11:08 -0700 (PDT) From: Ihor Radchenko To: D Subject: Re: [PATCH] Re: Re: org-forward-heading-same-level and the invisible-ok argument In-Reply-To: <8e63089c-ba3e-788a-f80f-c05b14d3228d@posteo.net> References: <87a6yi42ie.fsf@localhost> <61342cad-ed4c-59ef-d2fe-685de58df5de@posteo.net> <87tuwo2tr3.fsf@localhost> <67d953fc-3396-8038-4302-6e1ad4cde72c@posteo.net> <87tuwm7uo3.fsf@localhost> <8e63089c-ba3e-788a-f80f-c05b14d3228d@posteo.net> Date: Sat, 29 Aug 2020 13:10:03 +0800 Message-ID: <87364611hw.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::544; envelope-from=yantar92@gmail.com; helo=mail-pg1-x544.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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.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: aspmx2.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=GDsXaBTi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx2.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.21 X-TUID: 2rH+ak5fklni > 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). Oops. Sorry, I wrote that function without much thinking. Indeed, it should be (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 nil) (p (point-min))) (while (and (not visible) (< p (point-max))) (when (not (org-invisible-p p)) (setq visible t)) (setq p (next-single-char-property-change p 'invisible))) visible))) > 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. I also tested on one of my largest org files. There is not much difference and your version should be acceptable. > 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? I do not think it will make much difference. Mapcar will anyway apply #'org-invisible-p for all points at the headline (well, all, but 3 points). Probably, it is easier if you just use seq-every-p instead of mapcar on (number-sequence max-pos min-pos -1). The result of seq-every-p will be inverse of the currently used expression. Best, Ihor D writes: >>> + (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.