July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[patch] Removal of GIF support 26 years, 5 months

Jareth Hein

It really pains me to have to do this, but UniSys has given us no choice. Due to their claims that "Our patents cover both creating graphics and displaying (e.g., reading, decompressing) LZW. As such, a license is rquired to create or distribute products incorporating such capability." we must remove this support from XEmacs, and I am requesting that all of you who've downloaded GifReader please delete it. 1998-07-21 P. E. Jareth Hein <jareth(a)camelot.co.jp> * glyphs.c: Fix docstring of image-specifier-p to note added TIFF support and removal of GIF support * configure.in, glyphs-x.c, config.h.in: Removal of GIF support due to patent problems. -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder

3 participants
2 comments

Re: name conflict 26 years, 5 months

Michael Sperber

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> [I'm still planning on moving the non-c tm executables out of the core sb> prior to release, unless you've changed your mind.] sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-beta(a)xemacs.org: >> For 21.2, I suggest that we: >> 1. Generate `exec-path' from $PATH, and don't change anything. >> 2. See to it that packages use `exec-directory' for stuff from lib-src. sb> A single directory is a lose. We have to deal with external Lisp sb> packages that may wish to install executables into the search path sb> too. Ah! Forgot about that. Another path it must be, then. The argument remains the same, though. sb> At the moment the issue has been mostly ignored, but it shouldn't be. >> 3. Move movemail into the main bin directory, and search for it >> through `exec-path', as Martin suggests. >> Certainly, prepending architecture-specific stuff to `exec-path' is >> bad juju. sb> Why? Except for the movemail case, it would seem reasonable to me. Because XEmacs presents a different view of what the system path is from what the underlying system does. If XEmacs has its own ideas about where it looks for executables, it should clearly distinguish that view from the system's view. The movemail case demonstrates that you're always going to lose in some cases if you throw them all in one pot. I have designs for a more general infrastructure to handle this kind of problem, and intend to hack it into 21.2. It's obviously more pressing for `load-path', but I think a general, more flexible solution is possible for `exec-path' as well. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: name conflict 26 years, 5 months

SL Baur

[I'm still planning on moving the non-c tm executables out of the core prior to release, unless you've changed your mind.] Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-beta(a)xemacs.org: > For 21.2, I suggest that we: > 1. Generate `exec-path' from $PATH, and don't change anything. > 2. See to it that packages use `exec-directory' for stuff from lib-src. A single directory is a lose. We have to deal with external Lisp packages that may wish to install executables into the search path too. At the moment the issue has been mostly ignored, but it shouldn't be. > 3. Move movemail into the main bin directory, and search for it > through `exec-path', as Martin suggests. > Certainly, prepending architecture-specific stuff to `exec-path' is > bad juju. Why? Except for the movemail case, it would seem reasonable to me.

1 participants
0 comments

Re: name conflict 26 years, 5 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "Jeff" == Jeff Miller <jmiller(a)smart.net> writes: >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> [redirected to xemacs-beta] sb> gnuserv in XEmacs isn't installed into a user-visible directory and sb> the XEmacs architecture specific directory should get prepended to the sb> search patch, right? Jeff> I suggested this a long time ago. This would also fix a lot of the Jeff> movemail problems, or any other exe where we're expecting a certain Jeff> version of something. Right now, old tm installations, gnats, metamail Jeff> etc can potentially screw us over. Martin> Whether progs in exec-directory are run without benefit of PATH is a Martin> judgment call. Martin> The `gnuserv' executable is tightly bound to the XEmacs it works with, Martin> so gnuserv should be executed directly from `exec-directory', without Martin> using PATH. Martin> `movemail' in `exec-directory', on the other hand, is less likely to Martin> be an improvement on the movemail earlier in the PATH. In particular, Martin> it is less likely to be properly setgid. So movemail should be Martin> exec'ed using PATH. We discussed these issues awhile ago. The real problem is that XEmacs messes with `exec-path' at all because a number of packages execute things off it which come from lib-src. For 21.2, I suggest that we: 1. Generate `exec-path' from $PATH, and don't change anything. 2. See to it that packages use `exec-directory' for stuff from lib-src. 3. Move movemail into the main bin directory, and search for it through `exec-path', as Martin suggests. Certainly, prepending architecture-specific stuff to `exec-path' is bad juju. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Is anyone regularly using XEmacs on a color tty? 26 years, 5 months

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > > When are we supposed to get colors on tty ? > > Since XEmacs 19.14. Forget it. I killed the Strogg leader yesterday night, but during the fight, I obviously got brain damaged. > Perhaps the color test performed by XEmacs is suspect. Evaluate > (device-class) > in *scratch*. If it returns `color', then XEmacs thinks it's running > on a color terminal, else it returns `mono'. Funny. In my color_xterm on solaris, device-class returns mono, however, *after* loading my init files, I indeed get a few colors in font-lock enabled buffers. I don't see how XEmacs can think he's using a mono terminal and output colors all the same. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Is anyone regularly using XEmacs on a color tty? 26 years, 5 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> I just did a quick look-see on a Linux console and the default colors >> suck. Almost anything would be better. Has anyone developed a tty >> color palette for their own use they would like to share? > When are we supposed to get colors on tty ? Since XEmacs 19.14. > Has it something to do with ISO 6429 ? All I can get is bold fonts. Perhaps the color test performed by XEmacs is suspect. Evaluate (device-class) in *scratch*. If it returns `color', then XEmacs thinks it's running on a color terminal, else it returns `mono'. If I execute `xemacs -nw' in an XTerm (an orphaned ansi color xterm variant with scrollbars on the right) it reports `mono' to the above test although Lynx, color-ls and jed (to name three programs off the top of my head) have no problem displaying color. kterm is always detected as color. In src/redisplay-tty.c (init_tty_for_redisplay): { /* check for ANSI set-foreground and set-background strings, and assume color if so. #### we should support the other (non-ANSI) ways of specifying color, too. */ char foobuf[500]; char *fooptr = foobuf; if ((tgetstr ("AB", &fooptr) && tgetstr ("AF", &fooptr)) || (tgetstr ("Sf", &fooptr) && tgetstr ("Sb", &fooptr)) || ((tgetnum ("Co") > 0) && (tgetnum ("pa") > 0))) DEVICE_CLASS (d) = Qcolor; else DEVICE_CLASS (d) = Qmono; }

