[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.
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, (continued)
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Robert Weiner, 2016/06/18
- RE: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Drew Adams, 2016/06/18
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Robert Weiner, 2016/06/18
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Eli Zaretskii, 2016/06/18
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Robert Weiner, 2016/06/19
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Eli Zaretskii, 2016/06/19
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Robert Weiner, 2016/06/19
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions,
Eli Zaretskii <=
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Robert Weiner, 2016/06/19
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Eli Zaretskii, 2016/06/19
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Robert Weiner, 2016/06/19
- RE: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Drew Adams, 2016/06/19
- Re: bug#23794: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, Stefan Monnier, 2016/06/19
- Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions, John Wiegley, 2016/06/19