bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74637: [PATCH] Make view-read-only behave like view-file


From: Björn Bidar
Subject: bug#74637: [PATCH] Make view-read-only behave like view-file
Date: Sat, 07 Dec 2024 20:05:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  74637@debbugs.gnu.org,  Stefan Kangas
>>  <stefankangas@gmail.com>
>> Date: Sat, 07 Dec 2024 02:39:20 +0200
>> 
>> Andrea Corallo <acorallo@gnu.org> writes:
>> 
>> >> Stefan and Andrea, WDYT?
>> >
>> > Agree with your position.
>> 
>> If before killing the file there would be a check if it was deleted
>> is that better? The check would also improve the view-file related
>> functions.
>
> Personally, I'm not sure it is much better.  First, the file might
> have been moved or renamed, not deleted.  More generally, it strikes
> me as very un-Emacsy to kill a buffer when the user is done with it.

Would a better approach be then that pressing q burries the buffer but
doesn't exit view-mode if entered through view-read-only on a non
writable aka read-only file? Doing so wouldn't remove the option to exit
view-mode on such buffers but keep view-mode on in case the user visits
the buffer again. Pressing q to bury or delete a read-only buffer is a
common action across almost any mode.

> We only do that with temporary buffers created for the purpose of
> performing some processing; otherwise we leave the buffers in the
> session, leaving it to the user to decide when to kill them.  We also
> have optional features, like mindnight.el, which are capable of
> killing buffers that were not accessed for a long time, and the very
> fact that they are optional clearly shows the general attitude of
> Emacs: not to kill buffers unless explicitly told so by the user.

Buffer which visit read only files such as system documentation could be
considered temporary but I get the point.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]