October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [request] please test new pcl-cvs 27 years

Greg Klanderman

Great news! Let me know when you've put it through it's paces... greg >>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> >>>>> "Greg" == Greg Klanderman <greg(a)alphatech.com> writes: >>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: William> You should be able to just use 'shell-command-switch' William> for this instead of creating your own new variable. APA> Greg> Cool, thanks for the heads-up greg APA> APA> Hello Greg, hello everyone! APA> APA> I have pcl-cvs working (at least partially, I haven't tested very APA> much) in (version) "XEmacs 21.0 \"Poitou\" [Lucid] (i386-pc-win32) of APA> Sat Oct 10 1998 on TWILIGHT" built natively on system-type windows-nt. APA> APA> I have set the following: APA> APA> cvs-shell APA> "cmd.exe" APA> shell-command-switch APA> "/c"

1 participants
0 comments

add package: cvs.el 27 years

Greg Klanderman

It'd be nice to provide this too, Darryl at least has used it... one of these days I'll try it out. It should complement pcl-cvs by giving a per-file interface to CVS. >>>>> "Fred" == Frederic Lepied <fred(a)sugix.frmug.org> writes: Fred> Fred> I have integrated Darryl's patches and avoided pcl-cvs clashes as far Fred> as I know into the 1.30 release available at: Fred> Fred> http://www.teaser.fr/~flepied/

1 participants
0 comments

Re: Why using (push-mark) ? 27 years

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > ... the current behaviour is far from logical. ... > (this is kinda hard to explain; the best way is try it and see if you > share my and Didier's annoyance.) <AOL> I don't like the way this works either. I've disliked it for years. </AOL>

1 participants
0 comments

newer flyspell 27 years

Greg Klanderman

Steve, Is the newer flyspell.el posted sept 29 to this list by the author making it into the package updates?

1 participants
0 comments

please add package: greedy-delete 27 years

Greg Klanderman

Steve, Could you add greedy-delete, maybe to edit-utils? Get it from <http://www.python.org/~bwarsaw/betas/greedy-delete.el>

1 participants
0 comments

Re: Why using (push-mark) ? 27 years

Hrvoje Niksic

greg(a)alphatech.com (Greg Klanderman) writes: > (defun gk:beginning-of-buffer () > "Move point to the beginning of the buffer." > (interactive "_") > (if zmacs-region-active-p > (if (> (point) (mark)) > (exchange-point-and-mark)) > (push-mark)) > (goto-char (point-min))) I don't understand your (> (point) (mark)) check. If I were to change beginning-of-buffer, I'd make a simpler change: (defun ... (interactive "_") (unless (region-active-p) (push-mark)) ;; the rest of the function -- a bit more complex than this, but ;; essentially the same: (goto-char (point-min))) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- What is mind? No matter. What is matter? Never mind.

1 participants
0 comments

Re: Why using (push-mark) ? 27 years

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > I don't think this needs to be changed. There sure haven't been > many (any?) other complaints about it, and the existing behavior is > logical. Allow me to guess: you run with zmacs-regions set to nil? Because, if you don't, the current behaviour is far from logical. Press C-SPC, then C-f a few times, then M-<. I bet 90% of XEmacs users would expect the mark to remain at the point before C-f-ing. (this is kinda hard to explain; the best way is try it and see if you share my and Didier's annoyance.) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Reporter: Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea.

2 participants
1 comments

about the packages: directory names and places 27 years

Didier Verna

SO. Here are some comments that I have (or haven't) done before about things that sound non optimal to me in the current packaging stuff. I'll try to be very clear and precise in my comments this time. Also I'll try to point out the things that I consider the most important ones. Obviously, all the stuff below is IMHO, not directed at anyone in particular and only aimed at debating ideas that I think could improve the current scheme. Currently, the default scheme is to install packages under ${prefix}/lib/xemacs, respectively in site-packages, xemacs-pakages and mule-packages. 1/ Importance: 2/5 I personally don't like this `-packages' name replication, but I think that there is more than a matter of personal taste: basically I think that first, you can't force ~/.xemacs to be a user-local package directory[1] and second, it's important that the naming scheme remains coherent across user-local, site-local and distribution-wide placements. You can't force ~/.xemacs to be *THE* user-local package directory by default because the user should be able to do what it wants in this directory. I for instance have other subdirs like autosave/, drafts/ and others, and I had a lisp/ dir for stuff not being in any package (code under development, random hacks ...). I would then prefer to have a packages/ subdir under ~/.xemacs/, and use it to install packages locally. To stay coherent in the placement scheme, this also means that I'd prefer to see a packages/ subdir, everywhere packages could be installed. In other words, instead of having site-packages, mule-packages and xemacs-packages under ${prefix}/lib/xemacs/, I'd prefer to see ${prefix}/lib/xemacs/packages/ and then site/ mule/ and xemacs/[2]. 2/ Importance: 3/5 The name xemacs-packages is not informative for people: all packages are for xemacs. The difference is that those ones are standardly distributed and can be grabbed from the XEmacs ftp site. Instead it would probaby be better to prefix it with standard-, distrib-, core- or something like that. (or if 1/ is agreed on, name it directly like this ;-)) 3/ Importance: 4/5 The presence of the mule subdir appears questionable to me: this separation is put on the same level as the site-level or distrib-level split, but it has nothing to do with it. Consider this: - having site-packages is good, not only because you can put random stuff not in the distribution, but because it will allow you to override any packages already installed in the standard place (xemacs-packages) with something newer, locally modified, of a different flavor or whatever. For mule stuff this doesn't appear possible, since all mule stuff is supposed to go in the mule-packages directory. - if somebody writes a new package for mule, where does it go ? under site-packages or under mule-packages ? This is ambiguous. This makes me think that instead of the current 3 parts split, we'd better have `mule' as a sub-split under both site-packages and xemacs-packages. Like having site-packages/, site-packages/mule and the same for xemacs-packages. This modification solves the two problems cited above, and makes tarball installation easier too: a mule package tarball could now be built with the mule/ prefix, and thus people could not make the mistake of installing a mule package under a non mule installation directory. 4/ Importance: 5/5 Currently, the default prefix is ${prefix}/lib/xemacs. There, I'm gonna be very direct, sorry, but this is the *WRONG* place. Everything in packages is architecture independant: info files, etc random stuff, lisp and bytecode. So all this stuff should go at least under ${prefix}/share/ and not lib. Many people mount /share by NFS on heterogeneous networks exactly because it is meant for arch-independant stuff. I have almost all of the packages installed and this represents about 50Mo. Preserving 50Mo sounds worth it to me, if by any chance you wouldn't be convinced that it's better to use share/ rather than lib/. All right. I think that's it. I'd like to hear comments from anybody, not only for those involved in the packaging code development. Now, I've turned up my power-shield. You can BGF9000ize my head[3]. Footnotes: [1] I didn't find any information on this lately, so I'm assuming that this is still the package directory for users. [2] see next point though. [3] "shoot shoot, don't talk." -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: XEmacs package update 1998-10-12-1 27 years

Greg Klanderman

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> "binkit" wasn't ever intended to be a visible rule. It was created so sb> that individual Makefiles could specify their own installation sb> sequence[1]. The "bindist" rule is the one to be using to create tarballs. OK, bindist works, thanks

1 participants
0 comments

Re: pcl-cvs provides still wrong [was Re: Package update] 27 years

Greg Klanderman

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> sb> Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org: sb> ... >> It seems most of package-info.in is generated from values set in the >> Makefile (or generated via md5). Why not just put make variables in >> the Makefile for the other couple static things and auto-generate it? sb> sb> The information has got to be stored somewhere. package-info.in is a sb> template file that is used to autogenerate package-info. I'm trying sb> to move stuff out of the Makefile not put more stuff in it. sb> sb> A compromise might be to make package-info.in be in a form that can be sb> included by make as well as processed by XEmacs to create package-info. That'd be fine. The problem is that PROVIDES is defined in package-info.in, and REQUIRES is defined in Makefile. They should both be defined in the same place, it doesn't matter much where.

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