> How long did you wait?

I do not think that matters in this case.  The Emacs process
had gone  dead or crazy, and the operating system said that it was
not responding and offered to 'Force Close' the process, and
so I said go ahead and do it.

> Emacs 28 is no longer maintained.  But I don't think anything has
> changed since then in how we handle large files.  However, if the
> lines in the file are very long, you will be better off using Emacs 29
> where there are special features for speeding up the display of very
> long lines.

Long lines may be the problem!

I am utterly dependent upon Debian concerning the version of Emacs
I use.  If and when I get 29, I'll give the file another try.

Thank you,,

Bob


On Sun, Mar 3, 2024 at 1:39 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Boyer <robertstephenboyer@gmail.com>
> > Date: Sat, 2 Mar 2024 22:39:29 -0600
> >
> > My problem persists.  I very strongly believe that I have an example of
> a bug in Emacs.
> >
> > I have previously reported this.  I got some advice.  It did not solve
> my problem.
> >
> > Today I got a new, much bigger and better Chromebook, again from
> Lenovo.  This
> > one cost me $300, but it has 8gb of core and tons more disk.
> >
> > On my newest Chromebook I see the following:
> >
> > > free
> >                total        used        free      shared  buff/cache
>  available
> > Mem:         6736092     1194036     4052888       52208     1489168
>  5542056
> > Swap:              0           0           0
> > >
> >
> > I do not understand these things at all well, but it looks to me like I
> now
> > have 4gb of free space.
> >
> > So I think it is fair for me to report my real problem, again, almost
> exactly
> > as I did before.
> >
> > The 1 gb file for which I give a url below does not seem to work in
> Emacs.
> >
> > The file enumerates the primes below 10^9, so it would be very handy to
> > have around.
> >
> > I can find the file, literally, into an Emacs buffer.
> >
> > But then I cannot move to the bottom, i.e., using M->.  In fact, in the
> attempt to
> > move to the bottom, things go so badly that Emacs freezes, and I have to
> kill Emacs
> > by 'extraordinary measures'.
>
> How long did you wait?  Unless it's for an hour or so, this could be
> just some slow operation.  Does the system page during this (do you
> see the hard disk LED light more or less constantly)?  This could be
> one reason for the slowness.
>
> How many lines does this file have?  If its lines are very long, this
> could be a known slowness in the display engine.
>
> > Is this file just too big for Emacs to handle?
>
> No.
>
> >
> https://drive.google.com/file/d/1IaRNZ1rUQAZ72A7rJYpescmnJhpuGliA/view?usp=sharing
> >
> > Please, before you reply, fetch that file, find it literally, and see if
> > you can move to the bottom with M->.  I'd love to know whether you can
> do that.
>
> I cannot afford downloading such a huge file, sorry.  Maybe someone
> else can.
>
> > In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
> cairo version 1.16.0)
> >  of 2023-05-13, modified by Debian built on x86-ubc-01
> > Windowing system distributor 'The X.Org Foundation', version
> 11.0.12014000
> > System Description: Debian GNU/Linux 12 (bookworm)
>
> Emacs 28 is no longer maintained.  But I don't think anything has
> changed since then in how we handle large files.  However, if the
> lines in the file are very long, you will be better off using Emacs 29
> where there are special features for speeding up the display of very
> long lines.
>