face-remapping-alist client code

face-remapping-alist client code

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Attached is a small example of code using face-remapping-alist.

The file ("face-remap.el") contains a small set of utility functions for
making cooperative use of face-remapping-alist easier, and also contains
two example uses:

 (1) Face size increase/decrease commands (bound to C-= / C-+ and C--),
     similar to those in many GUI applications.

 (2) The `variable-pitch-mode' minor mode, which causes the
     `variable-pitch' face to be used for displaying the buffer text
     while active.  [I bind this to `C-c v']

Comments?

[If nobody objects, I'll commit this file too.]

-Miles


[-- Attachment #2: face-remap.el --]
[-- Type: application/emacs-lisp, Size: 8262 bytes --]

[-- Attachment #3: Type: text/plain, Size: 65 bytes --]


-- 
Success, n. The one unpardonable sin against one's fellows.

Re: face-remapping-alist client code

[David Reitter]

On 2 Jun 2008, at 11:27, Miles Bader wrote:
>
>
> (1) Face size increase/decrease commands (bound to C-= / C-+ and C--),
>     similar to those in many GUI applications.

Does this resize the frame?

Without your patch and this code, I've had a lot of "flicker" with the  
frame being resized (resized in pixels, to keep height/width in chars  
constant).

Re: face-remapping-alist client code

[Miles Bader]

David Reitter <david.reitter@gmail.com> writes:
>> (1) Face size increase/decrease commands (bound to C-= / C-+ and C--),
>>     similar to those in many GUI applications.
>
> Does this resize the frame?

No, just text size.

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: face-remapping-alist client code

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 85 bytes --]

Here's a newer version that makes the text-scaling stuff into a
minor-mode.

-Miles


[-- Attachment #2: face-remap.el --]
[-- Type: application/emacs-lisp, Size: 9199 bytes --]

[-- Attachment #3: Type: text/plain, Size: 42 bytes --]



-- 
Defenceless, adj. Unable to attack.

RE: face-remapping-alist client code

[Drew Adams]

> Attached is a small example of code using face-remapping-alist.
> The file ("face-remap.el") contains a small set of utility 
> functions for making cooperative use of face-remapping-alist
> easier, and also contains two example uses:
> 
>  (1) Face size increase/decrease commands (bound to C-= / C-+ 
>      and C--), similar to those in many GUI applications.
> 
>  (2) The `variable-pitch-mode' minor mode, which causes the
>      `variable-pitch' face to be used for displaying the buffer
>      text while active.  [I bind this to `C-c v']
> 
> Comments? [If nobody objects, I'll commit this file too.]
>
> Here's a newer version that makes the text-scaling stuff into a
> minor-mode.

I don't know if I object, because I won't be building Emacs to try out the face
remapping patch that this needs. I think the general idea of face remapping
sounds OK, however.

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.

In May of 2004, I believe you proposed something similar. How does this differ?
I seem to recall vaguely that there were some limitations wrt the fonts that
could be resized this way (some available font sizes were skipped, perhaps?). Am
I misremembering?

FWIW, I use the following code to resize the default font by changing its point
size. If your resizing code works as well or better than this does, then yours
would be preferable, since it doesn't twiddle at the font-name level.

(defun enlarge-font (&optional increment frame)
  "Increase size of font in FRAME by INCREMENT.
Interactively, INCREMENT is given by the prefix argument.
Optional FRAME parameter defaults to current frame."
  (interactive "p")
  (setq frame (or frame (selected-frame)))
  (let ((fontname (cdr (assq 'font (frame-parameters frame))))
        (count enlarge-font-tries))
    (setq fontname (enlarged-font-name fontname frame increment))
    (while (and (not (x-list-fonts fontname))
                (wholenump (setq count (1- count))))
      (setq fontname (enlarged-font-name fontname frame increment)))
    (unless (x-list-fonts fontname) (error "Cannot change font size"))
    (modify-frame-parameters frame (list (cons 'font fontname)))
    ;; Update faces that want a bold or italic version of the
    ;; default font.
    (frame-update-faces frame)))

(defun enlarged-font-name (fontname frame increment)
  "FONTNAME, after enlarging font size of FRAME by INCREMENT.
FONTNAME is the font of FRAME."
  (when (query-fontset fontname)
    (let ((ascii (assq 'ascii (aref (fontset-info fontname frame) 2))))
      (when ascii (setq fontname (nth 2 ascii)))))
  (let ((xlfd-fields (x-decompose-font-name fontname)))
    (unless xlfd-fields (error "Cannot decompose font name"))
    (let ((new-size
            (+ (string-to-number
                (aref xlfd-fields xlfd-regexp-pixelsize-subnum))
               increment)))
      (unless (> new-size 0)
        (error "New font size is too small: %s" new-size))
      (aset xlfd-fields xlfd-regexp-pixelsize-subnum
            (number-to-string new-size)))
    ;; Set point size & width to "*", so frame width will adjust
    ;; to new font size
    (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
    (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
    (x-compose-font-name xlfd-fields)))

(defcustom enlarge-font-tries 100
  "Number of times to try to change font size, when looking for a font.
The font-size portion of a font name is incremented or decremented at
most this many times, before giving up and raising an error."
  :type 'integer :group 'Frame-Commands)

----

Library zoom-frm.el uses the above code to provide convenient font (and frame)
zooming. It binds no keys, but suggests these key bindings:

(define-key global-map [S-mouse-1] 'zoom-frm-in)
(define-key global-map [C-S-mouse-1] 'zoom-frm-out)
;; Get rid of `mouse-set-font':
(define-key global-map [S-down-mouse-1] nil)

Zooming is incremental - just repeat to enlarge/shrink more.

(defun zoom-frm-in (&optional frame flip)
  "Zoom FRAME in by `frame-zoom-font-difference', making text larger.
If `frame-zoom-font-difference' is negative, make text smaller.
With prefix argument FLIP, reverse the direction:
if `frame-zoom-font-difference' is positive, then make text smaller.
This is equal but opposite to `zoom-frm-out'."
  (interactive (list (selected-frame) current-prefix-arg))
  (setq frame (or frame (selected-frame)))
  (let ((zoom-factor (frame-parameter frame 'zoomed))
        (increment (if flip
                       (- frame-zoom-font-difference)
                     frame-zoom-font-difference)))
    (unless zoom-factor (setq zoom-factor 0))
    (setq zoom-factor (+ zoom-factor increment))
    (enlarge-font increment frame)
    (modify-frame-parameters
      frame (list (cons 'zoomed zoom-factor)))))

(defun zoom-frm-out (&optional frame flip)
  "Zoom FRAME out by `frame-zoom-font-difference'.
If `frame-zoom-font-difference' is negative, make text larger.
With prefix argument FLIP, reverse the direction:
if `frame-zoom-font-difference' is positive, then make text larger.
This is equal but opposite to `zoom-frm-in'."
  (interactive (list (selected-frame) current-prefix-arg))
  (setq frame (or frame (selected-frame)))
  (let ((frame-zoom-font-difference (- frame-zoom-font-difference)))
    (zoom-frm-in frame flip)))

(defcustom frame-zoom-font-difference 1
  "*Number of points to change the frame font size when zooming.
The absolute value of this must be less than the current font size,
since the new font size cannot be less than 1 point."
  :type 'integer :group 'Frame-Commands)

http://www.emacswiki.org/cgi-bin/wiki/zoom-frm.el

Re: face-remapping-alist client code

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> 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.]

> In May of 2004, I believe you proposed something similar. How does this differ?
> I seem to recall vaguely that there were some limitations wrt the fonts that
> could be resized this way (some available font sizes were skipped, perhaps?). Am
> I misremembering?

I did, though the mechanism was quite different.

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).

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.]

-Miles

-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: face-remapping-alist client code

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
> 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).

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... :-)

-Miles

-- 
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.

Re: face-remapping-alist client code

[Chong Yidong]

No objections to either pieces of code you suggested.

>  (1) Face size increase/decrease commands (bound to C-= / C-+ and C--),
>      similar to those in many GUI applications.

I believe it's also common to bind to C-[mouse-4] and C-[mouse-5]
(C-mousewheel) keys.

Re: face-remapping-alist client code

[Juanma Barranquero]

On Mon, Jun 2, 2008 at 4:44 PM, Miles Bader <miles@gnu.org> wrote:

> 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.

With Vera Sans Mono, and using a smaller scale step (1.07) I get all
point sizes from 13 to 24 except for 19 and 23. Goint down it hits
every size, of course, though some of them appear twice because in
some steps the scaling is not big enough to reduce the font. All in
all, is quite useful and simple. Thanks.

A couple of small nitpicks:

 - the variables `text-scale-mode-lighter',
`text-scale-mode-remapping', `text-scale-mode-amount' and
`variable-pitch-mode-remapping' would  make more sense as
automatically buffer local, as they are always buffer-local'ized when
used.

 - the lighter for variable-pitch-mode is a bit of redundant, isn't
it? Either the user has a variable-pitch face different from the
default one (and so he doesn't need the reminder in the modeline), or
the mode is not going to be useful anyway...

 Juanma

Re: face-remapping-alist client code

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>  - the variables `text-scale-mode-lighter',
> `text-scale-mode-remapping', `text-scale-mode-amount' and
> `variable-pitch-mode-remapping' would  make more sense as
> automatically buffer local, as they are always buffer-local'ized when
> used.

I somehow got the impression that make-variable-buffer-local was frowned
upon.  Dunno if it's true.

>  - the lighter for variable-pitch-mode is a bit of redundant, isn't
> it? Either the user has a variable-pitch face different from the
> default one (and so he doesn't need the reminder in the modeline), or
> the mode is not going to be useful anyway...

I think the lighters are actually quite useful.  It's nice to have an
explicit reminders of active modes as well as implicit (and sometimes
subtle) ones.

-Miles

-- 
Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling.

Re: face-remapping-alist client code

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>  - the variables `text-scale-mode-lighter',
>> `text-scale-mode-remapping', `text-scale-mode-amount' and
>> `variable-pitch-mode-remapping' would  make more sense as
>> automatically buffer local, as they are always buffer-local'ized when
>> used.
>
> I somehow got the impression that make-variable-buffer-local was
> frowned upon.  Dunno if it's true.

It depends.  If a global value or at least default makes sense of its
own, I'd not use make-variable-buffer-local.  For values that carry
information that only ever makes sense tied to a buffer, I'd use it.

This probably implies that it makes more sense with defvar rather than
with defcustom.

Don't know whether there is a general policy here.

-- 
David Kastrup

Re: face-remapping-alist client code

[Juanma Barranquero]

On Mon, Jun 2, 2008 at 5:22 PM, Miles Bader <miles@gnu.org> wrote:

> I somehow got the impression that make-variable-buffer-local was frowned
> upon.  Dunno if it's true.

As David has said, it depends on whether the variable is going to have
a sensible default that can be often used without resorting to making
it buffer-local. But I think that's not the case here.

> I think the lighters are actually quite useful.  It's nice to have an
> explicit reminders of active modes as well as implicit (and sometimes
> subtle) ones.

Oh, I think we are on extreme opposites here. I tend to remove
lighters, or at the very least reduce them to the minimum possible
expression (one-char).

 Juanma

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.

Re: face-remapping-alist client code

[Stefan Monnier]

>> - the variables `text-scale-mode-lighter',
>> `text-scale-mode-remapping', `text-scale-mode-amount' and
>> `variable-pitch-mode-remapping' would  make more sense as
>> automatically buffer local, as they are always buffer-local'ized when
>> used.

> I somehow got the impression that make-variable-buffer-local was frowned
> upon.  Dunno if it's true.

It's perfectly fine for internal variables.  It's a definite no-no when
you call it on some other package's variable.  And as for variables that
are manipulated by other packages, it may be better to force them to
always use make-local-variable, otherwise they may be surprised if they
`setq' before your package was loaded.

>> - the lighter for variable-pitch-mode is a bit of redundant, isn't
>> it? Either the user has a variable-pitch face different from the
>> default one (and so he doesn't need the reminder in the modeline), or
>> the mode is not going to be useful anyway...

> I think the lighters are actually quite useful.  It's nice to have an
> explicit reminders of active modes as well as implicit (and sometimes
> subtle) ones.

Either I wouldn't see it (fine), or it'd push away some other lighter
(my mode-line is usually full already).


        Stefan

Re: face-remapping-alist client code

[Stefan Monnier]

> This probably implies that it makes more sense with defvar rather than
> with defcustom.

Buffer-local variables should generally not be mixed with defcustom,
because custom doesn't know what to do with it.  It won't collapse, but
the user may be disappointed.


        Stefan

RE: face-remapping-alist client code

[Drew Adams]

> > This probably implies that it makes more sense with defvar 
> > rather than with defcustom.
> 
> Buffer-local variables should generally not be mixed with defcustom,
> because custom doesn't know what to do with it.  It won't 
> collapse, but the user may be disappointed.

Why don't you document that, if it's not already documented?