From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: [RFC] Document level property drawer Date: Thu, 03 Oct 2019 13:06:18 -0500 Message-ID: <87muehbt5x.fsf@alphapapa.net> References: <87eezxrcwv.fsf@alphapapa.net> <84tv8tjywm.fsf@gmail.com> <87pnjgk1tz.fsf@alphapapa.net> <84eezvmodx.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39715) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iG5Uz-0007Y5-Rk for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 14:06:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iG5Uy-0007yf-UF for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 14:06:45 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:45406 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iG5Uy-0007yN-O2 for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 14:06:44 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1iG5Ur-000uMi-ST for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 20:06:37 +0200 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: > You say the visibility is better for the #+-property keywords. I say > they can occur _anywhere_ in the file and even in some drawers. See > above "#+CATEGORY: cat-doc-prop-keyword-2". > > Further you say > >>>> - However, it seems to me that the simplest, most natural protocol would >>>> be for later declarations to override earlier ones. > > This means that cat-doc-prop-keyword-2 from the example defines the > CATEGORY property which at least I find not so natural. And I already > stated what I find natural. Hi Marco, Org may allow #+KEYWORD: lines to appear anywhere in a file, including in arbitrary drawers, but that's up to the user. If the user chooses to hide them in drawers, it's his responsibility. AFAICT that's not a common or generally recommended thing to do. Most Org files have such lines at the top of the file, and some under a heading at the bottom of the file with other settings. Such lines don't need to be in drawers, and this proposal wouldn't change that. So I think it would be confusing if settings in a drawer at the top of the file were to absolutely override settings outside of drawers (which would mean that hidden settings could override plainly visible ones). The most natural protocol would be like written language: later declarations override earlier ones.