bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive


From: Eli Zaretskii
Subject: bug#24109: 24.5; Long lines in message mode make Emacs irresponsive
Date: Thu, 01 Sep 2016 17:30:28 +0300

> Date: Thu, 01 Sep 2016 05:35:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl,
>       Christophe.Troestler@umons.ac.be
> 
> > From: Yuri D'Elia <wavexx@thregr.org>
> > Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, 
> > Christophe.Troestler@umons.ac.be, rudalics@gmx.at
> > Date: Wed, 31 Aug 2016 18:49:30 +0200
> > 
> > > For starters, in this line:
> > >
> > >             if (w->hscroll != hscroll)
> > >
> > > what are the values of those two, and do they change each time
> > > hscroll_windows is called in the infloop, for the selected window?
> > 
> > They swap the value at each iteration:
> > 
> > Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) 
> > at xdisp.c:13086
> > $154 = 0
> > $155 = 487
> > Continuing.
> > 
> > Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) 
> > at xdisp.c:13086
> > $156 = 487
> > $157 = 0
> > Continuing.
> 
> What are your values of hscroll-step and hscroll-margin?

FWIW, I tried to use your recipe, but failed spectacularly.  mu4e
refuses to run without a working mu installation.  I tried to build mu
on my system, but was forced to give up after 2 hours of fighting with
GMIME and mu itself to compile and work correctly on MS-Windows --
there's too much Posix-only stuff there, and my quick & dirty
workarounds were probably too quick and too dirty.  The best I could
achieve is "mu index --rebuild" cheerfully tell me that it indexed
zero mails, and then (mu4e) in Emacs complained that the database is
empty and refused to continue.

So we are back to me asking questions and you answering them.

In addition to the above, here's one more: when hscroll_window_tree is
called with w->hscroll already non-zero (i.e. after the display engine
scrolls the window to bring point into the view), how come it tries
again to hscroll the window?  The complicated condition that starts at
line 12993 is supposed to yield false in that case, because the X
coordinate of the cursor, stored in w->cursor.x, is now supposed to be
between the left and the right hscroll margins.  Why isn't that
happening in your case?

Some values that might help understand the answer to the above are:

  in C:
    w->cursor
    w->min_hscroll
  in Lisp:
    hscroll-step
    hscroll-margin

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]