December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[mule] can't open iso-2022-jp and euc-jp mixed file 27 years

Martin Buchholz

I can't reproduce your crash. Also, I can't find a mcharset package. Here's what I did: (require 'emu-x20) (setq jis (mapconcat 'char-to-string '(?\^[ ?\$ ?B ?\$ ?\" ?\^[ ?\(?B) "")))) (setq euc (encode-mime-charset-string (decode-mime-charset-string jis 'iso-2022-jp) 'euc-jp)) (setq jiseuc (concat jis euc)) ;; fatal error (6) is happen at next line. (decode-mime-charset-string jiseuc 'automatic-conversion) This produced a string containing one kanji and 2 iso-8859-1 characters. Martin

1 participants
0 comments

Warnings while compilation 27 years

Christian Kurz

Hi, I've compiled XEmacs 21.0b59 one time with X-Support and one time without. Both times the compilation suceeded and XEmacs was working. But I found the following warnings. I don't know if they are interesting, but I think so and post them now. With X-Support the following warnings are presented: /home/shorty/work/xemacs-20/lib-src/etags.c: In function `hash': /home/shorty/work/xemacs-20/lib-src/etags.c:1849: warning: array subscript has type `char' /home/shorty/work/xemacs-20/lib-src/etags.c:1849: warning: array subscript has type `char' /home/shorty/work/xemacs-20/lib-src/ootags.c: In function `hash': /home/shorty/work/xemacs-20/lib-src/ootags.c:1912: warning: array subscript has type `char' /home/shorty/work/xemacs-20/lib-src/ootags.c:1912: warning: array subscript has type `char' search.c: In function `Fmatch_data': search.c:2265: warning: `prev' might be used uninitialized in this function search.c:2325: warning: `_obj' might be used uninitialized in this function redisplay-x.c: In function `x_flash': redisplay-x.c:2256: warning: implicit declaration of function `poll' Without X-Support the following warnings are presented: /home/shorty/work/xemacs-20/lib-src/etags.c: In function `hash': /home/shorty/work/xemacs-20/lib-src/etags.c:1849: warning: array subscript has type `char' /home/shorty/work/xemacs-20/lib-src/etags.c:1849: warning: array subscript has type `char' /home/shorty/work/xemacs-20/lib-src/ootags.c: In function `hash': /home/shorty/work/xemacs-20/lib-src/ootags.c:1912: warning: array subscript has type `char' /home/shorty/work/xemacs-20/lib-src/ootags.c:1912: warning: array subscript has type `char' events.c: In function `Fmake_event': events.c:637: warning: unused variable `f' search.c: In function `Fmatch_data': search.c:2265: warning: `prev' might be used uninitialized in this function search.c:2325: warning: `_obj' might be used uninitialized in this function Christian

1 participants
0 comments

Re: [Aphrodite] Gnus reports several warnings 27 years

Didier Verna

Marcus Thiessel writes: mt> The following messages are reported to stderr: Comparison between integer mt> and character is constant nil (0 and ?2) This is an Ebola notice. I know where it comes from in gnus, and I'd even sent a patch. However, Hrovje pointed out to me that the warnings, rather than the code are bogus in this case. Ebola warnings are generated when you try to compare chars and ints, but there are cases where this can be perfectly intentional, like looping a comparison on elements of a list whose types are different. Ebola is not clever enough to detect that and shut up. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

[Aphrodite] Gnus reports several warnings 27 years

Marcus Thiessel

The following messages are reported to stderr: Comparison between integer and character is constant nil (0 and ?2) [nntp-retrieve-headers, gnus-retrieve-headers, gnus-cache-retrieve-headers, gnus-retrieve-headers, gnus-select-newsgroup, gnus-summary-read-group-1, gnus-summary-read-group, gnus-group-read-group, gnus-topic-read-group, gnus-mouse-pick-topic, call-interactively] Comparison between integer and character is constant nil (0 and ?2) [nntp-retrieve-headers, gnus-retrieve-headers, gnus-cache-retrieve-headers, gnus-retrieve-headers, gnus-select-newsgroup, gnus-summary-read-group-1, gnus-summary-read-group, gnus-group-read-group, gnus-topic-read-group, gnus-mouse-pick-topic, call-interactively] Comparison between integer and character is constant nil (0 and ?2) [nntp-retrieve-headers, gnus-retrieve-headers, gnus-cache-retrieve-headers, gnus-retrieve-headers, gnus-select-newsgroup, gnus-summary-read-group-1, gnus-summary-read-group, gnus-group-read-group, gnus-topic-read-group, gnus-mouse-pick-topic, call-interactively] --Marcus

1 participants
0 comments

Re: New SUMOs 1998-12-09 uploaded to ftp.xemacs.org 27 years

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > These are somewhat different than the ones Jan made. They don't have > an lib/xemacs prefix, and XEmacs/Mule and non-Mule are separated. If > this is a problem let me know. Not for me. However my SUMOs both contained and were accompanied by a README with installation instructions and a list of included packages and in what version. I think that would still be good to have. Jan

1 participants
0 comments

Re: irchat & other package updates 27 years

Jan Vroonhof

Pekka Marjola <pema(a)iki.fi> writes: > (BTW, if there are problems with idea.el, irchat does not require it > and could be distributed without it - just add a note pointing > original site.) I think that was the problem yes. > > I finally started using package tools. Getting updated package list > required some digging, since package-ui seems not have any direct > commands for that. (BTW, latest package list lists irchat - with > zenirc description.) Could you please describe "digging"? I have a patch submitted to XEmacs patches that automatically offers to update the list-packages list. It is not in yet however. > I have all package tarballs copied to local directory. Adding > directory was quite simple, though I don't it's a good idea to delete > local tarballs by default. Are you sure it is doing that? How did you add the local directory, by adding the dir to package-get-remote? Then package-get should not delete them. > I had old versions of packages installed with symlinks (installit Perl > tool), and tried to upgrade on top of those. If these were 'pre MANIFEST' packages then this would happen I think. With modern packages it just deletes all files from pkginfo/MANIFEST.name > package-ui is quite useful, but I'd like it to make distinction > between multiple install dirs. Say, if I want to install some packages > to ~/.xemacs, some to xemacs-21.0/lib/xemacs-packages and some to > xemacs/lib/xemacs-packages, I'd like to know which versions are > installed where and to easily change targets. Package-ui is not up to this right now. Something for after 21.0 Jan

1 participants
0 comments

Re: XEmacs cannot find site-packages?? 27 years

Les Schaffer

> However, INSTALL doesn't mention yet that the site-lisp stuff is > turned off by default as of 21.0. Turn it back on with > --with-site-lisp on the configure command line. okay okay. but i am still curious to hear WHY the new default? should stuff in the old site-lisp dirs go somewhere else by default now???? les schaffer

1 participants
0 comments

Re: Window Maker bug or feature? 27 years

Jan Vroonhof

Didier Verna <verna(a)inf.enst.fr> writes: > Jan> I would then say this an window-maker bug. A title-bar only > Jan> window is the NeXT'ish equivalent of being iconified (the icons > Jan> are always visible under window-maker I think) so it should > Jan> just tell the application it is. > > This would be dangerous because when a window is iconified, > the application has the right to request the icon's window-id > which may not exist. Afterstep, for instance doesn't provide > an icon when windows are shaded. >From the ICCCM v2: IconicState - The client's top-level window is iconic (whatever that means for this window manager). The client can assume that its top-level window is not viewable, its icon_window (if any) will be viewable and, failing that, its icon_pixmap (if any) or its WM_ICON_NAME will be displayed. Note "what ever that means", seems like the windowmanager is fairly free. "if any", icon window does not need to exist. (I think it does in window maker). The problem is more in the "can assume [limited set of options] is viewable/displayed" part. However I think that can safely be ignored given the fact that this text is followed by In fact, the window manager may implement states with semantics other than those described above. For example, a window manager might implement a concept of an "inactive" state in which an infrequently used client's window would be represented as a string in a menu. But this state is invisible to the client, which would see itself merely as being in the Iconic state. I think the "only title bar visible" state is more or less what the ICCCM describes here with as "inactive". So I still think it would be better if window maker implemented this as "iconic". Jan

1 participants
0 comments

irchat & other package updates 27 years

Pekka Marjola

First, has someone latest irchat package since it is not in /pub/xemacs/packages... (BTW, if there are problems with idea.el, irchat does not require it and could be distributed without it - just add a note pointing original site.) I finally started using package tools. Getting updated package list required some digging, since package-ui seems not have any direct commands for that. (BTW, latest package list lists irchat - with zenirc description.) I have all package tarballs copied to local directory. Adding directory was quite simple, though I don't it's a good idea to delete local tarballs by default. I had old versions of packages installed with symlinks (installit Perl tool), and tried to upgrade on top of those. Old lisp directories were removed and replaced without promblems, but is there some particular reason why etc and info were not updated? I haven't followed discussion that closely... package-ui is quite useful, but I'd like it to make distinction between multiple install dirs. Say, if I want to install some packages to ~/.xemacs, some to xemacs-21.0/lib/xemacs-packages and some to xemacs/lib/xemacs-packages, I'd like to know which versions are installed where and to easily change targets. Setting pui-package-install-dir to "~/.xemacs" caused package to be silently installed to ~/lisp etc. Adding slash helped... Then deleting packages required eval'ing, since ~/.xemacs was not default location. Looking good already... (Sorry, no time to make patches right now.) -- Pekka Marjola * pema(a)iki.fi * http://www.iki.fi/pema/ * PGPid 0x2865206D

1 participants
0 comments

Re: [failure] alphaev56-unknown-linux 27 years

Aki Vehtari

"nbecker" == nbecker <nbecker(a)fred.net> writes: nbecker> b59 alphaev56-unknown-linux nbecker> egcs-1.1.1 nbecker> myserable failure. egcs-2.90.27 980315 (egcs-1.0.2 release) worked for me on alphaev5-unknown-linux. See my build report in xemacs-build-reports mailing list (at the time of writing not yet in mailing list archive). Aki

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 December 1998