[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [PATCH] org-table-beginning/end-of-field
From: |
Florian Beck |
Subject: |
Re: [O] [PATCH] org-table-beginning/end-of-field |
Date: |
Wed, 10 Sep 2014 19:08:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (gnu/linux) |
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