Emacs freezes again when I try to open a file including only one very long line.

Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

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

When I try to open the following file in Emacs, it freezes:

$ wc  __tmp.symbols
     0      1 896217 __tmp.symbols

The file mentioned above has been attached. Any hints for fixing this problem?

Regards,
Hongsheng
-- 
Assoc. Prof. Hongsheng Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

[-- Attachment #2: __tmp.symbols.tar.gz --]
[-- Type: application/gzip, Size: 230703 bytes --]

Re: Emacs freezes again when I try to open a file including only one very long line.

[Emanuel Berg]

Hongyi Zhao wrote:

> When I try to open the following file in Emacs, it freezes:
>
> $ wc  __tmp.symbols
>      0      1 896217 __tmp.symbols

It doesn't?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Mon, 27 Jun 2022 08:51:23 +0800
> 
> When I try to open the following file in Emacs, it freezes:
> 
> $ wc  __tmp.symbols
>      0      1 896217 __tmp.symbols
> 
> The file mentioned above has been attached. Any hints for fixing this problem?

Upgrade to Emacs 29?

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

On Mon, Jun 27, 2022 at 10:30 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Mon, 27 Jun 2022 08:51:23 +0800
> >
> > When I try to open the following file in Emacs, it freezes:
> >
> > $ wc  __tmp.symbols
> >      0      1 896217 __tmp.symbols
> >
> > The file mentioned above has been attached. Any hints for fixing this problem?
>
> Upgrade to Emacs 29?

My version of Emacs:

`M-x emacs-version RET`
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0) of 2021-11-14

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Mon, 27 Jun 2022 10:36:55 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> On Mon, Jun 27, 2022 at 10:30 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > > Date: Mon, 27 Jun 2022 08:51:23 +0800
> > >
> > > When I try to open the following file in Emacs, it freezes:
> > >
> > > $ wc  __tmp.symbols
> > >      0      1 896217 __tmp.symbols
> > >
> > > The file mentioned above has been attached. Any hints for fixing this problem?
> >
> > Upgrade to Emacs 29?
> 
> My version of Emacs:
> 
> `M-x emacs-version RET`
> GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
> cairo version 1.16.0) of 2021-11-14

That's too old.  You need a very recent version, and then set the
variable max-redisplay-ticks to something like 250,000.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

On Mon, Jun 27, 2022 at 7:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Mon, 27 Jun 2022 10:36:55 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > On Mon, Jun 27, 2022 at 10:30 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > > > Date: Mon, 27 Jun 2022 08:51:23 +0800
> > > >
> > > > When I try to open the following file in Emacs, it freezes:
> > > >
> > > > $ wc  __tmp.symbols
> > > >      0      1 896217 __tmp.symbols
> > > >
> > > > The file mentioned above has been attached. Any hints for fixing this problem?
> > >
> > > Upgrade to Emacs 29?
> >
> > My version of Emacs:
> >
> > `M-x emacs-version RET`
> > GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
> > cairo version 1.16.0) of 2021-11-14
>
> That's too old.  You need a very recent version, and then set the
> variable max-redisplay-ticks to something like 250,000.

Thank you for your tip. I will try it when I have time.

Regards,
Hongsheng

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

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

On Tue, Jun 28, 2022 at 7:13 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> [Why personal email?]

By accident, I didn't notice this :-(

> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Tue, 28 Jun 2022 12:26:22 +0800
> >
> > > That's too old.  You need a very recent version, and then set the
> > > variable max-redisplay-ticks to something like 250,000.
> >
> > I recompiled the latest master version of Emacs, but the problem
> > remains. Below the testing steps:
> >
> >
> > $ emacs -Q
> > `M-x emacs-version RET`
> > GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
> > cairo version 1.16.0) of 2022-06-28
> >
> > In scratch buffer, `C-x C-e` the following setting:
> >
> > (setq max-redisplay-ticks 3000000000000000)
> >
> > `C-x C-f` to open the file discussed here. If I drag the scroll bar on
> > the right side of the window with the mouse, Emacs will lose response,
> > as shown in the attached file.
>
> Why did you set the variable to such a large value?  That effectively
> disables the feature.  I told you what value I recommend; why didn't
> you use that?  What were you trying to accomplish by using the value
> 3000000000000000?

It's picked from the following relevant discussion:

https://mail.gnu.org/archive/html/bug-gnu-emacs/2022-06/msg01690.html

Anyway, I tried with your suggested configuration:

(setq max-redisplay-ticks 250000)

But the problem remains, as shown in the attached file.

