From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Patch to implement sorting Org tables by IP address Date: Sat, 13 Dec 2014 17:01:50 +0100 Message-ID: <87oar78ro1.fsf@nicolasgoaziou.fr> References: <87r3w4a326.fsf@nicolasgoaziou.fr> <87tx0z8vxw.fsf@nicolasgoaziou.fr> <42DDD6AD-8F6F-4F85-840B-4C3946AD3C55@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xzp8S-0006fG-7u for emacs-orgmode@gnu.org; Sat, 13 Dec 2014 11:01:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xzp8I-0007RL-23 for emacs-orgmode@gnu.org; Sat, 13 Dec 2014 11:01:36 -0500 Received: from relay6-d.mail.gandi.net ([2001:4b98:c:538::198]:46856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xzp8H-0007RE-SE for emacs-orgmode@gnu.org; Sat, 13 Dec 2014 11:01:25 -0500 In-Reply-To: <42DDD6AD-8F6F-4F85-840B-4C3946AD3C55@mac.com> (Jon Snader's message of "Sat, 13 Dec 2014 10:19:41 -0500") 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: Jon Snader Cc: emacs-orgmode@gnu.org Jon Snader writes: > The problem with that solution is that the user has to answer the > additional prompts every time he calls org-table-sort-lines with > a custom sort. Imagine, for example, a networking researcher who often > builds tables that he or she wants to sort by IP address (or any other > special format). Why should the researcher have to answer additional > prompts every time a table needs to be sorted? He doesn't need to. He could write his own sorting function, and bind it to a key. > What if a user wants to call org-do-sort from Elisp? We=E2=80=99d have to= add > additional parameters for the custom sort functions. `org-do-sort' is an internal function, which isn't meant to be used publicly. It really should be named `org-table--do-sort' and be moved within "org-table.el". OTOH, we can extend `org-table-sort-lines' to allow custom sorting function as a parameter. > The solution I=E2=80=99m suggesting will simplify org-do-sort, make it ea= sily > expandable, and allow programmatic calls to it. I disagree. It makes `org-do-sort'/`org-table-sort-line' more powerful, but certainly not simpler. I'm pretty sure that anyone able to provide an alist like you suggest is able to write his own sorting function anyway. IOW, no one really gains any power in the process. > It doesn=E2=80=99t really make it easier for the user because the extract= ion > and compare functions will still have to be written (at least in most > cases I can think of). Extraction function is standard, AFAICT. Your solution doesn't solve second point either. > As for org-sort-list, it too would benefit from being table driven for > the same reason that org-do-sort would: it enables users to define > custom sorts. If we agree on this approach, I=E2=80=99ll submit another p= atch > for org-sort-list. As pointed out earlier, my concern is about simplicity. What about simplifying your proposal so that associations are (prompt-char . compare-function) Extraction function would be always the same: the contents of the cell, as a string, and prompt would be hard-coded for default compare functions? Regards,