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: Sat, 18 Jun 2016 14:31:02 -0400 Message-ID: References: <83shwa9zmr.fsf@gnu.org> <83lh229ywc.fsf@gnu.org> <83inx69xcx.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ce25a2066ed053591ae14 X-Trace: ger.gmane.org 1466274713 12818 80.91.229.3 (18 Jun 2016 18:31:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jun 2016 18:31:53 +0000 (UTC) Cc: Richard Stallman , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 18 20:31:52 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 1bEL27-0000UZ-Ql for ged-emacs-devel@m.gmane.org; Sat, 18 Jun 2016 20:31:51 +0200 Original-Received: from localhost ([::1]:35999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEL26-0002kr-ST for ged-emacs-devel@m.gmane.org; Sat, 18 Jun 2016 14:31:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEL20-0002ka-ES for emacs-devel@gnu.org; Sat, 18 Jun 2016 14:31:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEL1x-00029a-8O for emacs-devel@gnu.org; Sat, 18 Jun 2016 14:31:44 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEL1x-00029T-5E for emacs-devel@gnu.org; Sat, 18 Jun 2016 14:31:41 -0400 Original-Received: from mail-oi0-f52.google.com ([209.85.218.52]:35918) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bEL1o-000138-3y; Sat, 18 Jun 2016 14:31:32 -0400 Original-Received: by mail-oi0-f52.google.com with SMTP id p204so160243531oih.3; Sat, 18 Jun 2016 11:31:32 -0700 (PDT) X-Gm-Message-State: ALyK8tLoXUmWCZrypSlxRDoOn+MQ5R74ZUY/jyilYJxYznqLm8Z8XMzveoGHieXfA00NaHXz866xsx0DjPCHbg== X-Received: by 10.202.178.84 with SMTP id b81mr4027118oif.155.1466274691440; Sat, 18 Jun 2016 11:31:31 -0700 (PDT) Original-Received: by 10.202.236.73 with HTTP; Sat, 18 Jun 2016 11:31:02 -0700 (PDT) In-Reply-To: <83inx69xcx.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:204488 Archived-At: --001a113ce25a2066ed053591ae14 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 18, 2016 at 2:15 PM, Eli Zaretskii wrote: > I don't think it's a bug, in the sense that the old behavior was > intended. I think the old behavior was a side effect of the > implementation, so when the implementation changed, the behavior > changed with it. > If RMS confirms that is the case, then I will retract my request that this be a blocking bug for the next release but I have a feeling the old behavior was intended. > > IOW, I don't think it was ever the design goal to have sorting > disregard invisible text. > I think you are misstating what happens a bit or should use some other phrasing. It is not that invisible text is ignored, it is simply that invisible line endings are ignored when computing lines and the text of invisible lines is paired with any prior visible line as part of it. Thus, the text characters within the invisible part are still considered when sorting but they are not sorted separately from the visible parts. Bob --001a113ce25a2066ed053591ae14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jun 18, 2016 at 2:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:<= br>
I don't think it's a bug, in the sense that the old be= havior was
intended.=C2=A0 I think the old behavior was a side effect of the
implementation, so when the implementation changed, the behavior
changed with it.

If RMS confirms = that is the case, then I will retract my request that this be a blocking bu= g for the next release but I have a feeling the old behavior was intended.= =C2=A0

IOW, I don't think it was ever the design goal to have sorting
disregard invisible text.

I think you= are misstating what happens a bit or should use some other phrasing.=C2=A0= It is not that invisible text is ignored, it is simply that invisible line= endings are ignored when computing lines and the text of invisible lines i= s paired with any prior visible line as part of it.=C2=A0 Thus, the text ch= aracters within the invisible part are still considered when sorting but th= ey are not sorted separately from the visible parts.

Bob



--001a113ce25a2066ed053591ae14--