modify-frame-parameters in Emacs 23 for fonts

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: modify-frame-parameters in Emacs 23 for fonts

[Drew Adams]

Resending -

----
From: Drew Adams Sent: Saturday, April 05, 2008 7:18 PM
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