Best,
Hongsheng

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 46346 bytes --]

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Tue, 28 Jun 2022 20:56:56 +0800
> 
> > > In scratch buffer, `C-x C-e` the following setting:
> > >
> > > (setq max-redisplay-ticks 3000000000000000)
> > >
> > > `C-x C-f` to open the file discussed here. If I drag the scroll bar on
> > > the right side of the window with the mouse, Emacs will lose response,
> > > as shown in the attached file.
> >
> > Why did you set the variable to such a large value?  That effectively
> > disables the feature.  I told you what value I recommend; why didn't
> > you use that?  What were you trying to accomplish by using the value
> > 3000000000000000?
> 
> It's picked from the following relevant discussion:
> 
> https://mail.gnu.org/archive/html/bug-gnu-emacs/2022-06/msg01690.html

Why did you think that value was relevant?

This variable is documented, and its documentation tells you how to
use it.  Please follow the documentation instead of some random
discussion on the bug list.

> Anyway, I tried with your suggested configuration:
> 
> (setq max-redisplay-ticks 250000)
> 
> But the problem remains, as shown in the attached file.

Which problem "remains"?  Don't you see that message at the bottom,
telling you

  Window showing buffer __tmp.symbols takes too long to redisplay

?  It is clearly seen in the screenshot you posted.

If you now type "C-x b RET" or "M-x", doesn't Emacs respond normally,
not after a very long time?

This is what this feature does: it interrupts a too-long redisplay and
lets you use Emacs regardless -- you can switch to another buffer, or
kill the problematic buffer, or do something else to remedy the
unexpected slowness, instead of having to wait forever for any
response to any Emacs command, which basically makes the session
unusable.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

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

On Tue, Jun 28, 2022 at 9:20 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Tue, 28 Jun 2022 20:56:56 +0800
> >
> > > > In scratch buffer, `C-x C-e` the following setting:
> > > >
> > > > (setq max-redisplay-ticks 3000000000000000)
> > > >
> > > > `C-x C-f` to open the file discussed here. If I drag the scroll bar on
> > > > the right side of the window with the mouse, Emacs will lose response,
> > > > as shown in the attached file.
> > >
> > > Why did you set the variable to such a large value?  That effectively
> > > disables the feature.  I told you what value I recommend; why didn't
> > > you use that?  What were you trying to accomplish by using the value
> > > 3000000000000000?
> >
> > It's picked from the following relevant discussion:
> >
> > https://mail.gnu.org/archive/html/bug-gnu-emacs/2022-06/msg01690.html
>
> Why did you think that value was relevant?
>
> This variable is documented, and its documentation tells you how to
> use it.  Please follow the documentation instead of some random
> discussion on the bug list.
>
> > Anyway, I tried with your suggested configuration:
> >
> > (setq max-redisplay-ticks 250000)
> >
> > But the problem remains, as shown in the attached file.
>
> Which problem "remains"?  Don't you see that message at the bottom,
> telling you
>
>   Window showing buffer __tmp.symbols takes too long to redisplay
>
> ?  It is clearly seen in the screenshot you posted.
>
> If you now type "C-x b RET" or "M-x", doesn't Emacs respond normally,
> not after a very long time?
>
> This is what this feature does: it interrupts a too-long redisplay and
> lets you use Emacs regardless -- you can switch to another buffer, or
> kill the problematic buffer, or do something else to remedy the
> unexpected slowness, instead of having to wait forever for any
> response to any Emacs command, which basically makes the session
> unusable.

Thank you for your explanation, but I find that in this case, the
incremental search doesn't work as expected, as shown in the attached
file.

Regards,
Hongsheng

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 294309 bytes --]

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Tue, 28 Jun 2022 21:56:58 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > This is what this feature does: it interrupts a too-long redisplay and
> > lets you use Emacs regardless -- you can switch to another buffer, or
> > kill the problematic buffer, or do something else to remedy the
> > unexpected slowness, instead of having to wait forever for any
> > response to any Emacs command, which basically makes the session
> > unusable.
> 
> Thank you for your explanation, but I find that in this case, the
> incremental search doesn't work as expected, as shown in the attached
> file.

"Doesn't work" in what way?

I think your expectations from what this does are incorrect.  This new
variable's purpose is to prevent Emacs from becoming frozen and
unusable because you happened to visit a problematic file.  It doesn't
make problematic files non-problematic, it just prevents such a file
from making the session hopelessly frozen without any way to recover.

In your case, you can kill the buffer and then visit it literally, or
make the file shorter and re-visit it, or decide that this file cannot
be reasonably edited with Emacs, or something else.  And your Emacs
session will still be usable and will not freeze -- which was your
complaint, see the Subject.

