From: Florian Beck <fb@miszellen.de>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] org-table-beginning/end-of-field
Date: Wed, 10 Sep 2014 19:08:00 +0200 [thread overview]
Message-ID: <871trjo13j.fsf@sophokles.streitblatt.de> (raw)
In-Reply-To: 87oauna8xm.fsf@nicolasgoaziou.fr
Nicolas Goaziou <mail@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
next prev parent reply other threads:[~2014-09-10 17:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-08 5:37 [BUG] org-table-beginning/end-of-field Florian Beck
2014-09-08 10:25 ` Nicolas Goaziou
2014-09-08 12:17 ` [PATCH] org-table-beginning/end-of-field Florian Beck
2014-09-08 15:30 ` Nicolas Goaziou
2014-09-09 11:09 ` Florian Beck
2014-09-10 13:42 ` Nicolas Goaziou
2014-09-10 17:08 ` Florian Beck [this message]
2014-09-12 8:29 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871trjo13j.fsf@sophokles.streitblatt.de \
--to=fb@miszellen.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).