8:50 a.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
There are incorrect colors displayed in the first XEmacs frame, when the user
has set his/her background color to black through custom.
Steps to reproduce:
- Start a new XEmacs process, with no .xemacs directory (or .emacs)
- From the menu: options->edit faces
- Go to the `default' color, change its foreground to white, and its
background to black
** Notice that, at this point, the faces that have light/dark
** background alternatives, like hyper-apropos-hyperlink, are still
** set to the light-background version instead of the dark
** background version. This is a problem, but not the main problem.
- Close and restart XEmacs
- Load hyper-help (C-h a foo)
- Create a new frame with the same buffer (C-x 5 2)
Now, notice that the colors in these two frames are different. The
first frame has the hyper-apropos colors used for light backgrounds
(incorrectly), while the second frame has the hyper-apropos colors for
dark backgrounds (correct).
In general, the first frame seems to always use (incorrectly) the
colors for light backgrounds instead of dark backgrounds.
I can reproduce this on any version of XEmacs I try, from this beta
version on Linux to an old Solaris build from a year and half ago. It
appears to be very common, I've noticed it on my friends' computers too.
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux peppermint 2.4.9-ac7 #1 2001ǯ 9·î 5Æü ¿åÍËÆü 04:25:45 JST i686 unknown
./configure '--with-sound=native,esd' '--cflags=-O2 -g -Wall'
'--with-x11' '--extra-verbose' '--with-site-lisp'
'--statedir=/var/lib' '--infodir=/usr/share/info/xemacs-21.5-b3'
'--prefix=/usr' '--error-checking=none' '--debug=no'
'--const-is-losing=no' '--dynamic' '--without-postgresql'
'--with-gpm=no' '--with_menubars=lucid' '--with_scrollbars=lucid'
'--with_dialogs=athena'
'--docdir=/usr/lib/xemacs-21.5-b3/i386-debian-linux/nomule/'
'--package-path=~/.xemacs:~/.xemacs/packages::/usr/share/xemacs21/packages:/usr/share/xemacs21/site-packages'
'i386-debian-linux'
XEmacs 21.5-b3 "asparagus" configured for `i386-debian-linux'.
Compilation / Installation:
Source code location: /home/takuo/work/guru/xe21.2/xemacs21-21.5.3
Installation prefix: /usr
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O2 -g -Wall
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw
- Athena library to link: Xaw
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Compiling in support for ESD (Enlightened Sound Daemon).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for dynamic shared object modules.
Load-Path Lisp Shadows:
----------------------
(/usr/share/xemacs21/site-lisp/ruby-elisp/rubydb3x
/usr/share/xemacs21/site-lisp/ruby-elisp/rubydb3x
/usr/share/xemacs21/site-lisp/ruby-elisp/rubydb2x
/usr/share/xemacs21/site-lisp/ruby-elisp/rubydb2x
/usr/share/xemacs21/site-lisp/ruby-elisp/ruby-mode
/usr/share/xemacs21/site-lisp/ruby-elisp/ruby-mode
/usr/share/xemacs21/site-lisp/ruby-elisp/inf-ruby
/usr/share/xemacs21/site-lisp/ruby-elisp/inf-ruby
/usr/share/xemacs21/site-lisp/tdtd/tdtd
/usr/share/xemacs21/site-lisp/tdtd/tdtd
/usr/share/xemacs21/site-lisp/tdtd/tdtd-font
/usr/share/xemacs21/site-lisp/tdtd/tdtd-font
/usr/share/xemacs21/site-lisp/tdtd/tdtd-font-maker
/usr/share/xemacs21/site-lisp/tdtd/tdtd-font-maker
/usr/share/xemacs21/site-lisp/tdtd/make-regexp
/usr/share/xemacs21/site-lisp/tdtd/make-regexp
/usr/share/xemacs21/site-lisp/tramp/trampcache
/usr/share/xemacs21/site-lisp/tramp/trampcache
/usr/share/xemacs21/site-lisp/tramp/tramp
/usr/share/xemacs21/site-lisp/tramp/tramp
/usr/share/xemacs21/site-lisp/tramp/tramp-util
/usr/share/xemacs21/site-lisp/tramp/tramp-util
/usr/share/xemacs21/site-lisp/tramp/format-spec
/usr/share/xemacs21/site-lisp/tramp/format-spec
/usr/share/xemacs21/site-lisp/tramp/base64
/usr/share/xemacs21/site-lisp/tramp/base64
/usr/share/xemacs21/site-lisp/tramp/tramp-vc
/usr/share/xemacs21/site-lisp/tramp/tramp-vc
/usr/share/xemacs21/site-lisp/debian-startup
/usr/share/emacs/site-lisp/debian-startup
/usr/share/xemacs21/packages/lisp/build/path
/usr/share/xemacs21/packages/lisp/calc/path
/usr/share/xemacs21/site-lisp/tramp/format-spec
/usr/share/xemacs21/packages/lisp/gnus/format-spec
/usr/share/xemacs21/site-lisp/tramp/base64
/usr/share/xemacs21/packages/lisp/mail-lib/base64
/usr/share/xemacs21/site-lisp/python-elisp/python-mode
/usr/share/xemacs21/packages/lisp/prog-modes/python-mode
/etc/emacs/site-start
/usr/share/xemacs21/site-packages/lisp/site-start)
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.11 :type regular)
(xemacs-devel :version 1.38 :type single-file)
(xemacs-base :version 1.55 :type regular)
(w3 :version 1.2 :type regular)
(vm :version 6.96 :type regular)
(viper :version 1.28 :type regular)
(view-process :version 1.11 :type regular)
(vhdl :version 1.13 :type regular)
(vc-cc :version 1.16 :type regular)
(vc :version 1.28 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.29 :type regular)
(time :version 1.11 :type regular)
(textools :version 1.12 :type regular)
(text-modes :version 1.32 :type single-file)
(texinfo :version 1.2 :type regular)
(supercite :version 1.18 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.21 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(slider :version 1.13 :type regular)
(sh-script :version 1.13 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.1 :type regular)
(scheme :version 1.11 :type regular)
(rmail :version 1.12 :type regular)
(reftex :version 1.23 :type regular)
(psgml :version 1.23 :type regular)
(ps-print-nomule :version 1.05 :type regular)
(prog-modes
:version
1
.42
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.55 :type regular)
(pc :version 1.2 :type single-file)
(os-utils :version 1.25 :type single-file)
(net-utils :version 1.23 :type single-file)
(misc-games :version 1.15 :type single-file)
(mine :version 1.14 :type regular)
(mh-e :version 1.13 :type regular)
(mew :version 1.14 :type regular)
(mailcrypt :version 2.09 :type regular)
(mail-lib :version 1.39 :type regular)
(ispell :version 1.23 :type regular)
(ilisp :version 1.19 :type regular)
(igrep :version 1.08 :type regular)
(idlwave :version 1.23 :type regular)
(hm--html-menus :version 1.16 :type regular)
(gnus :version 1.57 :type regular)
(gnats :version 1.12 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.09 :type single-file)
(frame-icon :version 1.09 :type regular)
(forms :version 1.13 :type regular)
(footnote :version 1.13 :type regular)
(eudc :version 1.34 :type regular)
(eterm :version 1.13 :type regular)
(eshell :version 1.01 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.08 :type single-file)
(eieio :version 1.01 :type regular)
(efs :version 1.26 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.7 :type single-file)
(ediff :version 1.33 :type regular)
(edebug :version 1.14 :type regular)
(dired :version 1.11 :type regular)
(debug :version 1.14 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.13 :type regular)
(cc-mode :version 1.26 :type regular)
(calendar :version 1.16 :type regular)
(calc :version 1.17 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.02 :type regular)
(bbdb :version 1.16 :type regular)
(auctex :version 1.25 :type regular)
(apel :version 1.2 :type regular)
(ada :version 1.1 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail hyper-apropos mmm-auto
mmm-vars mmm-compat overlay regexp-opt xcscope cus-face
zenirc-autoloads xemacs-devel-autoloads xemacs-base-autoloads
w3-autoloads vm-autoloads viper-autoloads view-process-autoloads
vhdl-autoloads vc-cc-autoloads vc-autoloads tpu-autoloads
tooltalk-autoloads tm-autoloads time-autoloads textools-autoloads
text-modes-autoloads texinfo-autoloads supercite-autoloads
strokes-autoloads speedbar-autoloads sounds-wav-autoloads
sounds-au-autoloads slider-autoloads sh-script-autoloads
sgml-autoloads semantic-autoloads scheme-autoloads rmail-autoloads
reftex-autoloads psgml-autoloads ps-print-nomule-autoloads
prog-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads net-utils-autoloads
misc-games-autoloads mine-autoloads mh-e-autoloads mew-autoloads
mailcrypt-autoloads mail-lib-autoloads ispell-autoloads
ilisp-autoloads igrep-autoloads idlwave-autoloads
hm--html-menus-autoloads gnus-autoloads gnats-autoloads
games-autoloads fsf-compat-autoloads frame-icon-autoloads
forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
eshell-autoloads emerge-autoloads elib-autoloads eieio-autoloads
efs-autoloads edt-autoloads edit-utils-autoloads ediff-autoloads
edebug-autoloads dired-autoloads debug-autoloads crisp-autoloads
cookie-autoloads cc-mode-autoloads calendar-autoloads calc-autoloads
c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads
apel-autoloads ada-autoloads src-autoloads loadhist auto-show
fontl-hooks x-iso8859-1 gutter-items menubar-items x-menubar
mode-motion mouse itimer auto-save lisp-mode easymenu iso8859-1 page
buff-menu lib-complete help-nomule cus-file derived frame text-props
obsolete cus-start custom widget cl-extra mini-cl cl cl-19 packages
backquote very-early-lisp lucid-scrollbars cut-buffer lucid-menubars
athena-dialogs x c-balloon-help tty-frames tty toolbar esd-sound
native-sound scrollbar unix-processes multicast network-streams
subprocesses modules menu-accelerator-support menubar berkeley-db md5
xemacs gutter tiff png gif jpeg xface xpm xbm lisp-float-type linux
dialog devices window-system base64)
Recent keystrokes:
-----------------
C-h a c o l o r RET C-c C-m C-x 5 2 M-x r e p o r TAB
x e m TAB RET
Recent messages (most recent first):
-----------------------------------
Loading mail-abbrevs...
Loading xemacsbug...done
Loading xemacsbug...
C-c C-m not defined.
Loading hyper-apropos...done
Loading hyper-apropos...
Loading 50yorick-auto...done
Loading 50yorick-auto...
Loading 50xslide...done
Loading 50xslide...
Loading 50tramp...done
Loading 50tramp...
Loading 50tdtd...done
Loading 50tdtd...
Loading 50ruby-elisp...done
Loading 50ruby-elisp...
Loading 50python-mode...done
Loading 50python-mode...
Loading 50php-elisp...done
Loading 50php-elisp...
9:28 a.m.
>>>> "Michael" == Michael Toomim
<toomim(a)cory.eecs.berkeley.edu> writes:
Michael> In general, the first frame seems to always use
Michael> (incorrectly) the colors for light backgrounds instead of
Michael> dark backgrounds.
No, AFAIK this is correct behavior, at least it has always been so.
The first frame is created early in the initialization process, and
therefore is different from all those created after initialization.
Changing behavior to what you might prefer is hard; you're welcome to
try.
Use X resources to initialize the first frame's resources.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
11:03 a.m.
On Mon, 2001-12-17 at 01:28, Stephen J. Turnbull wrote:
>>>>> "Michael" == Michael Toomim
<toomim(a)cory.eecs.berkeley.edu>
writes:
Michael> In general, the first frame seems to always use
Michael> (incorrectly) the colors for light backgrounds instead of
Michael> dark backgrounds.
No, AFAIK this is correct behavior, at least it has always been so.
The first frame is created early in the initialization process, and
therefore is different from all those created after initialization.
Changing behavior to what you might prefer is hard; you're welcome to
try.
Use X resources to initialize the first frame's resources.
Ok. I just might take a look sometime in the future. Meanwhile,
however, what about adding this information to the default face's custom
docstring? It would alleviate the confusion I've seen with many a user.
Right now it says "default face". It might be nice to mention:
a) The default face's special property of changing the frame's
background color (even where no text exists)
b) That setting it to a dark color might make the first XEmacs
frame's colors hard to read, and using X resources will fix it.
Also, I suppose that there isn't any easy work-around (like setting X
resources) for Windows (or otherwise non-x) users?
Michael
11:21 a.m.
Michael Toomim writes:
Also, I suppose that there isn't any easy work-around (like setting X
resources) for Windows (or otherwise non-x) users?
have you looked at color-theme.el ??
http://www.bright.net/~jonadab/emacs/
--
XEmacs Advocate | Do not try to bend the spoon, that's impossible,
FreeBSD Devote | but try to realise the truth... There is no spoon.
Perl Hacker | - Child Prodigy, The Matrix.
Apache God | <mailto:rendhalver＠users.sf.net>
6:42 p.m.
-- "Stephen J. Turnbull" <stephen(a)xemacs.org> spake thusly:
>>>>> "Michael" == Michael Toomim
<toomim(a)cory.eecs.berkeley.edu>
>>>>> writes:
Michael> In general, the first frame seems to always use
Michael> (incorrectly) the colors for light backgrounds instead of
Michael> dark backgrounds.
No, AFAIK this is correct behavior, at least it has always been so.
The first frame is created early in the initialization process, and
therefore is different from all those created after initialization.
Changing behavior to what you might prefer is hard; you're welcome to
try.
Use X resources to initialize the first frame's resources.
I would content that "It's always worked this way" and "This is the
correct behavior" are two totally different statements. Why should
anyone have to muck around with a completely different facility for
only the _first_ frame? I would say this is a bug. Even if it's a very
complex bug that would be extremely difficult to resolve, that doesn't
change the fact that it's a bug.
7:47 p.m.
Matt Tucker <tuck(a)whistlingfish.net> writes:
I would content that "It's always worked this way" and
"This is the
correct behavior" are two totally different statements. Why should
anyone have to muck around with a completely different facility for
only the _first_ frame? I would say this is a bug. Even if it's a
very complex bug that would be extremely difficult to resolve, that
doesn't change the fact that it's a bug.
I wrote/ported the code, and I agree that it's a bug. I'll explain
the background story first, and then give some ideas about the
possible remedies.
The background story:
XEmacs has specifiers, which are in spirit similar to how Custom
specifies faces. Ideally, a `defface' statement would be converted
into a fairly complex and equivalent specifier specification. At
first I tried to implement it that way, but that didn't work because
the specifiers missed some features.
This was some time ago, so I might not be remembering every detail.
But from what I do remember, the biggest problem was that it was
impossible to express the `background' matching requirement using a
specifier tag. `define-specifier-tag' didn't work because the custom
tags accept a DEVICE argument, whereas we needed a FRAME argument,
because you can have two frames with different backgrounds.
(In fact, background "lightness" should be defined on window level
with fallback to frame and device, but Custom insisted on dealing with
frames, so it was simpler to think in terms of frames.)
A possible course of action was to extend `define-specifier-tag' so
that you tell it that you wanted your tag frame-specific, not
device-specific. Something like
(define-specifier-tag 'background-lightness
(lambda (frame)
... blah blah ...)
:scope 'frame ; or even :scope 'window
)
But I never did that, for reasons I don't quite remember. It may have
had to do with the specifier cache getting in the way; the specifiers
were never meant to be that "dynamic". (For example, changing the
background of the `default' face should cause the background-lightness
thing to be recalculated.) But it may also have been the case that I
found the specifier code too complex at the time.
Then there were some weird issues with fonts. Font modifiers such as
`bold' and `italic' are even now almost useless, especially with Mule.
I'm pretty sure they wouldn't fit in the specifier model.
The current implementation:
So when I was unable to make it work the "right" way, I punted and
implemented things similar to how Per's original code did it: by
providing a function that runs whenever a frame is created, and that
inspects the frame's properties and modifies all the faces to match
custom's specifications *for that frame*. In case you're curious, the
function is `custom-initialize-frame', defined in `faces.el', and
called directly from Fmake_frame.
That doesn't work for the first frame for the obvious reason that it
is created before `.emacs' is run. I didn't have an obvious solution
to the problem, so I postponed it until later. Which is never a smart
thing to do, as proven by the fact that the problem is still there.
Possible solutions:
IMHO the simplest immediate solution would be to call the appropriate
Custom calls from `frame-notice-user-settings'. This might be
trickier than it initially seems because of all the hair that takes
place in that function, and because of how complex the face stuff is,
and how complex the Custom face stuff is, and the impedance mismatch
between XEmacs face concepts and Custom face concepts. To quote Ben's
comment in frame-notice-user-settings, "this [...] stuff is a load of
trash, and so is this function we're in." But all in all, it
shouldn't be too hard.
A much nicer solution would be for someone with the time and the
inclination to make defface translate into a proper specifier
specification. It would be an interesting project, and the reward of
deleting `custom-initialize-frame' from the face of the earth would
more than make up for all the hours of effort. :-)
8:09 p.m.
Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
Matt Tucker <tuck(a)whistlingfish.net> writes:
> I would content that "It's always worked this way" and "This is
the
> correct behavior" are two totally different statements. Why should
> anyone have to muck around with a completely different facility for
> only the _first_ frame? I would say this is a bug. Even if it's a
> very complex bug that would be extremely difficult to resolve, that
> doesn't change the fact that it's a bug.
I wrote/ported the code, and I agree that it's a bug. I'll explain
the background story first, and then give some ideas about the
possible remedies.
...
That doesn't work for the first frame for the obvious reason that
it
is created before `.emacs' is run. I didn't have an obvious solution
to the problem, so I postponed it until later.
Without knowing much about XEmacs internals, its seems to me thats
the problem. Ie. the first frame is created before the .emacs
is run instead of after.
Its not only the background color that misbehaves, but frame resizes
from the .emacs, repositioning, removing toolbars, scrollbars, etc.
My XEmacs frame jumps all over the place during startup, especially
on Windows.
It would seem pretty simple to start XEmacs with the equivalent of
-unmapped, and then have XEmacs add a make-frame after the .emacs
is read.
--
Dan Espen
444 Hoes Lane Room RRC 1C-214 E-mail: dane(a)mk.telcordia.com
Piscataway, NJ 08854 Phone: (732) 699-5570
10:27 p.m.
On Mon, 2001-12-17 at 11:47, Hrvoje Niksic wrote:
Possible solutions:
IMHO the simplest immediate solution would be to call the appropriate
Custom calls from `frame-notice-user-settings'. This might be
trickier than it initially seems because of all the hair that takes
place in that function, and because of how complex the face stuff is,
and how complex the Custom face stuff is, and the impedance mismatch
between XEmacs face concepts and Custom face concepts. To quote Ben's
comment in frame-notice-user-settings, "this [...] stuff is a load of
trash, and so is this function we're in." But all in all, it
shouldn't be too hard.
A much nicer solution would be for someone with the time and the
inclination to make defface translate into a proper specifier
specification. It would be an interesting project, and the reward of
deleting `custom-initialize-frame' from the face of the earth would
more than make up for all the hours of effort. :-)
I'm not sure what frame-notice-user-settings is for, but I fixed the
problem for myself by inserting the following five lines into my init.el
file:
(add-hook 'after-init-hook
(lambda ()
(set-frame-property (selected-frame) 'background-mode nil)
(set-frame-property (selected-frame) 'custom-properties nil)
(initialize-custom-faces (selected-frame))))
Is this what you were suggesting should go into
frame-notice-user-settings()?
Could a patch like this get folded into XEmacs?
10:46 p.m.
On Mon, 2001-12-17 at 14:27, Michael Toomim wrote:
I'm not sure what frame-notice-user-settings is for, but I fixed
the
problem for myself by inserting the following five lines into my init.el
file:
(add-hook 'after-init-hook
(lambda ()
(set-frame-property (selected-frame) 'background-mode nil)
(set-frame-property (selected-frame) 'custom-properties nil)
(initialize-custom-faces (selected-frame))))
Is this what you were suggesting should go into
frame-notice-user-settings()?
Could a patch like this get folded into XEmacs?
In fact, we could fix the other issues you mentioned (refreshing the
faces when other things change the background-mode from light to dark,
etc.) by wrapping these three statements up in a refresh-frame-faces()
function.
It could be called whenever the default face gets its color changed from
light to dark or dark to light, or when the variable
`frame-background-mode' is modified through custom. It would need to be
called on every frame in (frame-list).
Of course, refresh-frame-faces() is a bad name. I haven't looked at
enough custom-faces code to be able to choose a good one.
Michael
10:51 p.m.
Michael Toomim <toomim(a)cs.berkeley.edu> writes:
(add-hook 'after-init-hook
(lambda ()
(set-frame-property (selected-frame) 'background-mode nil)
(set-frame-property (selected-frame) 'custom-properties nil)
(initialize-custom-faces (selected-frame))))
Is this what you were suggesting should go into
frame-notice-user-settings()?
Yes, something like that would be a good start.
12:06 a.m.
Matt Tucker <tuck(a)whistlingfish.net> writes:
-- "Stephen J. Turnbull" <stephen(a)xemacs.org> spake
thusly:
>>>>>> "Michael" == Michael Toomim
<toomim(a)cory.eecs.berkeley.edu>
>>>>>> writes:
>
> Michael> In general, the first frame seems to always use
> Michael> (incorrectly) the colors for light backgrounds instead of
> Michael> dark backgrounds.
>
> No, AFAIK this is correct behavior, at least it has always been so.
> The first frame is created early in the initialization process, and
> therefore is different from all those created after initialization.
> Changing behavior to what you might prefer is hard; you're welcome to
> try.
>
> Use X resources to initialize the first frame's resources.
I would content that "It's always worked this way" and "This is the
correct behavior" are two totally different statements. Why should
anyone have to muck around with a completely different facility for
only the _first_ frame? I would say this is a bug. Even if it's a very
complex bug that would be extremely difficult to resolve, that doesn't
change the fact that it's a bug.
They are definitely two different things. I think it was Ben who suggested
having an initial 'splash screen' that would display the messages from your
.emacs and site initialization loading, and only after .emacs had been
fully parsed would the first real 'frame' be initialized.
This _should_ be fairly straightforward, but would be a lot of work
nonetheless.:)
-bp
--
Ceterum censeo vi esse delendam
4:47 a.m.
>>>> "Matt" == Matt Tucker
<tuck(a)whistlingfish.net> writes:
Matt> -- "Stephen J. Turnbull" <stephen(a)xemacs.org> spake thusly:
Matt> I would content that "It's always worked this way" and
"This
Matt> is the correct behavior" are two totally different
Matt> statements.
They are.
By "correct behavior" I mean "matches specifications." Since the
specification of visible behavior was never actually written down, I
approximate it with the historical behavior.
If you want to write a new specification that says that it's a bug,
fine with me. But many many releases of XEmacs have been made with
this "bug" unresolved and unremarked by the people planning releases.
We need to get 21.4 promoted to stable. This is not a showstopper.
Therefore it will wait.
Matt> Why should anyone have to muck around with a completely
Matt> different facility for only the _first_ frame?
They shouldn't. That's not what I said, what I said is "go ahead and
find a way to make it work in a desirable way". He did. I'm happy.
So users use Michael's workaround[1] for now, and somebody does something
better and more permanent in 21.5. Maybe it gets backported to 21.4.
Footnotes:
[1] IIRC somebody (Didier Verna?) tried this before, but with fonts,
and found the flashing too annoying (or maybe merely unesthetic) and
abandoned it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
10:59 a.m.
-- "Stephen J. Turnbull" <stephen(a)xemacs.org> spake thusly:
>>>>> "Matt" == Matt Tucker
<tuck(a)whistlingfish.net> writes:
Matt> -- "Stephen J. Turnbull" <stephen(a)xemacs.org> spake thusly:
Matt> I would content that "It's always worked this way" and
"This
Matt> is the correct behavior" are two totally different
Matt> statements.
They are.
By "correct behavior" I mean "matches specifications." Since the
specification of visible behavior was never actually written down, I
approximate it with the historical behavior.
If you want to write a new specification that says that it's a bug,
fine with me. But many many releases of XEmacs have been made with
this "bug" unresolved and unremarked by the people planning releases.
We need to get 21.4 promoted to stable. This is not a showstopper.
Therefore it will wait.
I didn't mean to imply that it was anything I thought should be fixed
for 21.4. I don't even necessarily think it's something that needs to
be fixed in 21.5. It sounds like a difficult problem, and there are
certainly plenty of other things to work on. I simply felt that this is
a bug and should be recognized as such, and that the method for dealing
with it is nothing more than a workaround.
If I ever get the itch, I may try to fix this particular problem. Until
then, I'll simply hope that someone else does, and deal with it as best
I can until then. It's really not that difficult, since I'm aware of
it, but I remember being confused by this and can certainly understand
how it would cause problems for others as well.
Matt> Why should anyone have to muck around with a completely
Matt> different facility for only the _first_ frame?
They shouldn't. That's not what I said, what I said is "go ahead and
find a way to make it work in a desirable way". He did. I'm happy.
So users use Michael's workaround[1] for now, and somebody does
something better and more permanent in 21.5. Maybe it gets
backported to 21.4.
Fair enough. Sorry if I came off like a pompous ass in my response. ;-)
8376
days inactive
8377
days old
13 comments
8 participants
participants (8)
-
Dan Espen -
Hrvoje Niksic -
Matt Tucker -
Michael Toomim -
Michael Toomim -
Peter Brown -
Stephen J. Turnbull -
William M. Perry