Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Stefan Monnier]

> diff --git a/etc/PROBLEMS b/etc/PROBLEMS
> index 14c1df25b1..4f02788ecd 100644
> --- a/etc/PROBLEMS
> +++ b/etc/PROBLEMS
> @@ -568,12 +568,6 @@ This can happen with CVS versions 1.12.8 and 1.12.9.  Upgrade to CVS
>  
>  ** Miscellaneous problems
>  
> -*** Editing files with very long lines is slow.
> -
> -For example, simply moving through a file that contains hundreds of
> -thousands of characters per line is slow, and consumes a lot of CPU.
> -This is a known limitation of Emacs with no solution at this time.

I wish this were true, but AFAIK the problem is still very much present.
We deal with it a bit better, but that doesn't mean the problem is gone.
In my tests, editing the end of a 1MB single-line JSON file is still
basically not an option, for example.


        Stefan

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Gregory Heytings]

>> -*** Editing files with very long lines is slow.
>> -
>> -For example, simply moving through a file that contains hundreds of
>> -thousands of characters per line is slow, and consumes a lot of CPU.
>> -This is a known limitation of Emacs with no solution at this time.
>
> I wish this were true, but AFAIK the problem is still very much present. 
> We deal with it a bit better, but that doesn't mean the problem is gone. 
> In my tests, editing the end of a 1MB single-line JSON file is still 
> basically not an option, for example.
>

Please try the feature branch, and you'll see the problem is gone.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

>>> -*** Editing files with very long lines is slow.
>>> -
>>> -For example, simply moving through a file that contains hundreds of
>>> -thousands of characters per line is slow, and consumes a lot of CPU.
>>> -This is a known limitation of Emacs with no solution at this time.
>>
>> I wish this were true, but AFAIK the problem is still very much
>> present. We deal with it a bit better, but that doesn't mean the
>> problem is gone. In my tests, editing the end of a 1MB single-line
>> JSON file is still basically not an option, for example.
>>
>
> Please try the feature branch, and you'll see the problem is gone.

I just tried it out, and while it certainly is an improvement, I noticed
that the performance appears to depend on the direction the point moves.
E.g. I generated a long line using

     yes abbbbbbbbbbbbbbbbbbbb | head -100000 | tr -d '\n' > long-line

and I could C-v to the end without any issues.  But M-v was
significantly slower.  The same applies to C-f vs. C-b.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Gregory Heytings]

>
> I just tried it out, and while it certainly is an improvement, I noticed 
> that the performance appears to depend on the direction the point moves. 
> E.g. I generated a long line using
>
> yes abbbbbbbbbbbbbbbbbbbb | head -100000 | tr -d '\n' > long-line
>
> and I could C-v to the end without any issues.  But M-v was 
> significantly slower.  The same applies to C-f vs. C-b.
>

Yes, the same is true without long lines, moving backward is slower than 
moving forward (but you probably meant C-p vs C-n, not C-f vs C-b). 
Please also read the relevant NEWS entry.  And try to edit that file with 
Emacs from master to see the difference.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> I just tried it out, and while it certainly is an improvement, I
>> noticed that the performance appears to depend on the direction the
>> point moves. E.g. I generated a long line using
>>
>> yes abbbbbbbbbbbbbbbbbbbb | head -100000 | tr -d '\n' > long-line
>>
>> and I could C-v to the end without any issues.  But M-v was
>> significantly slower.  The same applies to C-f vs. C-b.
>>
>
> Yes, the same is true without long lines, moving backward is slower
> than moving forward (but you probably meant C-p vs C-n, not C-f vs
> C-b).

No, I meant C-f and C-b, as the file contained only one line, but the
same applies to C-p and C-n.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Gregory Heytings]

>> Yes, the same is true without long lines, moving backward is slower 
>> than moving forward (but you probably meant C-p vs C-n, not C-f vs 
>> C-b).
>
> No, I meant C-f and C-b,

That's rather surprising.  Even with Emacs on master, C-f and C-b can 
(almost) be used in such a file, and take the same amount of time.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Gregory Heytings]

>> I wish this were true, but AFAIK the problem is still very much 
>> present. We deal with it a bit better, but that doesn't mean the 
>> problem is gone. In my tests, editing the end of a 1MB single-line JSON 
>> file is still basically not an option, for example.
>
> Please try the feature branch, and you'll see the problem is gone.
>

The feature has now landed on master.  You can now edit the end of a 1GB 
single-line file as if it were a 1KB file.  Enjoy!

(There are still a few limits, in particular font locking that should be 
turned off in files with long lines.  I will fix them soon.)

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> The feature has now landed on master.  You can now edit the end of a 1GB
> single-line file as if it were a 1KB file.  Enjoy!

Yay!  Congratulations.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Daniel Martín]

Gregory Heytings <gregory@heytings.org> writes:

>>> I wish this were true, but AFAIK the problem is still very much
>>> present. We deal with it a bit better, but that doesn't mean the
>>> problem is gone. In my tests, editing the end of a 1MB single-line
>>> JSON file is still basically not an option, for example.
>>
>> Please try the feature branch, and you'll see the problem is gone.
>>
>
> The feature has now landed on master.  You can now edit the end of a
> 1GB single-line file as if it were a 1KB file.  Enjoy!
>
> (There are still a few limits, in particular font locking that should
> be turned off in files with long lines.  I will fix them soon.)

Thank you for working on this.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Stefan Monnier]

> (There are still a few limits, in particular font locking that should be
>  turned off in files with long lines.  I will fix them soon.)

The font-lock (and `syntax-propertize`) code on `master` should already
"adapt" to long lines, in theory, so if you find single-line large files
significantly worse (because of `font-lock` or `syntax-propertize`) than
non-single line similarly large files, I'd be interested to hear
about it.


        Stefan

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 21 Jul 2022 11:25:14 -0400
> 
> > (There are still a few limits, in particular font locking that should be
> >  turned off in files with long lines.  I will fix them soon.)
> 
> The font-lock (and `syntax-propertize`) code on `master` should already
> "adapt" to long lines, in theory, so if you find single-line large files
> significantly worse (because of `font-lock` or `syntax-propertize`) than
> non-single line similarly large files, I'd be interested to hear
> about it.

One such recipe is described here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56393#425

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Gregory Heytings]

>> (There are still a few limits, in particular font locking that should 
>> be turned off in files with long lines.  I will fix them soon.)
>
> The font-lock (and `syntax-propertize`) code on `master` should already 
> "adapt" to long lines, in theory, so if you find single-line large files 
> significantly worse (because of `font-lock` or `syntax-propertize`) than 
> non-single line similarly large files, I'd be interested to hear about 
> it.
>

Take any sufficiently large database dump, minified Javascript file, HTML 
file, etc., edit it with font locking turned on and off, and you'll see 
that font locking still has a very significant impact on performance.

Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> The feature has now landed on master.  You can now edit the end of a
> 1GB single-line file as if it were a 1KB file.  Enjoy!

Thanks so much for working on this.  I've just tried this briefly (I'm
nominally still on vacation), but it seems to work wonderfully on the
couple pathological files I've tried this on.

The "long line total freezes" in Emacs was one of the most embarrassing
bugs in Emacs, and I'm so pleased that it's finally gone.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no