Re: write-region bug ?

[Jean-Christophe Helary]

> On Jan 6, 2020, at 0:35, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Stefan Monnier <address@hidden>
>> Cc: address@hidden,  address@hidden,
>>  address@hidden
>> 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