bug#23824: 25.0.95; Prevent compare one buffer with itself

[Tino Calancha <f92capac@gmail.com>]

On Thu, 23 Jun 2016, Eli Zaretskii wrote:
>But then what is that "also" word doing in the doc string?
Nothing special:
It states that the person whom wrote this func took in account both cases:
*) When buf-a is not visiting file-b (let's call it 'default' case).
*) When buf-a is visiting file-b ('special' case).
Something like: "Dear doc readers, i let you know that i have _also_
considered the case when buf-a is visiting file-b".


>I think there's more here than meets the eye.  Did you ask yourself
>why the user is asked twice whether to save the same buffer to the
>same file in your scenario?  Why does it do that?  What does it have
>in mind?

I guess is just a bug in the logic.  The author of this code
overlooked that
(get-file-buffer file-b)
may return the very same buffer that buf-a (when buf-a is visiting 
file-b).
Then, calling
(highlight-markup-buffers BUF-A FILE-B BUF-A FILE-B)
will prompt you twice to save BUF-A when BUF-A is modified.
It prompts you to save buf-a again even if you saved buf-a after
the first prompt: this is because `highlight-markup-buffers'
save the bit on the modification status of BUF-A and BUF-B at the
top of the function.

In my patch, for this case (buf-a visiting file-b), i explicitely create a 
temporary buffer whose content equals file-b content.
Then, I call
(set-buffer-modified-p nil)
to prevent being prompted to save this temporary buffer.

>Oh, it matters a lot.  insert-file-contents-literally will bypass any
>decoding and leave the CR-LF EOLs untranslated, something that you
>don't want to affect the comparison.

I see.  Another example that reviewing a patch before applying it
is a good thing.
Then, my patch need to be modified:

insert-file-contents-literally -> insert-file-contents