July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: GNU Emacs new isearch feature 24 years, 9 months

Hrvoje Niksic

Jake Colman <colman(a)ppllc.com> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> Here is the patch for it to work with itimers. It could > Hrvoje> probably be coded better (e.g. using the RESTART feature > Hrvoje> of itimers), but this should do for starters. > > Any chance that the new portions of FSF Emacs 20.4 be made available > in a 21.1.5 release? No. > Or is the 21.1 series frozen (except for bug fixes) and all new > stuff is in 21.2? 21.1 is deeply frozen, sorry. However, 21.2 happens to be quite stable, so xemacs-beta regulars should not hesitate to try it out.

1 participants
0 comments

Re: Shell trouble - third post (was Shell trouble - second post, please read) 24 years, 9 months

Karl M. Hegbloom

I've seen this sort of thing also. C-c C-c, and it hangs for a long time, flashing the gc cursor now and again.

1 participants
0 comments

Shell trouble - third post (was Shell trouble - second post, please read) 24 years, 9 months

Rodney Stromlund

Surely someone somewhere has had this problem. I am on a HP-UX 10.20 PA2.0. I have tried switching my stty settings to just about everything possible and I always have the same problem. I have not gotten a single email on this. Please just email me and tell me to shut up! Please read on : ** Previous post ** When I enter shell mode (I'm using ksh) if I start a program that has lots of output, I can't break it or move my cursor around until the program ends. Its almost like xemacs is waiting for the shell to take a breath before it will interrupt it. ie. If I pull a Homer and do "tar x" instead of a "tar t", I can press ^C^C and the screen freezes and I won't see anything until the find command finishes. But, when the screen finally refreshes, the find command was allowed to run to completion. Depending on the tarball, this could be a very bad thing! Then the ^C^C goes thru and I see a two command lines. That's just a little too late! This is happens with the latest release xemacs (21.1) and all betas I've used. This never happened on 20.4. Or: If I do a "tar t" and I want to start scrolling thru the output before the command finishes; as soon as I press a key the output freezes until the find finishes. And (say I pressed page up) the page up takes place from the bottom of the output and not where I actually pressed the key. This problem isn't there in telnet or rsh. It is there in rlogin and shell. If this is a FAQ or documented somewhere, just let me know. Otherwise HELP!!!!!!!!!!!!!!!! Thx in advance, ================================ Rodney Stromlund Southwest Airlines Co. Systems Department Sales & Revenue Accounting Group mailto:rstromlu＠wnco.com (214) 792-6484 ================================

2 participants
1 comments

Re: GNU Emacs new isearch feature 24 years, 9 months

Hrvoje Niksic

Here is the patch for it to work with itimers. It could probably be coded better (e.g. using the RESTART feature of itimers), but this should do for starters. The feature could probably be improved (more about that later), but it's quite nice even as it is. --- isearch-mode.el.orig Wed Jul 28 04:15:59 1999 +++ isearch-mode.el Wed Jul 28 04:16:03 1999 ＠＠ -1677,8 +1677,6 ＠＠ ;;; - the variable `isearch-invalid-regexp' is expected to be true ;;; iff `isearch-string' is an invalid regexp. -(require 'timer) - (defgroup isearch-lazy-highlight nil "Lazy highlighting feature for incremental search." :prefix "isearch-lazy-highlight-" ＠＠ -1731,7 +1729,7 ＠＠ (isearch-lazy-highlight-remove-extents)) (if isearch-lazy-highlight-timer (progn - (cancel-timer isearch-lazy-highlight-timer) + (delete-itimer isearch-lazy-highlight-timer) (setq isearch-lazy-highlight-timer nil)))) (defun isearch-lazy-highlight-remove-extents () ＠＠ -1759,8 +1757,10 ＠＠ isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-wrapped nil) (setq isearch-lazy-highlight-timer - (run-with-idle-timer isearch-lazy-highlight-initial-delay nil - 'isearch-lazy-highlight-update))))) + (start-itimer "Lazy highlight" + 'isearch-lazy-highlight-update + isearch-lazy-highlight-initial-delay + nil t))))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. ＠＠ -1805,8 +1805,10 ＠＠ (setq isearch-lazy-highlight-extents (cons ext isearch-lazy-highlight-extents)) (setq isearch-lazy-highlight-timer - (run-at-time isearch-lazy-highlight-interval nil - 'isearch-lazy-highlight-update)) + (start-itimer "Lazy highlight" + 'isearch-lazy-highlight-update + isearch-lazy-highlight-interval + nil t)) (if isearch-forward (setq isearch-lazy-highlight-end (point)) (setq isearch-lazy-highlight-start (point)))) ＠＠ -1815,8 +1817,10 ＠＠ ;; let's try wrapping around the end of the buffer (setq isearch-lazy-highlight-wrapped t) (setq isearch-lazy-highlight-timer - (run-at-time isearch-lazy-highlight-interval nil - 'isearch-lazy-highlight-update)) + (start-itimer "Lazy highlight" + 'isearch-lazy-highlight-update + isearch-lazy-highlight-interval + nil t)) (if isearch-forward (setq isearch-lazy-highlight-end (point-min)) (setq isearch-lazy-highlight-start (point-max))))))))))

2 participants
1 comments

Re: Image lib 24 years, 9 months

Didier Verna

Valdis.Kletnieks(a)vt.edu writes: > I was trying to port Enlightenment to AIX, and having a hell of a time > with what *looked* like linker/shared lib issues. 'better change the machine :-) > Upgrading to Imlib 1.9.5 > solved it - am running just fine on a 24-bit > TrueColor as I type this. I didn't know 1.9.5 was out. My "last version" was 1.9.4. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: Image lib 24 years, 9 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > Hrvoje Niksic <hniksic(a)srce.hr> writes: >> I'm afraid Imlib sucks much worse than ImageMagick. > It looks rather powerfull (there is a caching mechanism directly > implemented in it etc) Yes, but I believe we already do caching. > but the latest version has a bug which makes all applications crash > on TrueColor displays. It's been a while that this bug has been > identified. Ugh. And double ugh. > As always, the problem is to get the balance right between reinventing > the wheel and getting hooked on some external work that we don't have > control on. Maybe we should just write somewhere that we have nothing against unified interface graphics libraries, but until one gets written that doesn't suck we roll our own.

2 participants
1 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 24 years, 9 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> Right on: APA> With an unpatched vc.elc? fontification survives APA> vc-revert-buffer APA> when I have this in my .emacs: APA> (setq font-lock-support-mode 'fast-lock-mode) Oops, I tested this incorrectly. Fontification is lost for me in fast-lock-mode too! APA> Fontification is lost when I use any of these: APA> (setq font-lock-support-mode 'font-lock-mode) APA> (setq font-lock-support-mode 'lazy-lock-mode) APA> For font-lock-mode fontification is lost after `revert-buffer' calls APA> `insert-file-contents'. This is still true. Actually it happens when `insert-file-contents' calls `insert-file-contents-internal'. I don't understand yet why insert-file-contents get called twice for find-file and for vc-revert-buffer. vc-revert-buffer calls insert-file-contents with a t REPLACE argument. Adrian find-file: ====================================================================== 1 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=nil | 2 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=nil | 2 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13338) 1 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13338) vc-revert-buffer: ====================================================================== 1 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=t | 2 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=t | 2 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13328) 1 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13328) APA> All of this in 21.1.4 WindowsNT4sp4 native.

