[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sort-lines including non ASCII

From: Eli Zaretskii
Subject: Re: sort-lines including non ASCII
Date: Fri, 08 Jul 2016 13:01:56 +0300

> From: Michael Heerdegen <address@hidden>
> Date: Fri, 08 Jul 2016 00:55:26 +0200
> > > BTW, a relevant question is: Is `compare-buffer-substring' faster than
> > > `buffer-substring'+`string<'?
> >
> > Hard to say.  Measuring is the easiest way to answer that.
> Here is a first try.  The speed difference is negligible here.

That's not unexpected, given that they do almost the same things.

> -(defun sort-lines (reverse beg end)
> +(defun sort-lines (reverse beg end &optional predicate)
>    "Sort lines in region alphabetically; argument means descending order.
>  Called from a program, there are three arguments:
>  REVERSE (non-nil means reverse order), BEG and END (region to sort).
> @@ -210,7 +210,13 @@ sort-lines
>        (goto-char (point-min))
>        (let ;; To make `end-of-line' and etc. to ignore fields.
>         ((inhibit-field-text-motion t))
> -     (sort-subr reverse 'forward-line 'end-of-line)))))
> +     (sort-subr
> +         reverse #'forward-line #'end-of-line nil nil
> +         (and predicate
> +              (lambda (a b)
> +                (funcall predicate
> +                         (buffer-substring (car a) (cdr a))
> +                         (buffer-substring (car b) (cdr b))))))))))

First, I suggest buffer-substring-no-properties, it should be faster
(properties are not needed in the predicate, right?).

More importantly, I might be missing something, but how does this
support additional arguments to predicate, like those that
string-collate-lessp accepts?  Do you expect users to write their own
predicate that hides those arguments?

> > My opinion is the opposite: I think it's more important to have a
> > command that could collate-order strings according to a user-specified
> > locale, than make sort-lines more flexible on the Lisp level.
> What would you do?  Just create an additional command?

If that's the best idea, then yes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]