March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Steve's 21.2.32 crashes 24 years, 8 months

Hrvoje Niksic

SL Baur <steve(a)beopen.com> writes: > The problem is related to how I set X resources. (Ignoring Andy's > test patch) When I `xrdb < /dev/null', XEmacs starts up. When I have > the single X resource: > > XEmacs.modeline.attributeBackgroundPixmap: nothing > > XEmacs crashes. Yes, specifying the background pixmap of any face apparently causes a crash. Andy promised to fix it.

1 participants
0 comments

Re: Interesting bug 24 years, 8 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > It seems if you let bind a constant string, e.g: > > (let ((mystr "\n")) ...) > > and then attach an extent to it, if you run this code the extents > will *accumulate* rather than replace each other. Semantically when > I let bind a constant string I would expect it to be extent free... When you write "\n", you don't necessarily get a fresh string. Your code is equivalent to this C code: while (1) { char *p = "buhaha"; ... change contents of p ... } You may get a coredump doing so, but then again you may not.

1 participants
0 comments

Hash patch 24 years, 8 months

Andy Piper

This makes sure clicking always does something. 2000-03-20 Andy Piper <andy(a)xemacs.org> * glyphs.c (full_list_hash): make hashes of the same elements in different orders return different values. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
2 comments

I don't wont the f* underlinings in the menubar (aka accelerators) 24 years, 8 months

Giacomo Boffi

=============================================================== I DON'T LIKE THE UNDERLININGS IN THE MENUBAR (AKA ACCELERATORS) =============================================================== i told you so that you don't have to speculate about my feelings on that new user interface feature Ben Wing wrote: > 1. When you add a new user interface feature, and you think people > might not like it, make sure you put something on the Options > menu for this as well as just documenting a magic incantation > in NEWS. ciao

2 participants
2 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

Hrvoje Niksic

Jens Lautenbacher <jtl(a)schlund.de> writes: > mozilla wants to replace gtk again as ar as I know with pure xlib. > They do their own widgets now for very good reasons, still based at > the moment on gtk, but this makes no sense in the long run. The whole Mozilla thing is disgusting. Their whole Gtk hype was nothing but a marketing trick to try to attract "geek" developers. > One thing I toyed with if it wouldn't be a nice thing to simply use > gecko as XEmacs display engine... The gecko thing is far less modular/stable than it was intended to be. Maybe in a few years when it's finished. But it still won't be _simple_.

1 participants
0 comments

configure error with XFree86-4.0 24 years, 8 months

Hardy Mayer -- for reply, remove 'XXX-...-XXX'

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. In XEmacs 21.2 (beta32) "Kastor & Polydeukes" [Lucid] (i686-pc-linux) of Tue Mar 21 2000 on cx767414-a configured using `configure --ldflags=-s' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: In XEmacs 21.2 (beta32) "Kastor & Polydeukes" [Lucid] (i686-pc-linux) of Tue Mar 21 2000 on cx767414-a configured using `configure --ldflags=-s' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I tried to run configure with the new release of XFree86 version 4.0 installed, and configure failed to find X11/Intrinsic.h. Since I kept the previous version (3.3.6), I ran configure again after making a symbolic link to it. This time it worked, and the compilation worked fine with theXFree86-40 includes and libraries. I find this very strange, since the directory trees of both are identical (modulo dates and sizes, of course) and /usr/X11R6/include/X11/Intrinsic.h exists in both. In addition, there is a sym-link //usr/X11R6/include/X11 -> /usr/include/X11, so configure should have seen it. The only difference between the two files is in their rcs-headers: /* $TOG: Intrinsic.h /main/178 1998/02/06 13:23:20 kaleb $ */ versus /* $XConsortium: Intrinsic.h /main/176 1996/08/31 06:51:04 kaleb $ */ /* $XFree86: xc/lib/Xt/Intrinsic.h,v 3.2 1996/12/23 06:01:18 dawes Exp $ */ Could this make the difference? I have also reported this problem to XFree86.org. In addition, the "server-start" entry in my .emacs file failed. Recent keystrokes: misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Error in init file: Symbol's function definition is void: server-start -- Hardy -------****------- Meinhard E. Mayer, Research Professor of Physics and Mathematics Department of Physics and Astronomy, Frederick Reines Hall U. C., Irvine CA 92697-4575 In California: Tel: (949) 824-5543; UCI-FAX: (949) 824-2174 Home: 759-3378 E-fax: (734) 448-5140 URL: http://www-swiss.ai.mit.edu/~hardy/hardy.html http://www.ps.uci.edu/physics/mayer.html

1 participants
0 comments

I will be relatively inactive for a while 24 years, 8 months

Martin Buchholz

I'll be in Japan at m17n2000 and being a tourist for the next few weeks - exact plans uncertain. Martin

1 participants
0 comments

Re: Accelerator I18N [was: I don't wont the f* underlinings ...] 24 years, 8 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> Well, I think they're real purdy. :-) > > You obviously haven't tried this with a localized menubar. Indeed, I haven't. But accelerators are easy to add to the translations, aren't they? You just use the same %_ convention. > Has anybody thought about how to make accelerators "purdy" in > Japanese and Chinese? On second thought, how they are supposed to > work at all? I certainly haven't. The Japanese and Chinese will have to provide us with input regarding that issue. > For the implementor's information, Japanese accelerators under > Windows are indicated by an underlined Roman capital letter, That's sort of like Ben's numbered accelerators provided for menus that don't have explicit ones. > Oh yeah, the accelerators for _M_ule and C_m_ds are the same. I've complained about that. The same goes for "_M_essage" with Gnus. I don't know what's wrong, but I assume Ben will fix it. > By the way, Ben's improvements have made a bunch of work for menubar > localizers (who already have localized menus to work > with---obviously it doesn't matter for those who will be starting > fresh). Yes. Most improvements make a bunch of work for someone. Translators should be prepared to deal with a moving target.

3 participants
2 comments

Re: Ben's massive changes #1 24 years, 8 months

Robert Pluim

Ben Wing writes: > If people really don't like these accelerators > appearing at the beginning of the menu items, a variable can be > added to optionally turn them off, but I think this is rather > pointless because other menu items have accelerators and many or > most of the menu users will use the accelerators if the support is > there. The other menu changes I like a lot, the accelerators I absolutely despise (they just visually jar). Would it be possible to add this variable for turning them off? Thanks Robert -- The above are my opinions, and my opinions only.

5 participants
5 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

William M. Perry

<nic(a)niss.ac.uk> writes: > Jens Lautenbacher wrote on 21-March-2000: > > ->now I'm really not in the position to argue on technical stuff with > ->people like Ben or Bill or Michael, but shouldn't we at least consider > ->to remove some of the backward compatibility stuff for xemacs? gtk > ->can be compiled on quite a big range of unix machines (and on win32, > ->too by the way, although I don't think that this will be an option the > ->win32 people like to consider). > > Removing X/Xt support from XEmacs would result in all of us being sent > to bed with no supper. I'm not talking about _removing_ it. I'm talking about having another option. Basically if you ask for gtk support (I don't think this would be turned on by default except in infodock), you lose certain features, like: - multi-display capabilities (until gtk supports it) - Xt integration But you gain: - gnome integration (feh) - themes (oh boy I'm all hot now) - Ability to write real gtk applications from emacs lisp Basically, this is just replacing the lwlib cruft with gtk widgets and then doing rep-gtk (http://rep-gtk.sourceforge.net) for the 'real' emacs-lisp. -Bill P.

2 participants
1 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 2000