From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Beck Subject: Re: [PATCH] org-table-beginning/end-of-field Date: Wed, 10 Sep 2014 19:08:00 +0200 Message-ID: <871trjo13j.fsf@sophokles.streitblatt.de> References: <87mwaaekp8.fsf@sophokles.streitblatt.de> <871trmbe92.fsf@nicolasgoaziou.fr> <87egvme27x.fsf_-_@sophokles.streitblatt.de> <87wq9e9lkn.fsf@nicolasgoaziou.fr> <87ppf59hjs.fsf@sophokles.streitblatt.de> <87oauna8xm.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRlNe-0000sM-An for emacs-orgmode@gnu.org; Wed, 10 Sep 2014 13:08:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRlNY-000366-0S for emacs-orgmode@gnu.org; Wed, 10 Sep 2014 13:08:30 -0400 Received: from plane.gmane.org ([80.91.229.3]:39731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRlNX-00035h-Qx for emacs-orgmode@gnu.org; Wed, 10 Sep 2014 13:08:23 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XRlNW-0003vj-A4 for emacs-orgmode@gnu.org; Wed, 10 Sep 2014 19:08:22 +0200 Received: from ip-109-43-214-176.web.vodafone.de ([109.43.214.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Sep 2014 19:08:22 +0200 Received: from fb by ip-109-43-214-176.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Sep 2014 19:08:22 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou 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 "" in the string to avoid finding the > correct position later. E.g., > > "| Cell:1 | Cell2 |Cell3|\n| Cell4 | | Cell5|" Great, thanks! -- Florian Beck