March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

21.0-b66 splash screen is slightly different 25 years, 8 months

Raymond Toy

I notice that in 21.0-b66 the splash screen is slightly different than what it used to be. The copyright statements are in bold-italic. However, in b65 the actual font used is: (face-font-name (find-face 'bold-italic)) => "-adobe-courier-bold-o-*-*-*-120-75-75-*-*-*-*" But b66 says: (face-font-name (find-face 'bold-italic)) "-*-courier-bold-i-*-*-*-120-*-*-*-*-iso8859-*" The main difference is that in b66 bold-italic is pretty ugly because it (I think) the server uses the scalable courier font and creates an italic version out of it. What it used to do use get the oblique version, for which there is a nice-looking bitmap font. I haven't changed anything in my setup between these versions. I still have *try-oblique-before-italic-fonts* set to T, so obviously something is different. The obvious workaround is to set these fonts explicitly. Not what I wanted because that happens too late for the splash screen. Ray

1 participants
0 comments

Re: Trying out "Backspace direction reversion" 25 years, 8 months

Raymond Toy

>>>>> "gf" == Gary D Foster <Gary.Foster(a)Corp.Sun.COM> writes: gf> That suspicion would be incorrect. I fixed a bunch of packages that gf> did that, and changes were made to others (such as cc-mode) to take gf> into account an intelligent approach to determining expected actions. gf> Sounds like mh-e fell through my filters, though. Yes, I remember now that you had patched up a bunch of stuff quite a while ago. I didn't follow that discussion too closely because what I had worked (and still does). So, since you've done it for so many other packages, I'll let you cons up the appropriate patch for mh-e. Thanks for you work! Ray

1 participants
0 comments

Re: Trying out "Backspace direction reversion" 25 years, 8 months

Gary D. Foster

>>>>> "RT" == Raymond Toy <toy(a)rtp.ericsson.se> writes: RT> I suspect every single package that binds DEL to something is RT> broken since the backspace key doesn't return DEL anymore. RT> This is easy to fix for an experienced user, but we should fix RT> all of the packages to bind the appropriate key depending on RT> the setting of delete-key-deletes-forward. (Hmm, What happens RT> if the user changes the value during a session? What should RT> happen?) That suspicion would be incorrect. I fixed a bunch of packages that did that, and changes were made to others (such as cc-mode) to take into account an intelligent approach to determining expected actions. Sounds like mh-e fell through my filters, though. -- Gary F. -- "Whenever you find yourself on the side of the majority it is time to pause and reflect." -- Mark Twain

1 participants
0 comments

Trying out "Backspace direction reversion" 25 years, 8 months

Raymond Toy

With the discussion of the "backspace direction reversion" lately, I thought I would give it a try. For the longest time, I've had the key above return (marked BackSpace on my Sun Type-5 keyboard) set up to return a Delete keysym and had set my tty erase to ^?. So I changed my tty erase character and my xmodmap settings so that backspace returned a backspace. Then I set delete-key-deletes-forward to t as Steve wanted. Everything pretty much works as expected[1], and works fine on a sun console window! There is one problem: mh-e expects DEL to scroll back the message buffer. This doesn't work anymore since my backspace key doesn't say DEL anymore. I suspect every single package that binds DEL to something is broken since the backspace key doesn't return DEL anymore. This is easy to fix for an experienced user, but we should fix all of the packages to bind the appropriate key depending on the setting of delete-key-deletes-forward. (Hmm, What happens if the user changes the value during a session? What should happen?) Ray Footnotes: [1] Well, netscape didn't like it anymore, but that's because I forgot to remove my .motifbind file to get netscape to understand my old setup. Changing backspace to generate BS also had a nice effect on another application I use at work that had BS and DEL hardwired and therefore broken in my old setup, but corrected now. Cool!

2 participants
1 comments

