Re: [O] [PATCH] org-table-beginning/end-of-field

[Florian Beck]

Nicolas Goaziou <address@hidden> writes:

> the next (or maybe previous) cell. You may want to try
> `org-element-context' in the following places, where X denotes cursor:
>
>   | a | b |
>   X c | d |
>
>   X a | b |
>   | c | d |

This I did.


> X | a | b |
>   | c | d |
>
>   | a | b | X
>   | c | d |
>
>   | a | b |
> X | c | d |

This is arguably outside the scope of org-table-beginning/end, isn't it?

Come to think of it, these functions should only move to the
beginning or end of the field, period. Then handle the special case in
org-forward/backward-sentence or create two new functions.

> I don't think `org-element-get' should go into "org-element.el" in its
> current implementation. It is tied to a position, which implies to take
> care of boring stuff like buffer narrowing. It doesn't allow to re-use
> an already computed element or object either, which is sub-optimal.

Yes, it should be split into two functions.

> However, the feature is useful enough that some function could provide
> something similar. Maybe the following one:
>
>   (defun org-element-parent (blob &optional types genealogy)
>     "Return BLOB's parent, or nil.
>
>   BLOB is an object or element.
>
>   When optional argument TYPES is a list of symbols, return the
>   first element or object between BLOB and its ancestors whose type
>   belongs to that list.
>
>   When optional argument GENEALOGY is non-nil, return a list of all
>   ancestors, from closest to farthest.
>
>   When BLOB is obtained through `org-element-context' or
>   `org-element-at-point', only ancestors from its section can be
>   found. There is no such limitation when BLOB belongs to a full
>   parse tree."
>     (if (not (or types genealogy)) (org-element-property :parent blob)
>       (let ((up blob) ancestors)
>         (while (and up (not (memq (org-element-type up) types)))
>           (when genealogy (push up ancestors))
>           (setq up (org-element-property :parent up)))
>         (if genealogy (nreverse ancestors) up))))
>
> Its name is a bit confusing since it can return BLOB under some optional
> argument combination (i.e., if BLOB's type belongs to TYPES). However,
> it covers most, if not all, needs about ancestors. WDYT?

Yes this works. Making TYPES into a list is a nice touch. However:
 - the advertised functionality (returning the parent) is only
 marginally useful and handled in half a line of code; whereas most of
 the functionality is hidden as optional;
 - this leads to confusing behaviour, as you have noted, because
 the type of object I'm looking for, is not necessarily the parent;
 - BLOB on the other hand should be optional, because defaulting it to
 org-element-context would be highly useful.
 - not sure what GENEALOGY is useful for; if the user also specified
 TYPES, this returns the ancestors up to but NOT including those of TYPE.

>> Also, I modified `org-element-table-cell-parser', because otherwise
>> :contents-begin and :contents-end point to the end of the cell. Not sure
>> if this breaks anything.
>
> Usually, when an object has no contents (e.g., a link without
> description), both :contents-begin and :contents-end are nil. It is less
> confusing than providing an arbitrary buffer position.

That's another possibility. Unlike a link without description, one might
argue that an empty cell has a natural contents position.


> Minor note: you can insert "<point>" in the string to avoid finding the
> correct position later. E.g.,
>
>   "| Cell:<point>1   | Cell2 |Cell3|\n| Cell4 |     | Cell5|"

Great, thanks!


-- 
Florian Beck