From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Miele Subject: Re: [RFC] Document level property drawer Date: Tue, 01 Oct 2019 12:38:12 +0000 Message-ID: <87k19ovdxn.fsf@gmail.com> References: <87eezxrcwv.fsf@alphapapa.net> <84tv8tjywm.fsf@gmail.com> Reply-To: sebastian.miele@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:45844) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFHQ5-00080t-6V for emacs-orgmode@gnu.org; Tue, 01 Oct 2019 08:38:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFHQ3-00049e-8r for emacs-orgmode@gnu.org; Tue, 01 Oct 2019 08:38:21 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:42443) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iFHQ2-00046F-8F for emacs-orgmode@gnu.org; Tue, 01 Oct 2019 08:38:19 -0400 Received: by mail-wr1-x435.google.com with SMTP id n14so15290740wrw.9 for ; Tue, 01 Oct 2019 05:38:16 -0700 (PDT) Received: from tisch ([2a02:908:175c:4260:5ffc:7882:6024:ca5b]) by smtp.gmail.com with ESMTPSA id o9sm40096533wrh.46.2019.10.01.05.38.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Oct 2019 05:38:13 -0700 (PDT) In-reply-to: <84tv8tjywm.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Marco Wahl writes: > [..] > > I think the distinction between Org file and Org subtree should be kept > to a minimum. Wouldn't it be nice if Org files can be considered as Org > subtrees? Yes, this would be very nice. I have a related question or proposal. Up until now, I basically do not use property drawers except absolutely necessary, because properties are invisible by default. Properties "need to be inserted into a [..] drawer", and "in order to look inside the drawer, you need to move point to the drawer line and press =E2=80=98= =E2=80=99 there." A place that comes to mind where I really would like to use properties is the header-args property in order to specify parameters related to tangling for all src blocks in certain subtrees. But for such properties to satisfactorily work for me, they would have to be visible by default. E.g. I would want the header-args to be immediately visible just like they are when they are written after #+BEGIN_SRC or #+HEADER. Otherwise I would find myself constantly wondering whether this or that property drawer contains something essential and every TAB on a collapsed headline would have be followed by an accompanying move to the property drawer and a TAB there. On the other hand, there are properties that are very good candidates for remaining hidden by default, like ID. I would like to be able to make a clear distinction between properties that are visible by default and properties that are not. Maybe it would be possible to allow some #+.. syntax following headings for subtree properties that are visible by default. A requirement could be made that such property specifications always have to be followed by a property drawer, even if that is empty. Then everything #+.. that is before the property drawer would belong to the heading/subtree, and everything #+.. that follows the drawer would be treated as it is until now. Please tell me if I missed something and Org is already capable of something like that. If not, are there others who would like visible-by-default property specifications for headings/subtrees in addition to invisible-by-default property specifications in drawers, too? Finally, I would like to state an opinion: If there is visible-by-default (by #+..) and invisible-by-default (by drawers) syntax for headings/subtrees, including level 0, it may be viable to require them to be disjoint for each heading/subtree. Most probably it would be good practice, anyway. And the precedence question raised previously in this thread would be eliminated.