write-region bug ?

write-region bug ?

[Jean-Christophe Helary]

I mentioned that in a mail sent on the 18th of December:

> On Dec 18, 2019, at 23:10, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> The code is a most simple one liner variation on the following:
>> 
>> (write-region "stuff" nil "path/to/my/file/test.txt" nil t nil t).
>> 
>> Sometimes the whole *line* above (contained in file "test.el") would be
>> copied to the file "test.txt" and I have no idea why.
> 
> Very curious.  If you can come up with a recipe to reproduce it
> somewhat-reliably, then please `M-x report-emacs-bug`.

And I found a trivial way to reproduce the issue. Which may or may not be an issue, depending on my understanding of the command, hence my asking here for confirmation whether this is a bug or not...

1) create a foo.el file with only this content:
(write-region "" nil "~/Desktop/bar.txt" nil t nil t)

"~/Desktop/" can be anything that works on your system, the path just needs to point at a file that does not exist.

2) open the file and evaluate the expression

→ you should have an empty "bar.txt" at the location of your choice

3) modify foo.el, by adding a line for ex

4) save-buffer

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

→ for some reason, the foo.el buffer is now associated to bar.txt, if you hit "y", bar.txt now contains (write-region "" nil "~/Desktop/bar.txt" nil t nil t)

Am I missing something ?

Jean-Christophe Helary 

Re: write-region bug ?

[Andreas Schwab]

On Jan 03 2020, Jean-Christophe Helary wrote:

> → for some reason, the foo.el buffer is now associated to bar.txt

You asked for it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 3, 2020, at 2:08, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> On Jan 03 2020, Jean-Christophe Helary wrote:
> 
>> → for some reason, the foo.el buffer is now associated to bar.txt
> 
> You asked for it.

Where ?

(write-region "" nil "~/Desktop/bar.txt" nil t nil t)

write-region start end filename &optional append visit lockname mustbenew

1) If start is a string, then write-region writes or appends that string, rather than text from the buffer. end is ignored in this case.

start is "", isn't it ?


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

Re: write-region bug ?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Thu, 02 Jan 2020 18:08:21 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Jan 03 2020, Jean-Christophe Helary wrote:
> 
> > → for some reason, the foo.el buffer is now associated to bar.txt
> 
> You asked for it.

Indeed, because the VISIT argument of write-region was non-nil, and
that's what it does.  It's in the documentation.

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 3, 2020, at 2:25, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Date: Thu, 02 Jan 2020 18:08:21 +0100
>> Cc: Emacs developers <emacs-devel@gnu.org>
>> 
>> On Jan 03 2020, Jean-Christophe Helary wrote:
>> 
>>> → for some reason, the foo.el buffer is now associated to bar.txt
>> 
>> You asked for it.
> 
> Indeed, because the VISIT argument of write-region was non-nil, and
> that's what it does.  It's in the documentation.

OMG. Well, I did read the thing but it obviously did not parse well...
Everything that happened recently makes perfect sense now :)

Apologies for the hassle and thank you for the explanation.


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

Re: write-region bug ?

[Stefan Monnier]

>> > → for some reason, the foo.el buffer is now associated to bar.txt
>> You asked for it.
> Indeed, because the VISIT argument of write-region was non-nil, and
> that's what it does.  It's in the documentation.

OTOH, the VISIT argument can't make sense when the text comes from
a string rather than from a buffer.  So maybe we should signal an error
rather than doing something that's clearly wrong.


        Stefan

Re: write-region bug ?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,
>   jean.christophe.helary@traduction-libre.org,  emacs-devel@gnu.org
> Date: Sat, 04 Jan 2020 14:58:09 -0500
> 
> >> > → for some reason, the foo.el buffer is now associated to bar.txt
> >> You asked for it.
> > Indeed, because the VISIT argument of write-region was non-nil, and
> > that's what it does.  It's in the documentation.
> 
> OTOH, the VISIT argument can't make sense when the text comes from
> a string rather than from a buffer.

Why does it not make sense?  FILENAME is still provided.

Re: write-region bug ?

[Stefan Monnier]

