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

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

[Drew Adams]

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

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

[Glenn Morris]

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

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

[Drew Adams]

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

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

[Jason Rumney]

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.

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

[Drew Adams]

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

bug#1562: marked as done (23.0.60; modify-frame-parameters in Emacs 23 for fonts)

[Emacs bug Tracking System]

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

modify-frame-parameters in Emacs 23 for fonts

[Drew Adams]

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?

RE: bug#119 acknowledged by developer (Closing fixed bugs)

[Drew Adams]

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)

Subject of closure notifications sent to submitters [Re: bug#119 acknowledged by developer (Closing fixed bugs)]

[Don Armstrong]

On Thu, 12 Jun 2008, Drew Adams wrote:
> 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.

No, what is needed in the subject line is an informative message which
tells you why the bug has been closed. Using close with the control
interface should not be done unless you've already sent a mail to the
bug submitter explaining that their bug has been closed.

The subject contains the subject of the message that actually caused
the bug to be closed, and explains what the message that it is sending
you is about, which it did.


Don Armstrong

-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

http://www.donarmstrong.com              http://rzlab.ucr.edu

RE: Subject of closure notifications sent to submitters [Re: bug#119acknowledged by developer (Closing fixed bugs)]

[Drew Adams]

> > 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.
> 
> No, what is needed in the subject line is an informative message which
> tells you why the bug has been closed. Using close with the control
> interface should not be done unless you've already sent a mail to the
> bug submitter explaining that their bug has been closed.
> 
> The subject contains the subject of the message that actually caused
> the bug to be closed, and explains what the message that it is sending
> you is about, which it did.

Well, what can I say? Such a subject line is useless to me. The only connection
it shows with the bug I filed is the bug number, and that is not the most
helpful for finding the thread of messages, including the original, that involve
the bug.

The status might be the most important thing to you, but to me, the most
important thing to see in the Subject line is, well, the original subject.

Guess we'll just have to agree to disagree about this one.

FWIW, any bug tracking system I've ever used sends mails that keep the original
bug title intact as the subject. Even when the original title does not
accurately describe the bug, it is kept (along with the bug number) as the bug
identifier, and that identifier is used in the Subject of all mails concerning
the bug.

Also, please at least add a link in the mail body to the original bug report in
a threaded list on a Web page. We should be able to just click a link in any
mail regarding a particular bug to get to the complete thread.

Re: Subject of closure notifications sent to submitters [Re: bug#119acknowledged by developer (Closing fixed bugs)]

[Don Armstrong]

On Thu, 12 Jun 2008, Drew Adams wrote:
> Well, what can I say? Such a subject line is useless to me. The only
> connection it shows with the bug I filed is the bug number, and that
> is not the most helpful for finding the thread of messages,
> including the original, that involve the bug.

That's a message which is sent to a submitter, which is outside of the
thread of the discussion of the bug in most cases. Furthermore, the
message you got sent comes from using close, which is deprecated
because it doesn't provide enough information to the submitter to see
exactly why their bug was closed. [I'm most likely going to remove it
in the future anyway, so people whouldn't get used to using it now.]
 
> FWIW, any bug tracking system I've ever used sends mails that keep
> the original bug title intact as the subject. Even when the original
> title does not accurately describe the bug, it is kept (along with
> the bug number) as the bug identifier, and that identifier is used
> in the Subject of all mails concerning the bug.

That's because most bug tracking systems don't use mail for everything
that they do, and the only subject they have is the original message.

> Also, please at least add a link in the mail body to the original
> bug report in a threaded list on a Web page. We should be able to
> just click a link in any mail regarding a particular bug to get to
> the complete thread.

It's in the footer of all messages sent out by the BTS (or at last,
should be; if it's not, bounce me a complete example off list.)


Don Armstrong

-- 
This can't be happening to me. I've got tenure.
 -- James Hynes _Publish and Perish_

http://www.donarmstrong.com              http://rzlab.ucr.edu

RE: Subject of closure notifications sent to submitters [Re:bug#119acknowledged by developer (Closing fixed bugs)]

[Drew Adams]

> > Well, what can I say? Such a subject line is useless to me. The only
> > connection it shows with the bug I filed is the bug number, and that
> > is not the most helpful for finding the thread of messages,
> > including the original, that involve the bug.
> 
> That's a message which is sent to a submitter, which is outside of the
> thread of the discussion of the bug in most cases. Furthermore, the
> message you got sent comes from using close, which is deprecated
> because it doesn't provide enough information to the submitter to see
> exactly why their bug was closed. [I'm most likely going to remove it
> in the future anyway, so people whouldn't get used to using it now.]
>  
> > FWIW, any bug tracking system I've ever used sends mails that keep
> > the original bug title intact as the subject. Even when the original
> > title does not accurately describe the bug, it is kept (along with
> > the bug number) as the bug identifier, and that identifier is used
> > in the Subject of all mails concerning the bug.
> 
> That's because most bug tracking systems don't use mail for everything
> that they do, and the only subject they have is the original message.
> 
> > Also, please at least add a link in the mail body to the original
> > bug report in a threaded list on a Web page. We should be able to
> > just click a link in any mail regarding a particular bug to get to
> > the complete thread.
> 
> It's in the footer of all messages sent out by the BTS (or at last,
> should be; if it's not, bounce me a complete example off list.)

Much of what you wrote doesn't seem to be about the message that I spoke of,
IIUC. For instance, there is no link in the footer of that message.

Anyway, I guess you're saying that such messages will no longer be sent out (?)
because you are deprecating "close" (whatever that is). If so, this discussion
is presumably moot.

Re: Subject of closure notifications sent to submitters [Re:bug#119acknowledged by developer (Closing fixed bugs)]

[Don Armstrong]

On Thu, 12 Jun 2008, Drew Adams wrote:
> Much of what you wrote doesn't seem to be about the message that I
> spoke of, IIUC. For instance, there is no link in the footer of that
> message.

It applies to all of the messages which are sent out from things which
aren't the control bot.

> Anyway, I guess you're saying that such messages will no longer be
> sent out (?) because you are deprecating "close" (whatever that is).
> If so, this discussion is presumably moot.

It's actually already deprecated; I'm going to remove it entirely.
 

Don Armstrong

-- 
Certainly the game is rigged. Don't let that stop you. If you don't
bet, you can't win.
 -- Robert Heinlein _Time Enough For Love_ p240

http://www.donarmstrong.com              http://rzlab.ucr.edu

bug#119: marked as done (modify-frame-parameters in Emacs 23 for fonts)

[Emacs bug Tracking System]

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

Processed: Closing fixed bugs

[Emacs bug Tracking System]

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)