June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Moving mouse in balloon-help frame crashes XEmacs-21.2-b15 in MSWin 24 years, 11 months

Jan Vroonhof

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > If there are other outstanding redisplay bugs, send them my way. > It's still cold in Seattle. Don't forget to check the redisplay section of the bug tracking system. Good luck! Jan

1 participants
0 comments

Re: [FAILED] XEmacs 21.2.15 24 years, 11 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > You moved mule-misc.el to <core>/lisp/mule/ from > <packages>/lisp/mule-base/. I update packages by untarring them (I've > done something stupid and package-ui doesn't work well for me, it's my > fault though, not pui's); this doesn't remove the old ones. > > So I got hosed. I really didn't want to admit that :-) Maybe the package vs system files precedence order should be re thunk? Jan

1 participants
0 comments

mule-base change -- mule-debug.el must die 24 years, 11 months

SL Baur

It doesn't work and traces its lineage to Mule 0.9.8, which probably isn't very useful. There is a more up-to-date version in mule-diag.el and this has been run by Moriokasan. 1999-06-07 SL Baur <steve(a)xemacs.org> * mule-debug.el: delete. No patch. I'm cvs remove'ing the file. -- I protest the NATO war in Yugoslavia.

1 participants
0 comments

Re: ldap support fails 24 years, 11 months

Oscar Figueiredo

>>>>> "Michael" == Michael Harnois <mharnois(a)willinet.net> writes: Michael> I ended up disabling ldap support in the latest 21.2 from CVS because Michael> I couldn't figure out a way around this error: Michael> gcc -c -g -O2 -march=pentium -fno-exceptions -fno-omit-frame-pointer Michael> -Demacs -I. -DHAVE_CONFIG_H -I/usr/include/openldap Michael> -I/usr/X11/include /src/xemacs-21.2/src/eldap.c Michael> /src/xemacs-21.2/src/eldap.c: In function `signal_ldap_error': Michael> /src/xemacs-21.2/src/eldap.c:80: dereferencing pointer to incomplete type Michael> /src/xemacs-21.2/src/eldap.c: In function `Fldap_open': Michael> /src/xemacs-21.2/src/eldap.c:313: dereferencing pointer to incomplete type Michael> /src/xemacs-21.2/src/eldap.c:314: dereferencing pointer to incomplete type Michael> /src/xemacs-21.2/src/eldap.c:315: dereferencing pointer to incomplete type Michael> /src/xemacs-21.2/src/eldap.c:319: dereferencing pointer to incomplete type Michael> I tried several different things to no avail. This has been compiling Michael> for me for some time with no problem; I'm not sure what has changed, Michael> although I see there have been changes applied. There have been no recent changes to the LDAP C code in XEmacs (the changes that were applied lately were on ldap.el only). Something has certainly changed in the LDAP libraries you're using. What version/flavor of the LDAP libraries are you using ? Oscar

1 participants
0 comments

Re: string-lessp Mule speedup 24 years, 11 months

SL Baur

Mike McEwan <mike(a)lotusland.demon.co.uk> writes in xemacs-beta(a)xemacs.org: > Something funny started happenning with `func-menu' function > listings so... > (string-lessp "abcd" "abce") > ==> nil I see this too. -- I protest the NATO war in Yugoslavia.

2 participants
1 comments

Re: string-lessp Mule speedup 24 years, 11 months

Mike McEwan