>> >> > → for some reason, the foo.el buffer is now associated to bar.txt
>> >> You asked for it.
>> > Indeed, because the VISIT argument of write-region was non-nil, and
>> > that's what it does.  It's in the documentation.
>> 
>> OTOH, the VISIT argument can't make sense when the text comes from
>> a string rather than from a buffer.
>
> Why does it not make sense?  FILENAME is still provided.

VISIT basically tells that the buffer should be considered as
visiting FILENAME.  Here, we have VISIT and FILENAME but we don't have
the buffer (except that by accident).


        Stefan

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 5, 2020, at 7:58, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>>>>> → for some reason, the foo.el buffer is now associated to bar.txt
>>>>> You asked for it.
>>>> Indeed, because the VISIT argument of write-region was non-nil, and
>>>> that's what it does.  It's in the documentation.
>>> 
>>> OTOH, the VISIT argument can't make sense when the text comes from
>>> a string rather than from a buffer.
>> 
>> Why does it not make sense?  FILENAME is still provided.
> 
> VISIT basically tells that the buffer should be considered as
> visiting FILENAME.  Here, we have VISIT and FILENAME but we don't have
> the buffer (except that by accident).

*Yes*, that's where I stopped understanding the documentation. Thank you for pointing that out.


Even though I provide a string (START is an empty string in my case, but it happens with any string), the function considers that START is nil and hence instead of the provided string uses the whole buffer by default just *because* VISIT is non-nil.

The documentation says:

`If START is a string, then ‘write-region’ writes or appends that string, rather than text from the buffer.'

So I feel safe here.

But then:

`If VISIT is ‘t’, then Emacs establishes an association between the buffer and the file: the buffer is then visiting that file.'

I guess I still have issues with understanding what "the buffer is then *visiting* that file" means but it does seem to contradict the above description of START.

Obviously, there is an issue here.

If it is intended that a non-nil VISIT resets the value of START to nil, or overrides it that should be documented.

If it is not intended, then that's a bug.


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

Re: write-region bug ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sun, 5 Jan 2020 11:01:56 +0900
> 
> > VISIT basically tells that the buffer should be considered as
> > visiting FILENAME.  Here, we have VISIT and FILENAME but we don't have
> > the buffer (except that by accident).
> 
> *Yes*, that's where I stopped understanding the documentation. Thank you for pointing that out.

Please make sure you read the doc string as it is on the latest
emacs-27 branch (or master).

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 5, 2020, at 12:33, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Sun, 5 Jan 2020 11:01:56 +0900
>> 
>>> VISIT basically tells that the buffer should be considered as
>>> visiting FILENAME.  Here, we have VISIT and FILENAME but we don't have
>>> the buffer (except that by accident).
>> 
>> *Yes*, that's where I stopped understanding the documentation. Thank you for pointing that out.
> 
> Please make sure you read the doc string as it is on the latest
> emacs-27 branch (or master).