1 participants
0 comments

Re: Is anyone regularly using XEmacs on a color tty? 26 years, 5 months

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > I just did a quick look-see on a Linux console and the default colors > suck. Almost anything would be better. Has anyone developed a tty > color palette for their own use they would like to share? When are we supposed to get colors on tty ? Has it something to do with ISO 6429 ? All I can get is bold fonts.

1 participants
0 comments

Re: name conflict 26 years, 5 months

SL Baur

[redirected to xemacs-beta] gnuserv in XEmacs isn't installed into a user-visible directory and the XEmacs architecture specific directory should get prepended to the search patch, right? Or wrong: C-h v `exec-path' is a simple built-in variable. Value: ("/usr/openwin/bin/" "/home/steve/bin/" "/bin/" "/usr/bin/" "/usr/X11R6/bin/" "/usr/ucb/" "/usr/local/bin/" "/usr/bin/mh/" "/usr/local/www/bin/" "/usr/new/pbm/" "/usr/games/" "/usr/local/games/bin/" "/home/xemacs/xemacs-21.2/lib-src/") Documentation: *List of directories to search programs to run in subprocesses. Each element is a string (directory name) or nil (try default directory). Hmm. This might be a problem, but would the `gnuserv' in this package also be kept in a non-user-path directory? A setuid root program is not something I would casually add to the default system search path. Michael Harnois <mharnois(a)sbtek.net> writes: > I just ran across something that I think represents a potential > conflict ... > While building libgtop, "a library that fetches information about the > running system such as cpu and memory usage, active processes etc. On > Linux systems, these information are taken directly from the /proc > filesystem. For other systems such as Solaris, where such programs > need to be suid root (or only setgid kmem/mem on some systems), it > provides a suid/setgid server that fetches those information and a > client-side library that talks to this server" > I found out the daemon program is named gnuserv. > The author is Martin Baulig (martin(a)home-of-linux.org).

3 participants
3 comments

XEmacs 21.0-b49/pre6 "Belgian Fawn" is released 26 years, 5 months

SL Baur

This is the start of the out-of-alphabetical order Goats I warned you about last announcement. They will be alphabetical from now on. The next edition of XEmacs 21.0 has been uploaded to the ftp site. ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.0/ CVS sources are at http://cvs.xemacs.org/ Installable Lisp packages are in: ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.0/packages/binary-packages/ The CVS tag for this beta is `r21-0b49'. The CVS tag for the 21.2 branch is `release-21-2'. This release contains bug fixes and is a release candidate. I have further patches for about.el pending that don't effect basic testing. All such patches will get into 21.0 released. We're going to delay release until late August for further package support and the binary coordinator to get back from vacation. Um, it appears I've screwed up package-get-base.el in both 21.2-b1 and this release. Could someone please propose some code to deal with this file coming from ftp.xemacs.org? The whole XEmacs community will love you if you do. to 21.0 pre6 "Belgian Fawn" -- Miscellaneous bug fixes from various people -- Rename MS Windows 'resource image instantiator to 'mswindows-resource courtesy of Altrasoft and Ben Wing

4 participants
3 comments

Is anyone regularly using XEmacs on a color tty? 26 years, 5 months

SL Baur

I just did a quick look-see on a Linux console and the default colors suck. Almost anything would be better. Has anyone developed a tty color palette for their own use they would like to share?

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