GNU bug report logs - #23794
Make sort-lines respect visible lines

Previous Next

Full log

Message #23 received at 23794 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rswgnu <at> gmail.com
Cc: 23794 <at> debbugs.gnu.org, rms <at> gnu.org, drew.adams <at> oracle.com,
 emacs-devel <at> gnu.org
Subject: Re: Emacs bug #23794;
 sort-line behavior regressed from prior Emacs versions
Date: Sun, 19 Jun 2016 19:55:14 +0300

> From: Robert Weiner <rsw <at> gnu.org>
> Date: Sun, 19 Jun 2016 12:51:08 -0400
> Cc: Drew Adams <drew.adams <at> oracle.com>, Richard Stallman <rms <at> gnu.org>, 
> 	emacs-devel <emacs-devel <at> gnu.org>, 23794 <at> debbugs.gnu.org
> 
> On Sun, Jun 19, 2016 at 12:30 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  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?
> 
> The problem with that approach is that each mode has to be aware of this and add a setting, really not much
> different than each mode having its own sort function or way of calling a sort function. It is much more useful
> to centralize the behavior within the sorting library, even if it adds some conditional complexity to the code.

Not necessarily: if you set that up in outline-mode, all of its
descendants will inherit the setting for free.

> Here is the suggested patch to do it this way. -- Bob

Thanks, I hope others will comment on this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.