September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Ispell.el bug [was Re: Announcing Kspell version .10 alpha] 26 years, 7 months

Ken Stevens

Jan Vroonhof writes: > > For some reason Xemacs (and probably Emacs) want to reverse the > > suggestion list. If anyone can shed some light as to why Xemacs does > > this please let me know. > > Our DNS claims kdstevens.com does not exist Well, technically your DNS should claim that the search timed out. I got dropped on the floor as my Internet provider went out of business with no warning so I've been scrambling to get hooked up again. My new provider should propagate tomorrow from interNIC, so hopefully I'll be back on line. sigh. > Unless it was intentional (this seems unlikely to me) this is a bug in > ispell.el. It reads the output from ispell converting the result to a > list. However as it reads on it pushes each guess to the FRONT of the > list in effect creating a reversed list. Well, it was intentional only in that it didn't require an append or reverse call. I guess I worried more about performance than the alphabetical order of the list... > - (list original-word offset miss-list guess-list))))) > + ;; XEmacs change (return correct order) > + (list original-word offset (nreverse miss-list) (nreverse guess-list)))))) This fix looks like the best solution to me, as calling append as the function is being built is a real dog. Thanks! > Ken, in adition you might want to check out this > > 1998-09-06 Didier Verna <verna(a)inf.enst.fr> > > * ispell.el: changed *-latin-* symbols to *-8859-* so that ispell > can find the related coding systems. Does this work right with emacsen other than XEmacs? If so I'll stick that in as it is. > 1998-04-01 SL Baur <steve(a)altair.xemacs.org> > > * ispell.el (ispell-highlight-spelling-error): Fix typo in version > detection regexp. Yup, I caught that one right away. Thanks for the fix. cheers -Ken __________________________________________________________________________ Ken Stevens e-mail: k.stevens(a)ieee.org http://kdstevens.com/~stevens/ispell-page.html

1 participants
0 comments

Problems with creating frame on remote display 26 years, 7 months

David Bush

This is a mixture of a "how-to" question and a real problem I run Xemacs on my Sun workstation and frequently connect from my PC at home and use gnuclient to create a remote frame on the PC. I believe others on this list have mentioned in passing that they do someting similar. This works reasonably well, but I do have a couple of problems. 1. The frame on the PC is way to big and the fonts are oversized. Is there anyway to get Xemacs to adjust to different screen resolutions on different displays? 2. I haven't been able to get the meta key to work on the PC. On the Sun I still have it defaulted to the "diamond" key. My efforts to remap using xmodmap have been fruitless thus far. As anyone solved this? I have this problem even if run gnuclient -nw and work in tty mode. 3. If my ISP has a glitch and drops my connection, the X error causes the entire Xemacs on the Sun to die. Is there any way to prevent this from happening? TIA, david

1 participants
0 comments

Re: Bug: png files at cvs.xemacs.org 26 years, 7 months

SL Baur

[There's something weird going on at the mail server. I've started getting my own posts back with my address changed to <steve(a)tux.org>. Could someone please let me know what you are seeing from this message? Thanks.] Andy Piper <andyp(a)parallax.co.uk> writes in xemacs-beta(a)xemacs.org: > I hope you are using cvs 1.10 as the client and server. I fixed quite a few > bugs post 1.9 in this area. I know Jareth is testing cvs 1.10 for cvs.xemacs.org. He'll move to it when he trusts it. No one has direct access to the master core XEmacs CVS tree on altair. What are the problems on the client side? The core XEmacs tree (which started this thread) is maintained fully by vanilla CVS 1.9 and rsync'ed to cvs.xemacs.org. I have no plans on upgrading until after XEmacs 21.0 is released.

3 participants
2 comments

[RFC] the behavior of search_command 26 years, 7 months

Didier Verna

Several interactive search functions use the internal search_command function. This is *the* function that decides whether to be case-sensitive, according to the value of case-fold-search. In the case where case-fold-search is non nil (ignore case), I find the behavior not optimal. Basically (at least in the interactive case), I'd like to be able to type uppercase characters in order to specify that I want actually a case-sensitive search, just for this time, regardless of the value of case-fold-search. What this means is that when case-fold-search is non nil, we should scan the search string for uppercase characters, in order to decide whether to be really case-insensitive or not. There are two ways to achieve this: we can modify search_command (I have a patch ready for this), or we can modify each concerned lisp function. The point is that I don't know if there are non-interactive cases that could be fucked up with this new feature. If not, we'd better patch search_command directly. If yes, then it's preferable to modify the lisp functions, and check if we're calling them interactively. Or maybe not, if we use (downcase ...) to ensure we'll match everything ... RFC. -- / / _ _ 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

