From: Jon Snader <jsnader@mac.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org
Subject: Re: Patch to implement sorting Org tables by IP address
Date: Sun, 14 Dec 2014 10:19:34 -0500 [thread overview]
Message-ID: <63EA1170-B4E2-4CB8-95CD-77AF7AA117C3@mac.com> (raw)
In-Reply-To: <87tx0y79st.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]
> On Dec 14, 2014, at 6:25 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Jon Snader <jsnader@mac.com> writes:
>> Really, this doesn’t matter because I was
>> merely commenting on why (prompt . comparison) isn’t enough. Of
>> course, you could roll any special extraction functionality into the
>> comparison but I don’t really like that.
>
> Then
>
> (prompt comparison extraction)
>
> while still allowing
>
> (prompt comparison)
>
> which would be a special case for
>
> (prompt comparison #'org-sort-remove-invisible)
That would make sense. Also, I think the prompt should be something like “(t)ime” so that the prompt message can be built on-the-fly. The `t’ (or whatever) can be extracted from the prompt to build a list of legal answers.
>
>> Anyway, what I was suggesting in my last post was that we duplicate
>> the functionality of org-sort-list.
>
> This what I initially suggested. However, I'm trying to see if a table
> approach would ultimately be better.
You’ve convinced me that your original suggestion is the right one. It allows users to add additional sorting options if they need one. Even a user without Elisp skills could use it (by calling it interactively) if the extraction function was already available either in Emacs/Org itself or locally.
The important thing to me is that the user have the capability to add another sort when (admittedly rarely) needed. The ?f ?F mechanism provides the necessary escape hatch and is what current users are used to.
>
>> There, if you’re calling it programmatically you specify getkey-func
>> and compare-func. If you call it interactively, it asks you for the
>> extraction function (which must return a string or number) and it
>> tests it to see which comparison function to use. I like this approach
>> because it makes org-sort-list and org-table-sort-lines work the same
>> way. What’s not to like?
>
> The networking researcher will have to provide its sorting function each
> time, which was one of your arguments.
Sorry. That was because I didn’t completely understand your suggestion. The point is that the ?f ?F mechanism enables both interactive AND programmatic use. The researcher could write a bit of Elisp that calls org-table-sort-lines with his own extraction and comparison functions and then call that Elisp interactively.
As I see it, we’ve reached the conclusion that we should either have some sort of minimal table-driven mechanism or duplicate the functionality in org-sort-list. I like duplicating the org-sort-list functionality best. As you pointed out before, org-do-sort is an internal function and we probably shouldn’t let users mess with it. We could, I suppose, move all the work out to org-table-sort-lines but then org-do-sort is little more than a call to sort.
As I said above, you’ve convinced me that ?f ?F is the right solution.
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
next prev parent reply other threads:[~2014-12-14 15:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 19:16 Patch to implement sorting Org tables by IP address Jon Snader
2014-12-12 22:58 ` Nicolas Goaziou
2014-12-13 14:19 ` Jon Snader
2014-12-13 14:29 ` Nicolas Goaziou
2014-12-13 15:19 ` Jon Snader
2014-12-13 16:01 ` Nicolas Goaziou
2014-12-13 18:47 ` Jon Snader
2014-12-13 22:07 ` Nicolas Goaziou
2014-12-13 22:37 ` Jon Snader
2014-12-14 11:25 ` Nicolas Goaziou
2014-12-14 15:19 ` Jon Snader [this message]
2014-12-14 17:18 ` Nicolas Goaziou
2014-12-17 17:31 ` Jon Snader
2014-12-20 11:57 ` Nicolas Goaziou
2014-12-20 18:40 ` Jon Snader
2014-12-20 20:55 ` 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=63EA1170-B4E2-4CB8-95CD-77AF7AA117C3@mac.com \
--to=jsnader@mac.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/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).