Nicolas Goaziou <m...@nicolasgoaziou.fr> 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