DEFUN ("write-region", Fwrite_region, Swrite_region, 3, 7,
       "r\nFWrite region to file: \ni\ni\ni\np",
       doc: /* Write current region into specified file.
When called from a program, requires three arguments:
START, END and FILENAME.  START and END are normally buffer positions
specifying the part of the buffer to write.
If START is nil, that means to use the entire buffer contents; END is
ignored.

*** If START is a string, then output that string to the file
instead of any buffer contents; END is ignored. ***

Optional fourth argument APPEND if non-nil means
  append to existing file contents (if any).  If it is a number,
  seek to that offset in the file before writing.
Optional fifth argument VISIT, if t or a string, means
  set the last-save-file-modtime of buffer to this file's modtime
  and mark buffer not modified.

*** If VISIT is t, the buffer is marked as visiting FILENAME. ***


So, practically speaking, the START string is output to the file, and then, the buffer is "marked as visiting FILENAME" which practically speaking means that it overwrites the START string.

What is that for ?

Jean-Christophe Helary

Re: write-region bug ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sun, 5 Jan 2020 14:14:29 +0900
> 
> *** If VISIT is t, the buffer is marked as visiting FILENAME. ***
> 
> 
> So, practically speaking, the START string is output to the file, and then, the buffer is "marked as visiting FILENAME" which practically speaking means that it overwrites the START string.
> 
> What is that for ?

Sorry, I don't understand the question.  You could ask the same
question about any optional feature of any Emacs API.  And the answer
will be the same: for those applications that need this optional
feature.

Re: write-region bug ?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: schwab@linux-m68k.org,  jean.christophe.helary@traduction-libre.org,
>   emacs-devel@gnu.org
> Date: Sat, 04 Jan 2020 17:58:21 -0500
> 
> >> OTOH, the VISIT argument can't make sense when the text comes from
> >> a string rather than from a buffer.
> >
> > Why does it not make sense?  FILENAME is still provided.
> 
> VISIT basically tells that the buffer should be considered as
> visiting FILENAME.  Here, we have VISIT and FILENAME but we don't have
> the buffer (except that by accident).

I don't think it's up to us to second-guess the caller, whether this
is an accident or not.  I can envision legitimate use cases where this
can be useful.

Re: write-region bug ?

[Stefan Monnier]

>> >> OTOH, the VISIT argument can't make sense when the text comes from
>> >> a string rather than from a buffer.
>> > Why does it not make sense?  FILENAME is still provided.
>> VISIT basically tells that the buffer should be considered as
>> visiting FILENAME.  Here, we have VISIT and FILENAME but we don't have
>> the buffer (except that by accident).
>
> I don't think it's up to us to second-guess the caller, whether this
> is an accident or not.  I can envision legitimate use cases where this
> can be useful.

I can entertain the idea that some package out there somehow calls
write-region with a non-nil `visit` and a string as `start`, but I'm
hard pressed to imagine a case where this is useful.
What kind of scenario do you have in mind?


        Stefan

Re: write-region bug ?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: schwab@linux-m68k.org,  jean.christophe.helary@traduction-libre.org,
>   emacs-devel@gnu.org
> Date: Sat, 04 Jan 2020 23:54:56 -0500
> 
> > I don't think it's up to us to second-guess the caller, whether this
> > is an accident or not.  I can envision legitimate use cases where this
> > can be useful.
> 
> I can entertain the idea that some package out there somehow calls
> write-region with a non-nil `visit` and a string as `start`, but I'm
> hard pressed to imagine a case where this is useful.
> What kind of scenario do you have in mind?

I don't think we must imagine a specific scenario to justify
NON-removal of an old feature, just because someone became confused by
the doc string.  But since you asked...

  (write-region 1 1024 "foo")
  (write-region "\nEnd-of-foo\n." nil "foo" t t)

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 6, 2020, at 0:35, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: schwab@linux-m68k.org,  jean.christophe.helary@traduction-libre.org,
>>  emacs-devel@gnu.org
>> Date: Sat, 04 Jan 2020 23:54:56 -0500
>> 
>>> I don't think it's up to us to second-guess the caller, whether this
>>> is an accident or not.  I can envision legitimate use cases where this
>>> can be useful.
>> 
>> I can entertain the idea that some package out there somehow calls
>> write-region with a non-nil `visit` and a string as `start`, but I'm
>> hard pressed to imagine a case where this is useful.
>> What kind of scenario do you have in mind?
> 
> I don't think we must imagine a specific scenario to justify
> NON-removal of an old feature, just because someone became confused by
> the doc string.

:) I'm certainly not asking a removing of that feature. But the settings that I have for the function create a behavior that's weird.

>  But since you asked...
> 
>  (write-region 1 1024 "foo")
>  (write-region "\nEnd-of-foo\n." nil "foo" t t)

>> (write-region "stuff" nil "path/to/my/file/test.txt" nil t nil t).

With APPEND set to t, that makes sense, I guess (I tried the code you wrote and I don't see why you need to have VISIT set to t).

But when APPEND is set to nil, then, as in my case, the file first gets the string and then the string is *overwritten* by the contents of the buffer that contains the write-region. Also, there is no indication whatsoever that this is happening. I only know about that when I try to save the file and emacs tells me that the file has been changed externally.

Now, I am no insisting that my t value for VISIT is correct, and I don't know where I got the idea of setting it to t. But the fact is that I don't see much value in sending a string to a file and right after it having the file overwritten with the whole buffer where the write-region command was.


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

Re: write-region bug ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Mon, 6 Jan 2020 01:42:35 +0900
> 
> Now, I am no insisting that my t value for VISIT is correct, and I don't know where I got the idea of setting it to t. But the fact is that I don't see much value in sending a string to a file and right after it having the file overwritten with the whole buffer where the write-region command was.

It is not an uncommon situation that some feature doesn't look like
being of much value to us, until we get into a use case where it does.

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 6, 2020, at 12:37, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Mon, 6 Jan 2020 01:42:35 +0900
>> 
>> Now, I am no insisting that my t value for VISIT is correct, and I don't know where I got the idea of setting it to t. But the fact is that I don't see much value in sending a string to a file and right after it having the file overwritten with the whole buffer where the write-region command was.
> 
> It is not an uncommon situation that some feature doesn't look like
> being of much value to us, until we get into a use case where it does.

Indeed. 

And I wish I understood better what 

(docstring) "the buffer is marked as visiting FILENAME."

(lisp reference) "Emacs establishes an association between the buffer and the file: the buffer is then visiting that file."

mean practically speaking, because nowhere in those sentences does it imply (to me) that the buffer contents will overwrite the file.


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

Re: write-region bug ?

[Eli Zaretskii]

On January 6, 2020 5:50:55 AM GMT+02:00, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
> 
> > On Jan 6, 2020, at 12:37, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Jean-Christophe Helary
> <jean.christophe.helary@traduction-libre.org>
> >> Date: Mon, 6 Jan 2020 01:42:35 +0900
> >> 
> 
> And I wish I understood better what 
> 
> (docstring) "the buffer is marked as visiting FILENAME."
> 
> (lisp reference) "Emacs establishes an association between the buffer
> and the file: the buffer is then visiting that file."
> 
> mean practically speaking, because nowhere in those sentences does it
> imply (to me) that the buffer contents will overwrite the file.

This is explained at the very beginning of the "Files" node in the Emacs manual.  The Glossary also explains that under Saving and under Visiting.  These are very basic notions in Emacs, so if the relations between a buffer visiting a file and what happens when you save that buffer aren't clear to you, I suggest a good reading of those parts in the manual.

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 6, 2020, at 14:29, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> This is explained at the very beginning of the "Files" node in the Emacs manual.  The Glossary also explains that under Saving and under Visiting. These are very basic notions in Emacs, so if the relations between a buffer visiting a file and what happens when you save that buffer aren't clear to you, I suggest a good reading of those parts in the manual.

I'm right there. Thank you.

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

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 6, 2020, at 14:58, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
> 
> 
>> On Jan 6, 2020, at 14:29, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> This is explained at the very beginning of the "Files" node in the Emacs manual.  The Glossary also explains that under Saving and under Visiting. These are very basic notions in Emacs, so if the relations between a buffer visiting a file and what happens when you save that buffer aren't clear to you, I suggest a good reading of those parts in the manual.
> 
> I'm right there. Thank you.


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 

Re: write-region bug ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Thu, 9 Jan 2020 00:27:35 +0900
> 
> 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.

This:

  Saving
       Saving a buffer means copying its text into the file that was
       visited (q.v.) in that buffer.

IOW, the association established by visiting means that saving the
buffer well update the visited file.

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 9, 2020, at 1:05, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Thu, 9 Jan 2020 00:27:35 +0900
>> 
>> 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.
> 
> This:
> 
>  Saving
>       Saving a buffer means copying its text into the file that was
>       visited (q.v.) in that buffer.
> 
> IOW, the association established by visiting means that saving the
> buffer well update the visited file.

That's obviously not the part I do not understand.

I did some tests and I'll make a full description of what I think is really weird, later today I must go to work.

Thank you for not giving up on me though :)



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

Re: write-region bug ?

[Noam Postavsky]

On Wed, 8 Jan 2020 at 19:04, Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> wrote:

> >> "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.

> >       Saving a buffer means copying its text into the file that was
> >       visited (q.v.) in that buffer.
> >
> > IOW, the association established by visiting means that saving the
> > buffer well update the visited file.
>
> That's obviously not the part I do not understand.

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.

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

Re: write-region bug ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Thu, 9 Jan 2020 21:30:49 +0900
> 
> 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.

My proposed conclusion is different: what you did is not meant for
interactive use, certainly not by users who don't have a clear idea
what does "visiting a file" means for a buffer and its relation with
the file it visits.  This feature exists for Lisp programs which need
to do something very special for needs that happen relatively rarely,
without exposing that to the user.

There _are_ interactive features which change the file visited by the
current buffer, and they use this very feature, but they do it in a
way that doesn't confuse users.  See the documentation of "C-x C-w"
for more details.

> 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.

The display in the frame title that you describe is just the default.
It is deemed to be convenient and useful in regular use, because
normally users aren't expected to have the buffer's and file's names
diverge.  But if you intend to do this stuff frequently, or don't like
the default for any other reason, you can customize that to have the
file name displayed, either together with, or even instead of, the
buffer name.  See frame-title-format for more about this.

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 9, 2020, at 23:07, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Thu, 9 Jan 2020 21:30:49 +0900
>> 
>> 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.
> 
> My proposed conclusion is different: what you did is not meant for
> interactive use,

Indeed. And my original use was not interactive. I was writing a string to a file from inside some code.

And I just spent a few hours trying to understand what was actually happening to see how I could eventually have seen from the messages that what I was doing was wrong and I've just shown that the messages are not helping at all.

As I've written in this thread, the manual too was not helping much, neither were the doc strings, so I'm not sure from where I could 

> "have a clear idea what does "visiting a file" means for a buffer and its relation with the file it visits."


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

Re: write-region bug ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Thu, 9 Jan 2020 23:39:56 +0900
> 
> As I've written in this thread, the manual too was not helping much, neither were the doc strings, so I'm not sure from where I could 
> 
> > "have a clear idea what does "visiting a file" means for a buffer and its relation with the file it visits."

Experience, I guess.

Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 10, 2020, at 2:03, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Thu, 9 Jan 2020 23:39:56 +0900
>> 
>> As I've written in this thread, the manual too was not helping much, neither were the doc strings, so I'm not sure from where I could 
>> 
>>> "have a clear idea what does "visiting a file" means for a buffer and its relation with the file it visits."
> 
> Experience, I guess.

Let me politely suggest, "clearer explanations and edits in the manual." Although nobody has a duty to give explanations, there is a point where replies stop being helpful at all.

Also, somebody who seems to have read what I wrote earlier sent me this offlist:

>> 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)
> This is plainly a bug -- buffer-file-truename isn't being updated to match buffer-file-name.  I think that the inexcusable parts of what follows are (mostly) the result of this point.

Thank you to that person.

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

Re: write-region bug ?

[Stefan Monnier]

> I don't think we must imagine a specific scenario to justify
> NON-removal of an old feature, just because someone became confused by
> the doc string.  But since you asked...

I'm not suggesting breaking old code, but declaring such use as
non-supported (e.g. mention it in the docstring) and maybe even emit
a warning.

>   (write-region 1 1024 "foo")
>   (write-region "\nEnd-of-foo\n." nil "foo" t t)

Which is just as naturally written:

    (write-region 1 1024 "foo" nil t)
    (write-region "\nEnd-of-foo\n." nil "foo" t)


-- Stefan

Re: write-region bug ?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: schwab@linux-m68k.org,  jean.christophe.helary@traduction-libre.org,
>   emacs-devel@gnu.org
> Date: Sun, 05 Jan 2020 12:37:06 -0500
> 
> >   (write-region 1 1024 "foo")
> >   (write-region "\nEnd-of-foo\n." nil "foo" t t)
> 
> Which is just as naturally written:
> 
>     (write-region 1 1024 "foo" nil t)
>     (write-region "\nEnd-of-foo\n." nil "foo" t)

But that doesn't make the former illegitimate.  So I don't see any
reason to declare it unsupported.

Re: write-region bug ?

[Stefan Monnier]

>> >   (write-region 1 1024 "foo")
>> >   (write-region "\nEnd-of-foo\n." nil "foo" t t)
>> 
>> Which is just as naturally written:
>>
>>     (write-region 1 1024 "foo" nil t)
>>     (write-region "\nEnd-of-foo\n." nil "foo" t)
>
> But that doesn't make the former illegitimate.

It's not a legitimate *need*.  It's a use that happens to work, but it
doesn't show a use-case where you *need* this odd corner case.
So, I'm still at the same point as before: I can imagine existing code
which happens to use this behavior, but not code which needs
this behavior.

> So I don't see any reason to declare it unsupported.

It's simply to try and help users not to shoot themselves in the foot.
I know we usually don't try very hard, so it's not crucial.


        Stefan