bug#23794: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions

bug#23794: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

On Sun, Jun 19, 2016 at 12:30 PM, Eli Zaretskii <eliz@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.  Here is the suggested patch to do it
this way.  -- Bob

*** sort-orig.el.gz 2016-06-19 12:42:12.000000000 -0400
--- sort.el.gz 2016-06-19 12:42:12.000000000 -0400
***************
*** 39,44 ****
--- 39,50 ----
    :type 'boolean)
  ;;;###autoload(put 'sort-fold-case 'safe-local-variable 'booleanp)

+ (defcustom sort-invisible-lines nil
+   "Non-nil if the buffer `sort-line' function should treat invisible
lines like visible ones."
+   :group 'sort
+   :type 'boolean)
+ ;;;###autoload(put 'sort-invisible-lines 'safe-local-variable 'booleanp)
+
  ;;;###autoload
  (defun sort-subr (reverse nextrecfun endrecfun
   &optional startkeyfun endkeyfun predicate)
***************
*** 210,216 ****
        (goto-char (point-min))
        (let ;; To make `end-of-line' and etc. to ignore fields.
   ((inhibit-field-text-motion t))
! (sort-subr reverse 'forward-line 'end-of-line)))))

  ;;;###autoload
  (defun sort-paragraphs (reverse beg end)
--- 216,228 ----
        (goto-char (point-min))
        (let ;; To make `end-of-line' and etc. to ignore fields.
   ((inhibit-field-text-motion t))
! (if (and (not sort-invisible-lines)
! (or (derived-mode-p 'outline-mode)
!     (and (boundp 'outline-minor-mode) outline-minor-mode)))
!    ;; In in an outline mode with sort-invisible-lines nil, sort
!    ;; only visible lines.
!    (sort-subr reverse 'forward-visible-line 'end-of-visible-line)
!  (sort-subr reverse 'forward-line 'end-of-line))))))

  ;;;###autoload
  (defun sort-paragraphs (reverse beg end)

*** simple-orig.el.gz 2016-06-18 11:29:58.000000000 -0400
--- simple.el.gz 2016-06-18 11:29:58.000000000 -0400
***************
*** 4909,4918 ****
  (kill-region (point)
       (progn (forward-visible-line arg) (point))))))

! (defun forward-visible-line (arg)
!   "Move forward by ARG lines, ignoring currently invisible newlines only.
  If ARG is negative, move backward -ARG lines.
  If ARG is zero, move to the beginning of the current line."
    (condition-case nil
        (if (> arg 0)
   (progn
--- 4909,4919 ----
  (kill-region (point)
       (progn (forward-visible-line arg) (point))))))

! (defun forward-visible-line (&optional arg)
!   "Move forward by optional ARG lines (default = 1), ignoring currently
invisible newlines only.
  If ARG is negative, move backward -ARG lines.
  If ARG is zero, move to the beginning of the current line."
+   (if (null arg) (setq arg 1))
    (condition-case nil
        (if (> arg 0)
   (progn

[-- Attachment #2: Type: text/html, Size: 7053 bytes --]

bug#23794: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions

[Eli Zaretskii]

> From: Robert Weiner <rsw@gnu.org>
> Date: Sun, 19 Jun 2016 12:51:08 -0400
> Cc: Drew Adams <drew.adams@oracle.com>, Richard Stallman <rms@gnu.org>, 
> 	emacs-devel <emacs-devel@gnu.org>, 23794@debbugs.gnu.org
> 
> On Sun, Jun 19, 2016 at 12:30 PM, Eli Zaretskii <eliz@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.

bug#23794: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Sun, Jun 19, 2016 at 12:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Weiner <rsw@gnu.org>
> >
> > 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.
>

Ok.


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

One other possibility that is fairly clean is to add sort-visible-*
functions to the sort library; then callers would just have to remember to
call the visible or the regular version of the function and there would be
no need for any new defcustoms.


> Thanks, I hope others will comment on this.
>

Yes.

[-- Attachment #2: Type: text/html, Size: 1698 bytes --]

bug#23794: Emacs bug #23794; sort-line behavior regressed from prior Emacs versions

[Drew Adams]

Please don't send to both the bug list and emacs-devel, in general.

(And please consider using plain text, not HTML, mail.)