IOW, it sounds like your complaint is now something else, not that
"Emacs freezes again".

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

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

On Tue, Jun 28, 2022 at 10:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Tue, 28 Jun 2022 21:56:58 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > > This is what this feature does: it interrupts a too-long redisplay and
> > > lets you use Emacs regardless -- you can switch to another buffer, or
> > > kill the problematic buffer, or do something else to remedy the
> > > unexpected slowness, instead of having to wait forever for any
> > > response to any Emacs command, which basically makes the session
> > > unusable.
> >
> > Thank you for your explanation, but I find that in this case, the
> > incremental search doesn't work as expected, as shown in the attached
> > file.
>
> "Doesn't work" in what way?

I mean: When I'm typing the searching keyword in the minibuffer,
highlighting the keyword's occurrence in the file, as shown in the
vscode for the same file.

> I think your expectations from what this does are incorrect.  This new
> variable's purpose is to prevent Emacs from becoming frozen and
> unusable because you happened to visit a problematic file.  It doesn't
> make problematic files non-problematic, it just prevents such a file
> from making the session hopelessly frozen without any way to recover.
>
> In your case, you can kill the buffer and then visit it literally, or
> make the file shorter and re-visit it, or decide that this file cannot
> be reasonably edited with Emacs, or something else.  And your Emacs
> session will still be usable and will not freeze -- which was your
> complaint, see the Subject.
>
> IOW, it sounds like your complaint is now something else, not that
> "Emacs freezes again".

Yes. But new problem appears :-(

Best,
Hongsheng

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 416677 bytes --]

Re: Emacs freezes again when I try to open a file including only one very long line.

[Emanuel Berg]

Eli Zaretskii wrote:

> I think your expectations from what this does are incorrect.
> This new variable's purpose is to prevent Emacs from
> becoming frozen and unusable because you happened to visit
> a problematic file. It doesn't make problematic files
> non-problematic, it just prevents such a file from making
> the session hopelessly frozen [...]

