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

[Nicolas Goaziou]

Jon Snader <address@hidden> writes:

> 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?

He doesn't need to. He could write his own sorting function, and bind it
to a key.

> What if a user wants to call org-do-sort from Elisp? We’d have to add
> additional parameters for the custom sort functions.

`org-do-sort' is an internal function, which isn't meant to be used
publicly. It really should be named `org-table--do-sort' and be moved
within "org-table.el". OTOH, we can extend `org-table-sort-lines' to
allow custom sorting function as a parameter.

> The solution I’m suggesting will simplify org-do-sort, make it easily
> expandable, and allow programmatic calls to it.

I disagree. It makes `org-do-sort'/`org-table-sort-line' more powerful,
but certainly not simpler. I'm pretty sure that anyone able to provide
an alist like you suggest is able to write his own sorting function
anyway. IOW, no one really gains any power in the process.

> 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).

Extraction function is standard, AFAICT. Your solution doesn't solve
second point either.

> 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.

As pointed out earlier, my concern is about simplicity.

What about simplifying your proposal so that associations are

  (prompt-char . compare-function)

Extraction function would be always the same: the contents of the cell,
as a string, and prompt would be hard-coded for default compare
functions?


Regards,