bug#1562: 23.0.60; modify-frame-parameters in Emacs 23 for fonts

["Drew Adams" <drew.adams@oracle.com>]

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