reverting non-existent file

reverting non-existent file

[Colin Baxter]

I don't know if this is a bug or just a feature of emacs. Therefore, I'd
better ask here first.

1. emacs -Q <RET>
2. C-x C-f some-non-existing-file-name <RET>
3. M-x add-file-local-variable-prop-line <RET>
4. coding <RET>
5. iso-2022-jp <RET>
6. Told to revert file for effect to take place.
7. M-x revert-buffer <RET>
8. yes <RET>
9. Told cannot revert nonexistent file.

The same effect occurs with other codings, for example utf-16 - but not
with utf-8-unix. I'm using emacs-28.0.50.

Colin.


-- 
Colin Baxter
URL: http://www.Colin-Baxter.com

Re: reverting non-existent file

[Eli Zaretskii]

> From: Colin Baxter <m43cap@yandex.com>
> Date: Thu, 14 May 2020 17:13:22 +0100
> 
> 1. emacs -Q <RET>
> 2. C-x C-f some-non-existing-file-name <RET>
> 3. M-x add-file-local-variable-prop-line <RET>
> 4. coding <RET>
> 5. iso-2022-jp <RET>
> 6. Told to revert file for effect to take place.
> 7. M-x revert-buffer <RET>
> 8. yes <RET>
> 9. Told cannot revert nonexistent file.
> 
> The same effect occurs with other codings, for example utf-16 - but not
> with utf-8-unix. I'm using emacs-28.0.50.

I get the error message even if I don't do steps 3 to 6.  And that is
expected, as a non-existent file cannot be reverted.  So what did you
find surprising in this behavior?

(I'm guessing that your locale uses UTF-8 as its codeset, so the new
file's buffer has utf-8 encoding from the get-go, and thus adding the
local variable doesn't change the coding-system, and you are not asked
to revert the buffer.  Which is also expected.)

Confused.

Re: reverting non-existent file

[Colin Baxter]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

    >> From: Colin Baxter <m43cap@yandex.com> Date: Thu, 14 May 2020
    >> 17:13:22 +0100
    >> 
    >> 1. emacs -Q <RET> 2. C-x C-f some-non-existing-file-name <RET>
    >> 3. M-x add-file-local-variable-prop-line <RET> 4. coding <RET>
    >> 5. iso-2022-jp <RET> 6. Told to revert file for effect to take
    >> place.  7. M-x revert-buffer <RET> 8. yes <RET> 9. Told cannot
    >> revert nonexistent file.
    >> 
    >> The same effect occurs with other codings, for example utf-16 -
    >> but not with utf-8-unix. I'm using emacs-28.0.50.

    > I get the error message even if I don't do steps 3 to 6.  And that
    > is expected, as a non-existent file cannot be reverted.  So what
    > did you find surprising in this behavior?

    > (I'm guessing that your locale uses UTF-8 as its codeset, so the
    > new file's buffer has utf-8 encoding from the get-go, and thus
    > adding the local variable doesn't change the coding-system, and
    > you are not asked to revert the buffer.  Which is also expected.)

    > Confused.

Not now, thanks. I think I was confused by the response "revert-buffer"
when I knew I'd yet to save it. And yes, my locale is utf-8. Sorry to waste
your time.

Best wishes,



-- 
Colin Baxter
URL: http://www.Colin-Baxter.com

Re: reverting non-existent file

[Eli Zaretskii]

> From: Colin Baxter <m43cap@yandex.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 May 2020 19:52:29 +0100
> 
>     > I get the error message even if I don't do steps 3 to 6.  And that
>     > is expected, as a non-existent file cannot be reverted.  So what
>     > did you find surprising in this behavior?
> 
>     > (I'm guessing that your locale uses UTF-8 as its codeset, so the
>     > new file's buffer has utf-8 encoding from the get-go, and thus
>     > adding the local variable doesn't change the coding-system, and
>     > you are not asked to revert the buffer.  Which is also expected.)
> 
>     > Confused.
> 
> Not now, thanks. I think I was confused by the response "revert-buffer"
> when I knew I'd yet to save it. And yes, my locale is utf-8.

Hmm... maybe we should not suggest reverting if the file doesn't
exist?  Would that make this situation less confusing?

Re: reverting non-existent file

[Richard Copley]

On Thu, 14 May 2020 at 20:03, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Colin Baxter <m43cap@yandex.com>
> > Cc: emacs-devel@gnu.org
> > Date: Thu, 14 May 2020 19:52:29 +0100
> >
> >     > I get the error message even if I don't do steps 3 to 6.  And that
> >     > is expected, as a non-existent file cannot be reverted.  So what
> >     > did you find surprising in this behavior?
> >
> >     > (I'm guessing that your locale uses UTF-8 as its codeset, so the
> >     > new file's buffer has utf-8 encoding from the get-go, and thus
> >     > adding the local variable doesn't change the coding-system, and
> >     > you are not asked to revert the buffer.  Which is also expected.)
> >
> >     > Confused.
> >
> > Not now, thanks. I think I was confused by the response "revert-buffer"
> > when I knew I'd yet to save it. And yes, my locale is utf-8.
>
> Hmm... maybe we should not suggest reverting if the file doesn't
> exist?  Would that make this situation less confusing?

