May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [PATCH} customize package installation 26 years, 6 months

Andy Piper

At 02:42 AM 5/14/98 -0700, you wrote: >I'm asking what is the minimum amount of code required. The defcustom >per package code must not be part of the XEmacs core. >>> It doesn't need to be generated at build time, it can be installed at >>> run-time and have the same effect. > >> You mean when someone tries to customize packages? > >No. I mean this must be installable independently of the XEmacs >core. That will be the case if it's a package of its own. I think it should always be auto-generated though - its intimately tied to package-get-base.el or are you talking about putting package-get-base.el and package-get.el in a package as well? If package-get-base.el and package-get.el are in the core (which they are currently and which I like) then you could just generate package-get-custom.el on the fly when a user tries to customize packages. I still am confused though. What process do you envisage a user or builder going through. >Bang on me in xemacs-beta if this isn't 100% clear. To address changed. :) andy

1 participants
0 comments

I like the 3d vertical separators 26 years, 6 months

Andy Piper

Looking good Louis... :) andy

1 participants
0 comments

Re: package problems 26 years, 6 months

SL Baur

Andy Piper <andyp(a)parallax.co.uk> writes: >> I've just removed `add-little-package.sh' from the XEmacs distribution. > And fixed package-admin-add-single-file-package in package-admin.el? Not yet. The temporary fix is to not call that function until it can be fixed. `package-admin-add-binary-package' should be called unconditionally.

1 participants
0 comments

Re: enable-clash-detection 26 years, 6 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I just tried helping somebody compile XEmacs 20.4 to enable clash > detection again. So here are a few questions > 1. Where is is this documented? I have no idea. > 2. Is the default (disabled) intentional? I vaguely remember it being intentional. There are definitely problems with the implementation. > Jan > P.S. That 'somebody' also asked me to forward his plea to enable it > again. Which I just did :-). However if the answer to 2. is yes (like > I think it is because the old clash detection is ugly), I would say > we should implement the FSF 20.x style clash detection before > reenabling it. I also vaguely remember Steve writing something to that > effect. That wouldn't hurt. If you can get it done soon enough it can go into 21.0. > Personally I think locking like this has no place in an application (other > than automatic handling of other systems like for CVS). I don't know. The Roman Numeral editor does it. File locking is unreliable over NFS. IMO it's safer to not use it. The current code will detect when a file has changed out from under the editor and that's the best we can hope for in the general case.

1 participants
0 comments

Re: [Q] mirroring the xemacs CVS archive ? 26 years, 6 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes: > Checking out one XEmacs CVS version from Paris is definitely a long > term operation ... I'm not very well acquainted with cvs, but is it > possible to mirror a cvs archive, like Michael Schmidt does for the > ftp site ? How could this be done ? I believe this could be done the same way I'm currently updating the XEmacs core CVS -- rsync. You'll have to use ssh though, which rules France out unless you wish to take your chances[1]. Perhaps we can get a mirror in the UK or Germany? Footnotes: [1] Unless encryption by serfs has been decriminalized in France when I haven't been looking.

1 participants
0 comments

Re: package problems 26 years, 6 months

SL Baur

Andy Piper <andyp(a)parallax.co.uk> writes: > At 12:41 AM 5/14/98 -0700, SL Baur wrote: >> No, it shouldn't. A "regular" package means no single lisp file can >> be removed safely. A "single-file" packages means each lisp file is >> independent and any one (or more) of them may be removed at will. >> That is not and will not be the case with os-utils and edit-utils. > But add-little-package.sh loses ... I've just removed `add-little-package.sh' from the XEmacs distribution. The canonical definition of package types: `regular': No lisp file may be removed without grievious and possible fatal loss of functionality. "The XEmacs maintainers shall not be held responsible." `single-file': A package consisting of independent lisp files any of which may be deleted by the end user[1] without care about the consequences and if this causes failure due to dependencies on other XEmacs maintainer supported packages, the XEmacs maintainers are at fault. `add-little-package.sh' was a relic from the early implementation of XEmacs packages. Rather than distributing the many independent lisp files as single files I felt it was more convenient to bundle them up by functionality. Footnotes: [1] Procedures to update auto-autoloads.el/custom-load.el to be provided.

2 participants
1 comments

enable-clash-detection 26 years, 6 months

Jan Vroonhof

I just tried helping somebody compile XEmacs 20.4 to enable clash detection again. So here are a few questions 1. Where is is this documented? 2. Is the default (disabled) intentional? Jan P.S. That 'somebody' also asked me to forward his plea to enable it again. Which I just did :-). However if the answer to 2. is yes (like I think it is because the old clash detection is ugly), I would say we should implement the FSF 20.x style clash detection before reenabling it. I also vaguely remember Steve writing something to that effect. Personally I think locking like this has no place in an application (other than automatic handling of other systems like for CVS).

1 participants
0 comments

[Q] mirroring the xemacs CVS archive ? 26 years, 6 months

Didier Verna

Checking out one XEmacs CVS version from Paris is definitely a long term operation ... I'm not very well acquainted with cvs, but is it possible to mirror a cvs archive, like Michael Schmidt does for the ftp site ? How could this be done ? -- / / _ _ 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: Precedence of specification 26 years, 6 months

Didier Verna

"Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > Currently buffer specifications take precedence over window > specifications. Ben proposes to change the order of precedence > of these two when instantiating the specifiers, and I agree > with him here. I agree with this too. When you set a specifier for a window, you expect this value to stay whatever the buffer in it. So the window domain should be more specific than the buffer domain. -- / / _ _ 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: [Doc-bug] zap-to-char - including or up-to? 26 years, 6 months

SL Baur

Christian Nybø <chr(a)mediascience.no> writes: >> A convenient way of killing is combined with searching: `M-z' >> (`zap-to-char') reads a character and kills from point up to (but not >> including) the next occurrence of that character in the buffer. The manual is wrong (unfortunately). This behavior has always irritated me, but here we are. ... > What should zap-to-char do? What it does. > I wish changing the function rather than the doc was a viable option, > as it seems more useful for interactive use if zapping up to, but not > including, the character. It's worked the way it does for a very long time. Perhaps we could add `zap-up-to-char'? After all the Roman Numeral editor handles both with `d f <char>' and `d t <char>'. I must admit to using the latter far more often than the former.

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