December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

William M. Perry

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Martin Buchholz <martin(a)xemacs.org> writes: > > > rms explicitly denies XEmacs developers, like myself, access to the > > Emacs pre-testers list. > > Are there more than one pre-testers list? The one I'm on, and I suspect > a lot of XEmacs people, is utterly boring. There is only one that I know of, and it is supremely boring. > > Wow, I have access through martin(a)cvs.gnu.org! > > Cool, me too! Although it might be an error, I asked Dave Love / RMS > about CVS access recently, and they insisted that it was only possible if > I installed kerberos. Which I never did. read/write access may be removed for non-kerberos logins eventually. I am going to try and get them to set up the kserver access method, so you don't have to have krsh installed and in your path. Paranoia levels are a bit high after they got cracked a few months ago. -Bill P.

1 participants
0 comments

RE: URL retrieval rewrite... 26 years

William M. Perry

Yes, it did happen, and is fairly usable right now. Some weirdness with caching, but I think I have those fixed on my laptop right now, but no CVS access. The default for 'url-retrieve' is to be asynchronous, but there is a trivial function called url-retrieve-synchronously that wraps around it and returns a buffer or nil. -Bill P. -----Original Message----- From: Ben Wing To: wmperry(a)aventail.com Cc: xemacs-beta(a)xemacs.org Sent: 12/15/99 2:13 AM Subject: Re: URL retrieval rewrite... Did this ever happen? I agree extremely strongly about adding this functionality to the base. But you really should provide a synchronous interface. History has shown amply the folly of not doing so. ben "William M. Perry" wrote: > I'm most of the way through rewriting the URL loading for Emacs/W3. In the > process, I'm making the URL library much more standalone. This means that > it would be much easier to include just it in the base XEmacs tarball and > use it for package retrieval, etc. This way a user would be able to stick > FTP and HTTP URLs in the package directory list, and all would be well > with the world. > > The new HTTP loader is 100% asynchronous, and does all the work of waiting > for headers, decoding 'chunked' transfer-encodings, parsing headers, etc, > with after-change-functions. It will be up to the calling application to > deal with making it a synchronous operation. > > I'm probably going to be hacking on this late tonight, so I hope to have > something I can ship out to the w3-(beta|dev) and xemacs-beta lists > tomorrow. > > -Bill P. -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding.

1 participants
0 comments

Installation problem! 26 years

Sanjeev Shashikant Deshmukh

Hi, I have built XEmacs 21.2.23 on Solaris 2.5.1 with following options. ********************************************************************** In XEmacs 21.2 (beta23) "Hebe" [Lucid] (sparc-sun-solaris2.5.1) of Tue Dec 14 1999 on urvashi configured using `configure --prefix=/net/urvashi/usr1/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23 --with-xpm=yes --with-workshop=yes --site-libraries=/usr/local/lib/X11/' ********************************************************************** I have noticed that 21.2.8 onwards, I was never able to "install" the xemacs. It always fails while testing lisp shadows as, ********************************************************************** Loading very-early-lisp... Loading /usr1/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/lisp/dumped-lisp.el... Loading /users/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/lisp/backquote.elc... Loading /users/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/lisp/bytecomp-runtime.elc... Loading /users/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/lisp/find-paths.elc... Loading /users/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/lisp/packages.elc... Loading /users/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/lisp/setup-paths.elc... Loading /users/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/lisp/dump-paths.elc... Load file subr: not found Fatal error during load, aborting *** Error code 1 (ignored) Testing for Lisp shadows ... sh: ./xemacs: not found *** Error code 1 make: Fatal error: Command failed for target `xemacs' Current working directory /usr1/sdeshmuk/gnu/XEmacs/beta/xemacs-21.2.23/src *** Error code 1 make: Fatal error: Command failed for target `install-arch-dep' ********************************************************************** Also, the image mode does not load gif or jpeg files correctly. and in 21.2.23, whenever I load a directory dired mode, xemacs temporarily hangs. If I quit with C-g and load again, it works fine. Regards, Sanjeev.

1 participants
0 comments

Re: How about a feature freeze 26 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > It depends on what you mean by "feature freeze". Most of the new > features aren't fully implement yet, so I agree it would be a good > idea to start completing them. However imho it much to early for a > "no new functionality" type freeze exactly because all the new stuff > has just introduced low-level support and the highlevel support is > still missing. I agree. The feature I had in mind is "no new major features", where the notion of a "major feature" is left at the discretion of the reviewers. When we feel safe to do so, that freeze will be followed by a real "no new functionality" feature freeze. > Maybe it is possible to freeze parts, i.e. really finish the dumper > and switch over to it. That is an option, too.

1 participants
0 comments

