January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Feedback on pui-list-packages 25 years, 3 months

Jan Vroonhof

"Barry A. Warsaw" <bwarsaw(a)cnri.reston.va.us> writes: > I can sympathize with both reasons. However, the error message that > occurs when pui-list-packages is run isn't too helpful for someone who > might be less experienced. > It just bombs out saying > > No remote package sites specified in `package-get-remote'. What version are you running? This message appears nowhere in my version (which is THE version for the package code currently) and CVS tells me that version is also in 21.0.62 What you should get (and that is what happens here) is normal *Packages* buffer with additional text on top reading: === Warning: No download sites specified. Package index may be out of date. If you intend to install packages, specify download sites first. === > Okay, how do know where to set this to? I had hoped that the above would be enough to use the "add download site" menu item. Somebody still needs to write customize magic for package-get-remote so that it will offer values from package-get-download-sites as suggestions. Then we can add text/hyperlink to customize-variable package get remote. Unfortunately this will not happen before 21.0 is released. > I apologize ;-). What might be useful however is, once you've got a > bunch of mirrors lined up, you could pre-load this variable with those > sites, and do a random pick of a mirror from those choices. Picking a random mirror is bad as connections from here to australia are likely to be slow. > As for not going remote unintentionally, you could show some message > in the pui-list-packages buffer and have a single boolean custom > variable that says "go-remote?". I was/am hoping that with a good custom framework around package-get-remote adding another variable (a meta one) would be unnecessary. Jan

1 participants
0 comments

Re: Feedback on pui-list-packages 25 years, 3 months

Neal D. Becker

>>>>> "BAW" == Barry A Warsaw <bwarsaw(a)cnri.reston.va.us> writes: >>>>> "nbecker" == <nbecker(a)fred.net> writes: nbecker> Some packages are mutually exclusive. The current nbecker> packaging system doesn't handle that, and the UI doesn't nbecker> tell you. For example, I found out that mailcrypt is nbecker> incompatible with mailcryptng, in the sense that you must nbecker> remove mailcrypt to install mailcryptng. BAW> I hadn't noticed this, I think I installed both (not knowing what BAW> mailcryptng was, but being able to guess from its name :-). Looks BAW> like mailcrypting is working for me though. The two packages are just different versions of the same lisp files. If you install both, the result is basically random - just depends on which files show up first in the load-path. I think this is a general problem that may not have been addressed by our current package design. I think the first step toward a solution may be to at least provide a mechanism to warn the user about conflicts.

1 participants
0 comments

Source Comment Formatting 25 years, 3 months

Clarence Donath

