GNU logs - #72392, boring messages

Message sent to monnier@HIDDEN, bug-gnu-emacs@HIDDEN:

Subject: bug#72392: 30.0.50; Wrong `next-line` behavior
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: monnier@HIDDEN, bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 31 Jul 2024 07:44:01 +0000
Resent-Message-ID: <handler.72392.B.172241183631334 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 72392 <at> debbugs.gnu.org
Cc: monnier@HIDDEN
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvcymu6my6.fsf-monnier+@gnu.org>
Date: Wed, 31 Jul 2024 03:43:20 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=132.204.25.50;
 envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--=-=-=
Content-Type: text/plain

Package: Emacs
Version: 30.0.50


Here's a funny corner case I just bumped into:

- Apply the `smerge-mode.patch` below to Emacs's` master` (and
  recompile `smerge-mode.el`).
- Open the short diff file below with:

    emacs -Q --eval '(setq-default word-wrap t diff-font-lock-prettify t)' \
          .../bug-weird-next-line.diff

- In my case, when this opens there's a "word wrap" just before "This"
  and just before "\id{seg}" (on the 4th and 5th lines, resp).
  If that's not the case for you, resize your frame so that this is
  the case.

- Do `C-n` a few times.

What I see is that `C-n` jumps down to the "T" of the word-wrapped
"This" as it should, but that the next `C-n` doesn't jump to the next
(visual) line but jumps to the "s" of "This" instead.
The same kind of misbehavior occurs on the next (logical) line with
"\id{seg}".


        Stefan

--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=smerge-mode.patch

diff --git a/lisp/vc/smerge-mode.el b/lisp/vc/smerge-mode.el
index a16c7871ff9..05ab757f09a 100644
--- a/lisp/vc/smerge-mode.el
+++ b/lisp/vc/smerge-mode.el
@@ -1034,26 +1034,68 @@ smerge--refine-highlight-change
                                   smerge-refine-forward-function)
                                 startline)
                        (point)))
