emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs vers


From: Eli Zaretskii
Subject: Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions
Date: Sun, 19 Jun 2016 19:30:21 +0300

> From: Robert Weiner <address@hidden>
> Date: Sun, 19 Jun 2016 12:12:12 -0400
> Cc: Drew Adams <address@hidden>, Richard Stallman <address@hidden>, 
>       emacs-devel <address@hidden>
> 
> On Sun, Jun 19, 2016 at 11:18 AM, Eli Zaretskii <address@hidden> wrote:
> 
>  As I wrote, I'd very much prefer a solution that only affects
>  outline-mode and its descendants. In those modes, ignoring invisible
>  lines could be the default behavior. I think we should also provide a
>  defcustom to make sort-lines behave in outline modes as it does today,
>  because, although I agree that the current behavior makes less sense
>  in those modes, it's nonetheless a valid use case that we should not
>  disallow completely.
> 
>  As for modes that are not descendants of outline-mode, the default
>  should IMO stay as it is now. Whether we want an option to make
>  sort-lines disregard invisible text in those other modes is something
>  I have no opinion about, and won't object if patches to that effect
>  are submitted.
> 
> This is a much clearer statement of your thinking. Thanks, it is helpful. It 
> sounds like you are suggesting that
> sort-lines have an internal conditional check for whether an outline mode is 
> active in the buffer to be sorted
> (rather than suggesting a separate outline-sort-lines function), correct?
> 
> So I will try for a patch that leaves the default behavior of sort-lines the 
> same unless an outline-mode or
> descendant is active in which case the default will be to group invisible 
> lines with visible ones. There will be a
> way to override the default behavior with the other behavior (not grouping 
> invisible lines with visible ones and
> treating them as separate lines for sorting). How does that sound?

Didn't think that far, but is it really clean for sort-lines to have
special code for some major mode?  I thought a better way is to
override the default behavior by having sort-lines call functions
through funcall or somesuch, and then outline modes could set the
appropriate variable to the function of their liking?

Just thinking aloud.



reply via email to

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