bug#18823: 24.4; Built-in support on MS-Windows for visiting compressed files

bug#18823: 24.4; Built-in support on MS-Windows for visiting compressed files

[Dani Moncayo]

Severity: wishlist

Currently, on MS-Windows, if gzip.exe is not available at run time, it
is not possible to visit .gz files.  So, for example, it is not possible
to read any info manual from a binary distribution made with a plain
"make install".

But it seems that limitation could be removed [1].  Hence this request
for having built-in support on MS-Windows for displaying compressed
files.

TIA.

In GNU Emacs 24.4.1 (i686-pc-mingw32)
 of 2014-10-24 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --prefix=/c/usr'

--
Dani Moncayo

[1] http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00917.html

bug#18823: 24.4; Built-in support on MS-Windows for visiting compressed files

[Eli Zaretskii]

> Date: Sat, 25 Oct 2014 11:17:11 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> Currently, on MS-Windows, if gzip.exe is not available at run time, it
> is not possible to visit .gz files.  So, for example, it is not possible
> to read any info manual from a binary distribution made with a plain
> "make install".
> 
> But it seems that limitation could be removed [1].  Hence this request
> for having built-in support on MS-Windows for displaying compressed
> files.

I don't think there's anything Windows-specific here: AFAIK Emacs
requires 'gzip' for visiting compressed files on all supported
systems, including Unix and GNU systems.  It's just that on Posix
hosts the probability of 'gzip' being installed is much higher, though
not 100% AFAIK.

So I think the requested feature could be reworded as follows: enhance
jka-compr to support internal decompression methods such as
zlib-decompress-region.

bug#18823: Built-in support for visiting compressed files

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So I think the requested feature could be reworded as follows: enhance
> jka-compr to support internal decompression methods such as
> zlib-decompress-region.

I've now added this to Emacs 28.  I added it as a fallback (when the
external programme doesn't exist), because that seemed least likely to
break something, but we could consider reversing the code (since it's
likely to be faster to use the internal function).

This also reminded me that I wanted to add a function that does the
"reverse" of `insert-buffer-substring', which I don't think we have.  That
is, to allow saying

(let ((buf (current-buffer)))
  (with-temp-buffer
    (create-lots-of-data)
    (insert-into-buffer buf (point-min) (point-max))))

in an efficient way.  When dealing with temporary buffers, you have to
contort yourself to use `insert-buffer-substring' in the other
direction, and

(insert
  (with-temp-buffer
    ...
    (buffer-string)))

is pretty inefficient.

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

bug#18823: Built-in support for visiting compressed files

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dani Moncayo <dmoncayo@gmail.com>,  18823@debbugs.gnu.org
> Date: Tue, 13 Jul 2021 23:28:44 +0200
> 
> This also reminded me that I wanted to add a function that does the
> "reverse" of `insert-buffer-substring', which I don't think we have.  That
> is, to allow saying
> 
> (let ((buf (current-buffer)))
>   (with-temp-buffer
>     (create-lots-of-data)
>     (insert-into-buffer buf (point-min) (point-max))))
> 
> in an efficient way.  When dealing with temporary buffers, you have to
> contort yourself to use `insert-buffer-substring' in the other
> direction, and
> 
> (insert
>   (with-temp-buffer
>     ...
>     (buffer-string)))
> 
> is pretty inefficient.

To insert text, you must make the buffer into which you insert be the
current buffer.  That's how the low-level insertion primitives work.
So what will insert-into-buffer do that is different (and more
efficient) than the contortion you need to do now, which involves
temporary switch to the target buffer?

Or what am I missing?

bug#18823: Built-in support for visiting compressed files

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> To insert text, you must make the buffer into which you insert be the
> current buffer.  That's how the low-level insertion primitives work.
> So what will insert-into-buffer do that is different (and more
> efficient) than the contortion you need to do now, which involves
> temporary switch to the target buffer?

It just does the contortion for you.

This sort of thing comes up mostly when doing stuff with temporary
buffers, so I wonder whether we should consider adding a special form
for it.  That is, something like `with-temp-buffer-and-insert' that
would work identically as `with-temp-buffer', but insert the contents of
the buffer into the current buffer before killing the temporary
buffer...

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

bug#18823: Built-in support for visiting compressed files

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dmoncayo@gmail.com,  18823@debbugs.gnu.org
> Date: Wed, 14 Jul 2021 15:05:13 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To insert text, you must make the buffer into which you insert be the
> > current buffer.  That's how the low-level insertion primitives work.
> > So what will insert-into-buffer do that is different (and more
> > efficient) than the contortion you need to do now, which involves
> > temporary switch to the target buffer?
> 
> It just does the contortion for you.

So you want a function that does

  (let ((source-buf (current-buffer)))
    (with-current-buffer target-buf
      (insert-buffer-substring source-buf ...)))

is that it?

> This sort of thing comes up mostly when doing stuff with temporary
> buffers, so I wonder whether we should consider adding a special form
> for it.  That is, something like `with-temp-buffer-and-insert' that
> would work identically as `with-temp-buffer', but insert the contents of
> the buffer into the current buffer before killing the temporary
> buffer...

If it's something one must do a lot, maybe...

bug#18823: Built-in support for visiting compressed files

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So you want a function that does
>
>   (let ((source-buf (current-buffer)))
>     (with-current-buffer target-buf
>       (insert-buffer-substring source-buf ...)))
>
> is that it?

Yes -- it's already pushed to Emacs 28.

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

bug#18823: Built-in support for visiting compressed files

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> This sort of thing comes up mostly when doing stuff with temporary
>> buffers, so I wonder whether we should consider adding a special form
>> for it.  That is, something like `with-temp-buffer-and-insert' that
>> would work identically as `with-temp-buffer', but insert the contents of
>> the buffer into the current buffer before killing the temporary
>> buffer...
>
> If it's something one must do a lot, maybe...

I grepped the Emacs tree.  There's only ten instances of

(insert (with-temp-buffer ...))

But there's over 200 instances of

(with-temp-buffer ... (buffer-string))

where some of them basically eventually translate to inserting that into
the current buffer -- some of which do the `insert-into-buffer' contortion
themselves.

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

bug#18823: 24.4; Built-in support for visiting compressed files

[Dani Moncayo]

retitle 18823 Built-in support for visiting compressed files
stop

> I don't think there's anything Windows-specific here: AFAIK Emacs
> requires 'gzip' for visiting compressed files on all supported
> systems, including Unix and GNU systems.  It's just that on Posix
> hosts the probability of 'gzip' being installed is much higher, though
> not 100% AFAIK.
>
> So I think the requested feature could be reworded as follows: enhance
> jka-compr to support internal decompression methods such as
> zlib-decompress-region.

Ok, I misunderstood you.  Thanks.

-- 
Dani Moncayo