December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

minibuf.texi question 24 years, 4 months

Yoshiki Hayashi

I compared minibuf.texi with FSF version and of course there are some differences. I'm not sure about how to handle some part, so I'm asking here. 1. At read-from-minibuffer documentation, FSF manual says: *Usage note:* The INITIAL-CONTENTS argument and the DEFAULT argument are two alternative features for more or less the same job. It does not make sense to use both features in a single call to `read-from-minibuffer'. In general, we recommend using DEFAULT, since this permits the user to insert the default value when it is wanted, but does not burden the user with deleting it from the minibuffer on other occasions. FSF recommends DEFAULT over INITIAL-CONTENTS. Is that so in XEmacs too? 2. FSF minibuf.texi includes doc about read-passwd. However, that file is in xemacs-base package. Where should I document them? 3. read-string, read-command and read-variable doesn't have DEFAULT argument while FSF version has. Is that intentional or just because no one has requested? I'd prefer having DEFAULT argument to have better history support. -- Yoshiki Hayashi

1 participants
0 comments

Re: Ebola in files.el 24 years, 4 months

Eric Marsden

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> char= is all nice, but then we'd also need char<, char>, Hrvoje> char<= etc. That sounds ugly. How does CL collate Hrvoje> characters? A character in Common Lisp has an associated code (which in most implementations is an ASCII value), and the #'char< ordering is consistent with #'< on characters' codes. Alphanumeric characters are guaranteed to respect a sensible partial ordering. <URL:http://www.harlequin.com/support/books/HyperSpec/Body/sec_13-1-6.html> -- Eric Marsden

2 participants
1 comments

Re: OK, browse-url-kfm works (sortof) 24 years, 4 months

Matt Curtin

>>>>> On 17 Dec 1999 14:46:42 +0100, Jan Vroonhof <vroonhof(a)math.ethz.ch> said: I'm chiming in after I got the patch... been sorta busy. :-) Jan> It should never have been removed. Sorry for missing that. I echo that. I'm sure that I removed it inadvertently when trying to merge with FSF's source. (If I had to guess, I'd say that that FSF removed kfm support for political reasons.) -- Matt Curtin cmcurtin(a)interhack.net http://www.interhack.net/people/cmcurtin/

1 participants
0 comments

assert (!badly_p) in 21.2.24 cygnus version 24 years, 4 months

Dmitry Yaitskov

I'm getting this assert now and then while switching Windows' windows (to/from XEmacs): Fatal error: assertion failed, file event-msw.c, line 1337, !badly_p -- Cheers, -Dima.

1 participants
0 comments

Re: Jobs assignments 24 years, 4 months

John S. J. Anderson

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: (snip) Stephen> How about phrasing it: (snack) done; should be up by the time you read this. thanks, john. -- ------------------------------------------------------------------------ John S Jacobs Anderson \ <URL:http://www.xemacs.org> You'll have to pry my Emacs from my cold \ jacobs(a)xemacs.org dead oversized control-pressing left pinky finger. -- Randal L. Schwartz

1 participants
0 comments

Re: check process state before accessing coding_stream (fix PR#1061) 24 years, 4 months

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > Implementing message translation is not that hard. I've already > done a lot of preliminary work in places such as make-msgfile.lex in > lib-src/. Finishing up the work is not that big a task; I already > know exactly how it should be done. Please be ready to discuss details of this with other people who work on these problems. The people I have in mind are Francois Pinard from the Translation Project, Ulrich Drepper (author of GNU gettext), and Noah Friedman who also spent some time working on this.

1 participants
0 comments

Re: Weird byte-compiler tests 24 years, 4 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > One thing is, we haven't really agreed the marker behaviour were > > problems. Should (+ <marker> 0) really be guaranteed to convert > > a marker to integer? > > Is there any other reason to add the constant 0 to something unless > you want the integer coercion side effect? Yes; this kind of code can be obtained from macro expansion. Macros are also the reason why it can be important that that optimization be done. > (+ n 0.0) would be considered an obvious attempt to convert n to a > float. I don't see any intrinsic meaning in (+ n 0.0), and I wouldn't begrudge our compiler for optimizing it away. If you need to convert N to float, you can use the more obvious (float n). > Saying that the type of the return value can't be relied upon to be > a constant is opening a big can of worms. You have to know whether > the result of arithmetic will return a marker or not. Otherwise you > have to do the integer conversion yourself or risk that your > arithmetic results might change if the return value is a marker and > its underlying buffer is modified. The arithmetic functions should > always return constants. That's bad news, because then all number-related optimizations in byte-optimizer go down the drain.

1 participants
0 comments

Re: Ebola in files.el 24 years, 4 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > Hrv> This is not Ebola. Ebola is code like: > > Hrv> (if (eq <char> <integer>) > Hrv> ... > > Well, now I'm confused. > > Comparisons on Numbers > > Each of the functions in this section requires that its arguments > all be numbers; to call one with a non-number is an error. Unless > otherwise specified, each works on all types of numbers, > automatically performing any required coercions when arguments are > of different types. This is, I assume, Common Lisp? Because in XEmacs Lisp characters and markers are also allowed: In addition to numbers, all of the following functions also accept characters and markers as arguments, and treat them as their number equivalents. What "number equivalent" means is open for debate, but equality should remain well-defined in those terms. > There's the function char=, which kind of sounds like it does what > you want, but... char= is all nice, but then we'd also need char<, char>, char<= etc. That sounds ugly. How does CL collate characters? > { > CHECK_CHAR_COERCE_INT (c1); > CHECK_CHAR_COERCE_INT (c2); > > return XCHAR(c1) == XCHAR(c2) ? Qt : Qnil; > } > > Note how the documentation and the implementation don't match. Fixable by changing CHECK_CHAR_COERCE_INT to CHECK_CHAR. > Also note how the optional third buffer argument really sucks here. Totally.

1 participants
0 comments

Re: Weird byte-compiler tests 24 years, 4 months

Adrian Aichner

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: Hrvoje> ObXEmacs: what Perl mode are people actually *using*? The Hrvoje> cperl mode we ship behaves horribly. >> >> I switched to use Ilya's latest version of cperl-mode like a few >> other people on the list have. Hrvoje> Does that work? Where do I get it? 1. Yes, 2. good question. Contrary to what cperl-tips says: `cperl-tips' (buffer: *wide reply to Hrvoje Niksic*, mode: Message) Variable: value: please-ignore-this-line Get newest version of this package from ftp://ftp.math.ohio-state.edu/pub/users/ilya/emacs and/or ftp://ftp.math.ohio-state.edu/pub/users/ilya/perl Subdirectory `cperl-mode' may contain yet newer development releases and/or patches to related files. <lines deleted by Adrian> those links don't work today. I got cperl-version "4.24" today from http://www.cpan.org/misc/emacs/cperl-mode/cperl-mode.el.4.24 byte-compiled it and it now works fine. HTH, Adrian