VC on NT problems 26 years, 7 months

Jan Vroonhof

[N.B. Can anything which has the slightest chance of being related to non NT things please be discussed on xemacs-beta]. This is in response to thread about VC on NT that I saw on the archive. Regardless of whether any more general solutions for this problem will be implemented, I want to ask: Can everybody who is using an package which we keep in sync with the FSF please check the solutions from the latest FSF Emacs. This will keep the number of NIH solutions down and make syncing easier. In this case I think the FSF 20.3 version of VC has the "also look for .EXE etc" type patch already. In cases like this it is often better just to sync with the FSF regardless of the quality of their solution. JAn

1 participants
0 comments

Re: fix for redisplay! 26 years, 7 months

Hrvoje Niksic

Sorry Ben, but this is offending, to say the least. Mozilla is broken. It doesn't even recognize valid HTML comments, let alone an extension language or other much-needed functionality. It would make *a lot* sense to have a decent browser within XEmacs. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Call CIA and tell them that you have placed a bomb in a 7-11 shop! Be sure to let them trace you. Spend 10 years in jail and then regret it.

2 participants
1 comments

Problem with XEmacs.org mail server 26 years, 7 months

SL Baur

[The test can end now. The results are conclusive.] Ian MacKinnon <IMacKinnon(a)telia.co.uk> writes in xemacs-beta(a)xemacs.org: > Yup, steve＠tux All right, thanks Ian (and Stephen and Didier). There is very definitely a problem with the mail server. Please do not send me email at <steve(a)tux.org> -- it will get filtered into the shitter as SPAM. In the meantime I'm going to use another address that doesn't get mangled[1] until the problem gets fixed. Footnotes: [1] Except for filtered SPAM, it all goes into the same mailbox anyway.

1 participants
0 comments

RE: Bug: png files at cvs.xemacs.org 26 years, 7 months

Ian MacKinnon

Yup, steve＠tux --- Ian -----Original Message----- From: SL Baur [SMTP:steve＠tux.org] Sent: Monday, September 14, 1998 7:58 AM To: xemacs-beta(a)xemacs.org Subject: Re: Bug: png files at cvs.xemacs.org [There's something weird going on at the mail server. I've started getting my own posts back with my address changed to <steve(a)tux.org>. Could someone please let me know what you are seeing from this message? Thanks.] Andy Piper <andyp(a)parallax.co.uk> writes in xemacs-beta(a)xemacs.org: > I hope you are using cvs 1.10 as the client and server. I fixed quite a few > bugs post 1.9 in this area. I know Jareth is testing cvs 1.10 for cvs.xemacs.org. He'll move to it when he trusts it. No one has direct access to the master core XEmacs CVS tree on altair. What are the problems on the client side? The core XEmacs tree (which started this thread) is maintained fully by vanilla CVS 1.9 and rsync'ed to cvs.xemacs.org. I have no plans on upgrading until after XEmacs 21.0 is released.

1 participants
0 comments

The proposed XEmacs 21.0 distribution directory has been retracted 26 years, 7 months

SL Baur

I've moved it into xemacs/beta/xemacs-21.0-preliminary until the last minute issues get sorted out.

1 participants
0 comments

Re: fix for redisplay! 26 years, 7 months

Hrvoje Niksic

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > speaking of redisplay: is the rewrite project still alive (has it > ever been alive)??? The redisplay rewrite is not alive, because Joel's company quit the project. There was an explanatory message to this list some time ago. However, his ideas are still good ones (or so it would seem to me), and rewriting the redisplay should be an interesting project. Your patch looks good to me, based on your previous description of the problem, but be warned that I know next to nothing about redisplay. Could you please remail your patch to xemacs-patches, along with a short rehash of why it is needed, and a ChangeLog entry? Thanks. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

6 participants
6 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 September 1998