bug#69920: Proposed fix - Toggling MIME inline attachment previews adds superfluous newlines

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 22 Mar 2024 23:25:20 +0100
> From:  Alcor via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> git blame'ing the line in question on yields a decade-old
> commit. Apparently, this used to be (insert "\n\n") … (delete-region b
> (+ b 2)) about ~10 years ago, and the last relevant change turned that
> into (insert "\n") … (delete-region b (1+ b)), but it seems lots of
> other things on that codepath changed in the meantime.

That commit explains the rationale:

  commit 14ff920dc885636a763d6ab7f256cc9981c24781
  Author:     Katsumi Yamaoka <yamaoka@jpl.org>
  AuthorDate: Fri May 2 09:44:34 2014 +0000
  Commit:     Katsumi Yamaoka <yamaoka@jpl.org>
  CommitDate: Fri May 2 09:44:34 2014 +0000

      Gnus: Make gnus-mime-inline-part and gnus-mime-inline-part work similarly

> FWIW, (insert-image … "x") (insert "\n") inserts two characters,
> i.e. the image itself "x" and "\n"

The code inserts the character "x" with a 'display' property on it
(which causes the image to be shown instead of "x"), followed by the
newline.

> so it should either be (insert "\n") … (delete-region b (+ 2 b)) or,
> alternatively just (delete-region b (1+ b)) (without any `insert'
> call).

Are you saying that the problem is with the function that
"un-displays" the inline image, in that it fails to remove the
inserted newline?  (AFAIU, the code before the above commit also had
the same issue.)  That wasn't clear from the description of the
problem, and the Subject is ambiguous wrt what newlines are deemed
"superfluous".  So please clarify what is the problem you are flagging
here.

Thanks.