Re: recent emacs font problems?

Re: recent emacs font problems?

[Jan D.]

Hello.

I found out why changing font isn't working.  This change did it:

@@ -6603,7 +6604,9 @@
        frame_font = Fassq (Qfont, f->param_alist);
        xassert (CONSP (frame_font) && STRINGP (XCDR (frame_font)));
        frame_font = XCDR (frame_font);
-      set_lface_from_font_name (f, lface, frame_font, 1, 1);
+      /* Specify 0 for FORCE_P here, so that we don't override
+        a :family attribute specified for `default' for new frames.  */
+      set_lface_from_font_name (f, lface, frame_font, 0, 1);
      }
  #endif /* HAVE_WINDOW_SYSTEM */

2003-05-19  Richard M. Stallman  <rms@gnu.org>

         * xfaces.c (Finternal_set_lisp_face_attribute): Handle Qunspecified
         as value for QCfont attribute.
         (realize_default_face): lface should already exist; crash if not.
         Specify 0 for FORCE_P when calling set_lface_from_font_name.


The problem is that if FORCE_P is 0, all other attributes of the font won't be 
set unless they are unspecified in the default face.  For exampel size.  So if 
you have a default face font which is fully specified (no undefined parts) no 
font change will happen.

I cant really grasp the problem that lead to this change from the comment 
above, so if anyone can describe a case for the original problem, I can try and 
make this work.

	Jan D.

Re: recent emacs font problems?

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> I cant really grasp the problem that lead to this change from the
> comment above, so if anyone can describe a case for the original
> problem, I can try and make this work.


Here is what RMS said about the exact same fix some days ago; please
read the previous articles in this thread for a discussion on this
subject:

RMS> That is not correct.  It would bring back a bug I fixed recently.  I
RMS> think it was the following bug.


Date: Thu, 15 May 2003 09:59:01 +0200 (CEST)
From: Klaus Straubinger <KSNetz@Arcor.DE>
To: bug-gnu-emacs@gnu.org

