> On Dec 13, 2014, at 5:07 PM, Nicolas Goaziou wrote: > I don't think it needs to vary. As I suggested already, we can use cells > contents (in the appropriate column) as trimmed strings. So, it could be > built-in. > > Do you see any downside to it? Well, I’m just going by what happens now. In org-do-sort, each of the sort options sets a different extraction function. For example, if you want a numeric sort, the extraction function calls string-to-number, while if you want an alphabetic sort it calls org-sort-remove-invisible. 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. Anyway, what I was suggesting in my last post was that we duplicate the functionality of org-sort-list. 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?