From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id kBqFIHZcxWN25wAAbAwnHQ (envelope-from ) for ; Mon, 16 Jan 2023 15:17:26 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id IP2FIHZcxWNIBAAAauVa8A (envelope-from ) for ; Mon, 16 Jan 2023 15:17:26 +0100 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 3C4D111A1D for ; Mon, 16 Jan 2023 15:17:26 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHQHy-0004hK-6E; Mon, 16 Jan 2023 09:16:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHQHm-0004fA-2t for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 09:16:37 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHQHj-00037m-KK for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 09:16:29 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D198A2401BA for ; Mon, 16 Jan 2023 15:16:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1673878584; bh=RPkgRu4AQ1jPa44W/+az1ycp7tOMpksXjcM/LecqlkE=; h=From:To:Cc:Subject:Date:From; b=VdF0Uw+5Rv0Ja57WXh9VqkVLNB7EN2RM4qQ8zSgk4RTpZxkeY2UGyZw0lewveqEe8 IXuha2Jdld8VUq4WpLAJ59gF5E01GRjl6ksYC3c0ekLAlYAi8pGOA6wgUeSztIQa1E a9miEwTJlNrX3fWggoS1r/5RQli+qNf/HVAm/koXg8tpEcLVib9YbU1PyJWKIprIDR wc1jPSXIaJoIvtJUpQWfJAfa3DqXKKGXZkx9fDiXMtPtw/zo6PIWmy+5HHLf/H+qNt Gp1UFAT9/W6wi7DLj55FIt7O2g+lfv4tr9MrPt8xqFIM+eMNSHCa0mlNCsWYcZayRZ szIRpWmKxG+ww== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NwYwf6gS0z9rxD; Mon, 16 Jan 2023 15:16:18 +0100 (CET) From: Ihor Radchenko To: Sterling Hooten Cc: emacs-orgmode@gnu.org Subject: Re: Completely hide properties drawer in 9.6 In-Reply-To: References: <4CC6A1F4-0B08-44E0-AE4D-60CA11636663@gmail.com> <87k02uqrbw.fsf@localhost> <3B566A00-1AAB-4CFC-96C2-C25D05AD5855@gmail.com> <87bko6t3tb.fsf@localhost> <25EC8C19-CFD9-4973-8F5B-896AF45C7002@gmail.com> <87tu1xx20u.fsf@localhost> Date: Mon, 16 Jan 2023 14:16:49 +0000 Message-ID: <87wn5mk1im.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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.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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673878646; a=rsa-sha256; cv=none; b=hF7UYP+owrMjmSt0gMKPlrZkp2KNRq0ZPkbFliWKZMw0Uuvt+okRPM+nzJMO4hkxgzl2a4 fO6/9bhrG0fYTWcxDO2v8UVkfnxaAROhRgtcz4lHmzRlDNkhqa5PDuH8uplhYxFxEw0461 N2Xy7brh9cLpwZVMqbYdLPluRxim30JkDtjmzuXQyV7XhzaYAcqVUh09UUbSgljNi/GYMG mktGoSHjcY/dGzflWvM2mOu5KXUfkcA3ZJjvuD9e6XdZ9oh7lPaJcs8ARXmydaIr+r7Y/C eKGLSmHQS0DOUFnXJCE0oO2BlNPfkcWNKZU59Ii4ePwETM1O7VbN9VmQD4TbZA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=VdF0Uw+5; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673878646; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=4o/YndB7hA6Mikj4Z+WeFZbf2jWZECKwOnu/fe9JV/s=; b=MaqSvS7gDJ88MGIdabsE6iB2kSotrU/DXrfQNJf3u9g2IFr/erZNvybY15r6/W5o0EV/0v kstuil1kkWw1FLlpnXly6nA8SV3XRbpGm53lIzZuTGhgfeTJwzjv4FjWpAS5t7AOVAchgh OEyP/K5nlAUW30ZynuHMsQelWHA28jPqvQFWaf5tNMADJ1kWmg/ouDt1qJAR0oYjskt1vA BYSBBgsbL2smY/w+RThN7MCUPnqknNqPyY3s73yZ5fyXVZcmHwnzTa/4XZPC8zUsxyeybZ yTg2fTxf7efZbwQIkvdgCI0uMtEdRjOE51XYVgsz7rEEf95G5gGv2V/CAIih2A== X-Migadu-Spam-Score: -6.07 X-Spam-Score: -6.07 X-Migadu-Queue-Id: 3C4D111A1D X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=VdF0Uw+5; 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"; dmarc=pass (policy=none) header.from=posteo.net X-TUID: Uu0vzj1bWBLK Sterling Hooten writes: > In order to both have newly added properties automatically adopt the > invisibility text-property the interior characters of the properties > box needs to be sticky. But this conflicted with being able to type > with the point before the hidden text. To satisfy both these > requirements I applied =property-drawer-hidden-interior= as a folding > spec which was sticky to all but the first two and last two characters > of the property drawer. Then I applied =property-drawer-hidden-edges= > to these two remaining chunks. In this way you can add in new > properties and they'll be invisible, but typing at the edges appears > visibly. > > Is there an alternative way of doing this without two separate folding > specs? Maybe an additional key for ":interior-sticky" which is sticky > on all characters sharing the same spec, but not sticky at the front > and rear? In theory, it is possible to add something like :interior-sticky. However, it will be against how Emacs' sticky properties work. An alternative approach you may use is hooking into font-lock. Fontification will be re-applied upon editing, and you can hide only the property drawer and nothing else. And you will not need to deal with edge cases with inserting text. > I couldn't quite figure out what the :fragile setting was. :fragile makes sure that things are unfolded when a drawer is no longer a drawer. Imagine: :drawer: Some text. :end: Then, you delete ":": drawer: Some text. :end: :fragile defines rules allowing to auto-unfold the drawers (or anything else) as needed. We would not want the drawer above to remain folded as you would not be able to use to unfold any more - tab will no longer see a "drawer" at point. > #+begin_src emacs-lisp > (defun org-fold-show-property-drawer (&optional arg) > "Unhide property drawer in heading at point. > With non-nil ARG show the entire subtree." > (org-with-wide-buffer > (org-back-to-heading) > (let* ((beg (point)) > (end (if arg (org-element-property :end (org-element-at-point)) > (org-next-visible-heading 1) > (1+ (point))))) > (org-fold-region beg end nil > 'property-drawer-hidden-edges) > (org-fold-region beg end nil > 'property-drawer-hidden-interior)))) > > (defun org-fold-hide-property-drawer (&optional arg) > "Completely hide the property drawer in heading at point. > With non-nil ARG hide the entire subtree." > (org-with-wide-buffer > (org-back-to-heading) > (let* ((beg (point)) > (end (if arg (org-element-property :end (org-element-at-point)) > (org-next-visible-heading 1) > (1+ (point))))) > (org-fold--hide-property-drawers beg end)))) > #+end_src > > Is there a faster or better way of getting the boundary points for a > heading without the subheadings? I've wanted this feature in a few > other situations but don't know a clean way to fetch it. I suppose you > could also just have that the regex stop searching for the beginning > of the property box after 2 lines past the heading, since the > properties box needs to be in the first two lines. You can use the following at or inside a drawer: (org-element-lineage (org-element-at-point) '(section)) :begin and :end will contain current section boundaries. "section" is all the text under the parent heading, up to the first child. The AST is: (heading (section [(planning)] [(property-drawer)] [(paragraph1)] ...) (subheading) ...) > The default =org-end-of-meta-data= will go past any blank lines and > only stop at a non-empty line. I would prefer for hitting on > a headline to act as if the planning line and properties box were > immutable, and just pass directly after them. For this I wrote a > version that will stop after the logbooks or property drawer. > > Is there a better way to do this? I tried using the match-data but it > seemed unreliable (if there's nothing but blank lines after the meta > data it matches on the next heading). You can just use `org-element-at-point'. At planning, `org-element-type' will be 'planning. At property drawer - 'property-drawer. At drawer - 'drawer. :end property will include blank lines, but you can also check :post-blank that will contain the number of blank lines at the end. Check out `org--at-headline-data-p' implementation. > I am also experiencing a weird (overlay?) problem with i-search. After > implementing when I search for things it will make all of the windows > greyed out, and then only show the matching characters. I can see the > text again if I =mark-whole-buffer=. But I don't know what's causing > this. No idea here. Need more information. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at