December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Modules (was: Re: How about a feature freeze) 24 years, 11 months

John S. J. Anderson

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> john s jacobs anderson <jacobs(a)xemacs.org> writes: >> In order to really be attractive, I think Jan's suggestion would >> need to be accompanied by a mp3 player mode, and the inclusion of >> one or more of the IM/chat modes in the standard tarball. Jan> There already have UDP support in XEmacs 21.2 to support eicq and Jan> there are several mp3 control programs in elisp. I haven't seen Jan> an mp3 decode in elisp yet. One day, I will learn not to doubt the feature set of the One Editor. I actually had another thought on a way we could attract the 'transparent xterm' market segment: transparent console mode. "D00d! Itz the k-r4d n3w th1ng!!1!" On second thought... john. -- ------------------------------------------------------------------------ John S Jacobs Anderson \ <URL:http://www.xemacs.org> You'll have to pry my Emacs from my cold \ jacobs(a)xemacs.org dead oversized control-pressing left pinky finger. -- Randal L. Schwartz

1 participants
0 comments

Re: Modules (was: Re: How about a feature freeze) 24 years, 11 months

Karl M. Hegbloom

>>>>> "jsja" == john s jacobs anderson <jacobs(a)xemacs.org> writes: >>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> Jan Vroonhof wrote: >>> <fatalist> If the purpose is to attract more users, high >>> priority should given to implement transpart background >>> support Ben> explain? jsja> s/transpart/transparent/, I think. jsja> In order to really be attractive, I think Jan's suggestion jsja> would need to be accompanied by a mp3 player mode, and the jsja> inclusion of one or more of the IM/chat modes in the jsja> standard tarball. Don't forget the dancing paperclip.

1 participants
0 comments

[xemacs21*.deb] [FHS] Which is the real xemacs/site-lisp{,-21}? 24 years, 11 months

Karl M. Hegbloom