1 participants
0 comments

Re: GNU Emacs new isearch feature 24 years, 9 months

Vin Shelton

>>>>> On 28 Jul 1999, Jake Colman <colman(a)ppllc.com> said: Jake> Any chance that the new portions of FSF Emacs 20.4 be made available in a Jake> 21.1.5 release? Or is the 21.1 series frozen (except for bug fixes) and all Jake> new stuff is in 21.2? The 21.1.x series is reserved for bug fixes, so any new stuff which comes in from FSF Emacs 20.4 will only be in 21.2.x. - vin -- In a minute there is time For decisions and revisions which a minute will reverse. T.S. Eliot

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 24 years, 9 months

Adrian Aichner

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Because normal-mode restores the font lock state. >>> P.S. I am using lazy-shot.el that sim sb> I am using fast-lock. Raymond> Could this be the key? I've noticed that after Right on: With an unpatched vc.elc? fontification survives vc-revert-buffer when I have this in my .emacs: (setq font-lock-support-mode 'fast-lock-mode) Fontification is lost when I use any of these: (setq font-lock-support-mode 'font-lock-mode) (setq font-lock-support-mode 'lazy-lock-mode) For font-lock-mode fontification is lost after `revert-buffer' calls `insert-file-contents'. All of this in 21.1.4 WindowsNT4sp4 native. BTW: Although font-lock-support-mode is documented, it does not seem to be defined anywhere. Is this intentinal? Seem to me it should be defcustomed to take on any of the three choices above. Regards, Adrian Raymond> revert-buffer on large files lazy-shot doesn't fontify Raymond> anything. Only new stuff is fontified. Existing stuff Raymond> that hasn't been changed isn't fontified. So perhaps Raymond> lazy-shot is getting confused after revert-buffer about Raymond> what has been fontified and what has not? Raymond> Ray

1 participants
0 comments

Speaking of isearch-mode.el... 24 years, 9 months

Charles Hines

Since there seems to be an interest in isearch-mode.el right now, I'll ask a question I asked a long time ago - anybody know why using history with isearch is broken? For example, try this: run xemacs -q clear scratch buffer with C-_ enter 'a b c a b c a b c <RET>' isearch for a from beginning of buffer (M-< C-s a) stop isearch, then isearch for b (M-< C-s b) stop isearch, then isearch for c (M-< C-s c) stop isearch, then isearch for c again, using M-p to recall it, search for it twice, second time it starts looking for b instead of c (M-< C-s M-p M-p M-p C-s C-s) I've tried a couple of times (half-heartedly, I admit) to debug it, but haven't had much success other than it looks like the search-ring and search-ring-yank-pointer get out of sync at some point... The vanilla Emacs 20.4 isearch.el doesn't suffer from this, I noted, but they were enough different that it didn't really help me figure it out. Anyone have any ideas? Chuck -- Charles K. Hines <chuck_hines(a)vnet.ibm.com> <hinesc(a)us.ibm.com> IBM Logic Synthesis Developer [BooleDozer (TM)] Martial Arts Instructor [Modern Arnis and Balintawak Escrima] "Go back to sleep, Chuck. You're just havin' a nightmare -- of course, we ARE still in Hell." (Gary Larson)

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