Re: How about a feature freeze 26 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > How would you feel about announcing a feature freeze for 21.2? I > think it might be time to start finishing up and debugging the big > changes (most notably the dumper and the packages layout), and issuing > test releases. It depends on what you mean by "feature freeze". Most of the new features aren't fully implement yet, so I agree it would be a good idea to start completing them. However imho it much to early for a "no new functionality" type freeze exactly because all the new stuff has just introduced low-level support and the highlevel support is still missing. Maybe it is possible to freeze parts, i.e. really finish the dumper and switch over to it. Then afterwards help Andy with the widgets stuff. Jan

1 participants
0 comments

Re: XEmacs 21.2.23 crashes when url-insert-file-contents 26 years

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > I'm to blame for the multiple-change stuff. No blame is due. In this case, I didn't mean to imply that the code was unreadable. The code is good, it's just that every complexity takes time to understand. > Someone might want to verify that it actually improves efficiency. True enough. But then again, I really wish the same kind of optimization can be employed for undo. M-x query-replace is *horribly* slow with large files (even on very fast machines), and I think much of that slowness comes from repetitive small undo records.

1 participants
0 comments

Re: LDAP extended and revamped 26 years

Oscar Figueiredo

>>>>> "Robert" == Robert Pluim <rpluim(a)bigfoot.com> writes: Robert> Hrvoje Niksic writes: >> Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: >> >> > *** IMPORTANT NOTE *** >> > Due to the function renaming, this patch introduces an incompatible >> > change that breaks the packages using the current LDAP API, most >> > notably EUDC and W3. >> >> Renaming doesn't necessarily entail breaking backward compatibility. >> If you want to be kind to your users, define functions with old names >> that do nothing except call the new functions. Robert> Wouldn't define-{obsolete,compatible}-function-alias be better here? Robert> Or are they intended only for 'core' emacs functions? Of course I've been concerned by this problem. But I don't know what to do for the particular case of ldap-search. Currently ldap-search is the name of the high-level search function (vs. ldap-search-internal which is the low-level function). But according to the recent discussion on the subject, what we want is the low-level function to be called ldap-search and the high-level one called something else (my patch proposes ldap-search-entries). In this particular case I don't know how to rename backward compatible. That's the reason why I didn't provide compatibility aliases at all, compatibility will be broken anyway... :-(( I am not satisfied by this but I've seen no workaround. I don't know how many packages are currently using the LDAP API. I know of two: EUDC which I maintain myself and W3. As I said, I can provide a compatible version of EUDC as soon as necessary and I guess Bill is responsive enough these days to do the same. I just hope the consequences of this incompatible change will be minor, the LDAP API has been out since version 21.0 only. Oscar

3 participants
2 comments

URL retrieval rewrite... 26 years

William M. Perry

I'm most of the way through rewriting the URL loading for Emacs/W3. In the process, I'm making the URL library much more standalone. This means that it would be much easier to include just it in the base XEmacs tarball and use it for package retrieval, etc. This way a user would be able to stick FTP and HTTP URLs in the package directory list, and all would be well with the world. The new HTTP loader is 100% asynchronous, and does all the work of waiting for headers, decoding 'chunked' transfer-encodings, parsing headers, etc, with after-change-functions. It will be up to the calling application to deal with making it a synchronous operation. I'm probably going to be hacking on this late tonight, so I hope to have something I can ship out to the w3-(beta|dev) and xemacs-beta lists tomorrow. -Bill P.

2 participants
1 comments

Re: XEmacs 21.2.23 crashes when url-insert-file-contents 26 years

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > Be aware of the "internal" extent flag, created exactly for this > purpose. Yup, I know about that, and I intend to use it. It's just the complexity of things in insdel.c that stopped me from doing it that time. But I'm a big boy now. :-)

2 participants
1 comments

Re: XEmacs 21.2.23 crashes when url-insert-file-contents 26 years

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Yeah, this discussion does sound familiar. I think my position was > "well, fix this broken code!" and no one else wanted to fix it, so > in order to implement the change I would have to fix it. Broken Lisp code or broken C code? I wanted to fix the C code, but it was too hard for me at the time. I plan to try again soon. You claimed the code was fixable in Lisp. I asked you to fix it, but you said you wouldn't get involved. So it was 1:1, as our soccer friends would say. > > > We can fix the crash, but things like font-lock and setnu-mode, > > > which rely on having access to every change to operate > > > correctly, are still going to be screwed unless we disallow > > > these changes. > > > > Neither font-lock nor setnu are very useful with things like > > Customize buffers. > > Yes, but this is awfully ad hoc. We don't know what other > developers are going to do with the feature. It may be imperative > to see all the text that goes in and out of a buffer, even in a > Custom buffer. I don't see the reason why one would want that with a Customize buffer. > If I fix wid-edit.el (assuming its possible) and whatever else we > ship that uses buffer modifying change functions, would you be more > amenable to disabling buffer modifications while inside a buffer > change function? The point is not only what we ship, but what the users have written. Buffer modification has been allowed in before/pre-change functions for years, and code that employs it could have been written. In fact, it has been written -- Customize wasn't always shipped with XEmacs.

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 1999