[ Re: xemacs21*_21.1.*.deb packages by James LewisMoss <dres(a)debian.org> ] I notice there are both "/usr/{lib,share}/xemacs/site-lisp{,-21}" directories installed[1]. Which one are folks who've installed the package supposed to use? I'd say the one in share... Which one does the XEmacs-21.1.8 debian package expect? Below, I propose a better, IMO, `load-path'. Answering my own question, I see that `load-path' is: [ abridged ] ("/usr/share/xemacs21/site-lisp/windows" "/usr/share/xemacs21/site-lisp/tdtd" "/usr/share/xemacs21/site-lisp/psgml" "/usr/local/lib/xemacs/site-lisp" "/usr/share/xemacs/site-lisp-21/" "/usr/share/xemacs/site-lisp/" "/usr/share/xemacs21/site-lisp/" "/usr/share/xemacs21/site-lisp/dpkg-dev/" "/usr/share/xemacs21/site-lisp/.../" [...] "/usr/share/xemacs21/site-lisp/windows/" "/usr/share/emacs/site-lisp" "/home/karlheg/.xemacs/lisp/" "/home/karlheg/.xemacs/xemacs-packages/lisp/" "/home/karlheg/.xemacs/xemacs-packages/lisp/karlheg/" "/usr/lib/xemacs/site-lisp/" "/usr/share/xemacs21/packages/lisp/" "/usr/share/xemacs21/packages/lisp/Sun/" "/usr/share/xemacs21/packages/lisp/.../" [...] "/usr/share/xemacs21/packages/lisp/zenirc/" "/usr/share/xemacs21/site-packages/lisp/" "/usr/lib/xemacs-21.1.8/lisp/" "/usr/lib/xemacs-21.1.8/lisp/mule/" "/usr/lib/xemacs-21.1.8/lisp/term/") Hmmm... some end in "/", others don't. I bet it doesn't matter... as long as any codes that use the elements of `load-path' call `file-name-as-directory' on them to canonicalize. Many of these have been pushed on the `load-path' by the "/etc/{x,}emacs/{*,}/site-start.d" codes. The main idea is that lisp codes meant for the more specific `emacs-version', ${configuration} and/or ${hostname} are car-end `load-path', and the more portable/general codes cdr-end, so you can drop in a repaired version of something that doesn't work without a patch, doesn't work in $EMACS <= $VERSION, should be available only on a certain architecture or host, or shadow them with enhanced versions; whatever you require or prefer. The lisp codes' installation location is up to the .deb package that installs the lisp codes (or shared-object plugin, on `module-path', iirc, l8r w/21.2). Put the `packages' lisp ahead of `site-lisp', since that's often XEmacs-patched (and "site-lisp" is considered deprecated now for XEmacs >= 21.1, right?) and put the "~/.xemacs/*" [2] stuff ahead of everything else so a user can override anything on the system at will. I think that the mule specific codes ought shadow the other codes, along the way down `load-path'. (see the order I have them in below.) We use "/usr/{local/,}/share" in preference to "/usr/{local/,}/lib" for reasons outlined in the Linux Filesystem Heirarchy Standard (FHS). (Think NFS/SAMBA shares.) Maybe we need a load-path sorter function to be called after all of the "/etc/{xemacs{/21{.1,},},emacs}.d files" [3] are run? Or a `deb-load-path-insert'? What do yous think? It might be faster and most convenient to sort them once at the end, with "/etc/xemacs/${SHORT_VERSION}/\ site-start.d/99pathsort.el". Note that with XEmacs >= 21.1, the "auto-autoloads.el" mechanism mostly obviates the need for the "/etc/xemacs/*/site-start.d" files. Those files could (maybe --- I've not tested it.) simply contain `custom-file' settings, if all they do is initialize variables.... Comments or ideas on this? (Themes will be way cool. ;-) What I think I'd try and make it look along, in order, for `load-path', follows. This will likely have to be done via the debian specific "site-start.el" (which runs everything in "/etc/{x,}emacs/*/site-start.d" in a specific order) mechanism, and not via the standard `load-path' initialization setup by "{startup,paths}.el".[4] We'd override the upstream `load-path' setup codes, and roll our own FOR NOW. The paths passed to `configure' will just be seed values, to make `xemacs -vanilla' work as expected. The XEmacs startup code path needs to be followed, brain-run and maybe worked on some, IMO... (my custom settings for `default-x-frame-plist' don't take effect until I create the second frame. Very annoying. It's a ToDo.) Anyway, here's my idea of what `load-path' maybe should contain, in order. ;; User can shadow anything. ~/.xemacs{/21{.1,},}/{{mule-,}packages/,}lisp{/karlheg,}/ ; [5] ~/.gnulisp/ ; ? Is this commonly used out there? I saw it someplace... ;; /usr/local/share is first, so the sysadmin can shadow ;; anything, or drop in site or host local codes. /usr/local/lib/xemacs{/21{.1.${xemacs-beta-version},.1,}}{/${configuration},}/{mule-,}packages/{${hostname}-,}lisp/ /usr/local/share/xemacs{/21{.1,}}/{mule-,}packages/{${hostname}-,}lisp/ /usr/local/share/xemacs/{21{.1,}/,}site-lisp/ ; deprecated ? /usr/local/share/emacs/site-lisp/ ;; Debian packages install lisp codes under /usr/share. /usr/lib/xemacs{/21{.1.${xemacs-beta-version},.1,}}{/${configuration},}/{mule-,}packages/lisp/ /usr/share/xemacs{/21{.1,}}/{mule-,}packages/lisp/ /usr/share/xemacs/{21{.1,}/,}site-lisp/ /usr/share/xemacs/21.1/lisp{/mule,,/term}/ /usr/share/emacs/site-lisp/ Trying to figure out where to put something would be less confusing this way... A README belongs in "/usr/{local/,}share/xemacs", as well as in "/usr/share/doc/xemacs*". I guess the ones in the lisp directories ought to be symlinks to the one in doc. There should be no non-architecture-dependant codes under "/usr/lib/xemacs/*" at all. I would not even ship the dumped .elc files; but would ship their .el files in the supportel or whatever. You'll need the source package to custom-redump anyhow. Perhaps much of the "etc/" directory could be left behind in the source package as well, maybe with a "replacement" README in there explaining where to find them. It's way easy to run `apt-get source' now. There will probably need to be a debconf-displayed warning message or (bluck, just don't hang and wait for me to press a key) preinst message iff there are files in the (deprecated) site-lisp directories? Hmmm. We need to think that over some. `install-emacs' will need an update for all of this to work, methinks. Any comments or ideas? Please discuss it with everyone on debian-emacsen! You are invited to subscribe at debian-emacsen-request(a)lists.debian.org. (smartlist). It's been, so far, a very low-traffic list. Karl M. Hegbloom <karlheg(a)debian.org> <karlheg(a)inetarena.com> [ By the way, I'm still hacking on my build and packaging setup for XEmacs, working with XEmacs-21.2-beta. These days, I'm learning all I can about CVS (`bitkeeper' sounds cool too... haven't tried it yet.) Maybe someday soonish (3 months, minimum) I'll finish it and upload it to experimental, ifwhen.please() I have permission from the xemacs-beta team && it actually builds and runs, else, I'll try and see about releasing to unstable with XEmacs-21.2. I remember the "flame-war" last summer, and will think up a good way to make things work nicely both for folks who want to use "~/.emacs" and those who prefer "~/.xemacs/init.el" or somesuch. Hey, if you want your GNU Emacs to bomb on XEmacs specific `customize' options, go for it. It's your life. In the source package, I will make it possible to easily define customized configurations and dumped-lisp sets, something like `make-kpackage' for XEmacs. ] Footnotes: [1] Listed in the xemacs21-basesupport.list files. [2] Another debate was whether it ought to be "~/.xemacs" or "~/xemacs". [3] In that order too, I think. [4] Note the literal `~', not expanded to the builders home directory. <grin> Don't you hate those kind of silly errors? It's 2am, and ten minutes after the release upload, and I just realized that... [5] This belongs in /etc/skel, with a README under it explaining things, along with a Makefile that recreates "auto-autoloads.el{,c}" and "custom-load.el{,c}" in there. **There needs to be a mechanism where when a package drops new or modified conffiles into "/etc/skel", it will notify all users of the new files, so they can `cp' or `ediff'.

