bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Lars Ingebrigtsen]

This would be useful for large files like .sqlite and images.

The mechanism proposed on emacs-devel is to do something similar to
find-directory-functions in find-file-noselect:

(defun find-file-noselect (filename &optional nowarn rawfile wildcards)
[...]
  (if (file-directory-p filename)
      (or (and find-file-run-dired
	       (run-hook-with-args-until-success
		'find-directory-functions
		(if find-file-visit-truename
		    (abbreviate-file-name (file-truename filename))
		  filename)))

But for files.

So we could have a find-file-function-alist that maps from file names
(using the same syntax as auto-mode-alist) to functions that handle the
files.

This function would be called with the file name and would be
responsible for returning a buffer that "displays" the file in some
sense.  For .sqlite, it would basically call `sqlite-mode-open-file',
and image-mode should have a similar function.

There's some details that aren't clear.  Should this new buffer be
visiting the file?  That sounds dangerous, because saving the buffer
contents to the file would destroy the file.  But that could be handled
by...  write-file-functions?

Should there be another general mode these things should inherit from,
like special-mode, but taking care of things like write-file-functions
(i.e., disallow saving if the mode hasn't implemented a function for
that)?  If so, what should it be called?  `really-special-mode' is
probably too special.  Uhm...  Something that expresses "the displayed
contents of this mode doesn't match up the saved contents much"...
`unloaded-file-mode'?  Hm...  any ideas?


In GNU Emacs 29.0.50 (build 69, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
 of 2021-12-16 built on xo
Repository revision: e7a6d6a546e7e56e5a721aac86a19473e4303111
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Debian GNU/Linux bookworm/sid


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

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Adam Edge]

On 12/17/21 11:40, Lars Ingebrigtsen wrote:
> Should there be another general mode these things should inherit from,
> like special-mode, but taking care of things like write-file-functions
> (i.e., disallow saving if the mode hasn't implemented a function for
> that)?  If so, what should it be called?  `really-special-mode' is
> probably too special.  Uhm...  Something that expresses "the displayed
> contents of this mode doesn't match up the saved contents much"...
> `unloaded-file-mode'?  Hm...  any ideas?
Just my $.02, but would something related to "file projection" work? 
Since things like `sqlite-mode-open-file' "project" the file into a 
format that's more usable in Emacs. So my suggestion would be 
`projected-file-mode'.

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Juri Linkov]

> This would be useful for large files like .sqlite and images.

I'm not sure about images since some image formats are editable,
like .svg, .xpm, .ps...  Only .pdf with in doc-view-mode could have
this optimization of not loading the whole file.  Also archive files
could benefit from this optimization.

> This function would be called with the file name and would be
> responsible for returning a buffer that "displays" the file in some
> sense.

Or when it returns t, this could mean that the function displayed
the buffer in some other way, for example, by calling an external command.

Then find-file-alist could be used to implement a smarter
dired-guess-shell-alist like for https://debbugs.gnu.org/18132#92
So not only files visited by dired will be redirected
to an external command, but also files visited by C-x C-f.

> There's some details that aren't clear.  Should this new buffer be
> visiting the file?  That sounds dangerous, because saving the buffer
> contents to the file would destroy the file.  But that could be handled
> by...  write-file-functions?

Also functions that ask about saving a modified file buffer should
probably skip such buffers.

> Should there be another general mode these things should inherit from,
> like special-mode, but taking care of things like write-file-functions
> (i.e., disallow saving if the mode hasn't implemented a function for
> that)?  If so, what should it be called?  `really-special-mode' is
> probably too special.  Uhm...  Something that expresses "the displayed
> contents of this mode doesn't match up the saved contents much"...
> `unloaded-file-mode'?  Hm...  any ideas?

non-persistent-file-mode, or transient-file-mode, or ephemeral-mode...

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

>> This would be useful for large files like .sqlite and images.
>
> I'm not sure about images since some image formats are editable,
> like .svg, .xpm, .ps...  Only .pdf with in doc-view-mode could have
> this optimization of not loading the whole file.  Also archive files
> could benefit from this optimization.

This would improve performance, right?  If yes, I think this is sorely
needed for opening images in Emacs (though there are other things to
improve as well).  I think the editable image formats are in the
minority, so we could always handle them differently.

> Or when it returns t, this could mean that the function displayed
> the buffer in some other way, for example, by calling an external command.

Yes, that would be very nice.  I have wanted something like that to
replace the openwith package in my own use.

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> I'm not sure about images since some image formats are editable,
>> like .svg, .xpm, .ps...  Only .pdf with in doc-view-mode could have
>> this optimization of not loading the whole file.  Also archive files
>> could benefit from this optimization.
>
> This would improve performance, right?  If yes, I think this is sorely
> needed for opening images in Emacs (though there are other things to
> improve as well).

Yes, I think it should improve image performance substantially, but I
haven't done any measurements.

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

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> This would be useful for large files like .sqlite and images.
>
> I'm not sure about images since some image formats are editable,
> like .svg, .xpm, .ps...

I think we'd want to keep the traditinal auto-mode-alist for the
editable image formats.

> Only .pdf with in doc-view-mode could have this optimization of not
> loading the whole file.  Also archive files could benefit from this
> optimization.

arc-mode interprets zip files etc by itself, so I think that would be a
bigger challenge.

>> This function would be called with the file name and would be
>> responsible for returning a buffer that "displays" the file in some
>> sense.
>
> Or when it returns t, this could mean that the function displayed
> the buffer in some other way, for example, by calling an external command.
>
> Then find-file-alist could be used to implement a smarter
> dired-guess-shell-alist like for https://debbugs.gnu.org/18132#92
> So not only files visited by dired will be redirected
> to an external command, but also files visited by C-x C-f.

Hm...   interesting idea...  I think I'll have to ponder that more,
because that'd be a real user interface change, while the thing I was
thinking of here wouldn't be very apparent to the user at all -- it'd
just make things faster.

>> There's some details that aren't clear.  Should this new buffer be
>> visiting the file?  That sounds dangerous, because saving the buffer
>> contents to the file would destroy the file.  But that could be handled
>> by...  write-file-functions?
>
> Also functions that ask about saving a modified file buffer should
> probably skip such buffers.

Yes, probably.

> non-persistent-file-mode, or transient-file-mode, or ephemeral-mode...

Hm...  if `view-mode' wasn't taken already, perhaps that would have been
an option.

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

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> non-persistent-file-mode, or transient-file-mode, or ephemeral-mode...
>
> Hm...  if `view-mode' wasn't taken already, perhaps that would have been
> an option.

Here are some additional ideas:

    special-display-mode
    special-file-mode
    no-load-mode
    no-visit-mode    [if it won't be visiting]

bug#52569: 29.0.50; Wishlist: There should be a way for packages to handle files without reading them in first

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> non-persistent-file-mode, or transient-file-mode, or ephemeral-mode...
  > >
  > > Hm...  if `view-mode' wasn't taken already, perhaps that would have been
  > > an option.

  > Here are some additional ideas:

  >     special-display-mode
  >     special-file-mode
  >     no-load-mode
  >     no-visit-mode    [if it won't be visiting]

If it is useful to have a parent mode for modes that imitate visiting
a file without really doing so with the normal Emacs visit and save
mechanism, I suggest virtual-visit-mode.

But I suspect this will not prove useful, since we don't have
multiple inheritance for major modes.  I tend to think most of
these modes will turn out to have other things as parent modes.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)