Re: Memory-efficient way of opening large files in Emacs read-only

[Mikhail Pomaznoy <mikpom@mikpom.ru>]

Thanks for your replies. Seamless less-like viewing in Emacs (not 
terminals of any kind) is my ultimate goal and I will look into that per 
Marcin'c suggestion. If it will turn out not fun (too difficult), 
further investment into VLF makes total sense.

Thanks,

-Mikhail

On 12/8/22 21:27, Marcin Borkowski wrote:
> On 2022-12-08, at 03:49, Mikhail Pomaznoy <mikpom@mikpom.ru> wrote:
>
>> Greetings!
>>
>> In my daily workflows I commonly stumble upon a task of peeking into
>> a header of a large (sometimes compressed) file. Those files can
>> commonly be gigabytes in compressed form so can't fit into
>> memory. I was wondering how can this be done in Emacs to leverage its
>> search and navigate capabilities?
>>
>> In a terminal this task is nicely accomplished with `less`, which
>> loads file on demand while you scroll (memory-efficiently) and
>> automatically detects at least gzip compression. However I am
>> struggling to do something similar in Emacs for quite a long time.
>> I tried VLF (requires manually switching chunks loaded, encountered
>> problems with compression), view-file (loads everything in memory),
>> running less in Emacs terminals (I prefer outside-Emacs terminals) but
>> for various reasons all this solutions are suboptimal and I usually
>> end up with using `less`.
>>
>> Is there something in Emacs I am missing? Is something like this makes
>> sense to develop (I consider to write something for Emacs) ? I am
>> using Emacs 28 and maybe in Emacs 29 there are novelties related to
>> this issue?
> I have no idea if Emacs has anything like this (I doubt), but the way
> I'd go about it would be to either leverage `less' inside one of the
> Emacs terminals or write some Elisp, colling to things like `gunzip' and
> `head' and then putting the result into some buffer.  (I think you could
> even make it so that scrolling down would load the next portion in the
> background, à la modern Web.  While I /hate/ this behavior of websites,
> here it could actually make sense.)
>
> Best,
>