October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Puzzled: `line-move-ignore-invisible' and cursor? 24 years, 7 months

Jan Vroonhof

Mike McEwan <mike(a)lotusland.demon.co.uk> writes: > Why does the cursor disappear on lines 4 and 2? It moves to the wrong lines. Try enabling line-mumber-mode then you'll see that on the way down you get on (buffer-)line 1,3,5,7,9 (i.e. the visible-lines ). However if you press cursor up on line 9 you get to line 6 instead of seven! Jan

1 participants
0 comments

Puzzled: `line-move-ignore-invisible' and cursor? 24 years, 7 months

Mike McEwan

Do others see this: Evaluate the following two functions and then `M-x mmc-test RET'. You should be in buffer "mmc-test-buffer". Move the cursor up one line repeatedly until you reach the beginning of the buffer (up arrow, or `C-p'). Why does the cursor disappear on lines 4 and 2? The cursor remains visible on the way down the buffer? I've tried this with 21.2.b18 also, with the same results. I don't know about the 21.1 series, but the cursor remains visible at all times under FSF Emacs. `redisplay' ? Perhaps minor aesthetics, but you know what it's like when you've started with something :-). (defun mmc-hide-lines () "*Hide all but `Line: nn' lines in the current buffer." (interactive) (make-local-variable 'line-move-ignore-invisible) (setq line-move-ignore-invisible 't) ;ignore invisible lines (make-local-variable 'hide-extents) (setq hide-extents nil) (save-excursion (goto-char (point-min)) (let (beg end) (re-search-forward "^Line: [0-9]?[0-9]\n" nil t) (setq beg (match-end 0)) (while (re-search-forward "^Line: [0-9]?[0-9]\n" nil t) (setq end (match-beginning 0)) (push (cons beg end) hide-extents) (setq beg (match-end 0))) (setq end (point-max)) (push (cons beg end) hide-extents) (setq hide-extents (nreverse hide-extents)) (mapcar '(lambda (extent) (put-text-property (car extent) (cdr extent) 'invisible 't)) hide-extents)))) (defun mmc-test () (interactive) (require 'cl) (let ((test-data (concat "Line: 1\n" "Some intervening text.\n" "Line: 2\n" "Some intervening text.\n" "Line: 3\n" "Some intervening text.\n" "Line: 4\n" "Some intervening text.\n" "Line: 5\n" "Some intervening text.\n" ))) (switch-to-buffer "mmc-test-buffer") (insert test-data) (mmc-hide-lines))) -- Mike <mike(a)lotusland.demon.co.uk>

1 participants
0 comments

[FAIL] CVS Sources (NT) 24 years, 7 months

Norbert Koch

Hi! The latest sources fail to build due to ... (my formatting) elhash.c ..\src\elhash.c(921) : error C2039: 'ui' : is not a member of 'Lisp_Hash_Table' ..\src\elhash.c(47) : see declaration of 'Lisp_Hash_Table' ..\src\elhash.c(922) : error C2039: 'ui' : is not a member of 'Lisp_Hash_Table' ..\src\elhash.c(47) : see declaration of 'Lisp_Hash_Table' The relevant passage is (function resize_hash_table) if (XRECORD_LHEADER (ht)->data_dumped) XRECORD_LHEADER (ht)->data_dumped = 0; Lisp_Hash_Table doesn't have a member data_dumped (but don't ask me, why cl is complaining about 'ui' :-)). Is it missing, a typo (ie it should be 'header'), or is this a leftover from 'old days'? Thanks, norbert.

2 participants
1 comments

Re: Question about XEmacs 21 24 years, 7 months

Jan Vroonhof