Why suggest reverting, whether or not the file exists? The buffer
change just made by add-file-local-variable-prop-line hasn't been
saved to any file yet. Reverting will undo the change, along with any
other unsaved changes.

It seems like a little mistake in the wording of the suggestion. It
might make more sense to advise the user to save and then revert --
except that it wouldn't cause the file-local variable to take effect
anyway. Perhaps I'm misunderstanding what the message means
("revisit"?).

I think it should say just say to run "normal-mode".

Re: reverting non-existent file

[Stefan Monnier]

>> Not now, thanks. I think I was confused by the response "revert-buffer"
>> when I knew I'd yet to save it. And yes, my locale is utf-8.
>
> Hmm... maybe we should not suggest reverting if the file doesn't
> exist?  Would that make this situation less confusing?

Indeed, I think the confusion was simply introduced by Emacs telling the
user to revert, whereas that operation cannot be performed (and is not
needed), so silencing the message should take care of the root of
the problem.


        Stefan

Re: reverting non-existent file

[Colin Baxter]

>>>>> Richard Copley <rcopley@gmail.com> writes:

    > On Thu, 14 May 2020 at 20:03, Eli Zaretskii <eliz@gnu.org> wrote:
    >> 
    >> > From: Colin Baxter <m43cap@yandex.com> > Cc:
    >> emacs-devel@gnu.org > Date: Thu, 14 May 2020 19:52:29 +0100
    >> >
    >> > > I get the error message even if I don't do steps 3 to 6.  And
    >> that > > is expected, as a non-existent file cannot be reverted.
    >> So what > > did you find surprising in this behavior?
    >> >
    >> > > (I'm guessing that your locale uses UTF-8 as its codeset, so
    >> the > > new file's buffer has utf-8 encoding from the get-go, and
    >> thus > > adding the local variable doesn't change the
    >> coding-system, and > > you are not asked to revert the buffer.
    >> Which is also expected.)
    >> >
    >> > > Confused.
    >> >
    >> > Not now, thanks. I think I was confused by the response
    >> "revert-buffer" > when I knew I'd yet to save it. And yes, my
    >> locale is utf-8.
    >> 
    >> Hmm... maybe we should not suggest reverting if the file doesn't
    >> exist?  Would that make this situation less confusing?

    > Why suggest reverting, whether or not the file exists? The buffer
    > change just made by add-file-local-variable-prop-line hasn't been
    > saved to any file yet. Reverting will undo the change, along with
    > any other unsaved changes.

    > It seems like a little mistake in the wording of the
    > suggestion. It might make more sense to advise the user to save
    > and then revert -- except that it wouldn't cause the file-local
    > variable to take effect anyway. Perhaps I'm misunderstanding what
    > the message means ("revisit"?).

    > I think it should say just say to run "normal-mode".

Why must a user who has run 'add-file-local-variable-prop-line' be prompted
with anything? What about just removing 'revert-buffer'?

Best wishes,

Colin.


-- 
Colin Baxter
URL: http://www.Colin-Baxter.com

Re: reverting non-existent file

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Thu, 14 May 2020 20:54:02 +0100
> Cc: Colin Baxter <m43cap@yandex.com>, Emacs Development <emacs-devel@gnu.org>
> 
> > Hmm... maybe we should not suggest reverting if the file doesn't
> > exist?  Would that make this situation less confusing?
> 
> Why suggest reverting, whether or not the file exists?
> The buffer change just made by add-file-local-variable-prop-line
> hasn't been saved to any file yet. Reverting will undo the change,
> along with any other unsaved changes.
> It seems like a little mistake in the wording of the suggestion. It
> might make more sense to advise the user to save and then revert --
> except that it wouldn't cause the file-local variable to take effect
> anyway. Perhaps I'm misunderstanding what the message means
> ("revisit"?).

You are probably right.

> I think it should say just say to run "normal-mode".

I don't think normal-mode will take everything into consideration; for
example, 'coding:' will not affect it at all.

Re: reverting non-existent file

[Eli Zaretskii]

> From: Colin Baxter <m43cap@yandex.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs Development <emacs-devel@gnu.org>
> Date: Fri, 15 May 2020 06:36:15 +0100
> 
> Why must a user who has run 'add-file-local-variable-prop-line' be prompted
> with anything? What about just removing 'revert-buffer'?

As things frequently are in Emacs lately, any such minor bug report is
usually the result of an attempt to fix another minor bug report.  In
this case, see bug#9820.

I think we should try to restrain ourselves in our vigor of fixing
every minor annoyance users report, because this kind of story happens
time and again.  Emacs is a very old and complex package, and trying
to fix these minor annoyances more often than not exhibits the
behavior known to control engineers as the "limit cycle": small
oscillations that don't converge.  IOW, fixing one small bug
introduces another small bug of the same (and sometimes higher)
annoyance level.

At some point, we should simply decide not to fix such small
annoyances, because they almost always have simple workarounds.