RE: Some developement questions

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

> A little bit of marketing would help here. The initial contents of *scratch*,
> the mode line, and the minibuffer need not be monospaced, and would all
> benefit from a better font.

Just one opinion: No thanks to such marketing.

99.999% of my use of *scratch* and the minibuffer is code or data
that should be (i.e., that I want to be) monospace. And probably
90% of my mode-line too. (And I could change other parts of the
mode-line to use a different font, if I wanted to.)

IMHO, you could hardly have picked worse examples.

Info would have been a somewhat reasonable example. But even
there I'd rather have the code parts shown using monospace, and
code is a non-negligible part of many Info nodes. There's a reason
that technical doc typically uses variable-width for ordinary text
and fixed-width for code.

But it's true that you said only "the initial contents of..." (why?).
It's hard to argue that the initial contents of *scratch* call for a
monospace font. But are you proposing that Emacs automatically
change *scratch* to a monospace font when most of its contents
become code or such? Do you perhaps propose that Emacs
monitor such buffers to detect text that should reasonably be
monospace, and  automatically use a monospace font for those
parts (only)?

What's so hard about using a variable-width font for your Emacs 
classes/demos, at least for those buffers where you think it
makes sense? You could even show them how easy it is for them
to leave the dark-age 80s behind and become super cool on their
own.

(FWIW, on MS Windows it looks like menus use a variable-width
font.)