RE: face-remapping-alist client code

[Drew Adams]

> > I'm not crazy about binding keys for this (just by 
> > loading), and those key bindings in particular.
> > It's OK to suggest bindings in the Commentary, however.
> 
> That kind of thing will be cleaned up before committing (I'm not
> entirely sure how one goes about adding default bindings).
> [I think the C-+/C-= and C-- bindings are correct however, as they are
> what people expect.]

They might be what some people outside Emacs expect for font resizing, but I
would still prefer that the library not create any bindings. Except possibly via
a minor-mode map.

Also, `C--' is useful for its `negative-argument' binding (even if there are
alternatives).

Wrt `C-=', my personal preference would be to reserve that as a prefix key for
comparisons of different types. I use these, for instance:

 C-= b  ediff-buffers
 C-= d  diff
 C-= e  ediff-files
 C-= f  ediff-files
 C-= w  compare-windows

> The current code operates _per buffer_ (the previous code 
> grew or shrunk the entire frame).  I think per-buffer operation
> is far more useful (e.g., I currently have my Gnus article buffer
> resized up one step which is kind of pleasant; for viewing big
> files, resizing down a step or two is quite nice).

That is a definite advantage over the approach I use.

> The size calculations I'm using are the same as before -- a simple
> constant factor height scaling for each step -- and probably will
> occasionally miss a step on platforms with only non-scalable fonts and
> poor font size coverage.  With scalable fonts, however, this simple
> calculation works very well.
> 
> [Another issue with per-frame size changing was that very frequent
> changing of the default frame face tended to crash Emacs.  The whole
> baroque mechanism that gets invoked for that case is complicated and
> fragile.]

I don't see that, but perhaps it is platform-related. I'm using Windows. AFAICT,
it works fine and fast in Emacs 20 through 23.

> Another point is that the per-buffer mechanism is much faster 
> (even on a slow machine) -- frame-resize is _slow_ as well as being 
> flaky.  You can happily use auto-repeat... :-)

I don't see any slowdown either, but perhaps that too is platform-related. FWIW,
I use auto-repeat with frame-resizing all of the time. I use it not only to zoom
(via font) but also to change frame width and height.