emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Patch to implement sorting Org tables by IP address


From: Jon Snader
Subject: Re: [O] Patch to implement sorting Org tables by IP address
Date: Sun, 14 Dec 2014 10:19:34 -0500

> On Dec 14, 2014, at 6:25 AM, Nicolas Goaziou <address@hidden> wrote:
> 
> Jon Snader <address@hidden> 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: signature.asc
Description: Message signed with OpenPGP using GPGMail


reply via email to

[Prev in Thread] Current Thread [Next in Thread]