From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#23794: Emacs 25.0.94: Patch to make sort-lines respect visible lines (fairly urgent) Date: Sat, 18 Jun 2016 13:42:01 -0400 Message-ID: References: <83twgq9znu.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113db4bad5f7c1053590fed6 X-Trace: ger.gmane.org 1466271807 3944 80.91.229.3 (18 Jun 2016 17:43:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jun 2016 17:43:27 +0000 (UTC) Cc: 23794@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 18 19:43:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1bEKH3-0002ca-FD for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Jun 2016 19:43:13 +0200 Original-Received: from localhost ([::1]:35870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEKH2-00018S-Ks for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Jun 2016 13:43:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEKGw-0000w2-MN for bug-gnu-emacs@gnu.org; Sat, 18 Jun 2016 13:43:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEKGs-0008HW-GC for bug-gnu-emacs@gnu.org; Sat, 18 Jun 2016 13:43:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEKGs-0008HS-CW for bug-gnu-emacs@gnu.org; Sat, 18 Jun 2016 13:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bEKGs-0001w0-5d for bug-gnu-emacs@gnu.org; Sat, 18 Jun 2016 13:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Jun 2016 17:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23794 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23794-submit@debbugs.gnu.org id=B23794.14662717637388 (code B ref 23794); Sat, 18 Jun 2016 17:43:02 +0000 Original-Received: (at 23794) by debbugs.gnu.org; 18 Jun 2016 17:42:43 +0000 Original-Received: from localhost ([127.0.0.1]:45372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEKGY-0001v6-LM for submit@debbugs.gnu.org; Sat, 18 Jun 2016 13:42:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEKGX-0001ui-BE for 23794@debbugs.gnu.org; Sat, 18 Jun 2016 13:42:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEKGO-00088p-W6 for 23794@debbugs.gnu.org; Sat, 18 Jun 2016 13:42:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEKGO-00088g-ST for 23794@debbugs.gnu.org; Sat, 18 Jun 2016 13:42:32 -0400 Original-Received: from mail-oi0-f46.google.com ([209.85.218.46]:35947) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bEKGN-00084d-9q for 23794@debbugs.gnu.org; Sat, 18 Jun 2016 13:42:31 -0400 Original-Received: by mail-oi0-f46.google.com with SMTP id p204so159312514oih.3 for <23794@debbugs.gnu.org>; Sat, 18 Jun 2016 10:42:31 -0700 (PDT) X-Gm-Message-State: ALyK8tJGPT5K6vtw2uROtID5EgKLfs2/4aknEhvWRDmy/67z4vETgfR2rmbzU8fbvrgHJBhazWYkyKQdomMHuA== X-Received: by 10.157.14.174 with SMTP id 43mr4493447otj.83.1466271750549; Sat, 18 Jun 2016 10:42:30 -0700 (PDT) Original-Received: by 10.202.236.73 with HTTP; Sat, 18 Jun 2016 10:42:01 -0700 (PDT) In-Reply-To: <83twgq9znu.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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:119746 Archived-At: --001a113db4bad5f7c1053590fed6 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 18, 2016 at 1:26 PM, Eli Zaretskii wrote: > > From: Robert Weiner > > Date: Sat, 18 Jun 2016 11:47:08 -0400 > > > > sort-lines calls forward-line rather than forward-visible line, so if > > you have emacs outline entries that are collapsed/hidden to single lines > > each and you try to sort them, their bodies and subtrees are sorted > > separately because forward-visible-line is not used. > > I don't think we can make such a backward-incompatible change without > (a) an entry in NEWS, I am willing to write this. > (b) suitable changes in the manual(s), and > I looked at both the Emacs and the Elisp manuals and the only change necessary would be in the elisp manual where the full code for sort-lines is shown, so that would be a simple replace. (c) some way of getting back the old behavior (which could be by way > of having this new behavior as an optional one). > See below. For clarity, the original behavior of sort-lines is what the patch restores. The backward-incompatibility to which you refer is then just an implementation error that occurred when switching over to the overlay implementation of outlines as there was never any documentation that I can see that suggested any behavior change. There certainly could be better documentation as to whether a 'line' refers to a visible line, an invisible line or both but many functions do not delineate this. A major reason for making lines invisible is so that they are not treated as regular lines when functions are applied to buffer text. Thus, sort-lines should by default operate on visible lines. It could be extended or another function could be written to operate on invisible lines as well, e.g. sort-invisible-lines and an alias could be made to sort-lines to be called sort-visible-lines. All of this in the future. The only thing I am suggesting for right now is to restore the original behavior. Note that if all lines are visible, the patch codes works as well. The issue is that when lines are invisible the current code in Emacs does not work in a very useful way. Bob --001a113db4bad5f7c1053590fed6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jun 18, 2016 at 1:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:<= br>
> From: Robert Weiner <rsw@gnu.org>
> Date: Sat, 18 Jun 2016 11:47:08 -0400
>
> sort-lines calls forward-line rather than forward-visible line, so if<= br> > you have emacs outline entries that are collapsed/hidden to single lin= es
> each and you try to sort them, their bodies and subtrees are sorted > separately because forward-visible-line is not used.

I don't think we can make such a backward-incompatible change without (a) an entry in NEWS,

I am willing to write= this.
=C2=A0
(b) suitable c= hanges in the manual(s), and

I looked a= t both the Emacs and the Elisp manuals and the only change necessary would = be in the elisp manual where the full code for sort-lines is shown, so that= would be a simple replace.

(c) some way of getting back the old behavior (which could be by way
of having this new behavior as an optional one).

<= /div>
See below.=C2=A0

For clarity, the origin= al behavior of sort-lines is what the patch restores.=C2=A0 The backward-in= compatibility to which you refer is then just an implementation error that = occurred when switching over to the overlay implementation of outlines as t= here was never any documentation that I can see that suggested any behavior= change.=C2=A0 There certainly could be better documentation as to whether = a 'line' refers to a visible line, an invisible line or both but ma= ny functions do not delineate this.=C2=A0 A major reason for making lines i= nvisible is so that they are not treated as regular lines when functions ar= e applied to buffer text.=C2=A0 Thus, sort-lines should by default operate = on visible lines.=C2=A0 It could be extended or another function could be w= ritten to operate on invisible lines as well, e.g. sort-invisible-lines and= an alias could be made to sort-lines to be called sort-visible-lines.=C2= =A0 All of this in the future.=C2=A0 The only thing I am suggesting for rig= ht now is to restore the original behavior.=C2=A0 Note that if all lines ar= e visible, the patch codes works as well.=C2=A0 The issue is that when line= s are invisible the current code in Emacs does not work in a very useful wa= y.

Bob

--001a113db4bad5f7c1053590fed6--