> On Dec 13, 2014, at 9:29 AM, Nicolas Goaziou wrote: > I think my proposal is simpler: add ?f and ?F to built-in options, in > which case user is prompted for a custom sorting function (in your case, > `org-ip-lessp'). It is also more consistent with `org-sort-list’. 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? What if a user wants to call org-do-sort from Elisp? We’d have to add additional parameters for the custom sort functions. The solution I’m suggesting will simplify org-do-sort, make it easily expandable, and allow programmatic calls to it. It is, it seems to me, consistent with how Emacs does things: add to little Elisp to expand a functionality to cover an additional case. As things stand now, it’s not possible for me to add an IP sort locally. Your solution does provide that, after a fashion, but at the cost of having to enter additional information each time I call the sort. It doesn’t really make it easier for the user because the extraction and compare functions will still have to be written (at least in most cases I can think of). 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’ll submit another patch for org-sort-list. > Also, IMO, IP address sort should not be built-in, and needs not with > the proposal above. I don’t care overmuch if the IP address sort is built in (although others might appreciate the functionality) only that I have a way of adding it locally.