Hi Ihor,
Ihor Radchenko writes:
> Yet, why not simply alter the headline parser a little bit to support
> empty titles + tag? Such headlines are used in some of the tests. See
> the attached patch.
I've now applied this patch -- let's not close the discussion though,
and keep in mind Nicolas
Hello,
Bastien writes:
> Ihor Radchenko writes:
>
>> Yet, why not simply alter the headline parser a little bit to support
>> empty titles + tag? Such headlines are used in some of the tests. See
>> the attached patch.
>
> I'm in favor of this change...
>
> Nicolas Goaziou writes:
>
>>
Hi Bastien,
I am strongly in favor of this change. It simplifies the grammar
significantly, and from my work on the laundry lexer and parser, I'm
99% certain that the current behavior is a bug that is the result of
gobbling the space after the stars in the headline. The correct
implementation
Hi all,
Ihor Radchenko writes:
> Yet, why not simply alter the headline parser a little bit to support
> empty titles + tag? Such headlines are used in some of the tests. See
> the attached patch.
I'm in favor of this change...
Nicolas Goaziou writes:
> Because, as I wrote, this is
Tom Gillespie writes:
> Hi Ihor,
> Yes, happy to put my test cases into the org element cases and
> visa versa.
Patches welcome ;)
Ihor Radchenko writes:
> David Masterson writes:
>> Testing the usefulness of extensions to the grammar before they're added
>> to the grammar..?
>
> For simple cases, there is org-element-update-syntax. Otherwise, you
> will probably better use the usual patch/new feature workflow and modify
>
Hi Ihor,
Yes, happy to put my test cases into the org element cases and
visa versa. My long term plan is to come up with a set of test cases
that are unambiguous and potentially ambiguous so that we can
determine the expected behavior in those cases, so this is a great
first step. Best,
Tom
David Masterson writes:
> Testing the usefulness of extensions to the grammar before they're added
> to the grammar..?
For simple cases, there is org-element-update-syntax. Otherwise, you
will probably better use the usual patch/new feature workflow and modify
the parsers directly.
Best,
Ihor
Tom Gillespie writes:
> Hi David,
> Laundry produces a full s-expression representation of the org
> parse tree (though it is still evolving). I haven't added a pass that
> converts it to some Racket internal representation (probably will be
> structs). If you get it installed and put #lang
Hi David,
Laundry produces a full s-expression representation of the org
parse tree (though it is still evolving). I haven't added a pass that
converts it to some Racket internal representation (probably will be
structs). If you get it installed and put #lang org at the top of an
org file you
Tom Gillespie writes:
> Hi all,
> Here is the 4th (or so) iteration of the grammar for titles that
> I think deals with most of the issues in this thread along with a
> bunch of nasty test cases. The previous attempts can be inspected in
> the git history, but long story short, it is
Hi all,
Here is the 4th (or so) iteration of the grammar for titles that
I think deals with most of the issues in this thread along with a
bunch of nasty test cases. The previous attempts can be inspected in
the git history, but long story short, it is extremely hard to find a
grammar that
Ihor Radchenko writes:
> David Masterson writes:
>
>> Could an extensible pre-hook that runs a list of functions take care of
>> the inconsistencies where each function recognizes one change to the
>> standard grammar and adjusts the input accordingly?
>
> Could you elaborate? For now, this
David Masterson writes:
> Could an extensible pre-hook that runs a list of functions take care of
> the inconsistencies where each function recognizes one change to the
> standard grammar and adjusts the input accordingly?
Could you elaborate? For now, this sounds like unnecessary
Tim Cross writes:
> David Masterson writes:
>> But having undefined behaviors is limiting on the portability of Org
>> because people are unwilling to pick it up and attempt to (say) create a
>> (partial) Org for other platforms (iPhone, Android, etc.).
> This is very much a secondary
Ihor Radchenko writes:
> Nicolas Goaziou writes:
>
>> Currently, what Org does in this situation is unimportant, because the
>> behaviour is simply undefined, which is, IMO, tolerable. If we decide to
>> define it, it needs to be documented.
>
> I agree that currently there is no urgent need to
Nicolas Goaziou writes:
> Currently, what Org does in this situation is unimportant, because the
> behaviour is simply undefined, which is, IMO, tolerable. If we decide to
> define it, it needs to be documented.
I agree that currently there is no urgent need to decide on this, but
there
David Masterson writes:
> Nicolas Goaziou writes:
>
>> Sebastian Miele writes:
>
>>> Sebastian Miele writes:
David Masterson writes:
> Sebastian Miele writes:
>> Currently org-syntax.org says that "TITLE can be made of any
>> character but a new line. Though, it will
Nicolas Goaziou writes:
> Sebastian Miele writes:
>> Sebastian Miele writes:
>>>David Masterson writes:
Sebastian Miele writes:
> Currently org-syntax.org says that "TITLE can be made of any
> character but a new line. Though, it will match after every other
> part have
Hello,
Sebastian Miele writes:
> Sebastian Miele writes:
>>David Masterson writes:
>>> Sebastian Miele writes:
Currently org-syntax.org says that "TITLE can be made of any
character but a new line. Though, it will match after every other
part have been matched." This does
Sebastian Miele writes:
>David Masterson writes:
>> Sebastian Miele writes:
>>> Currently org-syntax.org says that "TITLE can be made of any
>>> character but a new line. Though, it will match after every other
>>> part have been matched." This does not reflect the currently
>>> effective
Hi David and all,
David Masterson writes:
> Sebastian Miele writes:
>> Currently org-syntax.org says that "TITLE can be made of any
>> character but a new line. Though, it will match after every other
>> part have been matched." This does not reflect the currently
>> effective behavior that
Sebastian Miele writes:
> Sebastian Miele writes:
>> #+BEGIN_EXAMPLE
>> ,* A
>> ,* :B:
>> ,* C
>> #+END_EXAMPLE
>>
>> org-element-parse-buffer and org-match-sparse-tree make the second
>> headline have title ":B:" and no tags.
>
> Currently org-syntax.org says that "TITLE can be made of any
Ihor Radchenko writes:
> Either way is fine while it is consistent. I just tried to test some
> edge cases with existing org-element code:
>
> * TODO COMMENT :tag:
>
> org-element-at-point returns :raw-value "".
>
> * TODO :tag:
>
> :raw-value ":tag:"
Concerning tags, it is the expected behavior
Sebastian Miele writes:
> #+BEGIN_EXAMPLE
> ,* A
> ,* :B:
> ,* C
> #+END_EXAMPLE
>
> org-element-parse-buffer and org-match-sparse-tree make the second
> headline have title ":B:" and no tags.
Currently org-syntax.org says that "TITLE can be made of any character
but a new line. Though, it
Nicolas Goaziou writes:
> You cannot distinguish the following two cases:
>
> * :mytag:
> * :myheadline:
In my opinion, the cleanest solution would be to allow not only tags
specifications of one or more tags, but also the tags specification ":"
of zero tags in the headline. Then in
*
Nicolas Goaziou writes:
>>> I suggest to not tag emptiness. `org-set-tags' could raise an error in
>>> this case.
>>
>> Of course, we can go the other way around and recognise "* :myheadline:"
>> as non-empty headline with no tags.
>
> There is no spoon^W way. Or, no way is satisfactory. "Don't
Ihor Radchenko writes:
> Actually, my patch would solve the existing inconsistency.
> Org mode already puts tag fontification on :tag: in "* :tag:" headline;
> org-get-tags returns ("tag") on such headline; org-set-tags sets the
> :tag: on "*" headline making it look like "* :tag:" (which is
Nicolas Goaziou writes:
> Because, as I wrote, this is ambiguous. You cannot distinguish the
> following two cases:
>
> * :mytag:
> * :myheadline:
Makes sense.
> So, your patch would only move the problem elsewhere.
Actually, my patch would solve the existing inconsistency.
Org mode
Hello,
Ihor Radchenko writes:
>> However, empty headline + tags is ambiguous. The right solution is to
>> disambiguate it by inserting "something" as the headline you want to
>> tag, like a non-breaking space.
>
> Yet, why not simply alter the headline parser a little bit to support
> empty
Nicolas Goaziou writes:
> Empty headline titles are supported, and "org-syntax.org" makes it
> clear.
>
> However, empty headline + tags is ambiguous. The right solution is to
> disambiguate it by inserting "something" as the headline you want to
> tag, like a non-breaking space.
Yet, why not
Hello,
Sebastian Miele writes:
> worg/dev/org-syntax.org is not clear about whether the title of a
> headline is allowed to be empty. I occasionally (would like to) use
> headlines with empty titles, e.g., when a tag in some headline already
> provides all necessary information, and an
32 matches
Mail list logo