1 participants
0 comments

Re: minibuf.texi question 24 years, 11 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Indeed, it is. Okay, I withdraw the above sentence ("I don't see the > point..."). But I maintain that the fact that the features are named > the same and similar in nature is bound to create confusion among the > (Lisp) users. Why? The DEFAULT argument is what to return if the user pressed RET. In addition some sensible magic is done. Why does it matter what exactly these magic side effects are? Jan

2 participants
1 comments

Re: Merging customize support 24 years, 11 months

Jan Vroonhof

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > I'm looking into porting the theme support from XEmacs into Emacs. Sorry for not responding earlier. The reason is that I have some aborted work on the UI part that I cannot seem to find :-(. The rest of my work (i.e. the basic infrastructure) is in the XEmacs CVS/betas. I have to finish my thesis before I can do any more serious work on it. > However, looking at the 21.0 source there are also some features that > could be ported the other way, like: > > Doc improvements. Always useful. > Using customize to set local variables If this is the same as in 20.4 then I consider this extremely ugly. > New keyword :set-after (explicit dependencies between options) > new font attributes > > Some of the later could perhaps be emulated with wmperry's font.el > package (same way the current font attributes are handled). Note that in XEmacs 21.2 I've been trying to move away from font.el (and use frob-face-property functions), however that also got stuck by time constraints. > If I start working on these, will someone look at it? Yes. Don't expect it to be before the end of January for the serious stuff. :-( Another thing: I and Dave Love had sort-of agreed that any new options in the customize-set-variables lines would be using keywords (starting with the comment stuff). Presumably that would greatly enhance cross Emacs and cross version compatibility. If you do that on the FSF side I'll do it here. Jan P.S. Would it be possible (politically) to insert a comment in the custom.el files to _please_ always contact us on customize options changes. Currently customize options are portable across Emacsen. I would love for it to stay that way.

1 participants
0 comments

Re: Modules (was: Re: How about a feature freeze) 24 years, 11 months

Jan Vroonhof

wmperry(a)aventail.com (William M. Perry) writes: > to their computer. They don't care that it is emacs underneath, or linux > underneath that, they just know they can use their computer and have > everything speech enabled magically. :) I think we should push Glynn Clements[1] to release his patches that make XEmacs have the right signal behavior for init and allows it to reap processes. innitab.el anyone? Jan Footnotes: [1] I think it was him.

2 participants
1 comments

Re: update packages screws gdb-mode 24 years, 11 months

Jan Vroonhof

nbecker(a)fred.net writes: > Instead of talking to gdb for me, it's acting as if I'm using raw gdb > with just a terminal interface. It didn't display the source (at > least, not at this point in the interaction), but it's asking me to > hit return or quit. Is M-x gdb hosed, or do I need to set some > variables to get reasonable behaviour? Are you sure you didn't want to type M-x gdbsrc ? Jan

1 participants
0 comments

Re: Modules (was: Re: How about a feature freeze) 24 years, 11 months

Tor Arntsen

On Dec 21, 22:12, Darryl Okahata wrote: > If you can write a pure-elisp mp3-player that can play 128-bit MP3s >in real-time using the existing elisp functionality (i.e, no specialized >C primitives, subprocesses, or dynamically-linked libraries), we'll all >bow down in tribute, and touch our heads to the floor, chanting, "All >hail William M. Perry, programming god." Nah, you just need an ultra-fast computer.. just write the thing and sit back and wait. > ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) :-) > Darryl Okahata -Tor

1 participants
0 comments

Re: Merging customize support 24 years, 11 months

William M. Perry

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > I'm looking into porting the theme support from XEmacs into Emacs. > However, looking at the 21.0 source there are also some features that > could be ported the other way, like: > > Doc improvements. > Using customize to set local variables > New keyword :set-after (explicit dependencies between options) > new font attributes > > Some of the later could perhaps be emulated with wmperry's font.el > package (same way the current font attributes are handled). > > If I start working on these, will someone look at it? Sure. We should really just try to emulate the real font model that is in Emacs 21 right now though. This would be a huge win for cross-platform setting of font resources. -Bill P.

1 participants
0 comments

Re: Modules (was: Re: How about a feature freeze) 24 years, 11 months

William M. Perry

Darryl Okahata <darrylo(a)sr.hp.com> writes: > wmperry(a)aventail.com (William M. Perry) wrote: > > > > > I haven't seen an mp3 decode in elisp yet. > > > > > > And I don't think that you will. > > > > Is that a challenge? :) > > If you can write a pure-elisp mp3-player that can play 128-bit MP3s > in real-time using the existing elisp functionality (i.e, no specialized > C primitives, subprocesses, or dynamically-linked libraries), we'll all > bow down in tribute, and touch our heads to the floor, chanting, "All > hail William M. Perry, programming god." > > ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) Well, that should be pretty simple. You didn't say the audio being produced needed to be CORRECT. :) (defun mp3-decode (file) (interactive "fMP3: ") (play-sound-file file)) > > X-Now-Listening-To: Joan Jett & The Blackheart - I Hate Myself For Loving You > > Cool! Yeah, was having an '80s flashback this afternoon. :) Hard to beat 'do you wanna touch me' and 'i hate myself for loving you'. :) -Bill P.

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