I am new to the list, I've scanned the list archives, and did not find a related subject. I am a Perl programmer and use XEmacs 20.4 for Perl and HTML. My suggestion will most likely apply to other languages as well. I think we all need some sort of Comment Formatting functionality. When I document my code, I use multiple #'s and spaces. When I edit my comments, I spend so much time moving text around to make it fit within 79 columns to make it look right. I WISH there were some utility that would take the commented blocks of my code and format them so that words wrap and the comment characters (#'s) are maintained. First, I don't know if such a utility exists. I suppose something could be built into Emacs that when a commented line passes a certain column, it wraps the word and begins the next line with the previous line's #'s. If there is such a utility in existence, please let me know. Otherwise, I'll probably write a processor in Perl to do this on a Perl source file. That would mean a second step would be required to format my comments, but such functionality would be very nice to have in the editor as the source is being developed. Looking forward to your response. Clarence Donath http://mrdo.com

1 participants
0 comments

Re: Feedback on pui-list-packages 25 years, 3 months

Neal D. Becker

Some packages are mutually exclusive. The current packaging system doesn't handle that, and the UI doesn't tell you. For example, I found out that mailcrypt is incompatible with mailcryptng, in the sense that you must remove mailcrypt to install mailcryptng.

2 participants
1 comments

[ERROR] 21.2 w3 display image -> SIGSEGV 25 years, 3 months

Norbert Koch

Hi, let me gather the bits ... - XEmacs 21.2 "Artemis" [Lucid] (i686-pc-linux, Mule) of Wed Jan 6 1999 on apollonius.delta-ii.de - WWW xp 1998/12/18 both from the respective CVS trees. I've tried to display images on <URL:http://www.debis.de/>. Always within the third frame (out of four), no matter what order, I get a SIGSEGV. I'm not sure, whether w3 or xemacs messes things up, though ... -norbert

1 participants
0 comments

Announce: folding 2.53 available 25 years, 3 months

Jari Aalto

Hi, Recently big changes in keybinding functions have taken place according to comments that vector prefix key notation was not working. Subtreee bugs have also been addressed. Get the latest verison from: ftp://ftp.csd.uu.se/pub/users/andersl/beta/ jari

1 participants
0 comments

Re: gdbm support of database.c 25 years, 3 months

Martin Buchholz

>>>>> "Mikio" == Mikio Nakajima <minakaji(a)osaka.email.ne.jp> writes: Mikio> From: Mikio Nakajima <minakaji(a)osaka.email.ne.jp> Mikio> Subject: gdbm support of database.c Mikio> Date: Sat, 02 Jan 1999 17:19:04 +0900 >> I herewith attach diff files which provide a facility of >> manipulating a gdbm file. I built XEmacs linked to gdbm 1.7.1 with >> --with-database=dbm,gnudbm option. The original XEmacs 21.2b8 insists >> that dbm options conflict to gnudbm, but attached ndbm.h.diff (diff >> file of ndbm.h of gdbm 1.7.1) can avoid it. Mikio> Too long e-mail seemed to be unhappy for you. I'm so sorry. The right way to submit patches is to send them to xemacs-patches(a)xemacs.org. Please read: etc/BETA in the source distribution. http://cvs.xemacs.org/ Mikio> Further to my work yesterday, I added to database.c three Emacs C Mikio> primitives; Mikio> `reorganize-database', Mikio> `sync-database', and Mikio> `setopt-database' Mikio> which are respectively referred to `gdbm_reorganize', `gdbm_sync' and Mikio> `gdbm_setopt' of gdbm library functions. Mikio> I made tar ball named `diff-to-xemacs.21.2.8.tar.gz' which contains Mikio> relative diffs and put it on, Mikio> http://www.asahi-net.or.jp/~gy2m-nkjm/diff-to-xemacs.21.2.8.tar.gz Mikio> Please note my home page index.html is Japanese only and is not Mikio> referred to the tar ball above, so please use wget or so to get it. Mikio> Thank you. Mikio> Mikio Nakajima <minakaji(a)osaka.email.ne.jp> Mikio> http://www.asahi-net.or.jp/~gy2m-nkjm/ Thank you. However.... your patch is not likely to go in in its current state. First of all, there is no way we can change ndbm.h. That file is provided as part of the operating system. configure is a generated file. You need to patch configure.in and run autoconf (get autoconf 2.12 from ftp://ftp.xemacs.org/pub/aux) I'm not sure we really want 3 different database types in the code (up from two today), since this will make maintenance more difficult. All the database functions will have to be changed someday to work better with different text encodings. On the other hand, I am not entirely opposed to it either. It will certainly help to clear up the configure specification confusion we currently have. Much of the functionality you implement is good, but should probably be extended to other database types, Berkeley db in particular. I suggest sync-database be renamed synchronize-database. I suggest setopt-database be renamed set-database-property. You probably also want to implement database-properties. Some of your changes go against XEmacs coding conventions, like the following: *************** *** 629,635 **** #endif /* HAVE_DBM */ #ifdef HAVE_BERKELEY_DB ! if (NILP (type) || EQ (type, Qberkeley_db)) { DBTYPE real_subtype; DB *dbase; --- 862,868 ---- #endif /* HAVE_DBM */ #ifdef HAVE_BERKELEY_DB ! if (NILP (type) ||EQ (type, Qberkeley_db)) { DBTYPE real_subtype; DB *dbase; Martin

4 participants
11 comments

Re: Is there no more need of our xemacs-beta mirror? 25 years, 3 months

SL Baur

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes in xemacs-beta(a)xemacs.org: > Didier Verna <verna(a)inf.enst.fr> writes: >> M Schmidt writes: >> M> What I would like to know is: If there is no more need of it or M> almost none then feel free to send me any message whether I may M> kick off our xemacs-beta mirror. Whether you keep the mirror or not is up to you. We appreciate your efforts. > I think the beta directory is now mirrored by a couple of the general > ftp.xemacs.org mirrors. Most testers probably switched to CVS anyway. That's my impression. >> Perhaps a cvs mirror would be more usefull now (though I have no idea >> how this can be done). Is cvsup the right tool for this? A secure brute force method of distributing the CVS tree read-only could be had with rsync. That wouldn't solve the problem of allow commits from the mirror though. >> As I did with your ftp mirror, I would be the one to >> use it. > Indeed, a CVS mirror somewhere in Europe would be great! I was hoping > Lars would eventually do something like that on 'quimby'... But a > mirror on one of the European academic networks would probably be much > better for most beta testers (and avoids the trip via NewJersey). Sounds good. I've been getting the most recent Linux kernel updates from the Norway and Finland mirrors -- they're fast even coming back across the Atlantic.

1 participants
0 comments

Re: Building 21.0.60 on AIX 4.3.1 25 years, 3 months

SL Baur

Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-beta(a)xemacs.org: ... > Notwithstanding the general brokenness of Motif, this is really a > problem with IBM's fucked-up distribution of it. At least in theory > it's possible someone with a service contract will send a Problem > Report to IBM, and with some luck, it will get fixed. I don't have any comment. That's such a great quote, I had to see it in print again. :-) ... sb> Death to Motif. Good riddance to bad rubbish. I think it's a serious sb> mistake defaulting to Motif support. > I like this idea a lot. Since this change would be trivial and not > really affect anything we've tested, couldn't we make it so for 21.0? It's O.K. with me if the patch can get committed immediately to the source tree for some minimal testing. >>> BTW: We still do need a note in PROBLEMS about AIX X libXt, don't we? sb> That would be good. > Coming up. O.K.

