bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

When editing an externally changed file (under version control, no idea
whether that is related), I get the following questions (see below in
the input and output section).

It does not make sense at all for Emacs to ask

smob-convert.sh changed on disk; really edit the buffer? (y, n, r or C-h) y

as a reply to me typing C-x C-s since C-x C-s is _not_ a request to edit
the buffer.  It is a request to save the file _after_ editing the
buffer, and I already discussed the consequences of editing and saving
with Emacs previously.

Apart from being annoying by asking me the same question several times,
the question does not even make any sense the second time round.
I never know whether Emacs requires me to answer this quite nonsensical
question with "y" or "n" in order to write the changed buffer, and what
will happen in either of the two cases of answering this no longer
applicable question.

In GNU Emacs 24.4.50.1 (i686-pc-linux-gnu, GTK+ Version 3.10.8)
 of 2014-07-28 on lola
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

Configured using:
 `configure --without-toolkit-scroll-bars'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Shell-script

Minor modes in effect:
  sh-electric-here-document-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  TeX-PDF-mode: t
  desktop-save-mode: t
  minibuffer-electric-default-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-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
  line-number-mode: t

Recent input:
<down> C-x r t # SPC <return> y <backspace> <backspace> 
C-x C-s y e s <return> y

Recent messages:
smob-convert.sh changed on disk; really edit the buffer? (y, n, r or C-h) y
File on disk now will become a backup file if you save these changes.
Saving file /usr/local/tmp/lilypond/scripts/auxiliar/smob-convert.sh...
smob-convert.sh changed on disk; really edit the buffer? (y, n, r or C-h) y
File on disk now will become a backup file if you save these changes.
Wrote /usr/local/tmp/lilypond/scripts/auxiliar/smob-convert.sh

Load-path shadows:
None found.

Features:
(shadow emacsbug org-element org-rmail org-mhe org-irc org-info org-gnus
org-docview doc-view image-mode org-bibtex bibtex org-bbdb org-w3m org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs cal-menu calendar cal-loaddefs nroff-mode ediff-merg
ediff-wind ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff
skeleton diff texmathp reftex-parse deuglify talk ffap vc-bzr vc-sccs
vc-svn vc-cvs vc-rcs gnus-topic canlock sh-script smie executable rect
url-util url-parse url-vars calc-alg calc-ext calc-menu calc
calc-loaddefs calc-macs shr-color color sendmail nnir shell pcomplete
imenu view woman man gnus-fun debug smerge-mode vc vc-dispatcher shr
gnus-dup eieio-opt speedbar sb-image ezimage dframe find-func dabbrev
browse-url flyspell ispell git-commit-mode log-edit pcvs-util add-log
misearch multi-isearch help-mode git-rebase-mode thingatpt diff-mode
gnus-kill qp mule-util sort smiley gnus-cite flow-fill mm-archive
mail-extr gnus-async gnus-bcklg gnus-ml disp-table pop3 nndir nndraft
nnmh gnutls network-stream auth-source eieio eieio-core starttls nnml
nnfolder nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime
password-cache dig mailcap nntp gnus-cache gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo
parse-time gnus-spec gnus-int gnus-range gnus-win jka-compr autorevert
filenotify latexenc preview prv-emacs tex-bar toolbar-x noutline outline
font-latex byte-opt bytecomp byte-compile cconv latex easy-mmode edmacro
kmacro tex-style reftex-dcr reftex-auc reftex reftex-vars tex-buf
tex-info texinfo tex dbus xml crm python json message dired-x dired
format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
scheme lilypond-mode compile comint ansi-color ring vc-git cc-langs
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs info easymenu package advice desktop frameset
minibuf-eldef gnus gnus-ems nnheader gnus-util mail-utils mm-util
help-fns mail-prsvr wid-edit cl-loaddefs cl-lib cus-start cus-load
preview-latex tex-site auto-loads server time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 8 936702 107452)
 (symbols 24 62111 274)
 (miscs 20 1517 5186)
 (strings 16 173785 25925)
 (string-bytes 1 4819519)
 (vectors 8 55012)
 (vector-slots 4 1881617 31930)
 (floats 8 524 1344)
 (intervals 28 65318 2112)
 (buffers 512 230)
 (heap 1024 73167 13542))

-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Stefan Kangas]

David Kastrup <dak@gnu.org> writes:

> When editing an externally changed file (under version control, no idea
> whether that is related), I get the following questions (see below in
> the input and output section).
>
> It does not make sense at all for Emacs to ask
>
> smob-convert.sh changed on disk; really edit the buffer? (y, n, r or C-h) y
>
> as a reply to me typing C-x C-s since C-x C-s is _not_ a request to edit
> the buffer.  It is a request to save the file _after_ editing the
> buffer, and I already discussed the consequences of editing and saving
> with Emacs previously.
>
> Apart from being annoying by asking me the same question several times,
> the question does not even make any sense the second time round.
> I never know whether Emacs requires me to answer this quite nonsensical
> question with "y" or "n" in order to write the changed buffer, and what
> will happen in either of the two cases of answering this no longer
> applicable question.

Thanks for the report.  Unfortunately, it didn't get a reply at the
time.

Maybe something has changed since you reported this, because I'm
seeing the following messages:

    (New file)
    Saving file /tmp/foo.txt...
    Wrote /tmp/foo.txt
    foo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
    File on disk now will become a backup file if you save these changes.
    Saving file /tmp/foo.txt...
    foo.txt has changed since visited or saved.  Save anyway? (y or n) y

This makes a lot of sense to me.  The prompts are really about two
different things, which seems to now be fully clear.

Given the above, I don't see any need to do any further changes here.
I'll close this bug in a couple of weeks unless there is more to
discuss.

Best regards,
Stefan Kangas

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

Stefan Kangas <stefan@marxist.se> writes:

> David Kastrup <dak@gnu.org> writes:

>> It does not make sense at all for Emacs to ask
>>
>> smob-convert.sh changed on disk; really edit the buffer? (y, n, r or C-h) y
>>
>> as a reply to me typing C-x C-s since C-x C-s is _not_ a request to edit
>> the buffer.  It is a request to save the file _after_ editing the
>> buffer, and I already discussed the consequences of editing and saving
>> with Emacs previously.

> Maybe something has changed since you reported this, because I'm
> seeing the following messages:
>
>     (New file)
>     Saving file /tmp/foo.txt...
>     Wrote /tmp/foo.txt
>     foo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
>     File on disk now will become a backup file if you save these changes.
>     Saving file /tmp/foo.txt...
>     foo.txt has changed since visited or saved.  Save anyway? (y or n) y
>
> This makes a lot of sense to me.  The prompts are really about two
> different things, which seems to now be fully clear.
>
> Given the above, I don't see any need to do any further changes here.
> I'll close this bug in a couple of weeks unless there is more to
> discuss.

I would agree with you that the second question is now more clear, but I
think the first question shouldn't be asked in this case, since there
was no edit attempt (as described in the original report).

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

Noam Postavsky <npostavs@gmail.com> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>
>>> It does not make sense at all for Emacs to ask
>>>
>>> smob-convert.sh changed on disk; really edit the buffer? (y, n, r or C-h) y
>>>
>>> as a reply to me typing C-x C-s since C-x C-s is _not_ a request to edit
>>> the buffer.  It is a request to save the file _after_ editing the
>>> buffer, and I already discussed the consequences of editing and saving
>>> with Emacs previously.
>
>> Maybe something has changed since you reported this, because I'm
>> seeing the following messages:
>>
>>     (New file)
>>     Saving file /tmp/foo.txt...
>>     Wrote /tmp/foo.txt
>>     foo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
>>     File on disk now will become a backup file if you save these changes.
>>     Saving file /tmp/foo.txt...
>>     foo.txt has changed since visited or saved.  Save anyway? (y or n) y
>>
>> This makes a lot of sense to me.  The prompts are really about two
>> different things, which seems to now be fully clear.
>>
>> Given the above, I don't see any need to do any further changes here.
>> I'll close this bug in a couple of weeks unless there is more to
>> discuss.
>
> I would agree with you that the second question is now more clear, but I
> think the first question shouldn't be asked in this case, since there
> was no edit attempt (as described in the original report).

And it is still the same in that respect.

[Original change behind Emacs' back, the trying to edit buffer]
smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
File on disk now will become a backup file if you save these changes.
[So far so good.  Now pressing C-x C-s]
Saving file /usr/local/tmp/lilypond/lily/smobs.cc...
[That message is ok]
smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
[That question is ludicrous.  I am saving the file, not editing it.]
File on disk now will become a backup file if you save these changes.
[What does that even mean?  I _am_ saving this file right now.]
Wrote /usr/local/tmp/lilypond/lily/smobs.cc

-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 01 Mar 2020 17:38:24 +0100
> Cc: Stefan Kangas <stefan@marxist.se>, 18336@debbugs.gnu.org
> 
> And it is still the same in that respect.
> 
> [Original change behind Emacs' back, the trying to edit buffer]
> smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
> File on disk now will become a backup file if you save these changes.
> [So far so good.  Now pressing C-x C-s]
> Saving file /usr/local/tmp/lilypond/lily/smobs.cc...
> [That message is ok]
> smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
> [That question is ludicrous.  I am saving the file, not editing it.]
> File on disk now will become a backup file if you save these changes.
> [What does that even mean?  I _am_ saving this file right now.]
> Wrote /usr/local/tmp/lilypond/lily/smobs.cc

Please try the latest pretest of Emacs 27, things are more reasonable
now.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sun, 01 Mar 2020 17:38:24 +0100
>> Cc: Stefan Kangas <stefan@marxist.se>, 18336@debbugs.gnu.org
>> 
>> And it is still the same in that respect.
>> 
>> [Original change behind Emacs' back, the trying to edit buffer]
>> smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
>> File on disk now will become a backup file if you save these changes.
>> [So far so good.  Now pressing C-x C-s]
>> Saving file /usr/local/tmp/lilypond/lily/smobs.cc...
>> [That message is ok]
>> smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
>> [That question is ludicrous.  I am saving the file, not editing it.]
>> File on disk now will become a backup file if you save these changes.
>> [What does that even mean?  I _am_ saving this file right now.]
>> Wrote /usr/local/tmp/lilypond/lily/smobs.cc
>
> Please try the latest pretest of Emacs 27, things are more reasonable
> now.

Uh, I compiled today from master.

GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.12,
cairo version 1.16.0) of 2020-03-01

Any changes since then?

-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: npostavs@gmail.com,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Sun, 01 Mar 2020 18:45:33 +0100
> 
> > Please try the latest pretest of Emacs 27, things are more reasonable
> > now.
> 
> Uh, I compiled today from master.

Then you see something very different from what I see on the emacs-27
branch, which is very strange.

When I modify the file in Emacs, after it was modified by some other
program, I see this:

  FILE changed on disk; really edit the buffer? (y, n, r or C-h)

Pressing 'y' shows this:

  File on disk now will become a backup file if you save these changes.

Typing C-x C-s then shows this:

  FILE has changed since visited or saved.  Save anyway? (yes or no)

Typing "yes" then says

  Wrote FILE

That sounds reasonable to me.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: npostavs@gmail.com,  stefan@marxist.se,  18336@debbugs.gnu.org
>> Date: Sun, 01 Mar 2020 18:45:33 +0100
>> 
>> > Please try the latest pretest of Emacs 27, things are more reasonable
>> > now.
>> 
>> Uh, I compiled today from master.
>
> Then you see something very different from what I see on the emacs-27
> branch, which is very strange.
>
> When I modify the file in Emacs, after it was modified by some other
> program, I see this:
>
>   FILE changed on disk; really edit the buffer? (y, n, r or C-h)
>
> Pressing 'y' shows this:
>
>   File on disk now will become a backup file if you save these changes.
>
> Typing C-x C-s then shows this:
>
>   FILE has changed since visited or saved.  Save anyway? (yes or no)
>
> Typing "yes" then says
>
>   Wrote FILE
>
> That sounds reasonable to me.

Well, I said that version control may be involved but this is the same
using emacs -Q and on a file not under version control.  Here is the
current report-emacs-bug blurb for identification:

In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.16.0)
 of 2020-03-01 built on lola
Repository revision: 279bf23695aff0f680fc846d285c5dc2b9596e76
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Ubuntu 19.10

This is actually

commit e98ee8ddac24f7db3acfbbaadde5116d138bf698 (origin/master, origin/HEAD)
Author: Stefan Kangas <stefankangas@gmail.com>
Date:   Sun Mar 1 01:19:23 2020 +0100

    Make 'load-dangerous-libraries' obsolete (Bug#37819)
    
    When 'load-dangerous-libraries' was t, Emacs allowed loading .elc
    files compiled by XEmacs.  This patch removes the support for that use
    case, and declares the variable obsolete.
    
    * lisp/subr.el (load-dangerous-libraries): Declare obsolete.
    * src/lread.c (Fload): Ignore its value, and thereby refuse to load
    files byte compiled by XEmacs.
    (syms_of_lread): Update doc string of 'bytecomp-version-regexp' to not
    refer to it.
    * doc/emacs/building.texi (Lisp Libraries): Remove its documentation.

with two unrelated commits of mine on top.


-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: npostavs@gmail.com,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Sun, 01 Mar 2020 19:22:32 +0100
> 
> >> Uh, I compiled today from master.
> >
> > Then you see something very different from what I see on the emacs-27
> > branch, which is very strange.
> >
> 
> Well, I said that version control may be involved but this is the same
> using emacs -Q and on a file not under version control.  Here is the
> current report-emacs-bug blurb for identification:
> 
> In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.16.0)
>  of 2020-03-01 built on lola
> Repository revision: 279bf23695aff0f680fc846d285c5dc2b9596e76
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
> System Description: Ubuntu 19.10

I tried the current master, and I see the same as on the emacs-27
branch, with a file not under any VCS.

I have no idea how you see something so different.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: npostavs@gmail.com,  stefan@marxist.se,  18336@debbugs.gnu.org
>> Date: Sun, 01 Mar 2020 19:22:32 +0100
>> 
>> >> Uh, I compiled today from master.
>> >
>> > Then you see something very different from what I see on the emacs-27
>> > branch, which is very strange.
>> >
>> 
>> Well, I said that version control may be involved but this is the same
>> using emacs -Q and on a file not under version control.  Here is the
>> current report-emacs-bug blurb for identification:
>> 
>> In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.16.0)
>>  of 2020-03-01 built on lola
>> Repository revision: 279bf23695aff0f680fc846d285c5dc2b9596e76
>> Repository branch: master
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
>> System Description: Ubuntu 19.10
>
> I tried the current master, and I see the same as on the emacs-27
> branch, with a file not under any VCS.
>
> I have no idea how you see something so different.

I've tried this now too, and I see the same as Eli, even on Emacs 26.3.
By the way, the "Save anyway?" question doesn't get logged to
*Messages*.

In GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2019-09-07 built on minid
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item
(Shell command succeeded with no output)
A.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
File on disk now will become a backup file if you save these changes.
Saving file /home/npostavs/tmp/A.txt...
Wrote /home/npostavs/tmp/A.txt

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: David Kastrup <dak@gnu.org>,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Sun, 01 Mar 2020 23:14:12 -0500
> 
> > I tried the current master, and I see the same as on the emacs-27
> > branch, with a file not under any VCS.
> >
> > I have no idea how you see something so different.
> 
> I've tried this now too, and I see the same as Eli, even on Emacs 26.3.

The only idea I had meanwhile is that maybe David has some local code
which redefines the functions involved in this use case.

> By the way, the "Save anyway?" question doesn't get logged to
> *Messages*.

In Emacs 27 as well?  Probably because we use there some API that
doesn't log its text or something.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@gmail.com>
>> Cc: David Kastrup <dak@gnu.org>,  stefan@marxist.se,  18336@debbugs.gnu.org
>> Date: Sun, 01 Mar 2020 23:14:12 -0500
>> 
>> > I tried the current master, and I see the same as on the emacs-27
>> > branch, with a file not under any VCS.
>> >
>> > I have no idea how you see something so different.
>> 
>> I've tried this now too, and I see the same as Eli, even on Emacs 26.3.
>
> The only idea I had meanwhile is that maybe David has some local code
> which redefines the functions involved in this use case.

Nope.  The two commits of my own do not touch anything even remotely in
the vicinity.

>> By the way, the "Save anyway?" question doesn't get logged to
>> *Messages*.
>
> In Emacs 27 as well?  Probably because we use there some API that
> doesn't log its text or something.

-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Noam Postavsky <npostavs@gmail.com>,  stefan@marxist.se,
>   18336@debbugs.gnu.org
> Date: Mon, 02 Mar 2020 10:42:53 +0100
> 
> > The only idea I had meanwhile is that maybe David has some local code
> > which redefines the functions involved in this use case.
> 
> Nope.  The two commits of my own do not touch anything even remotely in
> the vicinity.

I meant something you load at startup (you didn't say it was in "emacs -Q").

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Noam Postavsky <npostavs@gmail.com>,  stefan@marxist.se,
>>   18336@debbugs.gnu.org
>> Date: Mon, 02 Mar 2020 10:42:53 +0100
>> 
>> > The only idea I had meanwhile is that maybe David has some local code
>> > which redefines the functions involved in this use case.
>> 
>> Nope.  The two commits of my own do not touch anything even remotely in
>> the vicinity.
>
> I meant something you load at startup (you didn't say it was in "emacs -Q").

I did.  To quote:

    "Well, I said that version control may be involved but this is the
    same using emacs -Q and on a file not under version control.  Here
    is the current report-emacs-bug blurb for identification:"

-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 02 Mar 2020 12:41:04 +0100
> 
> > I meant something you load at startup (you didn't say it was in "emacs -Q").
> 
> I did.  To quote:
> 
>     "Well, I said that version control may be involved but this is the
>     same using emacs -Q and on a file not under version control.  Here
>     is the current report-emacs-bug blurb for identification:"

Right, so that theory eats dust.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Stefan Kangas]

Noam Postavsky <npostavs@gmail.com> writes:

>> I tried the current master, and I see the same as on the emacs-27
>> branch, with a file not under any VCS.
>>
>> I have no idea how you see something so different.
>
> I've tried this now too, and I see the same as Eli, even on Emacs 26.3.
> By the way, the "Save anyway?" question doesn't get logged to
> *Messages*.

OK, this is weird.  I think I'm now seeing the same as David on
current master.  Note that this is different from what I saw earlier,
when I saw exactly what Eli describes.

0. emacs -Q
1. C-x C-f /tmp/moo.txt RET
2. abc C-x C-s
3. From terminal: echo "foo" >> /tmp/moo.txt
4. type something, get these messages:
moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
5. Answer 'y', save the file, get:
- do you really want to save? [not logged]
- moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y

I tried this several times and got the same result.

In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.16.0)
 of 2020-03-01 built on joffe
Repository revision: d97688851bf5069430483c543032ef7cd0c9b5ef
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12007000
System Description: Debian GNU/Linux bullseye/sid

Recent messages:
(New file)
Saving file /tmp/moo.txt...
Wrote /tmp/moo.txt
moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
File on disk now will become a backup file if you save these changes.
Saving file /tmp/moo.txt...
moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
File on disk now will become a backup file if you save these changes.
Wrote /tmp/moo.txt

---

OK, I tried saving a file in my home directory instead, and now I
didn't see the second "changed on disk" message.  (That is, I see the
same thing that Eli described.)

Testing it a bit more, I was able to trigger the second message again,
but only once.

---

Investigating even further (on current master), I think I now have
that:

a. In my home directory, I consistently see the message.  (David's case)
b. In "/tmp" I consistently do *not* see the message.  (Eli's case)

So I guess the second message is triggered only under specific
circumstances?

(But even the above conclusion is confusing, since I also saw the
message (but only once) even when I saved in "/home".  And I don't see
why saving in a different directory should matter...)

Does anyone have any idea what could be going on here?  Have we found
ourselves a heisenbug?  Or have I thoroughly managed to confuse
myself?

Best regards,
Stefan Kangas

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Cc: Eli Zaretskii <eliz@gnu.org>,  David Kastrup <dak@gnu.org>,  18336@debbugs.gnu.org
> Date: Mon, 02 Mar 2020 09:39:14 +0100
> 
> 0. emacs -Q
> 1. C-x C-f /tmp/moo.txt RET
> 2. abc C-x C-s
> 3. From terminal: echo "foo" >> /tmp/moo.txt
> 4. type something, get these messages:
> moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
> 5. Answer 'y', save the file, get:
> - do you really want to save? [not logged]
> - moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y

First, this is not what David reported, see his description up-thread.

And second: are you saying you get the question

  do you really want to save? [not logged]

right after "C-x C-s", then the question

  moo.txt changed on disk; really edit the buffer? (y, n, r or C-h)

right after Emacs says "Wrote moo.txt"?  That is, you didn't do
anything after saving to get the last prompt?

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefan@marxist.se>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  David Kastrup <dak@gnu.org>,  18336@debbugs.gnu.org
>> Date: Mon, 02 Mar 2020 09:39:14 +0100
>> 
>> 0. emacs -Q
>> 1. C-x C-f /tmp/moo.txt RET
>> 2. abc C-x C-s
>> 3. From terminal: echo "foo" >> /tmp/moo.txt
>> 4. type something, get these messages:
>> moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
>> 5. Answer 'y', save the file, get:
>> - do you really want to save? [not logged]
>> - moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
>
> First, this is not what David reported, see his description up-thread.

Isn't it?  He described:

    [Original change behind Emacs' back, the trying to edit buffer]
    smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
    File on disk now will become a backup file if you save these changes.
    [So far so good.  Now pressing C-x C-s]
    Saving file /usr/local/tmp/lilypond/lily/smobs.cc...
    [That message is ok]
    smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
    [That question is ludicrous.  I am saving the file, not editing it.]

I don't think I see what the difference is from what I reported.

(Or maybe my description wasn't clear?)

> And second: are you saying you get the question
>
>   do you really want to save? [not logged]
>
> right after "C-x C-s", then the question
>
>   moo.txt changed on disk; really edit the buffer? (y, n, r or C-h)
>
> right after Emacs says "Wrote moo.txt"?  That is, you didn't do
> anything after saving to get the last prompt?

Yes.

Best regards,
Stefan Kangas

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Cc: dak@gnu.org,  npostavs@gmail.com,  18336@debbugs.gnu.org
> Date: Mon, 02 Mar 2020 10:04:06 +0100
> 
> >> 0. emacs -Q
> >> 1. C-x C-f /tmp/moo.txt RET
> >> 2. abc C-x C-s
> >> 3. From terminal: echo "foo" >> /tmp/moo.txt
> >> 4. type something, get these messages:
> >> moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
> >> 5. Answer 'y', save the file, get:
> >> - do you really want to save? [not logged]
> >> - moo.txt changed on disk; really edit the buffer? (y, n, r or C-h) y
> >
> > First, this is not what David reported, see his description up-thread.
> 
> Isn't it?  He described:
> 
>     [Original change behind Emacs' back, the trying to edit buffer]
>     smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
>     File on disk now will become a backup file if you save these changes.
>     [So far so good.  Now pressing C-x C-s]
>     Saving file /usr/local/tmp/lilypond/lily/smobs.cc...
>     [That message is ok]
>     smobs.cc changed on disk; really edit the buffer? (y, n, r or C-h) y
>     [That question is ludicrous.  I am saving the file, not editing it.]
> 
> I don't think I see what the difference is from what I reported.

This part of your report is missing from David's:

 - do you really want to save? [not logged]

And this part doesn't appear in your report:

   Saving file /usr/local/tmp/lilypond/lily/smobs.cc...

> > And second: are you saying you get the question
> >
> >   do you really want to save? [not logged]
> >
> > right after "C-x C-s", then the question
> >
> >   moo.txt changed on disk; really edit the buffer? (y, n, r or C-h)
> >
> > right after Emacs says "Wrote moo.txt"?  That is, you didn't do
> > anything after saving to get the last prompt?
> 
> Yes.

Strange.  Some debugging is required, I'd say.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

Stefan Kangas <stefan@marxist.se> writes:

> OK, I tried saving a file in my home directory instead, and now I
> didn't see the second "changed on disk" message.  (That is, I see the
> same thing that Eli described.)
>
> Testing it a bit more, I was able to trigger the second message again,
> but only once.
>
> ---
>
> Investigating even further (on current master), I think I now have
> that:
>
> a. In my home directory, I consistently see the message.  (David's case)
> b. In "/tmp" I consistently do *not* see the message.  (Eli's case)
>
> So I guess the second message is triggered only under specific
> circumstances?
>
> (But even the above conclusion is confusing, since I also saw the
> message (but only once) even when I saved in "/home".  And I don't see
> why saving in a different directory should matter...)

Mount options?  Time stamp granularity?

The file system I encountered this initially on is

/dev/sda7 on /usr/local type ext4 (rw,noatime,discard,data=ordered)

and my /tmp file system where I also saw this is

/dev/sda5 on / type ext4 (rw,noatime,discard)

I don't know whether Emacs uses /run/lock , if it does that would be

tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)

The noatime option is because this is an SSD where I want to minimize
write wear.


-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

David Kastrup <dak@gnu.org> writes:

> Mount options?  Time stamp granularity?
>
> The file system I encountered this initially on is
>
> /dev/sda7 on /usr/local type ext4 (rw,noatime,discard,data=ordered)
>
> and my /tmp file system where I also saw this is
>
> /dev/sda5 on / type ext4 (rw,noatime,discard)

Aha, this seems to be the key.  I ran my initial experiment in ~/tmp,
which is mounted with relatime

    /dev/sda9 on /home type ext4 (rw,relatime,data=ordered)

When I do the same on /tmp, which is mounted noatime I see the extra
"<file> changed on disk; really edit the buffer?" question on C-x C-s.

    /dev/sda8 on /tmp type ext4 (rw,noatime,data=ordered)

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Stefan Kangas <stefan@marxist.se>,  Eli Zaretskii <eliz@gnu.org>,  18336@debbugs.gnu.org
> Date: Mon, 02 Mar 2020 07:20:04 -0500
> 
> > and my /tmp file system where I also saw this is
> >
> > /dev/sda5 on / type ext4 (rw,noatime,discard)
> 
> Aha, this seems to be the key.  I ran my initial experiment in ~/tmp,
> which is mounted with relatime
> 
>     /dev/sda9 on /home type ext4 (rw,relatime,data=ordered)
> 
> When I do the same on /tmp, which is mounted noatime I see the extra
> "<file> changed on disk; really edit the buffer?" question on C-x C-s.
> 
>     /dev/sda8 on /tmp type ext4 (rw,noatime,data=ordered)

This seems to point to the call to lock_file we make in write_region
(which is called to save the buffer).  lock_file calls
verify-visited-file-modtime, which might be affected by the noatime
option.  But I don't understand how noatime could affect
verify-visited-file-modtime since the latter looks at mtime, not
atime.

Or maybe the time is not the issue here, and the problem is with the
check of the file's size that verify-visited-file-modtime performs?

Can someone who sees this step with GDB through lock_file and its
callees, and see what goes wrong there and why?

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

>> > and my /tmp file system where I also saw this is

>> I ran my initial experiment in ~/tmp,[...]
>> When I do the same on /tmp, which is mounted noatime I see the extra
>> "<file> changed on disk; really edit the buffer?" question on C-x C-s.

> lock_file calls verify-visited-file-modtime, which might be affected
> by the noatime option.  But I don't understand how noatime could
> affect verify-visited-file-modtime since the latter looks at mtime,
> not atime.

> Can someone who sees this step with GDB through lock_file and its
> callees, and see what goes wrong there and why?

Ah, looks like the noatime thing is just a coincidence.  What happens in
the ~/tmp case is that when lock_file is called from write_region, the
file doesn't exist, so the extra "changed on disk" question doesn't get
asked.  The reason the file doesn't exist, is because it was moved to
the backup name, in backup-buffer.  Files under /tmp/ are not backed up
by default, so in that case the file still exists and there is an extra
query.

    lock_file (Lisp_Object fn)
    {
      [...]
        if (!NILP (subject_buf)
        && NILP (Fverify_visited_file_modtime (subject_buf))
        && !NILP (Ffile_exists_p (fn)))
          call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);

    (defun backup-buffer ()
      [...]
                  (rename-file real-file-name backupname t)

If I do (setq backup-enable-predicate #'ignore), i.e., disable backup,
then I get the extra query for ~/tmp/foo as well.  The OP mentions
version control, that also affects this because of the
vc-make-backup-files option (defaulting to nil, i.e., backup doesn't
happen for files under vc).

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[David Kastrup]

Noam Postavsky <npostavs@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > and my /tmp file system where I also saw this is
>
>>> I ran my initial experiment in ~/tmp,[...]
>>> When I do the same on /tmp, which is mounted noatime I see the extra
>>> "<file> changed on disk; really edit the buffer?" question on C-x C-s.
>
>> lock_file calls verify-visited-file-modtime, which might be affected
>> by the noatime option.  But I don't understand how noatime could
>> affect verify-visited-file-modtime since the latter looks at mtime,
>> not atime.
>
>> Can someone who sees this step with GDB through lock_file and its
>> callees, and see what goes wrong there and why?
>
> Ah, looks like the noatime thing is just a coincidence.  What happens in
> the ~/tmp case is that when lock_file is called from write_region, the
> file doesn't exist, so the extra "changed on disk" question doesn't get
> asked.  The reason the file doesn't exist, is because it was moved to
> the backup name, in backup-buffer.  Files under /tmp/ are not backed up
> by default, so in that case the file still exists and there is an extra
> query.

Sorry for the red herring.  It was the thing that occured to me first.

-- 
David Kastrup

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

David Kastrup <dak@gnu.org> writes:

> Sorry for the red herring.  It was the thing that occured to me first.

No need to apologize, it was a reasonable guess.  And anyway it led to
the right answer in the end.

Eli Zaretskii <eliz@gnu.org> writes:
>> What happens in the ~/tmp case is that when lock_file is called from
>> write_region, the file doesn't exist, so the extra "changed on disk"
>> question doesn't get asked.

> Thanks.  Any suggestions for how to fix this?  A new argument to
> lock_file, perhaps?  Or maybe some additional check in
> userlock--ask-user-about-supersession-threat to recognize the special
> situation where we are saving a file?

I'm not sure.  Why exactly are we calling lock_file from write_region?
The comment for lock_file says:

   Do not (normally) call this for a buffer already modified,
   as either the file is already locked, or the user has already
   decided to go ahead without locking.

It seems we are doing exactly this, so I guess that makes
save-buffer/write-region an "abnormal" situation?

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Thu, 05 Mar 2020 12:54:41 -0500
> 
> > Thanks.  Any suggestions for how to fix this?  A new argument to
> > lock_file, perhaps?  Or maybe some additional check in
> > userlock--ask-user-about-supersession-threat to recognize the special
> > situation where we are saving a file?
> 
> I'm not sure.  Why exactly are we calling lock_file from write_region?

Because write-region can be called from an unmodified buffer, I
suppose, and from a buffer whose buffer-file-name is not the same as
the file being written to.

>    Do not (normally) call this for a buffer already modified,
>    as either the file is already locked, or the user has already
>    decided to go ahead without locking.
> 
> It seems we are doing exactly this, so I guess that makes
> save-buffer/write-region an "abnormal" situation?

Evidently, when we disabled backups in /tmp, we missed the fact that
lock_file called from write-region will be affected.  When backups are
not disabled, this works correctly.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

tags 18336 + patch
quit

Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> I'm not sure.  Why exactly are we calling lock_file from write_region?
>
> Because write-region can be called from an unmodified buffer, I
> suppose, and from a buffer whose buffer-file-name is not the same as
> the file being written to.

So maybe we could just check those conditions?  Here's a patch,
tentatively suggested for master.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1371 bytes --]

From ae6a82e1b10ce850731fbc7135611108cd2bd147 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Sat, 21 Mar 2020 21:00:08 -0400
Subject: [PATCH] Avoid extra "changed on disk" prompt in save-buffer
 (Bug#18336)

* src/fileio.c (write_region): Only call lock_file is the buffer is
unmodified or writing to some file other than the buffer's file.  As
mentioned in lock_file's commentary, calling it for modified buffers
is redundant (this reasoning only applies when writing to the buffer's
file).
---
 src/fileio.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/fileio.c b/src/fileio.c
index 482f88627a..323faa2e77 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -5123,7 +5123,12 @@ write_region (Lisp_Object start, Lisp_Object end, Lisp_Object filename,
     = choose_write_coding_system (start, end, filename,
                                  append, visit, lockname, &coding);
 
-  if (open_and_close_file && !auto_saving)
+  if (open_and_close_file && !auto_saving &&
+      /* Only call lock_file on unmodifed buffer (see lock_file
+         commentary).  */
+      (NILP (Fbuffer_modified_p (Qnil)) ||
+       /* Or if we're not writing to the buffer's file.  */
+       NILP (Fstring_equal (visit_file, BVAR (current_buffer, filename)))))
     {
       lock_file (lockname);
       file_locked = 1;
-- 
2.11.0


[-- Attachment #3: Type: text/plain, Size: 443 bytes --]


> Evidently, when we disabled backups in /tmp, we missed the fact that
> lock_file called from write-region will be affected.  When backups are
> not disabled, this works correctly.

To me, the fact that it works with backups enabled seems like an
accident.  The connection between locking and backups isn't very
obvious, and I don't see any commentary about it (which I would expect
for such a subtle interaction if it was done on purpose).

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: dak@gnu.org,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Sat, 21 Mar 2020 21:13:59 -0400
> 
> >> Why exactly are we calling lock_file from write_region?
> >
> > Because write-region can be called from an unmodified buffer, I
> > suppose, and from a buffer whose buffer-file-name is not the same as
> > the file being written to.
> 
> So maybe we could just check those conditions?  Here's a patch,
> tentatively suggested for master.

Isn't it better to check whether the file is already locked?  That
way, we don't need any (error-prone) heuristics for when it's okay to
ask the question and when it isn't.

> > Evidently, when we disabled backups in /tmp, we missed the fact that
> > lock_file called from write-region will be affected.  When backups are
> > not disabled, this works correctly.
> 
> To me, the fact that it works with backups enabled seems like an
> accident.

It might be an accident, but it's the reason why the default paradigm
works.

Thanks.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@gmail.com>
>> Cc: dak@gnu.org,  stefan@marxist.se,  18336@debbugs.gnu.org
>> Date: Sat, 21 Mar 2020 21:13:59 -0400
>> 
>> >> Why exactly are we calling lock_file from write_region?
>> >
>> > Because write-region can be called from an unmodified buffer, I
>> > suppose, and from a buffer whose buffer-file-name is not the same as
>> > the file being written to.
>> 
>> So maybe we could just check those conditions?  Here's a patch,
>> tentatively suggested for master.
>
> Isn't it better to check whether the file is already locked?  That
> way, we don't need any (error-prone) heuristics for when it's okay to
> ask the question and when it isn't.

If I understand the code correctly, lock_file() already checks this (the
'&& !NILP (Ffile_exists_p (fn))' part), but takes the wrong action in
that case.  So I'm not sure what we should do differently.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: dak@gnu.org,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Sun, 22 Mar 2020 11:45:24 -0400
> 
> > Isn't it better to check whether the file is already locked?  That
> > way, we don't need any (error-prone) heuristics for when it's okay to
> > ask the question and when it isn't.
> 
> If I understand the code correctly, lock_file() already checks this (the
> '&& !NILP (Ffile_exists_p (fn))' part), but takes the wrong action in
> that case.  So I'm not sure what we should do differently.

AFAIU, 'fn' in lock_file is the file we want to lock, not the file we
create to indicate the lock.  Am I missing something?

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Isn't it better to check whether the file is already locked?  That
>> > way, we don't need any (error-prone) heuristics for when it's okay to
>> > ask the question and when it isn't.
>> 
>> If I understand the code correctly, lock_file() already checks this (the
>> '&& !NILP (Ffile_exists_p (fn))' part), but takes the wrong action in
>> that case.  So I'm not sure what we should do differently.
>
> AFAIU, 'fn' in lock_file is the file we want to lock, not the file we
> create to indicate the lock.  Am I missing something?

Oh, you're right, I was confused.  The patch below seems to work.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1666 bytes --]

From 036eb17510ab63ce62aa858c9ff825b2ec5b5c7a Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Sat, 21 Mar 2020 21:00:08 -0400
Subject: [PATCH] Avoid extra "changed on disk" prompt in save-buffer
 (Bug#18336)

* src/filelock.c (lock_file): Don't query the user if the current
session already owns the lock.
---
 src/filelock.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/filelock.c b/src/filelock.c
index b28f16e9b5..5e14731ee8 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -679,6 +679,9 @@ lock_file (Lisp_Object fn)
   dostounix_filename (SSDATA (fn));
 #endif
   encoded_fn = ENCODE_FILE (fn);
+  if (create_lockfiles)
+    /* Create the name of the lock-file for file fn */
+    MAKE_LOCK_NAME (lfname, encoded_fn);
 
   /* See if this file is visited and has changed on disk since it was
      visited.  */
@@ -689,7 +692,8 @@ lock_file (Lisp_Object fn)
 
     if (!NILP (subject_buf)
 	&& NILP (Fverify_visited_file_modtime (subject_buf))
-	&& !NILP (Ffile_exists_p (fn)))
+        && !NILP (Ffile_exists_p (fn))
+        && (!create_lockfiles || current_lock_owner (NULL, lfname) != -2))
       call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
 
   }
@@ -697,10 +701,6 @@ lock_file (Lisp_Object fn)
   /* Don't do locking if the user has opted out.  */
   if (create_lockfiles)
     {
-
-      /* Create the name of the lock-file for file fn */
-      MAKE_LOCK_NAME (lfname, encoded_fn);
-
       /* Try to lock the lock.  FIXME: This ignores errors when
 	 lock_if_free returns a positive errno value.  */
       if (lock_if_free (&lock_info, lfname) < 0)
-- 
2.11.0

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: dak@gnu.org,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Sun, 22 Mar 2020 15:46:33 -0400
> 
> > AFAIU, 'fn' in lock_file is the file we want to lock, not the file we
> > create to indicate the lock.  Am I missing something?
> 
> Oh, you're right, I was confused.  The patch below seems to work.

LGTM, thanks.

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Noam Postavsky]

tags 18336 fixed
close 18336 28.1
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@gmail.com>
>> Cc: dak@gnu.org,  stefan@marxist.se,  18336@debbugs.gnu.org
>> Date: Sun, 22 Mar 2020 15:46:33 -0400
>> 
>> > AFAIU, 'fn' in lock_file is the file we want to lock, not the file we
>> > create to indicate the lock.  Am I missing something?
>> 
>> Oh, you're right, I was confused.  The patch below seems to work.
>
> LGTM, thanks.

Pushed to master.

[1: 8f694831c0]: 2020-03-22 23:06:05 -0400
  Avoid extra "changed on disk" prompt in save-buffer (Bug#18336)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8f694831c04b1fb9db81be72afdc1a1101d619c4

bug#18336: 24.4.50; When editing externally changed file, Emacs asks too many questions

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: dak@gnu.org,  stefan@marxist.se,  18336@debbugs.gnu.org
> Date: Thu, 05 Mar 2020 09:13:32 -0500
> 
> Ah, looks like the noatime thing is just a coincidence.  What happens in
> the ~/tmp case is that when lock_file is called from write_region, the
> file doesn't exist, so the extra "changed on disk" question doesn't get
> asked.  The reason the file doesn't exist, is because it was moved to
> the backup name, in backup-buffer.  Files under /tmp/ are not backed up
> by default, so in that case the file still exists and there is an extra
> query.
> 
>     lock_file (Lisp_Object fn)
>     {
>       [...]
>         if (!NILP (subject_buf)
>         && NILP (Fverify_visited_file_modtime (subject_buf))
>         && !NILP (Ffile_exists_p (fn)))
>           call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
> 
>     (defun backup-buffer ()
>       [...]
>                   (rename-file real-file-name backupname t)

Thanks.  Any suggestions for how to fix this?  A new argument to
lock_file, perhaps?  Or maybe some additional check in
userlock--ask-user-about-supersession-threat to recognize the special
situation where we are saving a file?