From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions Date: Sun, 19 Jun 2016 12:12:12 -0400 Message-ID: References: <83shwa9zmr.fsf@gnu.org> <83lh229ywc.fsf@gnu.org> <83inx69xcx.fsf@gnu.org> <0984ce22-cbcf-42a6-906e-a03b65f3c71c@default> <8360t5aolu.fsf@gnu.org> <83vb158awq.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d2b8274f03e0535a3dbba X-Trace: ger.gmane.org 1466352826 13066 80.91.229.3 (19 Jun 2016 16:13:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jun 2016 16:13:46 +0000 (UTC) Cc: Richard Stallman , Drew Adams , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 19 18:13:39 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bEfLu-0008Ss-P0 for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2016 18:13:39 +0200 Original-Received: from localhost ([::1]:39296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEfLt-0004k2-EU for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2016 12:13:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEfLJ-0004jk-HS for emacs-devel@gnu.org; Sun, 19 Jun 2016 12:13:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEfLF-0000Jg-8v for emacs-devel@gnu.org; Sun, 19 Jun 2016 12:13:00 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEfLF-0000JZ-5j for emacs-devel@gnu.org; Sun, 19 Jun 2016 12:12:57 -0400 Original-Received: from mail-oi0-f51.google.com ([209.85.218.51]:35139) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bEfL0-0005WF-NW; Sun, 19 Jun 2016 12:12:43 -0400 Original-Received: by mail-oi0-f51.google.com with SMTP id a64so26987222oii.2; Sun, 19 Jun 2016 09:12:42 -0700 (PDT) X-Gm-Message-State: ALyK8tLuI5GieH2LtBsU1qUY94c/TG+60ex7AjXt4+IRyHqPdpXm3iCm6mz4AW05Q7F2FhsFDOvq8Q4P18HDzQ== X-Received: by 10.202.224.85 with SMTP id x82mr6278775oig.176.1466352761365; Sun, 19 Jun 2016 09:12:41 -0700 (PDT) Original-Received: by 10.202.236.73 with HTTP; Sun, 19 Jun 2016 09:12:12 -0700 (PDT) In-Reply-To: <83vb158awq.fsf@gnu.org> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:204529 Archived-At: --001a113d2b8274f03e0535a3dbba Content-Type: text/plain; charset=UTF-8 On Sun, Jun 19, 2016 at 11:18 AM, Eli Zaretskii 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? I have already fixed this issue for Hyperbole, so I hereby retract the request that it be made a blocking issue for 25.1. Bob --001a113d2b8274f03e0535a3dbba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jun 19, 2016 at 11:18 AM, Eli Zaretskii <eliz@gnu.org> wrot= e:
As I wrote, I'd very much prefer a= solution that only affects
outline-mode and its descendants.=C2=A0 In those modes, ignoring invisible<= br> lines could be the default behavior.=C2=A0 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.=C2=A0 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 s= tatement of your thinking.=C2=A0 Thanks, it is helpful.=C2=A0 It sounds lik= e 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 so= rt-lines the same unless an outline-mode or descendant is active in which c= ase the default will be to group invisible lines with visible ones.=C2=A0 T= here will be a way to override the default behavior with the other behavior= (not grouping invisible lines with visible ones and treating them as separ= ate lines for sorting).=C2=A0 How does that sound?

I have already fixed this issue for Hyperbole, so I hereby retract the req= uest that it be made a blocking issue for 25.1.

Bo= b

--001a113d2b8274f03e0535a3dbba--