1 participants
0 comments

Re: Need help: How to apply diffs generated by `cvs diff' 24 years, 4 months

Tor Arntsen

On Dec 20, 9:57, Martin Buchholz wrote: >I tried to apply Daniel Pittman's patch created by `cvs diff' to my >workspace using `patch -d /my/workspace'. However, it only patched >the files in the root directory, like configure.in. Files in the >lwlib/ directory couldn't be found by patch, even though the headers >for those files look like: > >Index: lwlib/xlwradio.h >=================================================================== >RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/Attic/xlwradio.h,v >retrieving revision 1.1.2.1 >diff -u -r1.1.2.1 xlwradio.h >--- xlwradio.h 1999/07/30 09:13:56 1.1.2.1 >+++ xlwradio.h 1999/12/16 09:34:00 > > >The documentation for `patch' indicates that it should look at the >Index: line when patching. So why couldn't it find the file to >patch? More generally, what is the procedure for applying patches >generated by `cvs diff'? I always add -pN to patch, otherwise it will *always* patch all files in the top directory. Try adding -p0. I haven't used patch 2.5 much, but in older versions 'patch' would understand the Index line, but only to a limited extent: If there was a file in the top directory then it would patch that one instead.. only if the file was unique would it patch it where it should be patched. Gave me a lot of problems with ChangeLog and Makefile :-) Patch was thus never very good with Index files anyway, so CVS was fixed instead. More below. >Why doesn't cvs generate headers that look like this instead? patch >understands those. >--- lwlib/xlwradio.h 1999/07/30 09:13:56 1.1.2.1 >+++ lwlib/xlwradio.h 1999/12/16 09:34:00 The newer versions of CVS *do* generate these diffs. I just tried to generate a diff from the xemacs CVS repository, it generated the old diff so it looks like what matters is which version the server is using (all diffs I generate from my own repositories are good). I don't remember when this was fixed in CVS but I recommend upgrading the server to something like 1.10.7 at least. -Tor p.s. Somebody wrote a script to fix those old cvs diffs and posted it on info-cvs. If it's out of the question upgrading CVS then I could try to dig it out.

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 December 1999