[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [RFC] Sloppy `org-element-context'?
From: |
Rasmus |
Subject: |
Re: [O] [RFC] Sloppy `org-element-context'? |
Date: |
Thu, 27 Mar 2014 22:34:14 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Hi,
Nicolas Goaziou <address@hidden> writes:
> As you may know, `org-element-context' returns the object under point,
> according to Org Syntax. The questions are: should it be a little
> sloppy, for convenience? And, if it should, what degree of sloppiness is
> acceptable?
Would it make sense to make it optional? For my personal hacks, I
much prefer to work with an element, if possible, and flexibility
could facility fast and easy hacks. On the other hand in Org-core
clarity and strictness is (probably) preferable. So something like
this
(let (org-element-strict) (FUN (org-element-context) ...)).
> Note that, at the time being, the function is already somewhat sloppy,
> because it will return an object right before point. In the following
> example, "|" is point. Even though it is not on the bold object,
> evaluating (org-element-context) there will give:
>
> "*bold*| text" => (bold ...)
> Should we go further? A recent discussion about opening links in node
> properties suggests that some users expect to encounter Org syntax
> there. I believe this is not generally desirable.
I haven't seen this discussion. I looked briefly at the suggested
patch; I don't understand why it would be necessary or desirable. But
I will not rule out that I have yet to consider the correct case!
> Anyway, here we are. I think it is important to define clearly what
> belongs to the syntax (I think it is quite good at the moment), what can
> be allowed for the sake of convenience, and what line should never be
> crossed (I firmly believe, for example, that `org-element-context'
> should never return objects in a comment, an example block, or
> a fixed-width area).
As a user I have no problems with the syntax.
As a hacker (not quite a developer!), I do at time desire more
flexibility with org-context to temporarily evaluating an element
under alternative assumptions of its properties. A recent example
evaluate $x^{z}$ as-if it isn't a latex-fragment.
—Rasmus
--
This space is left intentionally blank