[I ditched review from the CC'es] Olivier Galibert <galibert(a)pobox.com> writes: > Some statistics you may find interesting, for a run of xemacs -q in my > local configuration (most, but not all, of the packages): > > site-start stats : 210 This is weird 1. After scanning the packages the locate-file cache should be filled and scanning the tree should be cheap shouldn't it? 2. If you _have_ site-start.el it should be in ../site-packages/lisp which should be very early in the search sequence. > auto-autoloads stats : 270 > Sucessful auto-autoload.el* stats are systematically followed by a > fstat. > > Some interesting excerpts: > [5 stats for one auto-load removed] > Looks like there is some room for improvement even without affecting > flexibility. The problem is that XEmacs is still doing the generic loading code at startup this includes such stuff as checking for outdated .elc files etc. IMHO XEmacs should just try to open ../lisp/package-name/auto-autoloads.elc and handle any errors. No stats required. Then one should get rid of the stupid double loading the mule coding does (if you do this at C level the first 3000 byte will typically still be in the stdio stream buffer and no additional I/O is required). Long term I think the format of the .elc files should be rethought. Why is it a lisp file? Jan

1 participants
0 comments

Re: Question about XEmacs 21 24 years, 7 months

Olivier Galibert

On Sat, Oct 02, 1999 at 07:25:08PM -0700, Kyle Jones wrote: > I haven't looked at the latest code, so I don't know all that is > causing the current slowdown. It is clear that the package > code has to check all the package directories for auto-autoloads > files, and that is enough by itself to cause a substantial > startup slowdown. To get the speed back, at the very least we'll > have to get rid of most of the newly added I/O. Some statistics you may find interesting, for a run of xemacs -q in my local configuration (most, but not all, of the packages): auto-autoloads stats : 270 site-start stats : 210 /toolbar stats : 25 /etc stats : 36 package dirs stats : 90 Sucessful auto-autoload.el* stats are systematically followed by a fstat. Some interesting excerpts: stat("/sw/xemacs/install/lib/xemacs/xemacs-packages/lisp/hm--html-menus/auto-autoloads.elc", {st_mode=0, st_size=0, ...}) = 0 stat("/sw/xemacs/install/lib/xemacs/xemacs-packages/lisp/hm--html-menus/auto-autoloads.elc", {st_mode=0, st_size=0, ...}) = 0 fstat(5, {st_mode=0, st_size=0, ...}) = 0 stat("/sw/xemacs/install/lib/xemacs/xemacs-packages/lisp/hm--html-menus/auto-autoloads.elc", {st_mode=0, st_size=0, ...}) = 0 fstat(5, {st_mode=0, st_size=0, ...}) = 0 stat("/sw/xemacs/install/lib/xemacs/xemacs-packages/lisp/hm--html-menus/auto-autoloads.el", {st_mode=0, st_size=0, ...}) = 0 fstat(5, {st_mode=0, st_size=0, ...}) = 0 stat("/sw/xemacs/install/lib/xemacs/mule-packages/lisp/site-start.elc", 0xbfffec88) = -1 ENOENT (No such file or directory) stat("/sw/xemacs/install/lib/xemacs/mule-packages/lisp/site-start.el", 0xbfffec88) = -1 ENOENT (No such file or directory) stat("/sw/xemacs/install/lib/xemacs/mule-packages/lisp/site-start", 0xbfffec88) = -1 ENOENT (No such file or directory) Looks like there is some room for improvement even without affecting flexibility. OG. PS: I don't care much, my xemacs pops up in less than one second, and I use gnuclient anyway.

1 participants
0 comments

Re: latest cvs fails 24 years, 7 months

Michael Harnois

On Sat, 2 Oct 1999 19:00:53 -0400, Olivier Galibert <galibert(a)pobox.com> said: > Heh. I don't pretend that the portable dumper is working yet > :-) I'm just surprised, because it's worked for me on every build but this one. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org An infallible method of conciliating a tiger is to allow oneself to be devoured. -- Konrad Adenauer

2 participants
1 comments

Re: latest cvs fails 24 years, 7 months

Michael Harnois

Ah, if I don't use the portable dumper it works ... -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org An infallible method of conciliating a tiger is to allow oneself to be devoured. -- Konrad Adenauer

2 participants
1 comments

latest cvs fails 24 years, 7 months

Michael Harnois

Goes fine till you get here ... make[1]: Entering directory `/usr/src/xemacs/src' EMACSBOOTSTRAPLOADPATH="/usr/src/xemacs-21.2/src/../lisp/:/usr/src/xemacs" EMACSBOOTSTRAPMODULEPATH="/usr/src/xemacs-21.2/src/../modules/:/usr/src/xemacs" ./temacs -batch -l /usr/src/xemacs-21.2/src/../lisp/update-elc.el *** Error in XEmacs initialization (error "Internal error: lstream has no writer" #<INTERNAL OBJECT (XEmacs bug?) (resizing-buffer lstream) 0x82eb8c0>) *** Backtrace really-early-error-handler((error "Internal error: lstream has no writer" #<INTERNAL OBJECT (XEmacs bug?) (resizing-buffer lstream) 0x82eb8c0>)) -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org An infallible method of conciliating a tiger is to allow oneself to be devoured. -- Konrad Adenauer

1 participants
0 comments

Qunbound and the portable dumper... 24 years, 7 months

Jan Vroonhof

Isn't the problem simply that UNBOUNDP fails on the variable although it is unbound? Does pdumping change the address of Qunbound without changing the values of unbound variables? Jan

2 participants
1 comments

RE: 21.2: patch for new portable dumper 24 years, 7 months

Damon Lipparelli

Works fine. Here's the corrected patch. -lipp -----Original Message----- From: Olivier Galibert [mailto:galibert＠pobox.com] Sent: Friday, October 01, 1999 4:05 PM To: 'xemacs-beta(a)xemacs.org'; xemacs-review(a)xemacs.org Subject: Re: 21.2: patch for new portable dumper On Fri, Oct 01, 1999 at 10:32:54AM -0700, Damon Lipparelli wrote: > I had to apply the following to get things compiling for native Windows. Sorry, missed that one. The patch is wrong, it should be REINITIALIZE_IMAGE_INSTANTIATOR_FORMAT, with only one parameter. Could you please try that way ? OG.

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