Hrvoje Niksic <hniksic(a)srce.hr> writes: > string-lessp uses string_char() to access individual charactrs, even > under Mule where that operation is O(n). This makes string comparison > O(n^2), potentially very slow for large strings. > > This is not noticable with short strings, but is catastrophic with > longer ones (and I can only guess what it does to sorting). To test > the slowness of comparing long strings, try this (under Mule): > > (setq s1 (make-string 10000 ?a)) <C-x C-e> > (setq s2 (make-string 10000 ?a)) <C-x C-e> > (string-lessp s1 s2) > > With this patch the comparison becomes instantaneous: > > 1999-06-04 Hrvoje Niksic <hniksic(a)srce.hr> > > * fns.c (Fstring_lessp): Remove O(n^2) under Mule. > Something funny started happenning with `func-menu' function listings so... (string-lessp "abcd" "abce") ==> nil ??? -- Mike.

1 participants
0 comments

Re: mswindows-get-clipboard broken in beta 15? 24 years, 11 months

Hrvoje Niksic

Dmitry Yaitskov <dimas(a)home.com> writes: > > I really don't want technical discussions to degrade to > > name-calling. > > I just re-read the whole thread. I haven't found any place where I > was "name-calling", but if it sounded that way I'm sorry. I meant that further discussion in the same tones would soon degrade to name-calling. Such things happen when we least want it, and nobody is really immune to that.

1 participants
0 comments

Re: mswindows-get-clipboard broken in beta 15? 24 years, 11 months

Dmitry Yaitskov

Hrvoje Niksic <hniksic(a)srce.hr> wrote: > Dmitry Yaitskov <dimas(a)home.com> writes: <snip> > > do not run b15 normally, it is unusable for me). > > ...which you keep repeating in every one of your messages. I'm sorry. > I really don't want technical discussions to degrade to > name-calling. I just re-read the whole thread. I haven't found any place where I was "name-calling", but if it sounded that way I'm sorry. > Clobbering clipboard contents with selection is not the desirable > behaviour, either in Windows or in X. I'm sure Andy will fix the > problem when he gets back. That's fine, from your and Andy's replies I gathered (hopefully, wrongly) that what looked like a problem to me was really an intended feature, and that really got me terribly worried, wouldn't you be if your favorite editor was becoming unusable for you (oops. I just repeated that again. Sorry :-) ). -- Cheers, -Dima.

1 participants
0 comments

Re: mswindows-get-clipboard broken in beta 15? 24 years, 11 months

Dmitry Yaitskov

Andy Piper <andy(a)xemacs.org> wrote: > At 06:03 PM 6/4/99 -0400, Dmitry Yaitskov wrote: > >Dmitry Yaitskov <dimas(a)home.com> wrote: > > > >> Hi, > >> > >> I've noticed that the behaviour of yank-clipboard-selection has > >> changed in b15 as opposed to b14 - now, if the function is invoked > >> while there is a selection active, *it* is yanked instead of the > >> clipboard contents. IMHO this is a bug, although I'm not sure - the > >> doc string is ambiguous, as it says: > >> > >> "Insert the current Clipboard selection at point." > >> > >> It is unclear what is meant by "Clipboard selection". Can somebody > >> please enlighten me - is it a bug or a feature? (in any case, it is > >> probably something that only matters under NT, as under X AFAIK the > >> selection *is* the "clipboard")... thanks. > > > >Sorry for followup to my own post. Seems like the bug is in the > >mswindows-get-clipboard function, which if I'm not mistaken copies the > >current selection into the clipboard if there is one - and it > >shouldn't do it. I can't be too sure as the problem seems to lie in > >the select-msw.c file, and I do not understand the code there. In > >particular, there is a new (in b15) function mswindows_own_selection > >which obviously is invoked by something, but I couldn't find any > >reference to it in any other sources... Can somebody who knows that > >code (Andy Piper?) please take a look at it? Thanks. > > I fly to San Fransico in 4 hours so don't have time right now. The change > is possibly intentional as the windows select behaviour should now mimic > the X behaviour. This is not necessarily completely what you want but is a > lot better than what we had before. I am not sure I understand you correctly, but if so - this means that it breaks the way cut/copy/paste is done in Windows. Is it a "good thing"? Why is that a lot better than what we had before? I for one went back to b14 only because of this. Ok, so I might be missing something. How can I mimic the old behaviour, which is standard in Windows, now? What I want is to be able to copy something to the clipboard, then select something else, and do a paste to replace the new selection with the clipboard contents. I tried doing (defun my-paste-selection () (interactive) (delete-primary-selection) (yank-clipboard-selection)) but it didn't work. That is, it still copied the current selection into the clipboard, before pasting it. AFAIK this indeed is the way X works, but what's so good about it? And now from what you say I gather that this new behaviour is intentional and built into a very low level of XEmacs, so that it is impossible to avoid? Unless am I missing something obvious... Thanks. -- Cheers, -Dima.

2 participants
1 comments

Re: mswindows-get-clipboard broken in beta 15? 24 years, 11 months

Hrvoje Niksic

Dmitry Yaitskov <dimas(a)home.com> writes: > And so, I dare say, will 99% of all Windows users. And please not > that it's even worse! Simply selecting text without doing any > explicit copy or cut in XEmacs b15 looks as if the text *has* been > copied to the clipboard. And guess what? It is, I just tried (no, I > do not run b15 normally, it is unusable for me). ...which you keep repeating in every one of your messages. I really don't want technical discussions to degrade to name-calling. Clobbering clipboard contents with selection is not the desirable behaviour, either in Windows or in X. I'm sure Andy will fix the problem when he gets back.

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