* bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts @ 2008-12-13 19:02 ` Drew Adams 2008-12-13 20:46 ` Glenn Morris ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Drew Adams @ 2008-12-13 19:02 UTC (permalink / raw) To: emacs-pretest-bug [-- Attachment #1: Type: text/plain, Size: 2144 bytes --] See bug #119. Both I and Jason have sent followups to this bug, but they do not appear in the Outstanding bugs list, AFAICT. This bug is Outstanding. It was mistakenly put in the "Resolved" (closed?) list. The bug still exists. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-24 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' Below is the last mail I sent about this bug. Attached are other mails that seem to be missing from the bug tracker. -----Original Message----- From: Drew Adams Sent: Friday, November 28, 2008 2:36 PM To: 'Stephen Berman' Cc: 119@emacsbugs.donarmstrong.com Subject: bug#119: modify-frame-parameters in Emacs 23 for fonts > > This bug seems still not to be fixed, and I cannot even > > find it listed in the bugs database: > > http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacs. > > > > What is that status of this bug? Is there some other bugs > > page where this appears? > > On the above page you can find it by clicking on either of > the links in "See the _archived reports_ or _archived and > unarchived reports_", i.e., > http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?orderi > ng=normal;archive=1;package=emacs;repeatmerged=1 > or > http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?orderi ng=normal;archive=both;package=emacs;repeatmerged=1 > > Also, you can find it from http://emacsbugs.donarmstrong.com/ > by typing "119" in the textbox below "Find a bug by number:" and > clicking the "Find" button. 1. Ah, thank you. I'd propose that a search field be added also to this page: http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacs, and that search there be limited to bugs that are in the Emacs package. That page seems to be the main entry point for Emacs bugs. It makes sense to have a search field there, IMO. 2. I and Jason have sent followups to this bug that do not appear in the bug-report page (the archived bugs page cited above). What happened to them? I have attached them to this mail. [-- Attachment #2: Type: message/rfc822, Size: 6331 bytes --] [-- Attachment #2.1.1: Type: text/plain, Size: 532 bytes --] > > FYI - This bug appears to be fixed in the Emacs 23 pretest > > (22.2.91). > > It is not an Emacs 23 pretest. It is an Emacs 22.3 pretest, > which is why bugs that have only ever been apparent in the > trunk are not present in this pretest. Oh, darn. I guess that means that these problems still are in Emacs 23. And this also explains the "return" to the Emacs 22 icon that I noticed. Please then disregard all my mails from yesterday about Emacs 23 bugs that I thought had been fixed. Sorry for the confusion. [-- Attachment #2.1.2: Type: text/html, Size: 1226 bytes --] [-- Attachment #3: Type: message/rfc822, Size: 3018 bytes --] [-- Attachment #3.1.1: Type: text/plain, Size: 260 bytes --] Drew Adams wrote: > FYI - This bug appears to be fixed in the Emacs 23 pretest (22.2.91). > It is not an Emacs 23 pretest. It is an Emacs 22.3 pretest, which is why bugs that have only ever been apparent in the trunk are not present in this pretest. [-- Attachment #3.1.2: Type: text/html, Size: 814 bytes --] [-- Attachment #4: Type: message/rfc822, Size: 16630 bytes --] [-- Attachment #4.1.1: Type: text/plain, Size: 4083 bytes --] FYI - This bug appears to be fixed in the Emacs 23 pretest (22.2.91). Thanks very much. > From: Drew Adams Sent: Thursday, August 07, 2008 10:38 AM > > This bug is marked fixed, but it has not been fixed. > Jason marked it as fixed on 2008-05-08, with this note: > > I've marked this as fixed, since the bug reported will > be fixed when font-backend is merged. > I will not close it at this time though, as valid points > about documentation were raised. > > Then, on 2008-06-12, I received a mail saying that it was > closed. In any case, it is *not* fixed - I see the same > thing in this recent build: > > GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) > of 2008-08-01 on LENNART-69DE564 > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > configured using `configure --with-gcc (3.4) --no-opt --cflags > -Ic:/g/include -fno-crossjumping' > > There are two things that might be the problem: > > (1) `modify-frame-parameters' changes the `font' parameter behind your > back from the value you provide `modify-frame-parameters': > > (modify-frame-parameters frame > (list (cons 'font "-outline-Lucida Console-normal-normal-\ > normal-mono-15-*-*-*-c-*-iso8859-1"))) > > The `font' frame parameter is then: > > "-outline-Lucida Console-normal-normal-normal-mono-15-\ > *-*-*-c-*-fontset-auto8" > > IOW, iso8859-1 gets replaced by fontset-auto8. > > (2) `x-list-fonts' returns nil when passed such a font (i.e. with > fontset-auto8). > > This breaks my code. Though the frame and the font appear normal, > `x-list-fonts' does not recognize such a font. My code changes the > font name to use a different size (e.g. changes 15 to 14), but it > checks that `x-list-fonts' recognizes the font name before trying to > use it. And `x-list-fonts' does not recognize the name (with > "fontset-auto8") that `modify-frame-parameters' establishes behind the > scene. > > The font that I provide to `modify-frame-parameters' is recognized by > `x-list-fonts', and it has the same appearance, but it never appears > as the frame parameter in this context because > `modify-frame-parameters' substitutes a different name. > > > Below is the pertinent part of the original bug report. The symptom is > the same, but the font that `modify-frame-parameters' substitutes is > slightly different. > > Back in April, it substituted: > "-outline-lucida console-normal-roman-normal-mono-15-\ > *-*-*-*-*-fontset-startup" > > Now it substitutes: > "-outline-Lucida Console-normal-normal-normal-mono-15-\ > *-*-*-c-*-fontset-auto8" > > Neither is recognized by `x-list-fonts'. > > --------8<---------2008-04-05 report ------------------- > > (frame-parameter nil 'font) -> > "-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1" > > (modify-frame-parameters > nil > (list > (cons > 'font > "-*-Lucida Console-normal-r-*-*-15-*-96-96-c-*-iso8859-1"))) > > (frame-parameter nil 'font) -> > "-outline-lucida > console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup" > > What's that about? In Emacs 20, 21, and 22, the result is > just the font I > specified. > > I have code that zooms frames (font size). I change just the > point size in the > font spec, using `x-decompose-font-name' and > `x-compose-font-name'. I check that > the result is a legitimate font using `x-list-fonts'. If not, > I increase or > decrease the increment until I find the font that works with > the closest size. > > [Yes, I know there are other ways to adjust font size, but > I've found that this > method is flexible for users and provides certain benefits.] > > My code no longer works without change, because after one call to > `modify-frame-parameters' the font is no longer something > recognized by > `x-list-fonts'. I can comment out the part that iterates > until it finds a size > that works (recognized by `x-list-fonts'). That works, but > I'm still curious > about this. (Is there perhaps a bug in `x-list-fonts' or in > `modify-frame-parameters'?) [-- Attachment #4.1.2: Type: text/html, Size: 7935 bytes --] [-- Attachment #5: Type: message/rfc822, Size: 14503 bytes --] [-- Attachment #5.1.1: Type: text/plain, Size: 3702 bytes --] This bug is marked fixed, but it has not been fixed. Jason marked it as fixed on 2008-05-08, with this note: I've marked this as fixed, since the bug reported will be fixed when font-backend is merged. I will not close it at this time though, as valid points about documentation were raised. Then, on 2008-06-12, I received a mail saying that it was closed. In any case, it is *not* fixed - I see the same thing in this recent build: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-08-01 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' There are two things that might be the problem: (1) `modify-frame-parameters' changes the `font' parameter behind your back from the value you provide `modify-frame-parameters': (modify-frame-parameters frame (list (cons 'font "-outline-Lucida Console-normal-normal-\ normal-mono-15-*-*-*-c-*-iso8859-1"))) The `font' frame parameter is then: "-outline-Lucida Console-normal-normal-normal-mono-15-\ *-*-*-c-*-fontset-auto8" IOW, iso8859-1 gets replaced by fontset-auto8. (2) `x-list-fonts' returns nil when passed such a font (i.e. with fontset-auto8). This breaks my code. Though the frame and the font appear normal, `x-list-fonts' does not recognize such a font. My code changes the font name to use a different size (e.g. changes 15 to 14), but it checks that `x-list-fonts' recognizes the font name before trying to use it. And `x-list-fonts' does not recognize the name (with "fontset-auto8") that `modify-frame-parameters' establishes behind the scene. The font that I provide to `modify-frame-parameters' is recognized by `x-list-fonts', and it has the same appearance, but it never appears as the frame parameter in this context because `modify-frame-parameters' substitutes a different name. Below is the pertinent part of the original bug report. The symptom is the same, but the font that `modify-frame-parameters' substitutes is slightly different. Back in April, it substituted: "-outline-lucida console-normal-roman-normal-mono-15-\ *-*-*-*-*-fontset-startup" Now it substitutes: "-outline-Lucida Console-normal-normal-normal-mono-15-\ *-*-*-c-*-fontset-auto8" Neither is recognized by `x-list-fonts'. --------8<---------2008-04-05 report ------------------- (frame-parameter nil 'font) -> "-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1" (modify-frame-parameters nil (list (cons 'font "-*-Lucida Console-normal-r-*-*-15-*-96-96-c-*-iso8859-1"))) (frame-parameter nil 'font) -> "-outline-lucida console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup" What's that about? In Emacs 20, 21, and 22, the result is just the font I specified. I have code that zooms frames (font size). I change just the point size in the font spec, using `x-decompose-font-name' and `x-compose-font-name'. I check that the result is a legitimate font using `x-list-fonts'. If not, I increase or decrease the increment until I find the font that works with the closest size. [Yes, I know there are other ways to adjust font size, but I've found that this method is flexible for users and provides certain benefits.] My code no longer works without change, because after one call to `modify-frame-parameters' the font is no longer something recognized by `x-list-fonts'. I can comment out the part that iterates until it finds a size that works (recognized by `x-list-fonts'). That works, but I'm still curious about this. (Is there perhaps a bug in `x-list-fonts' or in `modify-frame-parameters'?) [-- Attachment #5.1.2: Type: text/html, Size: 6225 bytes --] [-- Attachment #6: Type: message/rfc822, Size: 6331 bytes --] [-- Attachment #6.1.1: Type: text/plain, Size: 532 bytes --] > > FYI - This bug appears to be fixed in the Emacs 23 pretest > > (22.2.91). > > It is not an Emacs 23 pretest. It is an Emacs 22.3 pretest, > which is why bugs that have only ever been apparent in the > trunk are not present in this pretest. Oh, darn. I guess that means that these problems still are in Emacs 23. And this also explains the "return" to the Emacs 22 icon that I noticed. Please then disregard all my mails from yesterday about Emacs 23 bugs that I thought had been fixed. Sorry for the confusion. [-- Attachment #6.1.2: Type: text/html, Size: 1226 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts 2008-12-13 19:02 ` bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts Drew Adams @ 2008-12-13 20:46 ` Glenn Morris 2008-12-13 21:21 ` Drew Adams 2008-12-14 14:48 ` Jason Rumney 2009-01-01 2:20 ` bug#1562: marked as done (23.0.60; modify-frame-parameters in Emacs 23 for fonts) Emacs bug Tracking System 2 siblings, 1 reply; 9+ messages in thread From: Glenn Morris @ 2008-12-13 20:46 UTC (permalink / raw) To: 1562 Please try to be concise. It seems your mail can be summarized as: "I still see bug 119". The 5 attachments would seem to consist of a misunderstanding about Emacs 22.3 not being Emacs 23.1. To address your off-topic comments, it would seem bugs cannot be modified when archived. (This is not the place to discuss the operation of the bug tracker.) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts 2008-12-13 20:46 ` Glenn Morris @ 2008-12-13 21:21 ` Drew Adams 0 siblings, 0 replies; 9+ messages in thread From: Drew Adams @ 2008-12-13 21:21 UTC (permalink / raw) To: 'Glenn Morris', 1562 > From: Glenn Morris Sent: Saturday, December 13, 2008 12:47 PM > Please try to be concise. It seems your mail can be summarized as: > > "I still see bug 119". Fine. I already sent mail saying that, and it didn't seem to show up. But if the message has now been successfully passed (by creating a new bug), then that's good. > The 5 attachments would seem to consist of a misunderstanding about > Emacs 22.3 not being Emacs 23.1. Yes. I included them to point out the problem of updates to the bug not getting recorded. You can ignore them, now that the message has been delivered. Sorry for that noise. > To address your off-topic comments, it would seem bugs cannot be > modified when archived. (This is not the place to discuss the > operation of the bug tracker.) I don't know what the problem was, but what you say makes sense. I hope this bug gets reopened and finds its place again among the Outstanding bugs. I will send email about the tracker problem to emacs-devel. Thx. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts 2008-12-13 19:02 ` bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts Drew Adams 2008-12-13 20:46 ` Glenn Morris @ 2008-12-14 14:48 ` Jason Rumney 2008-12-14 17:30 ` Drew Adams 2009-01-01 2:20 ` bug#1562: marked as done (23.0.60; modify-frame-parameters in Emacs 23 for fonts) Emacs bug Tracking System 2 siblings, 1 reply; 9+ messages in thread From: Jason Rumney @ 2008-12-14 14:48 UTC (permalink / raw) To: Drew Adams, 1562; +Cc: emacs-pretest-bug Drew Adams wrote: > > There are two things that might be the problem: > > (1) `modify-frame-parameters' changes the `font' parameter behind your > back from the value you provide `modify-frame-parameters': > > (modify-frame-parameters frame > (list (cons 'font "-outline-Lucida Console-normal-normal-\ > normal-mono-15-*-*-*-c-*-iso8859-1"))) > > The `font' frame parameter is then: > > "-outline-Lucida Console-normal-normal-normal-mono-15-\ > *-*-*-c-*-fontset-auto8" > > IOW, iso8859-1 gets replaced by fontset-auto8. > I don't see this. Please try with emacs -Q. > (2) `x-list-fonts' returns nil when passed such a font (i.e. with > fontset-auto8). > Not a bug. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts 2008-12-14 14:48 ` Jason Rumney @ 2008-12-14 17:30 ` Drew Adams 0 siblings, 0 replies; 9+ messages in thread From: Drew Adams @ 2008-12-14 17:30 UTC (permalink / raw) To: 'Jason Rumney', 1562; +Cc: emacs-pretest-bug [-- Attachment #1: Type: text/plain, Size: 2905 bytes --] > > (1) `modify-frame-parameters' changes the `font' parameter > > behind your back from the value you provide > > `modify-frame-parameters': > > > > (modify-frame-parameters frame > > (list (cons 'font "-outline-Lucida Console-normal-normal-\ > > normal-mono-15-*-*-*-c-*-iso8859-1"))) > > > > The `font' frame parameter is then: > > > > "-outline-Lucida Console-normal-normal-normal-mono-15-\ > > *-*-*-c-*-fontset-auto8" > > > > IOW, iso8859-1 gets replaced by fontset-auto8. > > I don't see this. Please try with emacs -Q. See attached file, bug-zoom.el. emacs -Q, then load the file or eval it a sexp at a time if you want to see the initial font name etc. After loading, (frame-parameter nil 'font) gives "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1" Then do `C-u 5 M-x enlarge-font'. (frame-parameter nil 'font) gives "-outline-Lucida Console-normal-normal-normal-mono-19-*-*-*-c-*-iso8859-1" which is correct. Then do `C-u -5 M-x enlarge-font'. (frame-parameter nil 'font) gives "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-fontset-auto1" which is NOT correct. The code calls `modify-frame-parameters' with the same 14-point font name that was returned initially, and which ends in "-iso8859-1", not "-fontset-auto1". But that's not what the `font' parameter value is after the `modify-frame-parameters' call. `M-x debug-on-entry enlarge-font', and you will see, just after this call (notice that the font name passed as argument is correct): Debugger entered--returning value: nil modify-frame-parameters(#<frame emacs@DRADAMS-LAP1 0x2acf600> ((font . "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1"))) that (frame-parameter nil 'font) gives "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-fontset-auto1" which is wrong. (I also tried using `copy-sequence' to ensure that the string passed is a new one etc. No improvement.) Initially, I thought perhaps it had something to do with the call to `query-fontset' in the commented-out piece of code in `enlarged-font-name', since `query-fontset' returns a string with "-fontset-auto1" at the end. But the bug remains, even with that code commented out. Note too that over time, "-fontset-auto1" becomes "-fontset-auto2", and so on. The bug seems to be in `modify-frame-parameters'. FWIW, let me be clear why I would like this bug fixed. While waiting for the fix, I hacked the code for Emacs 23 to just modify the :height attribute for the `default' face. That is what most people do, to zoom a frame. That does not give as many font/frame size possibilities as my code does - it is not as flexible. So yes, I know there is a rudimentary workaround, but I would like this code to work again, as it does in Emacs 20, 21, and 22. It doesn't seem right that `modify-frame-parameters' modifies a frame differently from what you tell it to do. [-- Attachment #2: bug-zoom.el --] [-- Type: application/octet-stream, Size: 1958 bytes --] (modify-frame-parameters nil (list (cons 'font "-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1"))) (frame-parameter nil 'font) (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 100)) (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))) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#1562: marked as done (23.0.60; modify-frame-parameters in Emacs 23 for fonts) 2008-12-13 19:02 ` bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts Drew Adams 2008-12-13 20:46 ` Glenn Morris 2008-12-14 14:48 ` Jason Rumney @ 2009-01-01 2:20 ` Emacs bug Tracking System 2 siblings, 0 replies; 9+ messages in thread From: Emacs bug Tracking System @ 2009-01-01 2:20 UTC (permalink / raw) To: Jason Rumney [-- Attachment #1: Type: text/plain, Size: 900 bytes --] Your message dated Thu, 01 Jan 2009 10:10:49 +0800 with message-id <495C2629.40504@gnu.org> and subject line Re: bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts has caused the Emacs bug report #1562, regarding 23.0.60; modify-frame-parameters in Emacs 23 for fonts to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 1562: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1562 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 52739 bytes --] [-- Attachment #2.1.1: Type: text/plain, Size: 2144 bytes --] See bug #119. Both I and Jason have sent followups to this bug, but they do not appear in the Outstanding bugs list, AFAICT. This bug is Outstanding. It was mistakenly put in the "Resolved" (closed?) list. The bug still exists. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-24 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' Below is the last mail I sent about this bug. Attached are other mails that seem to be missing from the bug tracker. -----Original Message----- From: Drew Adams Sent: Friday, November 28, 2008 2:36 PM To: 'Stephen Berman' Cc: 119@emacsbugs.donarmstrong.com Subject: bug#119: modify-frame-parameters in Emacs 23 for fonts > > This bug seems still not to be fixed, and I cannot even > > find it listed in the bugs database: > > http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacs. > > > > What is that status of this bug? Is there some other bugs > > page where this appears? > > On the above page you can find it by clicking on either of > the links in "See the _archived reports_ or _archived and > unarchived reports_", i.e., > http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?orderi > ng=normal;archive=1;package=emacs;repeatmerged=1 > or > http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?orderi ng=normal;archive=both;package=emacs;repeatmerged=1 > > Also, you can find it from http://emacsbugs.donarmstrong.com/ > by typing "119" in the textbox below "Find a bug by number:" and > clicking the "Find" button. 1. Ah, thank you. I'd propose that a search field be added also to this page: http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacs, and that search there be limited to bugs that are in the Emacs package. That page seems to be the main entry point for Emacs bugs. It makes sense to have a search field there, IMO. 2. I and Jason have sent followups to this bug that do not appear in the bug-report page (the archived bugs page cited above). What happened to them? I have attached them to this mail. [-- Attachment #2.1.2: Type: message/rfc822, Size: 6331 bytes --] [-- Attachment #2.1.2.1.1: Type: text/plain, Size: 532 bytes --] > > FYI - This bug appears to be fixed in the Emacs 23 pretest > > (22.2.91). > > It is not an Emacs 23 pretest. It is an Emacs 22.3 pretest, > which is why bugs that have only ever been apparent in the > trunk are not present in this pretest. Oh, darn. I guess that means that these problems still are in Emacs 23. And this also explains the "return" to the Emacs 22 icon that I noticed. Please then disregard all my mails from yesterday about Emacs 23 bugs that I thought had been fixed. Sorry for the confusion. [-- Attachment #2.1.2.1.2: Type: text/html, Size: 1226 bytes --] [-- Attachment #2.1.3: Type: message/rfc822, Size: 3018 bytes --] [-- Attachment #2.1.3.1.1: Type: text/plain, Size: 260 bytes --] Drew Adams wrote: > FYI - This bug appears to be fixed in the Emacs 23 pretest (22.2.91). > It is not an Emacs 23 pretest. It is an Emacs 22.3 pretest, which is why bugs that have only ever been apparent in the trunk are not present in this pretest. [-- Attachment #2.1.3.1.2: Type: text/html, Size: 814 bytes --] [-- Attachment #2.1.4: Type: message/rfc822, Size: 16630 bytes --] [-- Attachment #2.1.4.1.1: Type: text/plain, Size: 4083 bytes --] FYI - This bug appears to be fixed in the Emacs 23 pretest (22.2.91). Thanks very much. > From: Drew Adams Sent: Thursday, August 07, 2008 10:38 AM > > This bug is marked fixed, but it has not been fixed. > Jason marked it as fixed on 2008-05-08, with this note: > > I've marked this as fixed, since the bug reported will > be fixed when font-backend is merged. > I will not close it at this time though, as valid points > about documentation were raised. > > Then, on 2008-06-12, I received a mail saying that it was > closed. In any case, it is *not* fixed - I see the same > thing in this recent build: > > GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) > of 2008-08-01 on LENNART-69DE564 > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > configured using `configure --with-gcc (3.4) --no-opt --cflags > -Ic:/g/include -fno-crossjumping' > > There are two things that might be the problem: > > (1) `modify-frame-parameters' changes the `font' parameter behind your > back from the value you provide `modify-frame-parameters': > > (modify-frame-parameters frame > (list (cons 'font "-outline-Lucida Console-normal-normal-\ > normal-mono-15-*-*-*-c-*-iso8859-1"))) > > The `font' frame parameter is then: > > "-outline-Lucida Console-normal-normal-normal-mono-15-\ > *-*-*-c-*-fontset-auto8" > > IOW, iso8859-1 gets replaced by fontset-auto8. > > (2) `x-list-fonts' returns nil when passed such a font (i.e. with > fontset-auto8). > > This breaks my code. Though the frame and the font appear normal, > `x-list-fonts' does not recognize such a font. My code changes the > font name to use a different size (e.g. changes 15 to 14), but it > checks that `x-list-fonts' recognizes the font name before trying to > use it. And `x-list-fonts' does not recognize the name (with > "fontset-auto8") that `modify-frame-parameters' establishes behind the > scene. > > The font that I provide to `modify-frame-parameters' is recognized by > `x-list-fonts', and it has the same appearance, but it never appears > as the frame parameter in this context because > `modify-frame-parameters' substitutes a different name. > > > Below is the pertinent part of the original bug report. The symptom is > the same, but the font that `modify-frame-parameters' substitutes is > slightly different. > > Back in April, it substituted: > "-outline-lucida console-normal-roman-normal-mono-15-\ > *-*-*-*-*-fontset-startup" > > Now it substitutes: > "-outline-Lucida Console-normal-normal-normal-mono-15-\ > *-*-*-c-*-fontset-auto8" > > Neither is recognized by `x-list-fonts'. > > --------8<---------2008-04-05 report ------------------- > > (frame-parameter nil 'font) -> > "-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1" > > (modify-frame-parameters > nil > (list > (cons > 'font > "-*-Lucida Console-normal-r-*-*-15-*-96-96-c-*-iso8859-1"))) > > (frame-parameter nil 'font) -> > "-outline-lucida > console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup" > > What's that about? In Emacs 20, 21, and 22, the result is > just the font I > specified. > > I have code that zooms frames (font size). I change just the > point size in the > font spec, using `x-decompose-font-name' and > `x-compose-font-name'. I check that > the result is a legitimate font using `x-list-fonts'. If not, > I increase or > decrease the increment until I find the font that works with > the closest size. > > [Yes, I know there are other ways to adjust font size, but > I've found that this > method is flexible for users and provides certain benefits.] > > My code no longer works without change, because after one call to > `modify-frame-parameters' the font is no longer something > recognized by > `x-list-fonts'. I can comment out the part that iterates > until it finds a size > that works (recognized by `x-list-fonts'). That works, but > I'm still curious > about this. (Is there perhaps a bug in `x-list-fonts' or in > `modify-frame-parameters'?) [-- Attachment #2.1.4.1.2: Type: text/html, Size: 7935 bytes --] [-- Attachment #2.1.5: Type: message/rfc822, Size: 14503 bytes --] [-- Attachment #2.1.5.1.1: Type: text/plain, Size: 3702 bytes --] This bug is marked fixed, but it has not been fixed. Jason marked it as fixed on 2008-05-08, with this note: I've marked this as fixed, since the bug reported will be fixed when font-backend is merged. I will not close it at this time though, as valid points about documentation were raised. Then, on 2008-06-12, I received a mail saying that it was closed. In any case, it is *not* fixed - I see the same thing in this recent build: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-08-01 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' There are two things that might be the problem: (1) `modify-frame-parameters' changes the `font' parameter behind your back from the value you provide `modify-frame-parameters': (modify-frame-parameters frame (list (cons 'font "-outline-Lucida Console-normal-normal-\ normal-mono-15-*-*-*-c-*-iso8859-1"))) The `font' frame parameter is then: "-outline-Lucida Console-normal-normal-normal-mono-15-\ *-*-*-c-*-fontset-auto8" IOW, iso8859-1 gets replaced by fontset-auto8. (2) `x-list-fonts' returns nil when passed such a font (i.e. with fontset-auto8). This breaks my code. Though the frame and the font appear normal, `x-list-fonts' does not recognize such a font. My code changes the font name to use a different size (e.g. changes 15 to 14), but it checks that `x-list-fonts' recognizes the font name before trying to use it. And `x-list-fonts' does not recognize the name (with "fontset-auto8") that `modify-frame-parameters' establishes behind the scene. The font that I provide to `modify-frame-parameters' is recognized by `x-list-fonts', and it has the same appearance, but it never appears as the frame parameter in this context because `modify-frame-parameters' substitutes a different name. Below is the pertinent part of the original bug report. The symptom is the same, but the font that `modify-frame-parameters' substitutes is slightly different. Back in April, it substituted: "-outline-lucida console-normal-roman-normal-mono-15-\ *-*-*-*-*-fontset-startup" Now it substitutes: "-outline-Lucida Console-normal-normal-normal-mono-15-\ *-*-*-c-*-fontset-auto8" Neither is recognized by `x-list-fonts'. --------8<---------2008-04-05 report ------------------- (frame-parameter nil 'font) -> "-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1" (modify-frame-parameters nil (list (cons 'font "-*-Lucida Console-normal-r-*-*-15-*-96-96-c-*-iso8859-1"))) (frame-parameter nil 'font) -> "-outline-lucida console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup" What's that about? In Emacs 20, 21, and 22, the result is just the font I specified. I have code that zooms frames (font size). I change just the point size in the font spec, using `x-decompose-font-name' and `x-compose-font-name'. I check that the result is a legitimate font using `x-list-fonts'. If not, I increase or decrease the increment until I find the font that works with the closest size. [Yes, I know there are other ways to adjust font size, but I've found that this method is flexible for users and provides certain benefits.] My code no longer works without change, because after one call to `modify-frame-parameters' the font is no longer something recognized by `x-list-fonts'. I can comment out the part that iterates until it finds a size that works (recognized by `x-list-fonts'). That works, but I'm still curious about this. (Is there perhaps a bug in `x-list-fonts' or in `modify-frame-parameters'?) [-- Attachment #2.1.5.1.2: Type: text/html, Size: 6225 bytes --] [-- Attachment #2.1.6: Type: message/rfc822, Size: 6331 bytes --] [-- Attachment #2.1.6.1.1: Type: text/plain, Size: 532 bytes --] > > FYI - This bug appears to be fixed in the Emacs 23 pretest > > (22.2.91). > > It is not an Emacs 23 pretest. It is an Emacs 22.3 pretest, > which is why bugs that have only ever been apparent in the > trunk are not present in this pretest. Oh, darn. I guess that means that these problems still are in Emacs 23. And this also explains the "return" to the Emacs 22 icon that I noticed. Please then disregard all my mails from yesterday about Emacs 23 bugs that I thought had been fixed. Sorry for the confusion. [-- Attachment #2.1.6.1.2: Type: text/html, Size: 1226 bytes --] [-- Attachment #3: Type: message/rfc822, Size: 3379 bytes --] From: Jason Rumney <jasonr@gnu.org> To: Drew Adams <drew.adams@oracle.com> Cc: 1562-done@emacsbugs.donarmstrong.com Subject: Re: bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts Date: Thu, 01 Jan 2009 10:10:49 +0800 Message-ID: <495C2629.40504@gnu.org> Drew Adams wrote: > After loading, (frame-parameter nil 'font) gives > "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1" > > Then do `C-u 5 M-x enlarge-font'. (frame-parameter nil 'font) gives > "-outline-Lucida Console-normal-normal-normal-mono-19-*-*-*-c-*-iso8859-1" > which is correct. > > Then do `C-u -5 M-x enlarge-font'. (frame-parameter nil 'font) gives > "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-fontset-auto1" > which is NOT correct. > I have fixed this now, x_new_font in w32term.c had not been updated in line with xterm.c. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <4850FC42.7060305@gnu.org>]
* Processed: Closing fixed bugs [not found] <4850FC42.7060305@gnu.org> @ 2008-06-12 10:45 ` Emacs bug Tracking System [not found] ` <000201c8978c$69739fe0$0200a8c0@us.oracle.com> 1 sibling, 0 replies; 9+ messages in thread From: Emacs bug Tracking System @ 2008-06-12 10:45 UTC (permalink / raw) To: Jason Rumney; +Cc: #119, Emacs Bugs Processing commands for control@emacsbugs.donarmstrong.com: > close 119 bug#119: modify-frame-parameters in Emacs 23 for fonts 'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing. bug closed, send any further explanations to "Drew Adams" <drew.adams@oracle.com> > fixed 201 23.0.60 bug#201: Setting default face font on W32 bug marked as fixed in version 23.0.60. > found 201 22.2 bug#201: Setting default face font on W32 bug marked as found in version 22.2. > thanks Stopping processing here. Please contact me if you need assistance. Don Armstrong (administrator, Emacs bugs database) ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <000201c8978c$69739fe0$0200a8c0@us.oracle.com>]
[parent not found: <handler.119.C.121326703431170.notifdonectrl.0@emacsbugs.donarmstrong.com>]
* RE: bug#119 acknowledged by developer (Closing fixed bugs) [not found] ` <handler.119.C.121326703431170.notifdonectrl.0@emacsbugs.donarmstrong.com> @ 2008-06-12 14:50 ` Drew Adams 0 siblings, 0 replies; 9+ messages in thread From: Drew Adams @ 2008-06-12 14:50 UTC (permalink / raw) To: 119; +Cc: bug-gnu-emacs, emacs-devel Please add the original Subject to the Subject line. We shouldn't have to open the mail and search its body to find what bug #119 is (in this case, "modify-frame-parameters in Emacs 23 for fonts". The status "acknowledged by developer (Closing fixed bugs)" is not needed in the Subject line. What is needed is the original Subject. Thx. > From: Emacs bug Tracking System Sent: Thursday, June 12, 2008 3:45 AM > Subject: bug#119 acknowledged by developer (Closing fixed bugs) > > This is an automatic notification regarding your bug report > #119: modify-frame-parameters in Emacs 23 for fonts, > which was filed against the emacs package. > > It has been marked as closed by one of the developers, namely > Jason Rumney <jasonr@gnu.org>. > > You should be hearing from them with a substantive response shortly, > in case you haven't already. If not, please contact them directly. > > Don Armstrong > (administrator, Emacs bugs database) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#119: marked as done (modify-frame-parameters in Emacs 23 for fonts) [not found] ` <000201c8978c$69739fe0$0200a8c0@us.oracle.com> [not found] ` <handler.119.C.121326703431170.notifdonectrl.0@emacsbugs.donarmstrong.com> @ 2009-01-01 2:20 ` Emacs bug Tracking System 1 sibling, 0 replies; 9+ messages in thread From: Emacs bug Tracking System @ 2009-01-01 2:20 UTC (permalink / raw) To: Jason Rumney [-- Attachment #1: Type: text/plain, Size: 891 bytes --] Your message dated Thu, 01 Jan 2009 10:10:49 +0800 with message-id <495C2629.40504@gnu.org> and subject line Re: bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts has caused the Emacs bug report #1562, regarding modify-frame-parameters in Emacs 23 for fonts to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 1562: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1562 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 8038 bytes --] From: "Drew Adams" <drew.adams@oracle.com> To: <emacs-devel@gnu.org> Subject: modify-frame-parameters in Emacs 23 for fonts Date: Sat, 5 Apr 2008 19:17:49 -0700 Message-ID: <000201c8978c$69739fe0$0200a8c0@us.oracle.com> I'm using this: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-04-04 on LENNART-69DE564. (frame-parameter nil 'font) -> "-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1" (modify-frame-parameters nil (list (cons 'font "-*-Lucida Console-normal-r-*-*-15-*-96-96-c-*-iso8859-1"))) (frame-parameter nil 'font) -> "-outline-lucida console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup" What's that about? In Emacs 20, 21, and 22, the result is just the font I specified. I have code that zooms frames (font size). I change just the point size in the font spec, using `x-decompose-font-name' and `x-compose-font-name'. I check that the result is a legitimate font using `x-list-fonts'. If not, I increase or decrease the increment until I find the font that works with the closest size. [Yes, I know there are other ways to adjust font size, but I've found that this method is flexible for users and provides certain benefits.] My code no longer works without change, because after one call to `modify-frame-parameters' the font is no longer something recognized by `x-list-fonts'. I can comment out the part that iterates until it finds a size that works (recognized by `x-list-fonts'). That works, but I'm still curious about this. (Is there perhaps a bug in `x-list-fonts' or in `modify-frame-parameters'?) I couldn't find anything that helps me understand this in the manuals. I haven't tried to dig through any code. Can someone light my lantern about this? I looked in NEWS also, and saw something about a font backend (I didn't follow the threads here about that). But I couldn't find anything in the Elisp or Emacs manuals about "backend" or "back?end", except for version-control back ends. A NEWS entry also says this: "the configure option `--disable-font-backend' (also available as a run-time option)." But I can't find any such option (variable) with `backend' or `back-end' in its name (except for `vc-handled-backends'). I see, in both NEWS and in my frames, a parameter named `font-backend', but I have no idea what it is. For me, its value is (font-backend uniscribe gdi), FWIW. Finding the function `fontp' mentioned in NEWS (but not in the Elisp manual, alas), I also tried that in place of `x-list-fonts'. But it too does not indicate that "-outline-lucida console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup" is a legitimate font. I see font terms in NEWS that I don't see explained in the manual: font-entity object, font-spec object, font property value. I also see functions mentioned, such as `font-font', that my Emacs does not recognize. Are they perhaps only for X? This whole area is a murky one, for me. Do others feel that this stuff is explained well enough - in either the manuals or NEWS? Am I the only dummy about this? Is this is a hidden subject for some secret club? ;-) If not, how about some explanation? [-- Attachment #3: Type: message/rfc822, Size: 3379 bytes --] From: Jason Rumney <jasonr@gnu.org> To: Drew Adams <drew.adams@oracle.com> Cc: 1562-done@emacsbugs.donarmstrong.com Subject: Re: bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts Date: Thu, 01 Jan 2009 10:10:49 +0800 Message-ID: <495C2629.40504@gnu.org> Drew Adams wrote: > After loading, (frame-parameter nil 'font) gives > "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1" > > Then do `C-u 5 M-x enlarge-font'. (frame-parameter nil 'font) gives > "-outline-Lucida Console-normal-normal-normal-mono-19-*-*-*-c-*-iso8859-1" > which is correct. > > Then do `C-u -5 M-x enlarge-font'. (frame-parameter nil 'font) gives > "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-fontset-auto1" > which is NOT correct. > I have fixed this now, x_new_font in w32term.c had not been updated in line with xterm.c. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-01-01 2:20 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <495C2629.40504@gnu.org>
2008-12-13 19:02 ` bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts Drew Adams
2008-12-13 20:46 ` Glenn Morris
2008-12-13 21:21 ` Drew Adams
2008-12-14 14:48 ` Jason Rumney
2008-12-14 17:30 ` Drew Adams
2009-01-01 2:20 ` bug#1562: marked as done (23.0.60; modify-frame-parameters in Emacs 23 for fonts) Emacs bug Tracking System
[not found] <4850FC42.7060305@gnu.org>
2008-06-12 10:45 ` Processed: Closing fixed bugs Emacs bug Tracking System
[not found] ` <000201c8978c$69739fe0$0200a8c0@us.oracle.com>
[not found] ` <handler.119.C.121326703431170.notifdonectrl.0@emacsbugs.donarmstrong.com>
2008-06-12 14:50 ` bug#119 acknowledged by developer (Closing fixed bugs) Drew Adams
2009-01-01 2:20 ` bug#119: marked as done (modify-frame-parameters in Emacs 23 for fonts) Emacs bug Tracking System
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).