Re: write-region bug ?

[Jean-Christophe Helary]

Ok, here is my (hopefully final) report on what I think is extremely weird and 
totally unfriendly. 

Noam just hinted at a fundamental reason for why that "visiting" thing is 
confusing, just copying it here for reference:

> I think the problem is that "visiting" can mean both reading the file
> contents into the buffer, and setting up the association for future
> buffer saves. For write-region, visiting means only setting up the
> association, not reading the file contents. Normally, visiting is done
> by find-file, which both reads the file in, and sets up the
> association, so the ambiguity doesn't matter in that case.


I try to describe all the manipulations I do with the most detail I can. It can 
be a bit tedious, apologies for that.

In the end, it is not a question of what the write-region command does, but 
about whether the user is or not made aware of what is happening, what the 
results of the commands are and how is the user informed of such results.



In emacs -Q

1) I visit a file A.txt, copy the following line in its buffer and save it:

(write-region "stuff" nil "B.txt" nil t nil t)

• the frame "title" is A.txt
• the mode line indicates U:--- A.txt
• *Buffer List* gives me Buffer: A.txt, File: ~/A.txt
• A.txt exists in my file system, I can see it in the external file manager 
(Finder, I'm on macos)
• A.txt contains (write-region "stuff" nil "B.txt" nil t nil t), I can see that 
from Finder

A quick look at the manual eventually shows that the mode line and the frame 
title only display the buffer name, which will happen to be extremely confusing 
as I advance in my tests.

(That's the cause of all the confusion I've experienced in the past weeks and I 
wish there would be a way to remedy this because it was a huge waste of time.)


2) I evaluate the expression:

• B.txt is created (Finder)
• B.txt contains "stuff" (Finder)
• the frame "title" is still A.txt
• the mode line still indicates U:--- A.txt
• but *Buffer List* now gives me Buffer: A.txt, File: ~/B.txt

