* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
@ 2017-11-23 16:11 Robert Marshall
2020-12-12 11:33 ` Lars Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Robert Marshall @ 2017-11-23 16:11 UTC (permalink / raw)
To: 29412
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:
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2017-11-23 16:11 bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable Robert Marshall
@ 2020-12-12 11:33 ` Lars Ingebrigtsen
2020-12-12 19:26 ` Drew Adams
0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-12 11:33 UTC (permalink / raw)
To: Robert Marshall; +Cc: 29412
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-12 11:33 ` Lars Ingebrigtsen
@ 2020-12-12 19:26 ` Drew Adams
2020-12-13 8:32 ` Juri Linkov
0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2020-12-12 19:26 UTC (permalink / raw)
To: Lars Ingebrigtsen, Robert Marshall; +Cc: 29412
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-12 19:26 ` Drew Adams
@ 2020-12-13 8:32 ` Juri Linkov
2020-12-13 13:18 ` Lars Ingebrigtsen
2020-12-13 16:55 ` Drew Adams
0 siblings, 2 replies; 10+ messages in thread
From: Juri Linkov @ 2020-12-13 8:32 UTC (permalink / raw)
To: Drew Adams; +Cc: Robert Marshall, Lars Ingebrigtsen, 29412
>> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-13 8:32 ` Juri Linkov
@ 2020-12-13 13:18 ` Lars Ingebrigtsen
2020-12-13 17:00 ` Drew Adams
2020-12-13 19:04 ` Robert Marshall
2020-12-13 16:55 ` Drew Adams
1 sibling, 2 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-13 13:18 UTC (permalink / raw)
To: Juri Linkov; +Cc: Robert Marshall, 29412
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-13 13:18 ` Lars Ingebrigtsen
@ 2020-12-13 17:00 ` Drew Adams
2020-12-13 19:04 ` Robert Marshall
1 sibling, 0 replies; 10+ messages in thread
From: Drew Adams @ 2020-12-13 17:00 UTC (permalink / raw)
To: Lars Ingebrigtsen, Juri Linkov; +Cc: Robert Marshall, 29412
> > 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.)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-13 13:18 ` Lars Ingebrigtsen
2020-12-13 17:00 ` Drew Adams
@ 2020-12-13 19:04 ` Robert Marshall
1 sibling, 0 replies; 10+ messages in thread
From: Robert Marshall @ 2020-12-13 19:04 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 29412, Juri Linkov
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-13 8:32 ` Juri Linkov
2020-12-13 13:18 ` Lars Ingebrigtsen
@ 2020-12-13 16:55 ` Drew Adams
2020-12-13 19:58 ` Juri Linkov
1 sibling, 1 reply; 10+ messages in thread
From: Drew Adams @ 2020-12-13 16:55 UTC (permalink / raw)
To: Juri Linkov; +Cc: Robert Marshall, Lars Ingebrigtsen, 29412
> >> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-13 16:55 ` Drew Adams
@ 2020-12-13 19:58 ` Juri Linkov
2020-12-13 21:45 ` Drew Adams
0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2020-12-13 19:58 UTC (permalink / raw)
To: Drew Adams; +Cc: Robert Marshall, Lars Ingebrigtsen, 29412
>> 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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable
2020-12-13 19:58 ` Juri Linkov
@ 2020-12-13 21:45 ` Drew Adams
0 siblings, 0 replies; 10+ messages in thread
From: Drew Adams @ 2020-12-13 21:45 UTC (permalink / raw)
To: Juri Linkov; +Cc: Robert Marshall, Lars Ingebrigtsen, 29412
> >> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-12-13 21:45 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-23 16:11 bug#29412: 27.0.50; dired-toggle-read-only should (at some point!) check that the direcory is writeable Robert Marshall
2020-12-12 11:33 ` Lars Ingebrigtsen
2020-12-12 19:26 ` Drew Adams
2020-12-13 8:32 ` Juri Linkov
2020-12-13 13:18 ` Lars Ingebrigtsen
2020-12-13 17:00 ` Drew Adams
2020-12-13 19:04 ` Robert Marshall
2020-12-13 16:55 ` Drew Adams
2020-12-13 19:58 ` Juri Linkov
2020-12-13 21:45 ` Drew Adams
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).