January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: "Symbol X has different size in shared object" bug reappears 24 years, 3 months

Hrvoje Niksic

Daniel Pittman <daniel(a)danann.net> writes: > The quick fix[1] is to edit /etc/ld.so.conf and move the entry for > /usr/X11R6/lib/ before the entry for /usr/X11R6/lib/Xaw3d/. This does work. Of course, now I get the ugly plain Athena buttons, but that's OK. When I decide I want 3D Athena, I'll say `--with-athena=3d' to configure, and things will (hopefully) work nicely. We might want to document these things in PROBLEMS, as clearly and legibly as possible.

1 participants
0 comments

Re: Info-directory-list 24 years, 3 months

Mike Fabian

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > > > Hrvoje> Info-directory-list should not be customizable at all. > > > > You're right. I suspect this perversion (Info-directory-list isn't > > even defcustom'ed) came about, because the documentation used to say > > `Info-default-directory-list' at that place, which never worked > > right either. > > OK. > > Now, what we need is a variable that *can* be customized, and that is > nil by default. Info would then use something like > (append <that-variable> Info-directory-list) for its directory search. > Code will be fully backward compatible wrt user customizations because > modifications of Info-directory-list will still work. > > I propose that the new variable be named Info-default-directory-list, > because GNU Emacs calls it that way (and also defaults it to nil.) I just tried in GNU Emacs 20.3.1 and it doesn't seem to default to nil there, it was set to ("/usr/local/lib/info/" "/usr/local/info/" "/usr/info/") after starting emacs with `emacs -q'. A slightly weird behaviour of XEmacs with respect to Info-directory-list is that it does use the value of environment variable INFOPATH, but appends it's contents to the end of Info-directory-list. Therefore, info-files in the .../lib/xemacs/xemacs-packages/info/ directory shadow info-files of the same names in directories from INFOPATH. Is this intentional? I didn't like that, because newer info-files installed somewhere in my HOME directory were shadowed by the older ones which came with XEmacs. I currently circumvent this by appending the contents of INFOPATH once more to the beginning of Info-directory-list in my .emacs: (if (getenv "INFOPATH") (let ((my-additional-info-directories (split-string (getenv "INFOPATH") ":"))) (if (string-match "XEmacs" emacs-version) (setq Info-directory-list (append my-additional-info-directories Info-directory-list)) ;; GNU Emacs (setq Info-default-directory-list (append my-additional-info-directories Info-default-directory-list))))) -- Mike Fabian <mike.fabian(a)gmx.de> <mike(a)nozomi.rhein-neckar.de>

1 participants
0 comments

Tabs' background pixmap 24 years, 3 months

Hrvoje Niksic

I noticed that buffer tabs (aka "gutter") don't inherit the background pixmap of the face they're supposed to be using. This makes them look very ugly for us that use a background pixmap. Here is an example: Different background style makes tabs look separate from the buffer, which breaks the illusion tabs are supposed to create.

3 participants
2 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 3 months

Daniel Pittman

On 05 Jan 2000, Hrvoje Niksic <hniksic(a)iskon.hr> wrote: > Daniel Pittman <daniel(a)danann.net> writes: > >> Hrm. Yes. The detection stuff does have XE_DIE() if we don't get a >> suitably matching library and header combination _and_ if the Athena >> widgets were used somewhere. >> >> Hmmm. My guess is that Hrvoje uses the flat Xaw and has the Debian >> `put something 3D in the LD search path as libXaw' lossage. > > Can't this be detected at configure-time? Note that we're not talking > about an old XEmacs here, tripped by a new 3D Athena package; I get > the reported by simply configuring XEmacs and running it immediately! > > Otherwise, it seems that the XE_DIE check doesn't get called. Do you > think it's a bug? The check should trigger if it finds a *compile time* mismatch. Sadly, this does not seem to follow quite the same rules as ld.so. :( What does ldd(1) say about your XEmacs? Daniel -- When the going gets weird, the weird turn pro. -- Hunter S. Thompson

1 participants
0 comments

Re: Info-directory-list 24 years, 3 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Hrvoje> Info-directory-list should not be customizable at all. > > You're right. I suspect this perversion (Info-directory-list isn't > even defcustom'ed) came about, because the documentation used to say > `Info-default-directory-list' at that place, which never worked > right either. OK. Now, what we need is a variable that *can* be customized, and that is nil by default. Info would then use something like (append <that-variable> Info-directory-list) for its directory search. Code will be fully backward compatible wrt user customizations because modifications of Info-directory-list will still work. I propose that the new variable be named Info-default-directory-list, because GNU Emacs calls it that way (and also defaults it to nil.)

1 participants
0 comments

Re: Global-Set-Key on C-Home ..... gets a complaint? 24 years, 3 months

Hrvoje Niksic

Warren Music <WarrenM(a)concur.com> writes: > It looks like Xemacs sets these up automatically, but I would like > to leave the mappings in my .emacs because I would like to use both > versions (emacs is just a tad faster but Xemacs has some other > things I like). Sure. So what's the problem?

1 participants
0 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 3 months

Hrvoje Niksic

