martin rudalics wrote: > > What exactly is in your .emacs file? That is, can you give a recipe to > reproduce the problem? > > It's reproducible here with my > > (custom-set-faces > ;; custom-set-faces was added by Custom. > ;; If you edit it by hand, you could mess it up, so be careful. > ;; Your init file should contain only one such instance. > ;; If there is more than one, they won't work right. > '(default ((t (:stipple nil :background "grey92" :foreground "black" > :inverse-video nil :box nil :strike-through nil :overline nil :underline nil > :slant normal :weight normal :height 98 :width normal :foundry "outline" :family > "Courier New"))))) I'm afraid that's not enough of a recipe for me to reproduce the problem. On Ubuntu 16.04 x86-64 if I change my ~/.emacs file so that it contains just the abovementioned code, and then run the shell command 'src/emacs -q --eval "(set-face-attribute 'default nil :height 80)"', I get a *scratch* buffer where evaluating (setq F (face-attribute 'default :font (car (car (cdr (current-frame-configuration)))) 'default)) yields a font object F that prints as #, and (font-get F :user-spec) indeed yields "Ubuntu Mono 13" in emacs-25 whereas it yields nil in Emacs 24.5. OK, but what is the regression here? The display has the same (ugly) appearance in Emacs 24.5 that it does in emacs-25. And in both Emacs 24.5 and emacs-25 if I reapply .emacs the display changes to the same (nicer) appearance. The emacs-25 value of (font-get F :user-spec) is what was intended by commit 42707278 as part of a fix for Bug#5157, by the way. > My analysis so far is as follows: In ‘font-setting-change-default-font’ > the disjunct (frame-parameter f 'font-parameter) always evaluates to > nil here. Before your patch, the disjunct > > (or (font-get (face-attribute 'default :font f 'default) > :user-spec) > > always evaluated to nil. After your patch it returns "Monospace 11" and > ‘frame-font’ gets set to that and the frame's default font too. IIUC > the height of the default face gets set to that value too but a new > frame gets the value from my .emacs. As a consequence, customizing the > default face will present me different height values corresponding to > the frame where I start the customization from. That is awfully weird. I'm afraid I can't reproduce a problem from this informal description. Perhaps if you could say exactly which code to run.... That being said, does the attached experimental patch address the issue for you? Again, I'm not seriously proposing installing this, just trying to understand the problem.