bug#50189: wdired chmod should not follow symlinks (Bug#11912 followup)

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Yeah, editing the permissions doesn't seem to work for me in dired.  If
> > I start with
> >
> >   -rw-r--r--  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG
> >
> > and press DEL after the final dash, it'll delete the dash and then say
> > "Text is read only", leaving me with:
> >
> >   -rw-r--r-  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG
> >
> > And then I can't insert anything there, because it's now read-only.  So
> > something is wonky in the way wdired tries to make certain bits of the
> > line read-only.
>
> Setting wdired-allow-to-change-permissions to t or `advanced' made this
> work -- you can't really edit the permissions without that.

That behavior not optimal and a bit confusing.

As you might remember, text properties in wdired are now attached on the
fly for better performance, implemented here:

| 4dbc44550d * lisp/wdired.el: Apply text properties lazily
| Arthur Miller <arthur.miller@live.com> 2021-03-27

[Arthur is CC'd]

The problem in this case: the read-only property is attached in
`before-change-functions'.  But that doesn't prevent the change being
performed.  Try e.g. in *scratch*:

#+begin_src emacs-lisp
(add-hook 'before-change-functions
          (lambda (&rest _)
            (put-text-property (point-min) (point-max)
                               'read-only t))
          nil t)
#+end_src

The first changes goes through although the text is already read-only,
because it's still the same command or so (anyone thinking this is a
bug?).

I think we could make wdired explicitly check for and throw a
"user-error" in this case so that the editing command is not performed
(but only after the properties were attached).

TIA,

Michael.