1 participants
0 comments

Re: Building 21.0.60 on AIX 4.3.1 25 years, 3 months

Michael Sperber

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks(a)vt.edu> writes: Valdis> [1 <text/plain; us-ascii (7bit)>] Valdis> On 05 Jan 1999 19:20:18 +0100, Michael Sperber [Mr. Preprocessor] said: >> From the PROBLEMS file: >> >> ** AIX >> *** On AIX 4.3, you must specify --with-dialogs=athena with configure Valdis> Until such time as we track down the actual problem here, would it make Valdis> sense for ./configure to default this, and to urinate all over the Valdis> user if they attempt to overrride it, since we *know* it won't work? I *did* figure out what the problem is in a rough way: Motif pees all over the data area with allocated storage. My general stance is that it's a bad idea to cater to OS fuckage in configure, because it will alleviate pressure to get the actual bug fixed. But I know Steve has felt differently about this in the past. I'll leave it to him. Valdis> I'm pretty sure that, unlike the 'xemacs -nw locks up' problem, this Valdis> one isn't a problem in the IBM X libraries, since I build against Valdis> the MIT X11R6.4 and *still* see it. I haven't looked to see if it's Valdis> an IBM xlc compiler fuckage (possibly), or if it's an actual XEmacs bug Valdis> (but why isn't it seen elsewhere?) No, it's Motif. BTW: We still do need a note in PROBLEMS about AIX X libXt, don't we? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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 1999