October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: pcl-cvs provides still wrong [was Re: Package update] 26 years, 1 month

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> provides (pcl-cvs dll elib-node generic-sc) sb> >> Oops, I thought dll and elib-node were outta there. sb> sb> Oops indeed. I didn't check before packaging: sb> sb> $ cvs diff -u prog/pcl-cvs/package-info.in sb> $ grep provides prog/pcl-cvs/package-info.in sb> provides (pcl-cvs dll elib-node generic-sc) Doh! Thanks for fixing it - for some reason I thought it was not set within the pcl-cvs package. Eventually I'll get all this stuff figured out... greg

1 participants
0 comments

Re: Question for bytecompiler gurus `require' and bytecompilation 26 years, 1 month

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > > > SL Baur <steve(a)xemacs.org> writes: > >> ;;; bar.el --- do something interesting > >> ... > >> (require 'foo) > >> ... > >> ;;; bar.el ends here > >> > >> > >> What difference (if any) does it make if foo.el (assuming foo.elc > >> hasn't been bytecompiled yet) or foo.elc is loaded? > > > It should make zero difference (except for totally weird things), > > It's the "totally weird things" that I'm asking about. Now that I think about it, I can't think of any weirdity to provoke bad behaviour. Originally, I had in mind something like: foo.el: (defvar global-var (lambda () ... code ...)) bar.el: ... (funcal global-var) ... and such, but now it occurred to me that the code will be evaluated at run-time, by which time foo.el will be compiled. If, on the other hand, you force the value of global-var to be open-coded, then the compiler will go ahead and compile it. > > as far as I know. What prompted you to ask that question? > > Why does it matter? I wanted to know what kind of oddities you might encounter. > If loading .els and .elcs via `require' in bytecompilation are > identical, then I can dispense with the order of bytecompilation > requirement. I think it might work. Unless someone points out something obvious that you and I are missing, of course. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- You can only be young once, but you can be immature forever.

1 participants
0 comments

Re: about the packages: directory names and places 26 years, 1 month

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > Mule packages have poison (Mule encoded characters) in the > auto-autoloads files that cause a non-Mule XEmacs to choke and die. > Mule packages are split away in order to allow them to coexist in the > same installation tree used by non-Mule XEmacsen. I'm well aware of this. I'm afraid I was still not clear, sorry. I wrote: | The mule subdir is questionable to me. I should have wrote: | The mule subdir *at this place in the tree* is questionable to me. What I said was questionable is to put this separation on the same level as site and xemacs packages, and thus proposed to lower this separation under each of these two last directories. That way, a non mule XEmacs would look into site-packages and xemacs-packages, while a mulized XEmacs would look into site-packages, site-packages/mule, xemacs-packages and xemacs-packages/mule. -- / / _ _ 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

1 participants
0 comments

Re: about the packages: directory names and places 26 years, 1 month

SL Baur

[Deferring comments on the rest for the time being] Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: ... > 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. Mule packages have poison (Mule encoded characters) in the auto-autoloads files that cause a non-Mule XEmacs to choke and die. Mule packages are split away in order to allow them to coexist in the same installation tree used by non-Mule XEmacsen.