If the font family of the default face is changed with
(set-face-attribute 'default nil :family "fixed")
then this does not change the face's font for subsequent frames, as can
be seen with the evaluation of (face-font 'default) in the first frame
and in a second, created with C-x 5 2, respectively.

I found that that call to set_lface_from_font_name was
clobbering the family that had come from the new-frame default.



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: recent emacs font problems?

[Jan D.]

> Here is what RMS said about the exact same fix some days ago; please
> read the previous articles in this thread for a discussion on this
> subject:
>
> RMS> That is not correct.  It would bring back a bug I fixed recently. 
>  I
> RMS> think it was the following bug.
>
>
> Date: Thu, 15 May 2003 09:59:01 +0200 (CEST)
> From: Klaus Straubinger <KSNetz@Arcor.DE>
> To: bug-gnu-emacs@gnu.org
>
> If the font family of the default face is changed with
> (set-face-attribute 'default nil :family "fixed")
> then this does not change the face's font for subsequent frames, as can
> be seen with the evaluation of (face-font 'default) in the first frame
> and in a second, created with C-x 5 2, respectively.

Thank you.  However, I still can't understand how things are supposed to
work.  In my .Xdefaults I set default font to courier-14.  Now if I
do (set-face-attribute 'default nil :family "fixed"), shall new frames
get courier-14 or fixed-14?  Currently they get fixed-14 but with the
font metrics of courier-14, so the frame is not 80 characters wide, but
more like 87 characters.

If I select courier 12 from the shift-down-1 menu, shall I get 
courier-12
or fixed-12?  Currently I get fixed-12 (with courier-12 font metrics).

	Jan D.

Re: recent emacs font problems?

[Richard Stallman]

    Thank you.  However, I still can't understand how things are supposed to
    work.  In my .Xdefaults I set default font to courier-14.  Now if I
    do (set-face-attribute 'default nil :family "fixed"), shall new frames
    get courier-14 or fixed-14?

The set-face-attribute call should certainly override the X resource.
So the family must be "fixed".

      Currently they get fixed-14 but with the
    font metrics of courier-14,

I am not completely sure what that means.  Do you mean that Emacs
chooses the font fixed-14 but uses some data taken from the wrong
font?  That is clearly a bug.  Whichever font is chosen, Emacs
should use it consistently.

    If I select courier 12 from the shift-down-1 menu, shall I get 
    courier-12
    or fixed-12?  Currently I get fixed-12 (with courier-12 font metrics).

This should select courier 12, the font that you chose.

Re: recent emacs font problems?

[Jan D.]

>     Thank you.  However, I still can't understand how things are 
> supposed to
>     work.  In my .Xdefaults I set default font to courier-14.  Now if I
>     do (set-face-attribute 'default nil :family "fixed"), shall new 
> frames
>     get courier-14 or fixed-14?
>
> The set-face-attribute call should certainly override the X resource.
> So the family must be "fixed".

Okay.

>
>       Currently they get fixed-14 but with the
>     font metrics of courier-14,
>
> I am not completely sure what that means.  Do you mean that Emacs
> chooses the font fixed-14 but uses some data taken from the wrong
> font?  That is clearly a bug.  Whichever font is chosen, Emacs
> should use it consistently.

It means that when Emacs calculates pixel width and height of the new 
frame
it uses the width and height of courier-14, but then renders text with
fixed-14.  I think the default face for the new frame has not been 
realized
when this calculation occurs.

>
>     If I select courier 12 from the shift-down-1 menu, shall I get
>     courier-12
>     or fixed-12?  Currently I get fixed-12 (with courier-12 font 
> metrics).
>
> This should select courier 12, the font that you chose.

Thanks,

	Jan D.

Re: recent emacs font problems?

[Richard Stallman]

    It means that when Emacs calculates pixel width and height of the new 
    frame
    it uses the width and height of courier-14, but then renders text with
    fixed-14.  I think the default face for the new frame has not been 
    realized
    when this calculation occurs.

That seems to be a bug.

Re: recent emacs font problems?

[Jan D.]

Hello.

I have checked in a fix that solves the original problem.  I have only
tested under GNU/Linux and Mac OSX, so if anyone with access to MS
Windows could try it, we can see if it works there.  I don't use 
fontsets,
so I haven't tested that.

There is one bug I know of.  When making a new frame, the frame size is 
determined from the default font, not from the default face.  So if you
have a default font size 12, and default face with size 14, the frame
will be sized with the 12 size.  It seems to have been like this for a 
long
time (21.1 at least).  I know the root of the problem (default face
is realized after the frame is created), but not the fix yet.

	Jan D.

Re: recent emacs font problems?

[Sam Steingold]

> * In message <B152633B-A81D-11D7-B65F-00039363E640@swipnet.se>
> * On the subject of "Re: recent emacs font problems?"
> * Sent on Thu, 26 Jun 2003 23:32:31 +0200
> * Honorable "Jan D." <jan.h.d@swipnet.se> writes:
>
> so if anyone with access to MS Windows could try it, we can see if it
> works there.

I would love to, but emacs does not link under msvc:

        link -out:obj-spd/i386/temacs.bin -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj   -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -debug:full -debugtype:both -pdb:obj-spd/i386\temacs.pdb -machine:i386 -subsystem:console -entry:_start -map:obj-spd/i386\temacs.map -profile obj-spd/i386/firstfile.obj obj-spd/i386/emacs.res obj-spd/i386/temacs0.lib     obj-spd/i386/temacs1.lib        obj-spd/i386/temacw32.lib       obj-spd/i386/lastfile.lib       winmm.lib     advapi32.lib      gdi32.lib       comdlg32.lib    user32.lib      mpr.lib                 shell32.lib     libc.lib
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

libc.lib(strftime.obj) : error LNK2005: _strftime already defined in temacs1.lib(strftime.obj)
obj-spd/i386/temacs.bin : fatal error LNK1169: one or more multiply defined symbols found
NMAKE : fatal error U1077: 'link' : return code '0x491'
Stop.
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio\VC98\BIN\nmake.exe"' : return code '0x2'
Stop.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat9 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
The only substitute for good manners is fast reflexes.

Re: recent emacs font problems?

[David Abrahams]

Sam Steingold <sds@gnu.org> writes:

>> * In message <B152633B-A81D-11D7-B65F-00039363E640@swipnet.se>
>> * On the subject of "Re: recent emacs font problems?"
>> * Sent on Thu, 26 Jun 2003 23:32:31 +0200
>> * Honorable "Jan D." <jan.h.d@swipnet.se> writes:
>>
>> so if anyone with access to MS Windows could try it, we can see if it
>> works there.
>
> I would love to, but emacs does not link under msvc:
>
>         link -out:obj-spd/i386/temacs.bin -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj   -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -debug:full -debugtype:both -pdb:obj-spd/i386\temacs.pdb -machine:i386 -subsystem:console -entry:_start -map:obj-spd/i386\temacs.map -profile obj-spd/i386/firstfile.obj obj-spd/i386/emacs.res obj-spd/i386/temacs0.lib     obj-spd/i386/temacs1.lib        obj-spd/i386/temacw32.lib       obj-spd/i386/lastfile.lib       winmm.lib     advapi32.lib      gdi32.lib       comdlg32.lib    user32.lib      mpr.lib                 shell32.lib     libc.lib
> Microsoft (R) Incremental Linker Version 6.00.8447
> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
>
> libc.lib(strftime.obj) : error LNK2005: _strftime already defined in temacs1.lib(strftime.obj)
> obj-spd/i386/temacs.bin : fatal error LNK1169: one or more multiply defined symbols found
> NMAKE : fatal error U1077: 'link' : return code '0x491'
> Stop.
> NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio\VC98\BIN\nmake.exe"' : return code '0x2'
> Stop.
>
> -- 
> Sam Steingold (http://www.podval.org/~sds) running RedHat9 GNU/Linux
> <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
> The only substitute for good manners is fast reflexes.

I would love to also, because as you can see from scanning the
archives I have been experiencing font-related crashes on Windows for
some time now.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: recent emacs font problems?

[Jason Rumney]

David Abrahams <dave@boost-consulting.com> writes:

> Sam Steingold <sds@gnu.org> writes:
> 
> >> * Honorable "Jan D." <jan.h.d@swipnet.se> writes:
> >>
> >> so if anyone with access to MS Windows could try it, we can see if it
> >> works there.

The fix works on MS-Windows.

> > I would love to, but emacs does not link under msvc:
> >
> > libc.lib(strftime.obj) : error LNK2005: _strftime already defined in temacs1.lib(strftime.obj)
> > obj-spd/i386/temacs.bin : fatal error LNK1169: one or more multiply defined symbols found
> 
> I would love to also, because as you can see from scanning the
> archives I have been experiencing font-related crashes on Windows for
> some time now.

The above link errors were fixed soon after they were reported.

Re: recent emacs font problems?

[Sam Steingold]

> * In message <uy8zahtih.fsf@jasonrumney.net>
> * On the subject of "Re: recent emacs font problems?"
> * Sent on 07 Jul 2003 23:16:54 +0100
> * Honorable Jason Rumney <jasonr@gnu.org> writes:
>
> David Abrahams <dave@boost-consulting.com> writes:
> > Sam Steingold <sds@gnu.org> writes:
> > >> * Honorable "Jan D." <jan.h.d@swipnet.se> writes:
> > >> so if anyone with access to MS Windows could try it, we can see if it
> > >> works there.
> The fix works on MS-Windows.

indeed.

> > > libc.lib(strftime.obj) : error LNK2005: _strftime already defined in temacs1.lib(strftime.obj)
> > > obj-spd/i386/temacs.bin : fatal error LNK1169: one or more multiply defined symbols found
> 
> The above link errors were fixed soon after they were reported.

indeed.

unfortunately, right now both win32 and rh9-gnu-linux builds fail with
the same error:

w32:

        "d:\gnu\emacs\src/obj-spd/i386/temacs.exe" -batch -l loadup dump
emacs: Invalid hash table rehash size: 0.0

linux:

...
emacs: Invalid hash table rehash size: 1.12341E-311

I do not have the linux error message in front of me, but the gist is
that the rehash size was not initialized.
linux sets the un-initialized double float with junk (that's where e-300
is coming from) while w32 sets it to 0.
but the bottom line is that the rehash size is un-initialized.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
cogito cogito ergo cogito sum

Re: recent emacs font problems?

[Miles Bader]

Sam Steingold <sds@gnu.org> writes:
> emacs: Invalid hash table rehash size: 1.12341E-311

Do `rm *.o' in the build .../src directory before building.

[Thanks to Stefan for that!]

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: recent emacs font problems?

[David Abrahams]

Jason Rumney <jasonr@gnu.org> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> Sam Steingold <sds@gnu.org> writes:
>> 
>> >> * Honorable "Jan D." <jan.h.d@swipnet.se> writes:
>> >>
>> >> so if anyone with access to MS Windows could try it, we can see if it
>> >> works there.
>
> The fix works on MS-Windows.

I'm not so sure.  I'm still seeing this crash:

 	emacs.exe!get_cached_font_char(bdffont * fontp=0x1129a004, int strchr=0x00000000)  Line 343 + 0x14	C
 	emacs.exe!get_bitmap_with_cache(bdffont * fontp=0x00000000, int strchr=0x00000020)  Line 542	C
 	emacs.exe!w32_BDF_TextOut(bdffont * fontp=0x1129a004, HDC__ * hdc=0x3c010c58, int left=0x00000073, int top=0x0000047d, unsigned char * text=0x0082db70, int dim=0x00000002, int bytelen=0x00000000, int fixed_pitch_size=0x00000000)  Line 672 + 0xc	C
 	emacs.exe!w32_text_out()  Line 1118 + 0x20	C
 	emacs.exe!x_draw_glyph_string_foreground(glyph_string * s=0x1129a004)  Line 1495	C
>	emacs.exe!x_draw_glyph_string(glyph_string * s=0x0082db74)  Line 2384	C
 	emacs.exe!draw_glyphs()  Line 17420 + 0x9	C
 	emacs.exe!draw_phys_cursor_glyph(window * w=0x0154cc00, glyph_row * row=0x01a3e800, draw_glyphs_face hl=DRAW_CURSOR)  Line 18847	C
 	emacs.exe!w32_draw_window_cursor()  Line 5124	C
 	emacs.exe!display_and_set_cursor(window * w=0x00000006, int on=0x00000001, int hpos=0x0000000f, int vpos=0x00000000, int x=0x00000069, int y=0x00000000)  Line 19042 + 0x18	C
 	emacs.exe!x_update_window_end(window * w=0x0154cc00, int cursor_on_p=0x00000001, int mouse_face_overwritten_p=0x00000000)  Line 542 + 0x20	C
 	emacs.exe!update_window(window * w=0x00000000, int force_p=0x00000000)  Line 4195 + 0x14	C
 	emacs.exe!update_window_tree(window * w=0x023b6800, int force_p=0x00000000)  Line 3881 + 0xa	C
 	emacs.exe!update_frame(frame * f=0x023b6800, int force_p=0x00000000, int inhibit_hairy_id_p=0x00000000)  Line 3819	C
 	emacs.exe!redisplay_internal(int preserve_echo_area=0x00000000)  Line 10052 + 0x8	C
 	emacs.exe!redisplay()  Line 9450 + 0x7	C
 	emacs.exe!read_char(int commandflag=0x00000001, int nmaps=0x00000002, int * maps=0x0082e358, int prev_event=0x1129a004, int * used_mouse_menu=0x0082e3a4)  Line 2497	C
 	emacs.exe!read_key_sequence(int * keybuf=0x0082e448, int bufsize=0x0000001e, int prompt=0x1129a004, int dont_downcase_last=0x00000000, int can_return_switch_frame=0x00000001, int fix_current_buffer=0x00000001)  Line 8827 + 0x24	C
 	emacs.exe!command_loop_1()  Line 1505 + 0x25	C
 	emacs.exe!internal_condition_case(int (void)* bfun=0x01057782, int handlers=0x112b8214, int (void)* hfun=0x01054487)  Line 1334	C
 	emacs.exe!command_loop_2()  Line 1292 + 0x15	C
 	emacs.exe!internal_catch(int tag=0x112bf13c, int (void)* func=0x010584fd, int arg=0x1129a004)  Line 1094 + 0x6	C
 	emacs.exe!command_loop()  Line 1264	C
 	emacs.exe!recursive_edit_1()  Line 987 + 0x5	C
 	emacs.exe!read_minibuf(int map=0x512cc934, int initial=0x1129a004, int prompt=0x00000064, int backup_n=0x00000000, int expflag=0x00000000, int histvar=0x1138213c, int histpos=0x00000000, int defalt=0x1129a004, int allow_props=0x00000000, int inherit_input_method=0x00000000)  Line 662	C
 	emacs.exe!Fread_from_minibuffer(int prompt=0x311d5144, int initial_contents=0x1129a004, int keymap=0x512cc934, int sys_read=0x1129a004, int hist=0x1138213c, int default_value=0x1129a004, int inherit_input_method=0x1129a004)  Line 946 + 0x32	C
 	emacs.exe!Feval(int form=0x511d5134)  Line 2102 + 0x18	C
 	emacs.exe!Feval(int form=0x511d5124)  Line 2043 + 0xc	C
 	emacs.exe!Fcall_interactively(int function=0x1131b984, int record_flag=0x1129a004, int keys=0x00005fdb)  Line 377 + 0xc	C
 	emacs.exe!Fcommand_execute(int cmd=0x1131b984, int record_flag=0x1129a004, int keys=0x1129a004, int special=0x1129a004)  Line 9726	C
 	emacs.exe!command_loop_1()  Line 1755 + 0x9	C
 	emacs.exe!internal_condition_case(int (void)* bfun=0x01057782, int handlers=0x112b8214, int (void)* hfun=0x01054487)  Line 1334	C
 	emacs.exe!command_loop_2()  Line 1292 + 0x15	C
 	emacs.exe!internal_catch(int tag=0x112bf13c, int (void)* func=0x010584fd, int arg=0x1129a004)  Line 1094 + 0x6	C
 	emacs.exe!command_loop()  Line 1264	C
 	emacs.exe!recursive_edit_1()  Line 987 + 0x5	C
 	emacs.exe!Frecursive_edit()  Line 1044	C
 	emacs.exe!Ffuncall(int nargs=0x00000004, int * args=0x0082ea58)  Line 2722	C
 	emacs.exe!Fbyte_code(int bytestr=0x022fad08, int vector=0x422fad00, int maxdepth=0x00000003)  Line 712	C
 	emacs.exe!Feval(int form=0x520c3ce4)  Line 2086	C
 	emacs.exe!Fprogn(int args=0x5218e1d4)  Line 409	C
 	emacs.exe!Fsave_window_excursion(int args=0x5218e1d4)  Line 5711	C
 	emacs.exe!Fbyte_code(int bytestr=0x021bfe08, int vector=0x421bfe00, int maxdepth=0x0000001a)  Line 861	C
 	emacs.exe!funcall_lambda(int fun=0x42639f20, int nargs=0x00000002, int * arg_vector=0x0082ec4c)  Line 2913 + 0x11	C
 	emacs.exe!Ffuncall(int nargs=0x00000004, int * args=0x0082ec48)  Line 2781 + 0xa	C
 	emacs.exe!Fapply(int nargs=0x00000002, int * args=0x0082ec84)  Line 2231 + 0xb	C
 	emacs.exe!apply1(int fn=0x112f1a44, int arg=0x520bb16c)  Line 2484 + 0xe	C
 	emacs.exe!call_debugger()  Line 265 + 0xe	C
 	emacs.exe!find_handler_clause(int handlers=0x77c71b98, int conditions=0x512bc914, int sig=0x00000000, int data=0x1129a004, int * debugger_value_ptr=0x0082ed10)  Line 1676 + 0x20	C
 	emacs.exe!Fsignal(int error_symbol=0x112b82bc, int data=0x520bb2b4)  Line 1506 + 0x11	C
 	emacs.exe!Fsymbol_value(int symbol=0x112bdcc4)  Line 1075 + 0x1a	C
 	emacs.exe!Feval(int form=0x112bdcc4)  Line 1969 + 0x6	C
 	emacs.exe!Ffuncall(int nargs=0x00000004, int * args=0x0082edd0)  Line 2725	C
 	emacs.exe!Fbyte_code(int bytestr=0x012318dc, int vector=0x412318d4, int maxdepth=0x0000000a)  Line 712	C
 	emacs.exe!funcall_lambda(int fun=0x412317c0, int nargs=0x00000001, int * arg_vector=0x0082eea8)  Line 2913 + 0x11	C
 	emacs.exe!Ffuncall(int nargs=0x00000004, int * args=0x0082eea4)  Line 2781 + 0xa	C
 	emacs.exe!Fbyte_code(int bytestr=0x01231a54, int vector=0x41231a4c, int maxdepth=0x00000004)  Line 712	C
 	emacs.exe!funcall_lambda(int fun=0x412319ec, int nargs=0x00000001, int * arg_vector=0x0082ef84)  Line 2913 + 0x11	C
 	emacs.exe!Ffuncall(int nargs=0x00000004, int * args=0x0082ef80)  Line 2781 + 0xa	C
 	emacs.exe!Fcall_interactively(int function=0x00000000, int record_flag=0x1129a004, int keys=0x41292d00)  Line 852	C
 	emacs.exe!Fcommand_execute(int cmd=0x1131d734, int record_flag=0x1129a004, int keys=0x1129a004, int special=0x1129a004)  Line 9726	C
 	emacs.exe!command_loop_1()  Line 1755 + 0x9	C
 	emacs.exe!internal_condition_case(int (void)* bfun=0x01057782, int handlers=0x112b8214, int (void)* hfun=0x01054487)  Line 1334	C
 	emacs.exe!command_loop_2()  Line 1292 + 0x15	C
 	emacs.exe!internal_catch(int tag=0x112bf13c, int (void)* func=0x010584fd, int arg=0x1129a004)  Line 1094 + 0x6	C
 	emacs.exe!command_loop()  Line 1264	C
 	emacs.exe!recursive_edit_1()  Line 987 + 0x5	C
 	emacs.exe!Frecursive_edit()  Line 1044	C
 	emacs.exe!Feval(int form=0x5132697c)  Line 2076	C
 	emacs.exe!Fprogn(int args=0x51326964)  Line 409	C
 	emacs.exe!funcall_lambda(int fun=0x513269b4, int nargs=0x00000001, int * arg_vector=0x0082f344)  Line 2904 + 0x15	C
 	emacs.exe!Ffuncall(int nargs=0x00000005, int * args=0x0082f340)  Line 2781 + 0xa	C
 	emacs.exe!Feval(int form=0x5118e690)  Line 2081 + 0x9	C
 	emacs.exe!Fif(int args=0x5118e6c0)  Line 355	C
 	emacs.exe!Feval(int form=0x5118e688)  Line 2026	C
 	emacs.exe!Fprogn(int args=0x5118e7a0)  Line 409	C
 	emacs.exe!Fcond(int args=0x5118dd04)  Line 385 + 0x6	C
 	emacs.exe!Feval(int form=0x5118dc84)  Line 2026	C
 	emacs.exe!Fprogn(int args=0x5118d970)  Line 409	C
 	emacs.exe!Fcond(int args=0x5118ea34)  Line 385 + 0x6	C
 	emacs.exe!Feval(int form=0x5118d938)  Line 2026	C
 	emacs.exe!Fprogn(int args=0x5118d930)  Line 409	C
 	emacs.exe!Fwhile(int args=0x5118d8f8)  Line 958 + 0x6	C
 	emacs.exe!Feval(int form=0x5118d8e0)  Line 2026	C
 	emacs.exe!Fprogn(int args=0x5118d8d8)  Line 409	C
 	emacs.exe!Feval(int form=0x5118d838)  Line 2026	C
 	emacs.exe!Funwind_protect(int args=0x5118eaac)  Line 1192	C
 	emacs.exe!Feval(int form=0x5118d830)  Line 2026	C
 	emacs.exe!Fprogn(int args=0x5118d828)  Line 409	C
 	emacs.exe!FletX(int args=0x5118d160)  Line 879	C
 	emacs.exe!Feval(int form=0x5118ce30)  Line 2026	C
 	emacs.exe!Fprogn(int args=0x5118ce28)  Line 409	C
 	emacs.exe!funcall_lambda(int fun=0x5118eb78, int nargs=0x00000005, int * arg_vector=0x0082f7b4)  Line 2904 + 0x15	C
 	emacs.exe!Ffuncall(int nargs=0x00000005, int * args=0x0082f7b0)  Line 2781 + 0xa	C
 	emacs.exe!Fbyte_code(int bytestr=0x011ab330, int vector=0x411ab328, int maxdepth=0x00000006)  Line 712	C
 	emacs.exe!Feval(int form=0x511ab2b8)  Line 2086	C
 	emacs.exe!Fprogn(int args=0x511ab2b0)  Line 409	C
 	emacs.exe!Fsave_window_excursion(int args=0x511ab2b0)  Line 5711	C
 	emacs.exe!Fbyte_code(int bytestr=0x011ab2ac, int vector=0x411ab2a4, int maxdepth=0x00000001)  Line 861	C
 	emacs.exe!funcall_lambda(int fun=0x411ab258, int nargs=0x00000002, int * arg_vector=0x0082f94c)  Line 2913 + 0x11	C
 	emacs.exe!Ffuncall(int nargs=0x00000004, int * args=0x0082f948)  Line 2781 + 0xa	C
 	emacs.exe!Fbyte_code(int bytestr=0x015aaa48, int vector=0x415aaa40, int maxdepth=0x00000004)  Line 712	C
 	emacs.exe!funcall_lambda(int fun=0x41790a60, int nargs=0x00000000, int * arg_vector=0x0082f9d0)  Line 2913 + 0x11	C
 	emacs.exe!apply_lambda(int fun=0x41790a60, int args=0x1129a004, int eval_flag=0x00000001)  Line 2836	C
 	emacs.exe!Feval(int form=0x5176fadc)  Line 2136 + 0xb	C
 	emacs.exe!Fprogn(int args=0x5176fae4)  Line 409	C
 	emacs.exe!Fsave_excursion(int args=0x5176fae4)  Line 954	C
 	emacs.exe!Feval(int form=0x5176fafc)  Line 2026	C
 	emacs.exe!Fif(int args=0x5176fb04)  Line 356 + 0x16	C
 	emacs.exe!Feval(int form=0x5176fb34)  Line 2026	C
 	emacs.exe!Fprogn(int args=0x5176fb4c)  Line 409	C
 	emacs.exe!funcall_lambda(int fun=0x5176f9ec, int nargs=0x00000000, int * arg_vector=0x0082fbe4)  Line 2904 + 0x15	C
 	emacs.exe!Ffuncall(int nargs=0x00000005, int * args=0x0082fbe0)  Line 2781 + 0xa	C
 	emacs.exe!apply1(int fn=0x11786614, int arg=0x1129a004)  Line 2476 + 0xb	C
 	emacs.exe!Fcall_interactively(int function=0x11786614, int record_flag=0x1129a004, int keys=0x00000b37)  Line 399 + 0xb	C
 	emacs.exe!Fcommand_execute(int cmd=0x11786614, int record_flag=0x1129a004, int keys=0x1129a004, int special=0x1129a004)  Line 9726	C
 	emacs.exe!command_loop_1()  Line 1755 + 0x9	C
 	emacs.exe!internal_condition_case(int (void)* bfun=0x01057782, int handlers=0x112b8214, int (void)* hfun=0x01054487)  Line 1334	C
 	emacs.exe!command_loop_2()  Line 1292 + 0x15	C
 	emacs.exe!internal_catch(int tag=0x112ad7c4, int (void)* func=0x010584fd, int arg=0x1129a004)  Line 1094 + 0x6	C
 	emacs.exe!command_loop()  Line 1272	C
 	emacs.exe!recursive_edit_1()  Line 987 + 0x5	C
 	emacs.exe!Frecursive_edit()  Line 1044	C
 	emacs.exe!main()  Line 1666 + 0x5	C
 	emacs.exe!mainCRTStartup()  Line 259 + 0x12	C
 	kernel32.dll!77e814c7() 	


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: recent emacs font problems?

[Jason Rumney]

David Abrahams <dave@boost-consulting.com> writes:

> Jason Rumney <jasonr@gnu.org> writes:
> 
> > David Abrahams <dave@boost-consulting.com> writes:
> >
> >> Sam Steingold <sds@gnu.org> writes:
> >> 
> >> >> * Honorable "Jan D." <jan.h.d@swipnet.se> writes:
> >> >>
> >> >> so if anyone with access to MS Windows could try it, we can see if it
> >> >> works there.
> >
> > The fix works on MS-Windows.
> 
> I'm not so sure.  I'm still seeing this crash:

The fix wasn't for a crash, this is a new bug. The fix was for the
fact that changes to the default font did not take effect.

Re: recent emacs font problems?

[Richard Stallman]

    > I cant really grasp the problem that lead to this change from the
    > comment above, so if anyone can describe a case for the original
    > problem, I can try and make this work.


    Here is what RMS said about the exact same fix some days ago; please
    read the previous articles in this thread for a discussion on this
    subject:

    RMS> That is not correct.  It would bring back a bug I fixed recently.  I
    RMS> think it was the following bug.

We need to understand what's going on in the two different cases
enough to figure out a way to distinguish them and do the right thing
for both.

Re: recent emacs font problems?

[Richard Stallman]

    The problem is that if FORCE_P is 0, all other attributes of the
    font won't be set unless they are unspecified in the default face.
    For exampel size.  So if you have a default face font which is
    fully specified (no undefined parts) no font change will happen.

That is right.

I made the change because in a specific circumstance it was wrong for
the defaults to be overridden here.  In some cases, you've found, it
is right for the defaults to be overridden here.

We need someone to figure out what distinguishes the case where they
should be overridden from the case where they should not be.

recent emacs font problems?

[Miles Bader]

Has anyone noticed problems recently with changing emacs' default font?

I find that I can change the default font emacs uses with the `-font'
option, but changing from within emacs (either via `set-default-font' or
the S-mouse-1 menu) has no effect -- or rather, emacs continues to
_display_ characters using the old font, but apparently changes the
default character cell size to use the new font (e.g., the tab-width
gets changed, and the window gets resized -- since the characters are
still displayed in the old font, this means that both tabs and
window-size calculations are now wrong)!

I use the GTK toolkit.

I'm not entirely sure that this is an emacs problem (rather than an X
font problem, or a GTK problem), but other X/GTK apps seem OK, so
currently I'm assuming it's emacs.

Thanks,

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: recent emacs font problems?

[Kenichi Handa]

In article <buou1bfyis6.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
> Has anyone noticed problems recently with changing emacs'
> default font?  I find that I can change the default font
> emacs uses with the `-font' option, but changing from
> within emacs (either via `set-default-font' or the
> S-mouse-1 menu) has no effect -- or rather, emacs
> continues to _display_ characters using the old font, but
> apparently changes the default character cell size to use
> the new font (e.g., the tab-width gets changed, and the
> window gets resized -- since the characters are still
> displayed in the old font, this means that both tabs and
> window-size calculations are now wrong)!

> I use the GTK toolkit.

I can reproduce that bug without GTK toolkit too.

---
Ken'ichi HANDA
handa@m17n.org

Re: recent emacs font problems?

[John Paul Wallington]

> > Has anyone noticed problems recently with changing emacs'
> > default font?  I find that I can change the default font
> > emacs uses with the `-font' option, but changing from
> > within emacs (either via `set-default-font' or the
> > S-mouse-1 menu) has no effect -- or rather, emacs
> > continues to _display_ characters using the old font, but
> > apparently changes the default character cell size to use
> > the new font (e.g., the tab-width gets changed, and the
> > window gets resized -- since the characters are still
> > displayed in the old font, this means that both tabs and
> > window-size calculations are now wrong)!
> 
> > I use the GTK toolkit.
> 
> I can reproduce that bug without GTK toolkit too.

Same here (without GTK too).

Is this the right fix (not properly tested) ?

--- /build/emacs/src/xfaces.c.~1.277.~	Wed May 28 06:00:50 2003
+++ /build/emacs/src/xfaces.c	Wed May 28 06:10:40 2003
@@ -6584,9 +6584,7 @@
       frame_font = Fassq (Qfont, f->param_alist);
       xassert (CONSP (frame_font) && STRINGP (XCDR (frame_font)));
       frame_font = XCDR (frame_font);
-      /* Specify 0 for FORCE_P here, so that we don't override
-	 a :family attribute specified for `default' for new frames.  */
-      set_lface_from_font_name (f, lface, frame_font, 0, 1);
+      set_lface_from_font_name (f, lface, frame_font, 1, 1);
     }
 #endif /* HAVE_WINDOW_SYSTEM */

Re: recent emacs font problems?

[Miles Bader]

John Paul Wallington <jpw@gnu.org> writes:
> > > Has anyone noticed problems recently with changing emacs'
> > > default font?
>
> Is this the right fix (not properly tested) ?

Hmm, that seems to fix things `sort of' -- it allows different fonts to
be set, and displayed but the font metrics are sometimes right,
sometimes wrong, e.g., using standard fonts, Courier10 - Courier18 look
correct, but Courier8 still has incorrectly sized tabs.  However this
may be a separate bug.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: recent emacs font problems?

[John Paul Wallington]

> > Is this the right fix (not properly tested) ?
> 
> Hmm, that seems to fix things `sort of' -- it allows different fonts to
> be set, and displayed but the font metrics are sometimes right,
> sometimes wrong, e.g., using standard fonts, Courier10 - Courier18 look
> correct, but Courier8 still has incorrectly sized tabs.  However this
> may be a separate bug.

I can't provoke incorrectly sized tabs here.  But my setup is rather
vanilla.  Hm.

Re: recent emacs font problems?

[Richard Stallman]

    Is this the right fix (not properly tested) ?

    --- /build/emacs/src/xfaces.c.~1.277.~	Wed May 28 06:00:50 2003
    +++ /build/emacs/src/xfaces.c	Wed May 28 06:10:40 2003
    @@ -6584,9 +6584,7 @@
	   frame_font = Fassq (Qfont, f->param_alist);
	   xassert (CONSP (frame_font) && STRINGP (XCDR (frame_font)));
	   frame_font = XCDR (frame_font);
    -      /* Specify 0 for FORCE_P here, so that we don't override
    -	 a :family attribute specified for `default' for new frames.  */
    -      set_lface_from_font_name (f, lface, frame_font, 0, 1);
    +      set_lface_from_font_name (f, lface, frame_font, 1, 1);
	 }
     #endif /* HAVE_WINDOW_SYSTEM */

That is not correct.  It would bring back a bug I fixed recently.  I
think it was the following bug.


Date: Thu, 15 May 2003 09:59:01 +0200 (CEST)
From: Klaus Straubinger <KSNetz@Arcor.DE>
To: bug-gnu-emacs@gnu.org

If the font family of the default face is changed with
(set-face-attribute 'default nil :family "fixed")
then this does not change the face's font for subsequent frames, as can
be seen with the evaluation of (face-font 'default) in the first frame
and in a second, created with C-x 5 2, respectively.

I found that that call to set_lface_from_font_name was
clobbering the family that had come from the new-frame default.

Re: recent emacs font problems?

[Kim F. Storm]

Reading through the case and the comments, and comparing this to the
code, I'm uncertain whether the intention of the fix is to _only_
avoid overriding the :family property (that's not what the fix does,
but what the comment below says), or whether the intention really is
to avoid overriding any of the properties (as the fix does).

If the intention is only to avoid overriding :family, then we could
pass -1 for FORCE_P and test explicitly for force_p > 0 in
set_lface_from_font_name in connection with the :family property.


Richard Stallman <rms@gnu.org> writes:

>     Is this the right fix (not properly tested) ?
> 
>     --- /build/emacs/src/xfaces.c.~1.277.~	Wed May 28 06:00:50 2003
>     +++ /build/emacs/src/xfaces.c	Wed May 28 06:10:40 2003
>     @@ -6584,9 +6584,7 @@
> 	   frame_font = Fassq (Qfont, f->param_alist);
> 	   xassert (CONSP (frame_font) && STRINGP (XCDR (frame_font)));
> 	   frame_font = XCDR (frame_font);
>     -      /* Specify 0 for FORCE_P here, so that we don't override
>     -	 a :family attribute specified for `default' for new frames.  */
>     -      set_lface_from_font_name (f, lface, frame_font, 0, 1);
>     +      set_lface_from_font_name (f, lface, frame_font, 1, 1);
> 	 }
>      #endif /* HAVE_WINDOW_SYSTEM */
> 
> That is not correct.  It would bring back a bug I fixed recently.  I
> think it was the following bug.
> 
> 
> Date: Thu, 15 May 2003 09:59:01 +0200 (CEST)
> From: Klaus Straubinger <KSNetz@Arcor.DE>
> To: bug-gnu-emacs@gnu.org
> 
> If the font family of the default face is changed with
> (set-face-attribute 'default nil :family "fixed")
> then this does not change the face's font for subsequent frames, as can
> be seen with the evaluation of (face-font 'default) in the first frame
> and in a second, created with C-x 5 2, respectively.
> 
> I found that that call to set_lface_from_font_name was
> clobbering the family that had come from the new-frame default.
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: recent emacs font problems?

[Richard Stallman]

    Reading through the case and the comments, and comparing this to the
    code, I'm uncertain whether the intention of the fix is to _only_
    avoid overriding the :family property (that's not what the fix does,
    but what the comment below says), or whether the intention really is
    to avoid overriding any of the properties (as the fix does).

I think the old bug would have occured for any of the attributes that
are part of the font name.  But I did not test others, only :family.

I would guess that the attributes for which the new bug occurs are the
same ones for which the old bug, that was fixed by my change, used to
occur.  I suspect that the correct treatment is the same for all these
attributes.  But I don't know what is correct.  Someone needs to
figure out what happens in the case that fails now, why the change
caused this new bug, and how to distinguish the case in which we want
to forcibly set all the attributes there from the case in which we
don't.

Re: recent emacs font problems?

[Karl Eichwalder]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Has anyone noticed problems recently with changing emacs' default
> font?

Yes, things behave very strange.

> I use the GTK toolkit.

I do not; my configuration options are:

    (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)

> I'm not entirely sure that this is an emacs problem (rather than an X
> font problem, or a GTK problem), but other X/GTK apps seem OK, so
> currently I'm assuming it's emacs.

Sorry, I cannot help that much here.  Maybe, my setup is a little bit
strange (for historical reasons).  I set some X resources in
~/.Xresources and some others via lisp code.  Thus far I didn't find
the time to wirte down a proper bug report.

-- 
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke@suse.de (work) / keichwa@gmx.net (home)               |   (*)/'(*)