> On Dec 14, 2014, at 6:25 AM, Nicolas Goaziou wrote: > > Jon Snader 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.