Re: BUG REPORT: Custom Unwanted Face/Color interaction 25 years, 8 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I think I know how to solve this (and the MULE font problem) as > follows > 1. custom adds it stuff to the specifier with a 'custom tag. > 2. reset-face is replaced by > '(remove-all-face-specifier-entries-with-tag face '(custom)) Yes yes yes! For more than a year, my TODO list has contained an entry saying "defface: RESET ONLY WHAT YOU KNOW ABOUT!"

2 participants
1 comments

Re: BUG REPORT: Custom Unwanted Face/Color interaction 25 years, 8 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > Actually it annoyingly flashes gray for a second, and then switches > back to black, which is my non-shell-buffer default background. So it does work according to plan (not sure why it is flashing, there really shouldn't be any redisplay in between those settings). It is just that in your case the plan is not working :-). Please cut custom some slack. It has already improved a lot. It used to be that you got white on black after using the font menu. Then you got black on gray always. Now you get your original colors black. The only thing custom cannot restore currently is settings that are dynamically changed using lisp. > A user has the right to expect that using the font menu will change > fonts, not colors. We have to find a way to fix the current behavior. I am afraid it is 'no can do' for the moment. Except to give font-menu a variable to not use custom. I think I know how to solve this (and the MULE font problem) as follows 1. custom adds it stuff to the specifier with a 'custom tag. 2. reset-face is replaced by '(remove-all-face-specifier-entries-with-tag face '(custom)) This changes the way custom specs work. Custom will override only those settings it actually sets. Thus it 1. Will not mess with colors when setting the fonts. 2. Will leave defaults/resources alone by not deleting their specifier entries. Thus it the call to 'x-init-global-faces is no longer necessary, nor are the calls to init-face-from-resources 3. It no longer destroys the Mule info. 4. Will probably make it incompatible with FSF 20.3 However I think it is too late to do it for 21.0. This is what per meant with discussing this in Tsukuba. Jan P.S. Do you think the font-menu should not use custom? Currently custom is used for all things in the Options menu (and only those). Isn't that consistent?

3 participants
2 comments

Re: BUG REPORT: Font menu font selection 25 years, 8 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > Lucidatypewriter to Courier. I have to use > Options->Font->Lucidatypewriter to get back to my preferred typeface. > This seems like a clear user interface bug. It is. Unfortunately I do not know a good way to solve this. Maybe the best way for now would be to always specify family and size to custom. i.e change (when (and family (not (equal family from-family))) (setq new-props (append (list :family family) new-props))) to ; (when (and family (not (equal family from-family))) (setq new-props (append (list :family (or family from-family)) new-props)) ; ) Does that work for you? Jan

2 participants
1 comments

Re: BUG REPORT: Custom Unwanted Face/Color interaction 25 years, 8 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > other buffers. So I do something like this: > > (add-hook > 'shell-mode-hook > (lambda () > (set-face-background 'default "midnightblue" (current-buffer)))) > > If I start a shell, then change fonts by doing Options->Size->14, my > font sizes do indeed change, but my background color customization is > gone. This is "intentional". Using custom (and thus the font-menu) overrides all runtime changes. I agree it is unexpected. At least you get gray instead of white. We should discuss in Tsukuba whether custom should really work that way, but currently this is the way it does. > Subsequently started shell buffers are back to midnightblue. And this is because the hooks change it back. No bugs. just funny effect of the way custom works. I am pretty sure this works the same on FSF Emacs. Jan

2 participants
1 comments

Re: Migrating old options files? 25 years, 8 months

Jan Vroonhof

Marat Boshernitsan <maratb(a)cs.berkeley.edu> writes: > Had this isuue ever been resolved? Unfortunately No. Jan

1 participants
0 comments

Migrating old options files? 25 years, 8 months

Marat Boshernitsan

I noticed a thread in xemacs-beta archives about migrating old options files to 21.0 (http://www.xemacs.org/list-archives/xemacs-beta/9806/msg00372.html). Had this isuue ever been resolved? Thanks, Marat.

1 participants
0 comments

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 March 1999