If the OP is in a campus or university area, can this be the
Emacs AI parsing the old "be cool, stay in school" slogan?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Tue, 28 Jun 2022 22:38:16 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > IOW, it sounds like your complaint is now something else, not that
> > "Emacs freezes again".
> 
> Yes. But new problem appears :-(

It isn't a new problem.  The problem is the same: a file with very
long lines.  What you see is a partial solution: you get an Emacs that
still works, at least on all the other buffers and windows, and Emacs
that still responds to commands.  The Emacs that was frozen cold is
gone.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

On Tue, Jun 28, 2022 at 11:58 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Tue, 28 Jun 2022 22:38:16 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > > IOW, it sounds like your complaint is now something else, not that
> > > "Emacs freezes again".
> >
> > Yes. But new problem appears :-(
>
> It isn't a new problem.  The problem is the same: a file with very
> long lines.  What you see is a partial solution: you get an Emacs that
> still works, at least on all the other buffers and windows, and Emacs
> that still responds to commands.  The Emacs that was frozen cold is
> gone.

Therefore, Emacs still cannot properly handle this situation
practically, at least for the user's point of view.

Best regards,
Hongsheng

Re: Emacs freezes again when I try to open a file including only one very long line.

[Emanuel Berg]

Hongyi Zhao wrote:

>> It isn't a new problem. The problem is the same: a file
>> with very long lines. What you see is a partial solution:
>> you get an Emacs that still works, at least on all the
>> other buffers and windows, and Emacs that still responds to
>> commands. The Emacs that was frozen cold is gone.
>
> Therefore, Emacs still cannot properly handle this situation
> practically, at least for the user's point of view.

You want the situation? You can't HANDLE the situation!

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Wed, 29 Jun 2022 09:05:45 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> On Tue, Jun 28, 2022 at 11:58 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > > Date: Tue, 28 Jun 2022 22:38:16 +0800
> > > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> > >
> > > > IOW, it sounds like your complaint is now something else, not that
> > > > "Emacs freezes again".
> > >
> > > Yes. But new problem appears :-(
> >
> > It isn't a new problem.  The problem is the same: a file with very
> > long lines.  What you see is a partial solution: you get an Emacs that
> > still works, at least on all the other buffers and windows, and Emacs
> > that still responds to commands.  The Emacs that was frozen cold is
> > gone.
> 
> Therefore, Emacs still cannot properly handle this situation
> practically, at least for the user's point of view.

Actually, it _can_ handle this situation "practically", in that now it
doesn't freeze the entire session, thus allowing the user to do
something about the issue without losing any edits.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

On Wed, Jun 29, 2022 at 10:36 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > Therefore, Emacs still cannot properly handle this situation
> > practically, at least for the user's point of view.
>
> Actually, it _can_ handle this situation "practically", in that now it
> doesn't freeze the entire session, thus allowing the user to do
> something about the issue without losing any edits.

I still don't understand what you mean. For example, how to get the
same incremental search results displayed in real time as what in the
vscode I showed.

Best,
Hongsheng

Re: Emacs freezes again when I try to open a file including only one very long line.

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

>> Therefore, Emacs still cannot properly handle this situation
>> practically, at least for the user's point of view.
>
> Actually, it _can_ handle this situation "practically", in that now it
> doesn't freeze the entire session, thus allowing the user to do
> something about the issue without losing any edits.

And as I said in this other thread about « a file with just one long
line », there still is longlines-mode (accessible from the So long
menu).
-- 
Manuel Giraud

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Wed, 29 Jun 2022 10:48:16 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> On Wed, Jun 29, 2022 at 10:36 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > Therefore, Emacs still cannot properly handle this situation
> > > practically, at least for the user's point of view.
> >
> > Actually, it _can_ handle this situation "practically", in that now it
> > doesn't freeze the entire session, thus allowing the user to do
> > something about the issue without losing any edits.
> 
> I still don't understand what you mean.

I mean Emacs is no longer frozen.  This is the only practical handling
of this situation that we could provide for such files.

> For example, how to get the same incremental search results
> displayed in real time as what in the vscode I showed.

The results of incremental search are shown as long as displaying them
takes a reasonable amount of time.  When Emacs is no longer capable of
displaying the results in reasonable time (a.k.a. "freezes"), the
results are no longer displayed, to give you a responsive Emacs
session.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Wed, 29 Jun 2022 08:44:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Actually, it _can_ handle this situation "practically", in that now it
> > doesn't freeze the entire session, thus allowing the user to do
> > something about the issue without losing any edits.
> 
> And as I said in this other thread about « a file with just one long
> line », there still is longlines-mode (accessible from the So long
> menu).

Yes, and this new feature lets the user a chance to invoke that mode
in the offending buffer, since the session as a whole is not wedged.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

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

On Wed, Jun 29, 2022 at 7:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Wed, 29 Jun 2022 10:48:16 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > On Wed, Jun 29, 2022 at 10:36 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > > Therefore, Emacs still cannot properly handle this situation
> > > > practically, at least for the user's point of view.
> > >
> > > Actually, it _can_ handle this situation "practically", in that now it
> > > doesn't freeze the entire session, thus allowing the user to do
> > > something about the issue without losing any edits.
> >
> > I still don't understand what you mean.
>
> I mean Emacs is no longer frozen.  This is the only practical handling
> of this situation that we could provide for such files.
>
> > For example, how to get the same incremental search results
> > displayed in real time as what in the vscode I showed.
>
> The results of incremental search are shown as long as displaying them
> takes a reasonable amount of time.  When Emacs is no longer capable of
> displaying the results in reasonable time (a.k.a. "freezes"), the
> results are no longer displayed, to give you a responsive Emacs
> session.

But I waited a minute and didn't see any matching results highlighted
on the screen, as shown in the attached file.
BTW, all the matched results will be displayed in vscode almost at the
same time as the input.

Yours,
Hongsheng

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 266968 bytes --]

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Wed, 29 Jun 2022 19:25:53 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > > For example, how to get the same incremental search results
> > > displayed in real time as what in the vscode I showed.
> >
> > The results of incremental search are shown as long as displaying them
> > takes a reasonable amount of time.  When Emacs is no longer capable of
> > displaying the results in reasonable time (a.k.a. "freezes"), the
> > results are no longer displayed, to give you a responsive Emacs
> > session.
> 
> But I waited a minute and didn't see any matching results highlighted
> on the screen, as shown in the attached file.

With what value of max-redisplay-ticks?

With a reasonable value, you should see a warning telling you that the
window displaying this file is taking too long to redisplay, and Emacs
should remain responsive, so that you can type C-g and then other
commands.

> BTW, all the matched results will be displayed in vscode almost at the
> same time as the input.

Can VSCode be programmed to changed its display and its commands like
Emacs can?

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

On Wed, Jun 29, 2022 at 7:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Wed, 29 Jun 2022 19:25:53 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > > > For example, how to get the same incremental search results
> > > > displayed in real time as what in the vscode I showed.
> > >
> > > The results of incremental search are shown as long as displaying them
> > > takes a reasonable amount of time.  When Emacs is no longer capable of
> > > displaying the results in reasonable time (a.k.a. "freezes"), the
> > > results are no longer displayed, to give you a responsive Emacs
> > > session.
> >
> > But I waited a minute and didn't see any matching results highlighted
> > on the screen, as shown in the attached file.
>
> With what value of max-redisplay-ticks?

(setq max-redisplay-ticks 250000)

> With a reasonable value, you should see a warning telling you that the
> window displaying this file is taking too long to redisplay, and Emacs
> should remain responsive, so that you can type C-g and then other
> commands.
>
> > BTW, all the matched results will be displayed in vscode almost at the
> > same time as the input.
>
> Can VSCode be programmed to changed its display and its commands like
> Emacs can?

Not clear. My description of the behavior of it and its specific
third-party plug-ins is based on the corresponding default settings.

Best,
Hongsheng

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Wed, 29 Jun 2022 20:22:36 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > > But I waited a minute and didn't see any matching results highlighted
> > > on the screen, as shown in the attached file.
> >
> > With what value of max-redisplay-ticks?
> 
> (setq max-redisplay-ticks 250000)

Then I cannot reproduce this.  In my case, Emacs pops up a window
showing the *Warnings* buffer which says:

  Window showing buffer __tmp.symbols takes too long to redisplay

> > Can VSCode be programmed to changed its display and its commands like
> > Emacs can?
> 
> Not clear. My description of the behavior of it and its specific
> third-party plug-ins is based on the corresponding default settings.

VSCode is a different program with different display routines and
different features.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

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

On Wed, Jun 29, 2022 at 10:12 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Wed, 29 Jun 2022 20:22:36 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > > > But I waited a minute and didn't see any matching results highlighted
> > > > on the screen, as shown in the attached file.
> > >
> > > With what value of max-redisplay-ticks?
> >
> > (setq max-redisplay-ticks 250000)
>
> Then I cannot reproduce this.  In my case, Emacs pops up a window
> showing the *Warnings* buffer which says:
>
>   Window showing buffer __tmp.symbols takes too long to redisplay

OK. Let me take a concrete result as an example. If I search
`|isgroup|', then VSCode will give the only result immediately as
shown in the attached file. Now, how can I achieve this in Emacs?

> > > Can VSCode be programmed to changed its display and its commands like
> > > Emacs can?
> >
> > Not clear. My description of the behavior of it and its specific
> > third-party plug-ins is based on the corresponding default settings.
>
> VSCode is a different program with different display routines and
> different features.

Best,
Hongsheng

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 448376 bytes --]

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Wed, 29 Jun 2022 22:30:47 +0800
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> OK. Let me take a concrete result as an example. If I search
> `|isgroup|', then VSCode will give the only result immediately as
> shown in the attached file. Now, how can I achieve this in Emacs?

Maybe you can't, it depends on how deep into the file that match is
and how fast is your system (if it's very fast, try enlarging the
value of max-redisplay-ticks).

But you are asking questions that are not relevant to what this
feature does.  This feature prevents Emacs from freezing when you
visit such files.  That is all it does.  As I tried explaining several
times already.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

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

On Thu, Jun 30, 2022 at 12:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Wed, 29 Jun 2022 22:30:47 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > OK. Let me take a concrete result as an example. If I search
> > `|isgroup|', then VSCode will give the only result immediately as
> > shown in the attached file. Now, how can I achieve this in Emacs?
>
> Maybe you can't, it depends on how deep into the file that match is
> and how fast is your system (if it's very fast, try enlarging the
> value of max-redisplay-ticks).

I tried with the following value, and Emacs really does the trick, as
shown in the attached file:

(setq max-redisplay-ticks 100000000)

However, in this case, the delay between input and display in
minibuffer is very large.

> But you are asking questions that are not relevant to what this
> feature does.  This feature prevents Emacs from freezing when you
> visit such files.  That is all it does.  As I tried explaining several
> times already.
>

Best,
Honsghen

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 251740 bytes --]

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

On Thu, Jun 30, 2022 at 8:38 AM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Thu, Jun 30, 2022 at 12:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > > Date: Wed, 29 Jun 2022 22:30:47 +0800
> > > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> > >
> > > OK. Let me take a concrete result as an example. If I search
> > > `|isgroup|', then VSCode will give the only result immediately as
> > > shown in the attached file. Now, how can I achieve this in Emacs?
> >
> > Maybe you can't, it depends on how deep into the file that match is
> > and how fast is your system (if it's very fast, try enlarging the
> > value of max-redisplay-ticks).
>
> I tried with the following value, and Emacs really does the trick, as
> shown in the attached file:
>
> (setq max-redisplay-ticks 100000000)
>
> However, in this case, the delay between input and display in
> minibuffer is very large.

Just out of curiosity, I wonder why my following configuration as
discussed here [1], also can't solve the real-time display of search
results appeared in extremely long lines:

```
(use-package so-long
  :config
  (setq-default so-long-action 'longlines-mode)
  (setq-default longlines-show-hard-newlines t)
  (global-so-long-mode +1)
  )
```

[1] https://lists.gnu.org/archive/html/help-gnu-emacs/2022-03/msg00511.html

> > But you are asking questions that are not relevant to what this
> > feature does.  This feature prevents Emacs from freezing when you
> > visit such files.  That is all it does.  As I tried explaining several
> > times already.
> >
>
> Best,
> Honsghen

Re: Emacs freezes again when I try to open a file including only one very long line.

[Manuel Giraud]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> And as I said in this other thread about « a file with just one long
> line », there still is longlines-mode (accessible from the So long
> menu).

My bad: I hadn't tested with this new file and here longlines-mode does
not help that much (Emacs is still responsive for me though). It might
be that longlines-mode is searching for space and there is none in this
file.
-- 
Manuel Giraud

Re: Emacs freezes again when I try to open a file including only one very long line.

[Manuel Giraud]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

[...]

> My bad: I hadn't tested with this new file and here longlines-mode does
> not help that much (Emacs is still responsive for me though). It might
> be that longlines-mode is searching for space and there is none in this
> file.

And that's it. It works on the "__tmp.symbols" file by modifying those
two functions in "longlines.el" as follow (here I've just changed the
string " " to "|"):

--8<---------------cut here---------------start------------->8---
(defun longlines-find-break-backward ()
  "Move point backward to the first available breakpoint and return t.
If no breakpoint is found, return nil."
  (and (search-backward "|" (line-beginning-position) 1)
       (save-excursion
         (skip-chars-backward "|" (line-beginning-position))
         (null (bolp)))
       (progn (forward-char 1)
              (if (and fill-nobreak-predicate
                       (run-hook-with-args-until-success
                        'fill-nobreak-predicate))
                  (progn (skip-chars-backward "|" (line-beginning-position))
                         (longlines-find-break-backward))
                t))))

(defun longlines-find-break-forward ()
  "Move point forward to the first available breakpoint and return t.
If no break point is found, return nil."
  (and (search-forward "|" (line-end-position) 1)
       (progn (skip-chars-forward " " (line-end-position))
              (null (eolp)))
       (if (and fill-nobreak-predicate
                (run-hook-with-args-until-success
                 'fill-nobreak-predicate))
           (longlines-find-break-forward)
         t)))
--8<---------------cut here---------------end--------------->8---

Maybe those searches should work against a bag of separators like
space, semicolon, veritcal bar… but it is a case to un-obsolete
longlines.el
-- 
Manuel Giraud

Re: Emacs freezes again when I try to open a file including only one very long line.

[Michael Heerdegen]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> Just out of curiosity, I wonder why my following configuration as
> discussed here [1], also can't solve the real-time display of search
> results appeared in extremely long lines:

Seems longlines.el only breaks at whitespace - see
`longlines-find-break-backward' - and that's hardcoded :-(

Michael.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Emanuel Berg]

Manuel Giraud wrote:

>> My bad: I hadn't tested with this new file and here longlines-mode does not help that much (Emacs is still responsive for me though). It might be that longlines-mode is searching for space and there is none in this file.
>
> And that's it. It works on the "__tmp.symbols" file by modifying those two functions in "longlines.el" as follow [...]

Long lines ... is that ... I mean I don't know :$ Heh, embarrassing. It just rings a bell somewhere really deep that that means something. Obviously it isn't a problem but it can be interesting to find out.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs freezes again when I try to open a file including only one very long line.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> But you are asking questions that are not relevant to what this
> feature does.  This feature prevents Emacs from freezing when you
> visit such files.  That is all it does.  As I tried explaining several
> times already.

Would it be more sensible to do something different than showing the
partially redisplayed window with a non-blinking cursor?  Even if Emacs
successfully aborted redisplay and everything is good, people might
think Emacs is still frozen because it looks frozen. That's what
happened to me: I thought the feature wouldn't work with my config for
some reason, until I tried to select a different window and then - ah! -
that actually works!  But it took some time...

Yes, I saw the warning window pop up, but it still just looked frozen
anyway.

Michael.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Emanuel Berg]

>ƒƒMyƒbad:ƒIƒhadn'tƒtestedƒwithƒthisƒnewƒfileƒandƒhereƒlonglines-modeƒdoesƒnotƒhelpƒthatƒmuchƒ(Emacsƒisƒstillƒresponsiveƒforƒmeƒthough).ƒItƒmightƒbeƒthatƒlonglines-modeƒisƒsearchingƒforƒspaceƒandƒthereƒisƒnoneƒinƒthisƒfile.
>
>ƒAndƒthat'sƒit.ƒItƒworksƒonƒtheƒ"__tmp.symbols"ƒfileƒbyƒmodifyingƒthoseƒtwoƒfunctionsƒinƒ"longlines.el"ƒasƒfollowƒ[...]

ƒLongƒlinesƒ...ƒisƒthatƒ...ƒIƒmeanƒIƒdon'tƒknowƒ:$ƒHeh,ƒembarrassing.ƒItƒjustƒringsƒaƒbellƒsomewhereƒreallyƒdeepƒthatƒthatƒmeansƒsomething.ƒObviouslyƒitƒisn'tƒaƒproblemƒbutƒitƒcanƒbeƒinterestingƒtoƒfindƒout.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs freezes again when I try to open a file including only one very long line.

[Manuel Giraud]

Emanuel Berg <incal@dataswamp.org> writes:

> Long lines ... is that ... I mean I don't know :$ Heh,
> embarrassing. It just rings a bell somewhere really deep that that
> means something. Obviously it isn't a problem but it can be
> interesting to find out.

I've seen that it was obsoleted some 10 years ago by 70de7cf72 but it
seems that it can still have some use case, no?
-- 
Manuel Giraud

Re: Emacs freezes again when I try to open a file including only one very long line.

[Hongyi Zhao]

On Thu, Jun 30, 2022 at 8:02 PM Manuel Giraud <manuel@ledu-giraud.fr> wrote:
>
> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
> [...]
>
> > My bad: I hadn't tested with this new file and here longlines-mode does
> > not help that much (Emacs is still responsive for me though). It might
> > be that longlines-mode is searching for space and there is none in this
> > file.
>
> And that's it. It works on the "__tmp.symbols" file by modifying those
> two functions in "longlines.el" as follow (here I've just changed the
> string " " to "|"):
>
> --8<---------------cut here---------------start------------->8---
> (defun longlines-find-break-backward ()
>   "Move point backward to the first available breakpoint and return t.
> If no breakpoint is found, return nil."
>   (and (search-backward "|" (line-beginning-position) 1)
>        (save-excursion
>          (skip-chars-backward "|" (line-beginning-position))
>          (null (bolp)))
>        (progn (forward-char 1)
>               (if (and fill-nobreak-predicate
>                        (run-hook-with-args-until-success
>                         'fill-nobreak-predicate))
>                   (progn (skip-chars-backward "|" (line-beginning-position))
>                          (longlines-find-break-backward))
>                 t))))
>
> (defun longlines-find-break-forward ()
>   "Move point forward to the first available breakpoint and return t.
> If no break point is found, return nil."
>   (and (search-forward "|" (line-end-position) 1)
>        (progn (skip-chars-forward " " (line-end-position))
>               (null (eolp)))
>        (if (and fill-nobreak-predicate
>                 (run-hook-with-args-until-success
>                  'fill-nobreak-predicate))
>            (longlines-find-break-forward)
>          t)))
> --8<---------------cut here---------------end--------------->8---
>
> Maybe those searches should work against a bag of separators like
> space, semicolon, veritcal bar… but it is a case to un-obsolete
> longlines.el

I think things/features like this should be added/extended into
longlines.el for flexibility in handling more scenarios.

> --
> Manuel Giraud

Best,
Hongsheng

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Thu, 30 Jun 2022 14:02:21 +0200
> 
> And that's it. It works on the "__tmp.symbols" file by modifying those
> two functions in "longlines.el" as follow (here I've just changed the
> string " " to "|"):
> 
> --8<---------------cut here---------------start------------->8---
> (defun longlines-find-break-backward ()
>   "Move point backward to the first available breakpoint and return t.
> If no breakpoint is found, return nil."
>   (and (search-backward "|" (line-beginning-position) 1)
>        (save-excursion
>          (skip-chars-backward "|" (line-beginning-position))
>          (null (bolp)))
>        (progn (forward-char 1)
>               (if (and fill-nobreak-predicate
>                        (run-hook-with-args-until-success
>                         'fill-nobreak-predicate))
>                   (progn (skip-chars-backward "|" (line-beginning-position))
>                          (longlines-find-break-backward))
>                 t))))
> 
> (defun longlines-find-break-forward ()
>   "Move point forward to the first available breakpoint and return t.
> If no break point is found, return nil."
>   (and (search-forward "|" (line-end-position) 1)
>        (progn (skip-chars-forward " " (line-end-position))
>               (null (eolp)))
>        (if (and fill-nobreak-predicate
>                 (run-hook-with-args-until-success
>                  'fill-nobreak-predicate))
>            (longlines-find-break-forward)
>          t)))
> --8<---------------cut here---------------end--------------->8---
> 
> Maybe those searches should work against a bag of separators like
> space, semicolon, veritcal bar… but it is a case to un-obsolete
> longlines.el

Feel free to suggest an improvement, like a defcustom that allows to
control what character(s) are used to break long lines.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Thu, 30 Jun 2022 14:52:54 +0200
> 
> Would it be more sensible to do something different than showing the
> partially redisplayed window with a non-blinking cursor?

I'd need more specific proposals to say anything intelligent.  To your
general question, my only answer is: this is what avoiding redisplay
of a window looks like in Emacs.  (Perhaps you didn't realize, but
blinking the cursor on a GUI frame requires a redisplay cycle each
time the cursor is turned on or off -- that's why it stops blinking in
the window whose buffer is marked "not for redisplay".)

> Even if Emacs successfully aborted redisplay and everything is good,
> people might think Emacs is still frozen because it looks
> frozen. That's what happened to me: I thought the feature wouldn't
> work with my config for some reason, until I tried to select a
> different window and then - ah! - that actually works!  But it took
> some time...

I think it's a one-time "eureka!" thing -- once you realize that this
is what happens, it will no longer be a surprise.  (Note that the
warning popping up was a last-minute improvement: the original
implementation just silently stopped updating the window, because we
cannot signal an error from redisplay in a way that causes an error
message to appear in the echo-area.)

Again, practical proposals for something you think is better are
welcome.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:


> I'd need more specific proposals to say anything intelligent.  To your
> general question, my only answer is: this is what avoiding redisplay
> of a window looks like in Emacs.

Can one still do useful things in a partially displayed window?

Michael.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Thu, 30 Jun 2022 16:16:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> 
> > I'd need more specific proposals to say anything intelligent.  To your
> > general question, my only answer is: this is what avoiding redisplay
> > of a window looks like in Emacs.
> 
> Can one still do useful things in a partially displayed window?

Sometimes.  Try C-l and then C-f.  If neither of them pops another
warning, you can use commands like C-f and C-b.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > Can one still do useful things in a partially displayed window?
>
> Sometimes.  Try C-l and then C-f.  If neither of them pops another
> warning, you can use commands like C-f and C-b.

Would it make sense to include an advice like that (or maybe a link to
(info "(emacs) Long Lines")) into the warning?

Michael.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > Can one still do useful things in a partially displayed window?
>
> Sometimes.  Try C-l and then C-f.  If neither of them pops another
> warning, you can use commands like C-f and C-b.

But my first reaction was: unselect the window, so that the user can
notice Emacs is still alive.  And doesn't try to edit the buffer without
seeing what one is doing.

Michael.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Thu, 30 Jun 2022 16:32:42 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > Can one still do useful things in a partially displayed window?
> >
> > Sometimes.  Try C-l and then C-f.  If neither of them pops another
> > warning, you can use commands like C-f and C-b.
> 
> Would it make sense to include an advice like that (or maybe a link to
> (info "(emacs) Long Lines")) into the warning?

How long do we want the warning to be?  It is already almost as long
as the normal frame dimensions allow for a single line.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Thu, 30 Jun 2022 16:36:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > Can one still do useful things in a partially displayed window?
> >
> > Sometimes.  Try C-l and then C-f.  If neither of them pops another
> > warning, you can use commands like C-f and C-b.
> 
> But my first reaction was: unselect the window, so that the user can
> notice Emacs is still alive.  And doesn't try to edit the buffer without
> seeing what one is doing.

That could be what you'd like to do in that case, but it doesn't have
to be what everyone will want to do.  Other possibilities include
turning on longlines mode there, or turning on so-long-mode, or
killing the buffer.  And I'm sure there could be other possibilities
that make sense in some cases.

IOW, I'm completely unsure that there's one-fits-all modus operandi
when that happens.

Re: Emacs freezes again when I try to open a file including only one very long line.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> IOW, I'm completely unsure that there's one-fits-all modus operandi
> when that happens.

I'm also unsure.  Let's see if the future brings more feedback from
others.

Michael.