bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Robert Marshall]

In a shell

mkdir dired-err
touch dired-err/xx
chmod 555 dired-err

emacs -Q
M-x dired  dired-err
C-x C-q
edit the xx file name to taste
C-c C-c (finish the edit)
You exit the filename editing mode with an error (not surprising) but
all your edits are lost. It would be more helpful if either C-x C-q gave
you a warning or the finish of the edit spotted that nothing was going
to work and complained or that it didn't exit the mode (though I realise
that there may be cases where some edits may have worked e.g. where the
dired-err subdir has been inserted in another dired session before
editing the file names)

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.25)
 of 2017-11-14 built on ct-lt-579
Repository revision: 13248f7444630508cfc3b78a07e8d96613af11c8
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.9 (jessie)

Recent messages:
Saving file /home/robertmarshall/.newsrc.eld...
Wrote /home/robertmarshall/.newsrc.eld
Saving /home/robertmarshall/.newsrc.eld...done
Directory has changed on disk; type g to update Dired
Press C-c C-c when finished or C-c ESC to abort changes
1 rename actions failed--type ? for details
Auto-saving...
Quit
Type C-x 1 to delete the help window.
Scanning for dabbrevs...done [2 times]

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS NOTIFY GNUTLS LIBXML2
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  gnus-desktop-notify-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Lars Ingebrigtsen]

Robert Marshall <robert.marshall@codethink.co.uk> writes:

> mkdir dired-err
> touch dired-err/xx
> chmod 555 dired-err

[...]

> You exit the filename editing mode with an error (not surprising) but
> all your edits are lost. It would be more helpful if either C-x C-q gave
> you a warning

I've now made `C-c C-q' signal an error if the directory isn't writable
in Emacs 28.

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

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Drew Adams]

> I've now made `C-c C-q' signal an error if the directory isn't writable
> in Emacs 28.

I don't feel strongly about this, but I wonder whether
that's the right thing to do.  We do NOT do that for
files, for example.

The use cases, for files and directories too, I believe,
are these:

1. You can make changes in the buffer for other reasons,
with no intention to save.  You can do that to affect
information gathering, analysis, discovery, sorting,
searching whatever.

2. You can make changes and THEN make the file or dir
writable (inside or outside Emacs), and THEN save the
changes you've already prepared.

#2 can be handy in a situation where the resource is
shared, or where for some other reason you want to
minimize the time during which it is writable: you 
make it writable only for the duration of saving, not
for the entire time you do the editing.

Unless I'm missing some counter arguments, I'd say
this request and the "fix", though well-meaning, are
misguided.

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Juri Linkov]

>> I've now made `C-c C-q' signal an error if the directory isn't writable
>> in Emacs 28.
>
> I don't feel strongly about this, but I wonder whether
> that's the right thing to do.  We do NOT do that for
> files, for example.

OTOH, displaying a warning might go unnoticed by the user.

Then maybe better would be to ask a y-or-n question
whether the user still wants to edit the unwritable buffer.

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> OTOH, displaying a warning might go unnoticed by the user.
>
> Then maybe better would be to ask a y-or-n question
> whether the user still wants to edit the unwritable buffer.

Makes sense.  I've now done this change.

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

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Drew Adams]

> >> I've now made `C-c C-q' signal an error if the directory isn't writable
> >> in Emacs 28.
> >
> > I don't feel strongly about this, but I wonder whether
> > that's the right thing to do.  We do NOT do that for
> > files, for example.
> 
> OTOH, displaying a warning might go unnoticed by the user.
> Then maybe better would be to ask a y-or-n question
> whether the user still wants to edit the unwritable buffer.

I disagree.  This should be handled _exactly_ the
same way we handle a buffer for a file that is
read-only.  I see no argument why we should treat
a directory buffer different from a file buffer.

For a file buffer, `C-x C-q' simply echoes:

  "Read-Only mode disabled in current buffer"

That is perfectly clear.

And any attempt to use a subsequent `C-x C-q to
save edit changes should be the time to query a
user for what to do (e.g. confirm saving the
changes or ignore them).

Come up with a good argument why this should be
handled differently from the file-editing case
and we can talk about it.  There are very good
use cases for allowing the _buffer_ to be edited,
regardless of whether the user ultimately wants
such changes applied to disk.

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Drew Adams]

> > OTOH, displaying a warning might go unnoticed by the user.
> >
> > Then maybe better would be to ask a y-or-n question
> > whether the user still wants to edit the unwritable buffer.
> 
> Makes sense.  I've now done this change.

Why do you keep making changes before even reading
responses or giving people a chance to respond?

Not one argument has been presented so far, by
anyone, as to why this case should be treated any
differently from the read-only file case.

I've given arguments why it should be treated the
same.  (They're the same arguments as would be
given for the file case.)

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Robert Marshall]

On Sun, Dec 13 2020, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Juri Linkov <juri@linkov.net> writes:
>
>> OTOH, displaying a warning might go unnoticed by the user.
>>
>> Then maybe better would be to ask a y-or-n question
>> whether the user still wants to edit the unwritable buffer.
>
> Makes sense.  I've now done this change.

I'm in agreement with this! (as original bug submitter - you'll get
bounces from my robert.marshall@codethink.co.uk address as I'm now
retired ;) )

Robert
-- 
Robert Marshall               twitter: @rajm

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Juri Linkov]

>> Then maybe better would be to ask a y-or-n question
>> whether the user still wants to edit the unwritable buffer.
>
> I disagree.  This should be handled _exactly_ the
> same way we handle a buffer for a file that is
> read-only.  I see no argument why we should treat
> a directory buffer different from a file buffer.

Asking a y-or-n question is _exactly_ what
'C-x C-q' does in wdired, i.e. after typing
'C-x C-q' (wdired-exit) it asks a question:

  Buffer modified; save changes? (y or n) 

So now entering wdired mode does the same thing with
'C-x C-q' (dired-toggle-read-only):

  Directory isn't writable; edit anyway? (y or n) 

bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable

[Drew Adams]

> >> Then maybe better would be to ask a y-or-n question
> >> whether the user still wants to edit the unwritable buffer.
> >
> > I disagree.  This should be handled _exactly_ the
> > same way we handle a buffer for a file that is
> > read-only.  I see no argument why we should treat
> > a directory buffer different from a file buffer.
> 
> Asking a y-or-n question is _exactly_ what
> 'C-x C-q' does in wdired, i.e. after typing
> 'C-x C-q' (wdired-exit) it asks a question:
> 
>   Buffer modified; save changes? (y or n)

Yes, for saving changes.  That's just what I suggested.

> So now entering wdired mode does the same thing with
> 'C-x C-q' (dired-toggle-read-only):
> 
>   Directory isn't writable; edit anyway? (y or n)

That is NOT the same way we handle a file buffer.

We are both repeating ourselves, it seems.

I gave 2 good reasons why this should be handled the
same way as we handle read-only files.  And they are
no doubt among the reasons (perhaps the only reasons?)
Emacs has always behaved as it does for file buffers.

So far, no one has given ANY reasons why we should not
handle directory visits and editing the same way as
file visits and editing.