bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug'

["Drew Adams" <drew.adams@oracle.com>]

> > That change unfortunately breaks fitting the frame to the 
> > buffer (using my fit-frame.el), horribly.
> 
> I'd rather fix fit-frame.el so it handles this case as well.

Suggestions welcome. ;-)

I've thought a little about it.  I could check each character for a display
property that is, in effect, a replacement string (as in this case), and then
get its width.

But that would slow things down considerably.  Currently I just get the line
width for each line using `end-of-line'.

I believe there is a longstanding Emacs bug regarding the same kind of thing for
a vanilla Emacs function that does some window/buffer fitting.

Perhaps you recall the discussion from a few years back.  The plan/hope was to
make it DTRT in terms of what actually gets displayed, not just what is inserted
(text, images) in the buffer.  AFAIK, nothing ever came of those hopes.
fit-frame.el suffers from the same lack of magic.

Anyway, clearly, for this latest bug (breaking fit-frame), it is FAR easier to
revert to what we had before your fix or to find some other solution to the
problem, as you saw it, of users copying text they "shouldn't".

It is far easier to fix that than it would be to fix fit-frame.el's calculation
of needed frame size so that it takes all display artifacts into account.

We should not let the ideal become the enemy of the good.  But as I said, if you
have some simple suggestions for fit-frame.el in this regard, they are welcome.

Even then, while waiting, it would be good to fix this minor
unwarranted-text-copying problem some other way than your `display' property
hack.  I don't even see it as a real problem that needed fixing, personally, or
at least not an important one.  How much has it really been a problem in
practice that users included instructions in their bug-report text?