magit section cannot show content correctly

[Elilif]

Description

When I toggle magit section by calling magit-section-toggle in magit buffer, that command occasionally expand the previous section.

Steps to Reproduce

    $ cd ~/.emacs.d/elpa/magit-N
    $ emacs -Q --debug-init --eval '(setq debug-on-error t)' -L ../dash-N -L ../git-commit-N -L ../transient-N -L ../with-editor-N -L ../ghub-N  -L ../compat-N -L ../magit-section-N -L . -l magit

then enter magit buffer and type TAB (magit-section-toggle)

Backtrace

there no error occurs.

Expected Results

Environment

dash-20220608.1931
git-commit-20220803.2341
transient-20220806.2224
with-editor-20220810.1159
compat-28.1.2.0
magit-section-20220810.1158
magit-20220814.1855
emacs-version: GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-08-19 emacs-repository-version: 67ec99418079dc6443b73b60840dc281ba2a68ae

[djcb]

I noticed something similar.

In my case, this used to work fine with the Emacs git build until a week ago or so; and it still works fine with emacs 28.

[kyleam]

In my case, this used to work fine with the Emacs git build until a week ago or so; and it still works fine with emacs 28.

I tried building from the Emacs commit mentioned in the initial post (67ec99418079) and didn't have any luck triggering the problem. @djcb, since you building from the Emacs repo and it sounds like it might be due to a recent commit, could you try bisecting it to an Emacs commit?

[Elilif]

didn't have any luck triggering the problem

actually I can reproduce the problem everytime I open the magit buffer, and when the cursor isn't on the beginning of each line (on the char "m"), it works fine. so I suggest that the reason is magit gets wrong point location information.

[kyleam]

I've figured out a way to reliably trigger it on my end: with the changes below applied to the magit repo, go to the beginning of the line for the second file (lisp/magit-status.el) or third file (lisp/magit.el) in the unstaged changes section and press TAB. But if I expand the first file before that, then I do not see the issue.

This is with a vanilla configuration and the current tip of magit's master branch (124a5ad).

The first Emacs commit that I see the issue with is a71c05b44de (Further speedups of redisplay of long and truncated lines, 2022-08-14), and I still see it when I try with Emacs's current master (b2f9c4c6d4b).

At a glance, it seems as though magit-section (and perhaps other spots in magit) may need to now consider/disable long-line-threshold, but I don't have anymore time to look into it tonight.

test changes in magit.git

on top of 124a5ad

diff --git a/lisp/magit-clone.el b/lisp/magit-clone.el
index 302dcdd4..f974e7f3 100644
--- a/lisp/magit-clone.el
+++ b/lisp/magit-clone.el
@@ -96,6 +96,10 @@ (defcustom magit-clone-url-format "git@%h:%n.git"
   "Format used when turning repository names into urls.
 %h is the hostname and %n is the repository name, including
 the name of the owner.  Also see `magit-clone-name-alist'."
+
+
+
+
   :package-version '(magit . "3.0.0")
   :group 'magit-commands
   :type 'regexp)
diff --git a/lisp/magit-status.el b/lisp/magit-status.el
index 186828a4..31d3f565 100644
--- a/lisp/magit-status.el
+++ b/lisp/magit-status.el
@@ -1,5 +1,8 @@
 ;;; magit-status.el --- The grand overview  -*- lexical-binding:t -*-

+
+
+
 ;; Copyright (C) 2008-2022 The Magit Project Contributors

 ;; Author: Jonas Bernoulli <jonas@bernoul.li>
@@ -142,6 +145,8 @@ (defcustom magit-status-show-hashes-in-headers nil
   :group 'magit-status
   :type 'boolean)

+
+
 (defcustom magit-status-margin
   (list nil
         (nth 1 magit-log-margin)
diff --git a/lisp/magit.el b/lisp/magit.el
index b45c8663..e2db331d 100644
--- a/lisp/magit.el
+++ b/lisp/magit.el
@@ -1,3 +1,5 @@
+;; oasdf
+
 ;;; magit.el --- A Git porcelain inside Emacs  -*- lexical-binding:t; coding:utf-8 -*-

 ;; Copyright (C) 2008-2022 The Magit Project Contributors
@@ -18,6 +20,11 @@
 ;; Keywords: git tools vc

 ;; Package-Version: 3.3.0-git
+
+
+
+
+
 ;; Package-Requires: (
 ;;     (emacs "25.1")
 ;;     (compat "28.1.1.2")

[kyleam]

@Elilif

so I suggest that the reason is magit get wrong point location information.

Well, magit is going to the wrong place, so yeah, somewhere the point location comes out wrong. The interesting piece of information is that it appears to only happen as of a recent commit in the Emacs repo. So, while Magit may need to update its logic (and is perhaps even wrong in some cases), the interaction with the Emacs change is important to understand.

This all assumes something I don't spot you say explicitly: that you've only started seeing the issue on your end with a recent Emacs build. I think so, as that's consistent with the Emacs commit you report, consistent with my bisect, and matches what @djcb experienced. But if not (e.g., do you see it with Emacs 28?), please say so.

[Elilif]

you've only started seeing the issue on your end with a recent Emacs build.

yes, you're right, and thank you for your bisect.

[aaronjensen]

Disabling long-line-threshold in the magit status buffer doesn't appear to help. I can confirm that resetting to the parent of a71c05b44de fixes it for me. Has this been reported to Emacs or is it more likely that this is actually a (new) magit problem in Emacs' new world of approximation for long line performance?

[aaronjensen]

The problem appears to be caused by this change in line-move:

emacs-mirror/emacs@a71c05b44de#diff-2d36b759704d27f0bba5f763df83a6d5011e51bf6746b802910e1c52a48ee4e3R7713-R7721

It's fixed if I disable truncate-lines in the magit status buffer.

[kyleam]

Has this been reported to Emacs or is it more likely that this is actually a (new) magit problem in Emacs' new world of approximation for long line performance?

I'd need to look more into it to say and probably won't find the time to do so at least for the next few days. But if you or anyone else makes progress (as it seems like you have), any information/assessment is of course appreciated.

[aaronjensen]

Fixed upstream: emacs-mirror/emacs@a2d6245

Possibly still a bug in magit (per Eli): https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg02517.html

(Btw, I think it's a subtle bug in Magit that it assumes cursor motion
will never end up on invisible text in such buffers.)

[kyleam]

Thanks, @aaronjensen. I've confirmed the fix on my end too.

Possibly still a bug in magit (per Eli): https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg02517.html

That's sounds related to the discussion/decision in #3789. Perhaps Jonas will have thoughts on that when he returns.