May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[Failure} Cygwin/W95 b41 26 years, 8 months

David Bush

Updated via CVS from b41-pre1 make clean ./configure (no options) make beta Get the following error: gcc -c -g -O3 -Wall -Wno-switch -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves objects-msw.c objects-msw.c: In function `mswindows_initialize_font_instance': objects-msw.c:1067: `JOHAB_CHARSET' undeclared (first use this function) objects-msw.c:1067: (Each undeclared identifier is reported only once objects-msw.c:1067: for each function it appears in.) objects-msw.c:1076: `MAC_CHARSET' undeclared (first use this function) make[1]: *** [objects-msw.o] Error 1 make: *** [src] Error 2

1 participants
0 comments

Re: Toolbar buttons not resizing to size of toolbar. 26 years, 8 months

Hrvoje Niksic

[ Added xemacs-beta, as this is not Windows-specific ] "Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > Toolbars are not redrawn even they definietly have to. This is shown > in 20.3/X too. Try C-x 2, (set-specifier default-toolbar-height 70 > (selected-window)). Toolbar enlarges. When you click on another > window, showing the same buffer, the toolbar does *not* shrinks > back. Pull window by its corner. Aha, XEmacs knows that the toolbar > should be redrawn, it just a bit lazy on doind this :) Yup, I can repeat this in 21.0-b40 under X. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Predestination was doomed from the start.

3 participants
3 comments

Re: Toolbar buttons not resizing to size of toolbar. 26 years, 8 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > > in 20.3/X too. Try C-x 2, (set-specifier default-toolbar-height 70 > > > (selected-window)). Toolbar enlarges. When you click on another > > > window, showing the same buffer, the toolbar does *not* shrinks > > > back. Pull window by its corner. Aha, XEmacs knows that the toolbar > > > should be redrawn, it just a bit lazy on doind this :) > > > > Yup, I can repeat this in 21.0-b40 under X. > > This is expected behavior. Window toolbar sizes are constrained > to be no larger than the sizes instantiated at the frame level. > The point of this is to avoid having the frame size flap when the > current buffer or selected window changes. The "laziness" part still looks like a bug to me. Anyway, this has been changed fixed in b41. Toolbar is redrawn when you change selected window, and the other window has a different toolbar height. The frame size remains unchanged, though. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Jone's law: The man who smiles when things go wrong has thought of someone to blame it on.

1 participants
0 comments

Re: initialization of frame info 26 years, 8 months

Ben Wing

yes Kirill M. Katsnelson wrote: > May we load something like ~/.xemacs-early for those who care? > > Kirill > > [1] With variations thereof

1 participants
0 comments

Re: Faces, bugs or features ? 26 years, 8 months

Hrvoje Niksic

"Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > Font/face relationships have to be retunk and reimplemented. > Currenly, bold face cannot inherit its point size from the default > face: point size can be inherited only wholesale with "boldness". > What a bogosity! Agree 100%. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

1 participants
0 comments

Faces, bugs or features ? 26 years, 8 months

Olivier Galibert

xemacs -vanilla, actually all .*emacs* moved out of the way Options/Customize/Faces... Choose all. Open Bold and Default. Both have the "Size" attribute inactive. Sets the default size to "8pt" and use "set for current session". -> Most fonts become 8pt as asked -> the bold, italic and bold italic faces stay at 12pt (bug or feature?) -> the background becomes white (huh?) -> the modeline background becomes white (huh????) Look at the already opened "Bold" face information. Nothing changed, but the face is still 12pt. Close and reopen the face information. Oh! "Size" is now activated and set to "12", without any unit (huh?). Select Bold.Size, retype 12, use Set for current session -> the size changes, the default unit isn't pt (huh?) I have some other problems but they seem to come from by environment so I'm going to track and kill them. OG.

2 participants
1 comments

Re: Scrollbar problems in b40 and b41 26 years, 8 months

Oliver Graf

Oliver Graf <ograf(a)fga.de> writes: > Oliver Graf <ograf(a)fga.de> writes: > > > The scrollbars show minimal thumbs for unscrollable buffers and maximum thumbs > > for buffers that are scrollable. Some sort of inverted behaviour. This > > happened with all sorts of Xaw libs (orig, 3d, neXtaw). > > Does not happen with lucid scrollbars... Forget everything. After patching up to b41 again, everything works fine. Perhaps I've missed a autoconf the first time, or I left some of my patches in... Regards, Oliver.

1 participants
0 comments

[BUG] Drifting mouse pointer on the hrz scrollbar 26 years, 8 months

Kirill M. Katsnelson

This have been reported about a week ago, but seems to have come unnoticed. I found a very bright reproduction for this bug. I see it in 20.3 and in 21.0 beta 37 under X on Solaris, with lucid sb. xemacs -vanilla C-x 3 Now get a grip on any of the horizontal scrollbars, and move the hanle left and right *real* *real* *slowly*. When moving right, the handle makes its way about 1+1/3 of the distance made by the pointer. When you move left, the handle moves 3-4 times further than the pointer! Kirill

1 participants
0 comments

Re: Scrollbar problems in b40 and b41 26 years, 8 months

Oliver Graf

Oliver Graf <ograf(a)fga.de> writes: > The scrollbars show minimal thumbs for unscrollable buffers and maximum thumbs > for buffers that are scrollable. Some sort of inverted behaviour. This > happened with all sorts of Xaw libs (orig, 3d, neXtaw). Does not happen with lucid scrollbars...

2 participants
1 comments

Re: initialization of frame info 26 years, 8 months

Kirill M. Katsnelson

Some time ago, John Morey wrote... |+ | I have the following in my .emacs file: | | (set-specifier default-toolbar-height 48) | (setq initial-frame-alist | '( | (width . 81) | (height . 35) | )) | )) | | The code does work, as in it makes the toolbar larger and the initial | frame the size that I want it, but it does not take effect until the | frame has already been displayed. Currently the initial frame is | displayed before that changes take effect and then the frame display | changes when .emacs is read in. Is there a way that I can specify | the changes before the initial frame is displayed so that it initially | comes up the way that it is to be displayed. |- This is the behavior by design for the first frame, and a known bug for the second one, Windows specific. The only[1] way to specifiy frame size for the first frame to avoid what's your dislike is: 1. Create a file named auto-autoloads.el in an empty directory which is a sibling to packages in your package hierarchy. Say if you have .../packages/lisp/xemacs-base create .../packages/lisp/evilhack, and put the file into this directory. 2. Put the following into the file: ;;;### autoload (setq default-frame-plist '(width 81 height 35)) May we load something like ~/.xemacs-early for those who care? Kirill [1] With variations thereof

1 participants
0 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta May 1998