Hi Adam,
Adam Porter writes:
> There are a lot of deprecation recommendations in your attached
> document:
>
> > I propose to depricate property-keywords
> > I propose to depricate the Options-keyword
> > I propose to relabel these keywords as document keywords
> > I propose to depricate the
Gustav,
There are a lot of deprecation recommendations in your attached
document:
> I propose to depricate property-keywords
> I propose to depricate the Options-keyword
> I propose to relabel these keywords as document keywords
> I propose to depricate the #+CATEGORY syntax
> I propose to
> Sooo, a separate branch is created in the Org mode repository named
> "next". I'm not entirely sure how we're supposed to work with it. But
> I've anyways pushed my (non-breaking) patch there.
Thanks again.
One issue for me is the positioning of the level 0 property drawer.
Having the
Gustav Wikström writes:
[...]
> Sooo, a separate branch is created in the Org mode repository named
> "next". I'm not entirely sure how we're supposed to work with it. But
> I've anyways pushed my (non-breaking) patch there.
Okay, thanks. I try to follow the development on the 'next' branch.
Hi!
I'll start with the most important info at the top. I've applied the
patch! But before anyone comes screaming I'll just say it's applied on
a separate branch. After consultation with Nicolas Goaziou that was
seen as the most reasonable thing to do. The idea is that it's high
time to start
Gustav Wikström writes:
> I'd like to take the next step with this patch. I'm hesitant to do it
> without wider support though, since only a few people have commented.
>
> @Marco Wahl; As I understand you've applied the patch and tried it
> out. Have you found any issues yet? What do you think
Gustav Wikström writes:
> Hi again,
>
> I'd like to take the next step with this patch. I'm hesitant to do it
> without wider support though, since only a few people have commented.
>
> @Marco Wahl; As I understand you've applied the patch and tried it
> out. Have you found any issues yet? What
Hi again,
I'd like to take the next step with this patch. I'm hesitant to do it without
wider support though, since only a few people have commented.
@Marco Wahl; As I understand you've applied the patch and tried it out. Have
you found any issues yet? What do you think of the patch after
Adam Porter writes:
> Marco Wahl writes:
>
>> One could even think about letting fade out the "#+"-file-wide
>> property definition syntax or at least think about a good place within
>> a file or a subtree for those definitions. (There is at least
>> Sebastian Miele who wants to keep that
Hi Matt,
Thanks for your comment! I can assure you that you need not worry
about the propsed patch here in terms of your workflow. This is in no
way a hasty, sloppy work. Care has been taken when developing it to
not break anything existing. I hear your concerns on the larger topic
of keywords
Hi Adam,
> > In no way is this a major, breaking change. No document you have
> > today will break by the introduction of this. The only thing changing
> > is if you *actively* create a document level property drawer and
> > choose to enter a property there that you already have defined in
On Sat., Oct. 5, 2019, 6:10 p.m. Adam Porter, wrote:
> Marco Wahl writes:
>
> > Just I got the idea that for a good part this discussion is about
> > personal preferences.
>
> Personal preferences are relevant to this issue in that Org is flexible
> and allows users to configure it accordingly.
Marco Wahl writes:
> Just I got the idea that for a good part this discussion is about
> personal preferences.
Personal preferences are relevant to this issue in that Org is flexible
and allows users to configure it accordingly. But that is not the only
consideration at stake. Consistency,
Marco Wahl writes:
> One could even think about letting fade out the "#+"-file-wide
> property definition syntax or at least think about a good place within
> a file or a subtree for those definitions. (There is at least
> Sebastian Miele who wants to keep that syntax as he stated in another
>
Gustav Wikström writes:
>> In Org, some keywords are special, like #+CATEGORY. For many years,
>> such keywords have had file-wide effects regardless of their placement
>> in the file. IIUC, your proposal would change that, and that would
>> still be a major, breaking change.
>
> This seems
Hi again Adam,
> IIUC, your proposal would work like this:
>
> #+BEGIN_SRC org
> :PROPERTIES:
> :CATEGORY: Gamma
> :END:
>
> # Category here is "Gamma"
>
> ,* Node 1
>
> # Category here is "Gamma"
>
> ,* Node 2
> :PROPERTIES:
> :CATEGORY: Beta
> :END:
>
> # Category
Adam Porter writes:
> 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
Adam Porter writes:
> Gustav Wikström writes:
>
>> I'd argue that precedence already works that way. One has to take
>> inheritance into account. With inheritance turned on, tell me which
>> value for Property1 is used for the nodes in the following example:
>>
>> #+begin_src org
>> ,* Node 1
Hi Gustav,
Gustav Wikström writes:
> I'd argue that precedence already works that way. One has to take
> inheritance into account. With inheritance turned on, tell me which
> value for Property1 is used for the nodes in the following example:
>
> #+begin_src org
> ,* Node 1
> ,* Node 2
>
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
Hi Sebastian,
> From: Sebastian Miele
> Subject: Re: [O] [RFC] Document level property drawer
> Date: Tue, 01 Oct 2019 12:38:12 +
> ...
> I would like to be able to make a clear distinction between properties
> that are visible by default and properties that are n
Adam Porter writes:
> Marco Wahl writes:
>
>> Adam Porter writes:
>>
>>> Gustav Wikström writes:
>>>
3) Properties defined in a property drawer will have precedence over
properties defined as a property keyword, if the same property is
defined using both conventions.
>>>
Marco Wahl writes:
> Adam Porter writes:
>
>> Gustav Wikström writes:
>>
>>> 3) Properties defined in a property drawer will have precedence over
>>>properties defined as a property keyword, if the same property is
>>>defined using both conventions.
>>
>> That protocol seems unnatural
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
Hi Adam,
> How does it differ from what was previously proposed?
It differs by not introducing the document concept in Org element.
Removing that means there is no reason to wait for another major
version of Org mode.
> What exactly does "will (shall)" mean?
You can ignore the inside of the
Adam Porter writes:
> Gustav Wikström writes:
>
>> 3) Properties defined in a property drawer will have precedence over
>>properties defined as a property keyword, if the same property is
>>defined using both conventions.
>
> That protocol seems unnatural and confusing to me:
>
> - If
Gustav Wikström writes:
> Hi,
>
> This patch introduces a document level property drawer.
>
> This has been discussed previously in a larger context:
> - https://lists.gnu.org/archive/html/emacs-orgmode/2019-06/msg0.html
> -
Hi,
> This patch introduces a document level property drawer.
[...]
> What do you say?
I'll install the patch and have a look how it feels in my little
personal Org universe.
Thanks,
--
Marco
Hi,
This patch introduces a document level property drawer.
This has been discussed previously in a larger context:
- https://lists.gnu.org/archive/html/emacs-orgmode/2019-06/msg0.html
- https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00339.html
-
29 matches
Mail list logo
