GNU bug report logs -
#1804
23.0.60; (with-ns) application preferences should be global
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
When did you last pull?
The font panel isn't shown from Preferences for me. Prefs should show
the same as M-x customize RET.
(The prefs panel that we used to have is gone.)
Can you confirm so we can close this?
If it was there and showed the font panel, then I would absolutely
agree with you...
Btw, even if it is shown (using M-x ns-popup-font-panel, which I
blieve is the only way to bring it up now), it does not clearly show
its association with a window. This, however, is a Cocoa problem with
the design of the panel.
- David
On May 4, 2009, at 12:11 PM, B Smith-Mannschott wrote:
> On Tue, Apr 28, 2009 at 15:25, David Reitter
> <david.reitter <at> gmail.com> wrote:
>> Ben,
>>>
>>> 7. Select a font 8. (nothing happens) 9. Click on a currently open
>>> emacs
>>> frame (not the Preferences window). 10. (the Preferences window
>>> loses
>>> keyboard focus) 11. Select a font (from the font panel) 12. (The
>>> font of the
>>> currently focused frame will change.) 13. (The font of the second
>>> frame will
>>> not change.)
>>
>> I don't think that the font panel should apply globally
>
> It should be clear form the context that produces it, what the font
> panel will affect. As it stands, it's displayed by Preferences in the
> *Application* menu. This makes it global, by implication. If font
> control isn't intended to be global, then it simply shouldn't be made
> available through the application-wide Preferences window.
>
>> (at least not in GNU
>> Emacs); also because it gives the user less control.
>
> This line of argument *can* be used to paper over all manner of
> usability sins, but in the case of Emacs it's correct. It is in Emacs'
> nature to be all dials, toggles and blinkenlights.
>
>> However, it should set the font for future frames, because there is
>> no other
>> way to set that through the GUI (w/o customization buffer).
>> Perhaps that
>> would serve as a working compromise. For that, try the code below.
>
> I'll give the code a spin the next time I'm on my mac. I still
> thinking removing this option from the application-wide preferences
> window is the simplest way not to violate the user's expectations.
> (Naturally, the functionality still needs to be accessible and
> discoverable thorough other means.)
>
>> (defun ns-respond-to-change-font ()
>> "Respond to changeFont: event, expecting ns-input-font and\n\
>> ns-input-fontsize of new font."
>> (interactive)
>> (let ((face 'default))
>> (set-face-attribute face t
>> :family ns-input-font
>> :height (* 10 ns-input-fontsize))
>> (set-face-attribute face (selected-frame)
>> :family ns-input-font
>> :height (* 10 ns-input-fontsize))
>> (let ((spec
>> (list (list t (face-attr-construct 'default)))))
>> (put face 'customized-face spec)
>> (custom-push-theme 'theme-face face 'user 'set spec)
>> (put face 'face-modified nil))))
[smime.p7s (application/pkcs7-signature, attachment)]
This bug report was last modified 15 years and 156 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.