That *Buffer List* will be the only place during the whole process that could 
inform me about the fact that I'm now pointing at a file different from the 
original. So emacs is seemingly now using the buffer "A.txt" with the contents 
`(write-region "stuff" nil "B.txt" nil t nil t)' to point at the file ~/B.txt 
that has the content "stuff", but the frame information is not giving me any 
clue about the fact that the target (associated ? visited ?) file has changed.

At this point, *Messages* contains:

Saving file /Users/suzume/A.txt...
Wrote /Users/suzume/A.txt
Wrote /Users/suzume/B.txt

Here, no visual indication that B.txt is from now on playing an important role.


3) I add a line under the expression, the content is now

(write-region "stuff" nil "B.txt" nil t nil t)
;; more stuff


4) I try to save the modification, not aware, from the frame info or from 
anywhere else, that I'm targeting ~/B.txt:

→ [Echo] A.txt changed on disk; really edit the buffer? (y, n, r or C-h)
→ [me] n
→ [Echo] File changed on disk: /Users/suzume/A.txt

First, it is weird that I am asked *now* whether I want to "really edit" the 
buffer, when the edit has taken place a while ago and I am now *saving* the 
buffer.

This is confusing.

And what is that A.txt that has changed "on disk" ? By which manipulation of 
mine has the A.txt file changed directly on disk ?

The last message is weird, because in Finder A.txt has not changed and is still 
containing that one-liner and as far as I can tell, B.txt has still not 
changed. So, from an external view point *nothing* has changed and the frame 
info kind of confirms that.

Contents of *Messages*

Auto-saving...
Saving file /Users/suzume/B.txt...
A.txt changed on disk; really edit the buffer? (y, n, r or C-h) n
ask-user-about-supersession-threat: File changed on disk: /Users/suzume/A.txt

The Auto-saving has created an #A.txt# file (*not* a #B.txt# file, even though 
we are supposed to be visiting B.txt at the moment). And the second line says 
that B.txt is being saved, but then why the "A.txt changed on disk" message ? 
In the end, there is no indication that the command was aborted, or whether the 
file(s) were or not saved. The impression I have from the messages is that 
B.txt has been saved (good for B) and that A.txt has changed, which is visibly 
not the case.

5) I save the modification again, this time I ask emacs to revert the file from 
disk:

→ [Echo] A.txt changed on disk; really edit the buffer? (y, n, r or C-h)
→ [me] r
→ [Echo] Buffer has been auto-saved recently.  Revert from auto-save file? (y 
or n)
→ at that point, I can see that in Finder there is a new B.txt~ file and that 
B.txt has disappeared. It will return later.
→ [me] n

*Message* contents:

Saving file /Users/suzume/B.txt...
A.txt changed on disk; really edit the buffer? (y, n, r or C-h) r
Buffer has been auto-saved recently.  Revert from auto-save file? (y or n) n
ask-user-about-supersession-threat: File reverted: /Users/suzume/A.txt

But there was an [Echo] message that is not registered in *Messages* it is:
"Revert buffer from file /User/suzume/B.txt.txt? (yes or no)"

to which I replied "no".

So, A.txt has explicitly *not* been reverted. And from Finder, B.txt is still 
exactly in the same state as when it was created. Currently, only #A.txt# 
contains the modifications with the added 2nd line.

#A.txt#

(write-region "stuff" nil "B.txt" nil t nil t)
;; more stuff

The frame info still gives me no indication that I am in a file different from 
A.txt. And the frame/buffer contains:

(write-region "stuff" nil "B.txt" nil t nil t)
;; more stuff

Which is only saved in #A.txt# for now.

*But*, when I check dired, I can see A.txt and B.txt:

If I click on A.txt I return to the previous display (1 command line, 1 comment 
line, frame title and mode line info set to "A.txt"), but with the weird [Echo] 
message "~/A.txt and /User/suzume/B.txt are the same file" when obviously they 
are not... (and why use relative vs absolute paths ?)

If I click on B.txt, I have exactly the same display with the frame title and 
mode line info set to "A.txt" and with the -:**- info that seems to say that 
the buffer is modified, but how can it be since I explicitly called B.txt from 
dired (hence, supposedly from the file system), and conversely, how can it be 
displaying the 2 lines when Finder *still* shows that B.txt only contains 
"stuff"...

6) This time I go all the way to revert the file first from auto-save, to see 
what has changed:

→ Saving file /Users/suzume/B.txt...
→ A.txt changed on disk; really edit the buffer? (y, n, r or C-h) r
→ Buffer has been auto-saved recently.  Revert from auto-save file? (y or n) y
→ ask-user-about-supersession-threat: File reverted: /Users/suzume/A.txt

From Finder, I can see that:
#A.txt# still contains:
(write-region "stuff" nil "B.txt" nil t nil t)
;; more stuff

A.txt now contains:
(write-region "stuff" nil "B.txt" nil t nil t)

B.txt still contains:
"stuff"

As far as I can tell, A.txt has indeed been reverted to its original state, 
which is weird anyway since it was supposed to revert from #A.txt# which also 
had the comment line.

7) I add two empty lines to A.txt in emacs (not for a second realizing that I 
am targeting B.txt), I save and now I have:

→ Wrote /Users/suzume/B.txt

With *Messages* containing:

Saving file /Users/suzume/B.txt...
Wrote /Users/suzume/B.txt

Now, #A.txt# has disappeared

B.txt, which was supposed to only contain "stuff" has:

(write-region "stuff" nil "B.txt" nil t nil t)
;; more stuff

A.txt still only has the 1-line command

B.txt~ has been created with the original "stuff" string.

And I still have no visual clue that I'm actually inside B.txt, and it is only 
now that dired and Finder agree on the contents of the files. Also, in macos 
ctrl-clicking on the menu bar title "A.txt" brings a superimposed "B.txt" along 
with a drop down that shows the path to the file in Finder, but that B.txt is 
immediately replaced by A.txt when I stop clicking.



Conclusion: the user experience is a mess, messages appear to be contradictory 
and don't seem to reflect what is actually happening, the state of the file 
system in emacs does not match the state of the file system in Finder, and 
besides for the very last message, there are no clues that I've been working on 
B.txt all that time.

Even if I knew that it had been the case all along, the UX would still not help 
at all.

I don't think it is a plain case of "read the manual". The buffer/file 
difference is a fundamental feature of emacs and ought to be much more 
accessible, especially because people who come to emacs *now* are typically 
used to having one buffer associated (or potentially associated) with at most 
one file that *has the exact same name* as the buffer.

For one, having in plain sight the name of the file (and an extra indication if 
there are many) associated with the current buffer, if any, or an indication 
that the buffer is not targeting its original file, would go a long way to 
remove a considerable amount of potential confusion.

I hope I'm making more sense now.


Jean-Christophe 




> On Jan 9, 2020, at 0:27, Jean-Christophe Helary 
> 
> 
> File A.txt contains:
> (write-region "stuff" nil "B.txt" nil t nil t)
> 
> File B.txt is empty until I run file A.txt.
> 
> 
> The manual says:
> 
> 25.4 Writing to Files
> 
> write-region
> 
> "If visit is t, then Emacs establishes an association between the buffer and 
> the file: the buffer is then visiting that file."
> 
> 
> 25.1 Visiting Files
> 
> "Visiting a file means reading a file into a buffer. Once this is done, we 
> say that the buffer is visiting that file, and call the file the visited file 
> of the buffer."
> 
> 
> → My understanding from the above manual quotes is that file B.txt is read 
> into the buffer where file A.txt is.
> 
> I don't know how that should look like, but what I see is seemingly the 
> opposite: full contents of file A.txt is written to file B.txt.
> 
> There is obviously something that I am missing in the documentation.
> 
> Jean-Christophe 

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune