when nothing happens, buffer still marked as modified

[Emanuel Berg]

Here [1] is a function I once wrote. My mind
isn't what it was back then, but testing it
with the different options (the `C-u' combos)
I understand it from a user's perspective and
it seems to do what it says.

Only one thing is missing what I can see, and
that is, when nothing happens (i e the piece of
text is already in the desired shape), the
buffer is still marked as modified (the `**')!

What is the correct way to prevent that?

(defun fill-down (start end &optional justify)
"Fill the current paragraph from the current line down.\n
With mark active, act upon the region instead.\n
With \\[universal-argument] before invocation, JUSTIFY fully.
With \\[universal-argument] twice, remove full justification. (Or just fill it!)
With \\[universal-argument] thrice, center."
(interactive
(if (use-region-p)
(list (region-beginning) (region-end) current-prefix-arg)
(list (line-beginning-position)
(save-excursion (forward-paragraph) (point))
current-prefix-arg)))
(if (equal justify '(16)) ; C-u C-u -> unjustify
(canonically-space-region start end)
(fill-region
start end
(pcase justify
(`(4) 'full) ; C-u -> justify
(`(64) 'center) )))) ; C-u C-u C-u -> center
;; no C-u -> none (i e just fill)

[1] http://user.it.uu.se/~embe8573/emacs-init/fill-new.el

[Eli Zaretskii]

Date: Wed, 05 Dec 2018 03:48:59 +0100
Only one thing is missing what I can see, and
that is, when nothing happens (i e the piece of
text is already in the desired shape), the
buffer is still marked as modified (the `**')!
What is the correct way to prevent that?

Use with-silent-modifications, or just manually mark the buffer
unmodified using set-buffer-modified-p, when the function is about to
return.

[Emanuel Berg]

Post by Eli Zaretskii

Wed, 05 Dec 2018 03:48:59 +0100
Only one thing is missing what I can see, and
that is, when nothing happens (i e the piece
of text is already in the desired shape), the
buffer is still marked as modified (the
`**')!
What is the correct way to prevent that?

Use with-silent-modifications, or just manually
mark the buffer unmodified using
set-buffer-modified-p, when the function is
about to return.

But how do I determine if the buffer has
changed or not? If it has, of course it should
be marked `**'!

[Eli Zaretskii]

Date: Wed, 05 Dec 2018 08:23:24 +0100

Post by Eli Zaretskii
Use with-silent-modifications, or just manually
mark the buffer unmodified using
set-buffer-modified-p, when the function is
about to return.

But how do I determine if the buffer has
changed or not? If it has, of course it should
be marked `**'!

That's the same problem that M-q has, and it leaves the modified
status intact. Why not do as it does?

You could, of course, save a copy of the buffer before the changes,
and then compare, but why bother?

[Emanuel Berg]

Post by Eli Zaretskii

Post by Emanuel Berg
But how do I determine if the buffer has
changed or not? If it has, of course it
should be marked `**'!

That's the same problem that M-q has, and it
leaves the modified status intact. Why not do
as it does?

I'm not following, "Why not do as it does"?

Post by Eli Zaretskii
You could, of course, save a copy of the
buffer before the changes, and then compare,
but why bother?

Don't you think it is confusing, even
incorrect, to have the buffer change status
when the data hasn't changed from the command?

[Eli Zaretskii]

Date: Wed, 05 Dec 2018 11:09:24 +0100

Post by Eli Zaretskii

Post by Emanuel Berg
But how do I determine if the buffer has
changed or not? If it has, of course it
should be marked `**'!

That's the same problem that M-q has, and it
leaves the modified status intact. Why not do
as it does?

I'm not following, "Why not do as it does"?

I mean why not follow M-q's example? It marks the buffer modified
even if re-filling the text arrived at the same text as before the
command.

Post by Eli Zaretskii
You could, of course, save a copy of the
buffer before the changes, and then compare,
but why bother?

Don't you think it is confusing, even
incorrect, to have the buffer change status
when the data hasn't changed from the command?

The data did change, it just eventually arrived at the same contents.
Sheer luck.

[Amin Bandali]

Post by Eli Zaretskii
I mean why not follow M-q's example? It marks the buffer modified
even if re-filling the text arrived at the same text as before the
command.

I’d noticed that in the past and found it strange. Are there any
strong reasons for keeping the current behaviour vs. only marking
the buffer as modified when re-filling actually results in a
change? Marking the buffer as modified when there was no visual
change seems like a ‘leaky abstraction’.

Though thinking about the wording (“modified”) more precisely, I
suppose the behaviour does technically make sense, but it still
feels somewhat strange / counter-intuitive. I think it would be
nice to have a “difference” indicator for when an action results
in an actual difference compared to before.

Just my 2¢.

[Eli Zaretskii]

Date: Wed, 05 Dec 2018 08:39:49 -0500

Post by Eli Zaretskii
I mean why not follow M-q's example? It marks the buffer modified
even if re-filling the text arrived at the same text as before the
command.

I’d noticed that in the past and found it strange. Are there any
strong reasons for keeping the current behaviour vs. only marking
the buffer as modified when re-filling actually results in a
change?

The only strong reason is that it's not trivial to implement, and no
one has yet proposed a satisfactory patch to do that.

[Joost Kremers]

Post by Eli Zaretskii

Date: Wed, 05 Dec 2018 11:09:24 +0100

Post by Eli Zaretskii

Post by Emanuel Berg
But how do I determine if the buffer has
changed or not? If it has, of course it
should be marked `**'!

That's the same problem that M-q has, and it
leaves the modified status intact. Why not do
as it does?

I'm not following, "Why not do as it does"?

I mean why not follow M-q's example? It marks the buffer
modified
even if re-filling the text arrived at the same text as before
the
command.

Now I'm confused. The NEWS section for Emacs 26 says:

** 'fill-paragraph' no longer marks the buffer as changed unless
it
actually changed something.

Which seems to be implemented (correct me if I'm wrong, I only
took a very quick look) by using `buffer-hash'. I thought that was
what you meant when you said "do as it does"...

[Eli Zaretskii]

Date: Wed, 05 Dec 2018 16:00:15 +0100
** 'fill-paragraph' no longer marks the buffer as changed unless
it
actually changed something.
Which seems to be implemented (correct me if I'm wrong, I only
took a very quick look) by using `buffer-hash'. I thought that was
what you meant when you said "do as it does"...

I meant what it did before the change, but either way is a
possibility.

[Michael Heerdegen]

** 'fill-paragraph' no longer marks the buffer as changed unless it
actually changed something.

Indeed. But Emmanuel used `fill-region' which wasn't "fixed" in this
way, right?

Michael.

[Emanuel Berg]

Post by Joost Kremers
** 'fill-paragraph' no longer marks the
buffer as changed unless it actually
changed something.

Indeed. But Emmanuel used `fill-region' which
wasn't "fixed" in this way, right?

Either that, or my Emacs is too old:

GNU Emacs 24.4.1 (arm-unknown-linux-gnueabihf,
GTK+ Version 3.14.5) of 2017-09-13 on
mb-lxc-01, modified by Debian

[Michael Heerdegen]

Don't you think it is confusing, even incorrect, to have the buffer
change status when the data hasn't changed from the command?

See Bug#13949 and related. AFAIR most people agreed that it would be
nice if Emacs behave differently in cases like yours, but it is an
absolutely non-trivial problem, and any solution wouldn't be extensive
and have downsides.

Michael.

[Emanuel Berg]

Post by Eli Zaretskii

Post by Emanuel Berg
Don't you think it is confusing, even
incorrect, to have the buffer change status
when the data hasn't changed from
the command?

The data did change, it just eventually
arrived at the same contents. Sheer luck.

I see. In a way that makes sense. If you hit
someone in the head with a bottle, but by sheer
luck do not inflict any physical or mental
damage whatsoever, it should still be
considered a crime. Put it up `**' in the
criminal record with my blessing!