1 participants
0 comments

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > I could provide a patch and let people try it for some time. Also, > if somebody sees something that could get broken, let he speak. For one, various macros that depended on the current behaviour in subtle ways may easily be broken. On a more serious note, I don't like the subtle changes between zmacs-regions being set to t or nil. Somehow I feel that explicit checking for zmacs-regions and modifying the behaviour of functions accordinly is not a good way to go. It's only a hunch, though. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- aibohphobia (ay' bo fo beeya): n. The fear of palindromes.

1 participants
0 comments

Undefined reference to ... 26 years, 1 month

Fukae Seiji

I try to compile XEmacs 21.2-b2 on Red Hat Linux release 4.2. Then, I got the following messages: glyphs-eimage.o: In function `png_instantiate': /work02/users/sf/xemacs/xemacs-21.2-b2/src/glyphs-eimage.c:940: undefined reference to `png_get_bKGD' /work02/users/sf/xemacs/xemacs-21.2-b2/src/glyphs-eimage.c:959: undefined reference to `png_set_strip_alpha' make[1]: *** [temacs] Error 1 make: *** [dump-elcs] Error 2 and "make" stoped. What happend and what do I have to do ? Fukae Seiji fukae(a)ipc.hiroshima-u.ac.jp

1 participants
0 comments

Why using (push-mark) ? 26 years, 1 month

Didier Verna

What's the reason for [beginning|end]-of-buffer using `(push-mark)' ? I find this very annoying in most of the cases (M-C-[<|>]) because it breaks the expected behavior when the mark is already active: if you type C-SPACE at the beginning of a line, and move around with the arrows, C-n, C-p or whatever. The mark stays at the same position, which is good IMO. Now if you use C-> or C-< this fucks up your previous mark. I'd like this behavior to go away unless there's a very good reason (that I missed) to have it. --didier

2 participants
1 comments

[request] please test new pcl-cvs 26 years, 1 month

Greg Klanderman

Hi XEmacs beta testers, I'd like to solicit help testing the latest distributed pcl-cvs binary package 1.30. This version is based on author version 2.0 beta 2, and contains a significant parser rewrite, M-x cvs-status and M-x cvs-examine, and many other new features. Those of you who use pcl-cvs, could you please beat on it as much as possible and give me feedback. In particular, if there are things the parser does not handle, I'd like to add code to handle those things. Fortunately the new parser will just insert a warning in the *cvs* buffer and continue, unlike the old one. Also I really need help choosing colors for the faces defined in pcl-cvs-xemacs.el. They're only really defaulted for a dark background, and even those I'm not very happy with. I've just completed the rest of the merge with our previous XEmacs version, notably I added parsing of conflicts on stdout (recent CVS versions moved it from stderr) but this is untested. I also merged my patch from last spring for setting flags to the underlying commands. I've also made a first pass at updating the documentation. This stuff is on the branch r1-31-devel. It'll get merged to the main branch in a day or so once I test it some. thanks, Greg

2 participants
4 comments

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > What's the reason for [beginning|end]-of-buffer using `(push-mark)' > ? All the motion commands that take you "far" push the mark, so you can press `C-x C-x' to return where you've been, or to kill the region when it is activated. > I find this very annoying in most of the cases (M-C-[<|>]) because > it breaks the expected behavior when the mark is already active: if > you type C-SPACE at the beginning of a line, and move around with > the arrows, C-n, C-p or whatever. The mark stays at the same > position, which is good IMO. Now if you use C-> or C-< this fucks up > your previous mark. Huh?? You mean M-< and M->? C-< and C-> are commands explicitly used for changing the mark, and they work well. > I'd like this behavior to go away unless there's a very good reason > (that I missed) to have it. Well... {beginning,end}-of-buffer could check if the region was already active, and not push the mark in that case, but I'd like to make damn sure that we don't break anything by that change. M-< and M-> have pushed the mark for ages. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- - When I die, shall I not be like Enkidu? - Like, no, man, you'll be, like, totally dead.

1 participants
0 comments

Re: m2ps missing 26 years, 1 month

SL Baur

Mark Moll <mmoll(a)cs.cmu.edu> writes in xemacs-beta(a)xemacs.org: > It appears that m2ps (the program to convert mule encoded files to > PostScript) is missing. Is there a different way now to print these files? m2ps has never to my knowledge worked with XEmacs. There is a hacked version of ps-print.el to handle Japanese (assuming a postscript printer that can deal with Japanese), but it hasn't been integrated yet. I haven't had access to a postscript printer in over a year and I can't test it. I know the current version of ps-print.el works with XEmacs-no-Mule.

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