Daniel Pittman <daniel(a)danann.net> writes: > Hrm. Yes. The detection stuff does have XE_DIE() if we don't get a > suitably matching library and header combination _and_ if the Athena > widgets were used somewhere. > > Hmmm. My guess is that Hrvoje uses the flat Xaw and has the Debian > `put something 3D in the LD search path as libXaw' lossage. Can't this be detected at configure-time? Note that we're not talking about an old XEmacs here, tripped by a new 3D Athena package; I get the reported by simply configuring XEmacs and running it immediately! Otherwise, it seems that the XE_DIE check doesn't get called. Do you think it's a bug?

1 participants
0 comments

Re: Info-directory-list 24 years, 3 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> If I understand things correctly, the preferred way to add stuff to Hrvoje> Info directory search path is using `Info-directory-list', e.g.: Hrvoje> (push "~/my-info-dir" Info-directory-list) Hrvoje> or: Hrvoje> (setq Info-directory-list (append '("dir1" "dir2" "dir3") Info-directory-list)) Hrvoje> This works in .emacs because Info-directory-list is autoloaded rather Hrvoje> than set in info.el. The documentation says: Hrvoje> The first directory in this list, the "dir" file there will become Hrvoje> the (dir)Top node of the Info documentation tree. If you wish to Hrvoje> modify the info search path, use `M-x customize-variable, Hrvoje> Info-directory-list' to do so. Hrvoje> The last sentence is IMO wrong: if you change the value of the Hrvoje> variable, you will completely override the autoloaded defaults. This Hrvoje> means that if the autoloaded stuff changes, e.g. by installing a new Hrvoje> package, the new values get ignored. Hrvoje> Info-directory-list should not be customizable at all. You're right. I suspect this perversion (Info-directory-list isn't even defcustom'ed) came about, because the documentation used to say `Info-default-directory-list' at that place, which never worked right either. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 3 months

Daniel Pittman

On 04 Jan 2000, Hrvoje Niksic <hniksic(a)iskon.hr> wrote: > This bug I haven't seen for quite a while has apparently reared it > ugly head one more time. This is printed to stderr when I start > XEmacs: [...] > I've seen this before, and I managed to fix it by finding a magic > combination of 3D Athena headers and libraries with on my system. Its > reappearance is likely due to recent Athena detection rewrite in > configure, but it might also be the a package upgrade. > > I'll be happy to provide relevant data. Any ideas? This is caused by using mismatched flat and 3D Athena headers when building. If you use 3D Athena -- and especially if you have overwritten libXaw.so with a 3D version, make sure that the 3D (or whatever variant) headers are on your path. IIRC you use Debian; the xaw3dg-dev package has suitable headers for the 3D Athena libraries they ship. Oh, if you use flat Athena, BTW, check /etc/ld.so/conf and make sure that the search path does not find something like Xaw3d/libXaw first. ldd(1) is good for that. :) This should probably be in PROBLEMS, I guess. Also the Installation file should log what Athena library and headers were used. I will work on a patch for these later today. Daniel -- Of all lies, art is the least untrue. -- Flaubert

3 participants
2 comments

Confusion surrounding CVS xemacs-packages usability 24 years, 3 months

Michael Lee Crogan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to keep a hierarchy of XEmacs/xemacs-packages CVS updated and usable for the xemacs binaries installed. However, I am thoroughly confused about how to set this up without using symbolic links and long EMACSLOADPATH's. When I drop the SUMO xemacs packages (and mule packages) into the appropriate directory, then xemacs is easily able to find any and all packages. The layout of the directories that the two tar files (sumo packages and sumo mule) creates is: {xemacs,mule}-packages/{etc,info,lib-src,lisp,man,pkginfo}. However, when doing a CVS update of XEmacs/xemacs-packages, the layout is considerably different. I place the CVS hierarchy in /usr/local/src/XEmacs/XEmacs/xemacs-packages. Now because xemacs is not going to look here unless directed to by the load-path, I need to make this available to users automatically--perhaps through a single symbolic link. My initial approach was to, from /usr/local/lib/xemacs-21.2-b26: ln -s ../../src/XEmacs/XEmacs/xemacs-packages . and ln -s ../../src/XEmacs/XEmacs/xemacs-packages/mule ./mule-packages However this approach fails. I could consider populating the directory with mysterious symbolic links so that the two layouts appear to be the same, but this does not seem to be the best approach and would even be hard to automate because there are exceptions in the layout of the tree that would have to be dealt with manually. Clearly untarring the SUMO packages works without any additional effort. However there seems to be no way to do the same for the checked out CVS xemacs-packages tree. My first step after doing the CVS update is to do a ``make World'' from that directory (which completed successfully). Initially I thought that this would take care of presenting the available packages to XEmacs automatically, but this was not the case. The advantage of using CVS is the speed of doing a CVS update rather than fetching a new SUMO tar file or even fetching newer packages one by one. From having a checked out CVS xemacs-packages tree and an xemacs-21.2-b26 base install (with defaults), what is the quickest and most elegant way to present the former to the latter so that all packages are available? Any help on this matter would be greatly appreciated. Michael Lee Crogan -- <mcrogan(a)purdue.edu> -- Purdue University -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (HP-UX) Comment: Processed by Mailcrypt 3.5.4 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE4ctI+6BV6u092RJURAvVTAJsEuJHvneY1qvpKW17k8rfLvob3FwCeIDrX KkV6JKGWw2rlS7albuvZaiE= =wQU6 -----END PGP SIGNATURE-----

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 January 2000