-           (end (progn (funcall (if smerge-refine-weight-hack
-                                    #'forward-char
-                                  smerge-refine-forward-function)
-                          (if match-num2
-                              (- (string-to-number match-num2)
-                                 startline)
-                            1))
-                       (point))))
-      (when smerge-refine-ignore-whitespace
-        (skip-chars-backward " \t\n" beg) (setq end (point))
-        (goto-char beg)
-        (skip-chars-forward " \t\n" end)  (setq beg (point)))
-      (when (> end beg)
+           (end (if (eq t match-num2) beg
+                  (funcall (if smerge-refine-weight-hack
+                               #'forward-char
+                             smerge-refine-forward-function)
+                           (if match-num2
+                               (- (string-to-number match-num2)
+                                  startline)
+                             1))
+                  (point))))
+      (when (eq t match-num2)
+        ;; FIXME: No idea where this off-by-one comes from!
+        (setq beg (1+ beg))
+        (setq end (1+ end))
+        (goto-char end))
+      (when (and smerge-refine-ignore-whitespace
+                 (< beg end))
+        (let* ((newend (progn (skip-chars-backward " \t\n" beg) (point)))
+               (newbeg (progn (goto-char beg)
+                              (skip-chars-forward " \t\n" newend) (point))))
+          (unless (eq newend newbeg)
+            (setq end newend)
+            (setq beg newbeg))))
+      (cond
+       ((> end beg)
         (let ((ol (make-overlay
                    beg end nil
                    ;; Make them tend to shrink rather than spread when editing.
                    'front-advance nil)))
+          (overlay-put ol 'smerge--debug (list match-num1 match-num2 startline))
           (overlay-put ol 'evaporate t)
           (dolist (x props) (overlay-put ol (car x) (cdr x)))
-          ol)))))
+          ol))
+       ((= end beg)
+        (setq end (if (< beg (point-max))
+                      (1+ beg)
+                    (cl-assert (< (point-min) (point-max)))
+                    (setq beg (1- (point-max)))
+                    (point-max)))
+        (let ((ol (make-overlay
+                   beg end nil
+                   ;; Make them tend to shrink rather than spread when editing.
+                   'front-advance nil)))
+          (overlay-put ol 'smerge--debug (list match-num1 match-num2 startline))
+          (overlay-put ol 'evaporate t)
+          ;; Some of the properties need to go to `ol' and others
+          ;; need to go to the string :-(
+          ;; FIXME: I've seen lines in `diff-mode' where the half-space ends up
+          ;; placed at the beginning of the next line rather than the
+          ;; end of the current line, as in:
+          ;;
+          ;;     -foo bar
+          ;;     + foo bar b
+          ;;      ^
+          (overlay-put ol 'before-string
+                       (propertize
+                        " " 'face (cdr (assq 'face props))
+                        'display '(space :width 0.5)))
+          (dolist (x props)
+            (unless (eq (car-safe x) 'face)
+              (overlay-put ol (car x) (cdr x))))
+          ol))
+       (t (error "Smerge WOW! %S" (list beg end match-num2)))))))
 
 ;;;###autoload
 (defun smerge-refine-regions (beg1 end1 beg2 end2 props-c &optional preproc props-r props-a)
@@ -1114,20 +1156,18 @@ smerge-refine-regions
                     (m2 (match-string 2))
                     (m4 (match-string 4))
                     (m5 (match-string 5)))
-                (when (memq op '(?d ?c))
-                  (setq last1
-                        (smerge--refine-highlight-change
-			 beg1 m1 m2
-			 ;; Try to use props-c only for changed chars,
-			 ;; fallback to props-r for changed/removed chars,
-			 ;; but if props-r is nil then fallback to props-c.
-			 (or (and (eq op '?c) props-c) props-r props-c))))
-                (when (memq op '(?a ?c))
-                  (setq last2
-                        (smerge--refine-highlight-change
-			 beg2 m4 m5
-			 ;; Same logic as for removed chars above.
-			 (or (and (eq op '?c) props-c) props-a props-c)))))
+                (setq last1
+                      (smerge--refine-highlight-change
+		       beg1 m1 (if (eq op ?a) t m2)
+		       ;; Try to use props-c only for changed chars,
+		       ;; fallback to props-r for changed/removed chars,
+		       ;; but if props-r is nil then fallback to props-c.
+		       (or (and (eq op '?c) props-c) props-r props-c)))
+                (setq last2
+                      (smerge--refine-highlight-change
+		       beg2 m4 (if (eq op ?d) t m5)
+		       ;; Same logic as for removed chars above.
+		       (or (and (eq op '?c) props-c) props-a props-c))))
               (forward-line 1)                            ;Skip hunk header.
               (and (re-search-forward "^[0-9]" nil 'move) ;Skip hunk body.
                    (goto-char (match-beginning 0))))

--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=bug-weird-next-line.diff

@@ -2004,7 +2538,8 @@
 
 equivalent to a function out of the interval. Its defining characteristic is
-that the output of such a function has to agree at both endpoints of $\bI$. This
-is enforced by the elimination principle of the $\bI$ that ensures that \id{seg}
+that the output of such a function has to agree at both endpoints of $\bI$.
+This is enforced by the elimination principle of the $\bI$ that ensures that
+\id{seg} is respected.
 
 \begin{minted}[escapeinside=@@,mathescape=true]{agda}
     type I

--=-=-=--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Stefan Monnier <monnier@HIDDEN>
Subject: bug#72392: Acknowledgement (30.0.50; Wrong `next-line` behavior)
Message-ID: <handler.72392.B.172241183631334.ack <at> debbugs.gnu.org>
References: <jwvcymu6my6.fsf-monnier+@gnu.org>
X-Gnu-PR-Message: ack 72392
X-Gnu-PR-Package: emacs
Reply-To: 72392 <at> debbugs.gnu.org
Date: Wed, 31 Jul 2024 07:44:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  monnier@HIDDEN
(after having been given a bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 72392 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
72392: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72392
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72392: 30.0.50; Wrong `next-line` behavior
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 02 Aug 2024 06:58:01 +0000
Resent-Message-ID: <handler.72392.B72392.172258187625737 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Cc: 72392 <at> debbugs.gnu.org, monnier@HIDDEN
Date: Fri, 02 Aug 2024 09:57:25 +0300
Message-Id: <867cczwgx6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvcymu6my6.fsf-monnier+@gnu.org> (bug-gnu-emacs@HIDDEN)
References: <jwvcymu6my6.fsf-monnier+@gnu.org>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Cc: monnier@HIDDEN
> Date: Wed, 31 Jul 2024 03:43:20 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> - Apply the `smerge-mode.patch` below to Emacs's` master` (and
>   recompile `smerge-mode.el`).
> - Open the short diff file below with:
> 
>     emacs -Q --eval '(setq-default word-wrap t diff-font-lock-prettify t)' \
>           .../bug-weird-next-line.diff
> 
> - In my case, when this opens there's a "word wrap" just before "This"
>   and just before "\id{seg}" (on the 4th and 5th lines, resp).
>   If that's not the case for you, resize your frame so that this is
>   the case.
> 
> - Do `C-n` a few times.

Any hope of a simpler recipe, which would not require patching Emacs?
Cannot you just post the contents of the problematic buffer and the
non-default settings to use to reproduce the problem?

The bug is probably somewhere in vertical-motion or in line-move and
its subroutines, but a simpler recipe will make the investigation less
painful.

TIA

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72392: 30.0.50; Wrong `next-line` behavior
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 24 Aug 2024 08:24:02 +0000
Resent-Message-ID: <handler.72392.B72392.172448778625979 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: monnier@HIDDEN
Cc: 72392 <at> debbugs.gnu.org
Date: Sat, 24 Aug 2024 11:22:08 +0300
Message-Id: <86r0aenxe7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <867cczwgx6.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 02
 Aug 2024 09:57:25 +0300)
References: <jwvcymu6my6.fsf-monnier+@gnu.org> <867cczwgx6.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Ping! A simple test case could go a long way towards a solution.

> Cc: 72392 <at> debbugs.gnu.org, monnier@HIDDEN
> Date: Fri, 02 Aug 2024 09:57:25 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> > Cc: monnier@HIDDEN
> > Date: Wed, 31 Jul 2024 03:43:20 -0400
> > From:  Stefan Monnier via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> > 
> > - Apply the `smerge-mode.patch` below to Emacs's` master` (and
> >   recompile `smerge-mode.el`).
> > - Open the short diff file below with:
> > 
> >     emacs -Q --eval '(setq-default word-wrap t diff-font-lock-prettify t)' \
> >           .../bug-weird-next-line.diff
> > 
> > - In my case, when this opens there's a "word wrap" just before "This"
> >   and just before "\id{seg}" (on the 4th and 5th lines, resp).
> >   If that's not the case for you, resize your frame so that this is
> >   the case.
> > 
> > - Do `C-n` a few times.
> 
> Any hope of a simpler recipe, which would not require patching Emacs?
> Cannot you just post the contents of the problematic buffer and the
> non-default settings to use to reproduce the problem?
> 
> The bug is probably somewhere in vertical-motion or in line-move and
> its subroutines, but a simpler recipe will make the investigation less
> painful.
> 
> TIA
> 
> 
> 
>

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

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