Jon Snader <jsna...@mac.com> writes: > 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.
Then (prompt comparison extraction) while still allowing (prompt comparison) which would be a special case for (prompt comparison #'org-sort-remove-invisible) > 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. > 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. Regards,
