January 2001 - XEmacs-Beta - XEmacs Mailing List Archives

ediff control frame has buffer tabs 23 years, 3 months

Stephen J. Turnbull

This is not a feature IMHO. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

2 participants
1 comments

Re: Tab display patch 23 years, 3 months

Ilpo Nyyss=f6nen

Markus Alt <altmark(a)de.ibm.com> writes: > Now, if I open a lot of files (i.e. more tabs than fit in the visible > buffer tabs area), it appears to me as if the least recently opened > files' tabs go into a kind of "second buffer tabs list". When switching > back (via C-x b) to a buffer whose tab is currently not visible, I see > this "second list", i.e. the tab of the selected buffer tab and the > other tabs formerly not displayed. > > But instead I would expect to see the tab of the selected buffer added > to the currently displayed tabs and the least recently visited buffer's > tab removed from the visible tabs in order to "make room" for the tab of > the selected buffer. In other words: Always display the tabs of the most > recently used buffers. I ran into this same bug and found out that automatic font-lock-mode with that verbose thing on causes this. You should be able to reproduce this by making the font-lock-mode with that verbose thing on to come on automatically and then open few buffers with that, for example foo1.c and foo2.c. Now the one you opened last should be the rightmost and without that font-lock-mode's verbose stuff it would be the leftmost. At least this is what I ran into. I think that I will leave that verbose setting off. :-) I have the latest cvs-version of xemacs. -- Ilpo Nyyssönen # biny /* :-) */

2 participants
1 comments

Infinite loop displaying article in Gnus 23 years, 3 months

Gleb Arshinov

In XEmacs 21.2 (beta37) "Pan" [Lucid] (i586-pc-win32) of Wed Nov 15 2000 on SLOTH configured using `configure UNKNOWN' Sometimes when for the first time opening a message after Gnus startup, XEmacs seems to go into infinite loop consuming 100% CPU. Any ideas? Gleb XEMACS! memchr + 5 bytes bi_scan_buffer(buffer * 0x024bc200, int 10, long 177, long 16354, long 2147483644, long * 0x0082a530, int 0) line 608 + 33 bytes scan_buffer(buffer * 0x024bc200, int 10, long 1, long 16354, long 2147483647, long * 0x0082a530, int 0) line 697 + 33 bytes buffer_line_number(buffer * 0x024bc200, long 16354, int 0) line 297 + 47 bytes window_line_number(window * 0x023c7c00, int 2) line 6646 + 15 bytes decode_mode_spec(window * 0x023c7c00, int 108, int 2) line 6721 + 13 bytes generate_fstring_runes(window * 0x023c7c00, position_redisplay_data_type * 0x0082a870, long 61, long 60, long -1, long 29515220, int 3, int 657, unsigned int 1, int 2, long * 0x0082a864, long 28360708) line 3874 + 17 bytes generate_fstring_runes(window * 0x023c7c00, position_redisplay_data_type * 0x0082a870, long 60, long 0, long -1, long 37758360, int 1, int 657, unsigned int 1, int 2, long * 0x0082a864, long 28360708) line 4056 + 65 bytes generate_formatted_string_db(long 37758228, long 36476276, window * 0x023c7c00, display_line * 0x024b5000, display_block * 0x01b5be00, unsigned int 1, int 2, int 659, int 2) line 3507 + 54 bytes generate_modeline(window * 0x023c7c00, display_line * 0x024b5000, int 2) line 3669 + 51 bytes ensure_modeline_generated(window * 0x023c7c00, int 2) line 4211 + 19 bytes real_current_modeline_height(window * 0x023c7c00) line 4224 + 11 bytes window_modeline_height(window * 0x023c7c00) line 930 + 9 bytes window_bottom_window_gutter_height(window * 0x023c7c00) line 1046 + 9 bytes window_bottom_gutter_height(window * 0x023c7c00) line 1059 + 9 bytes start_end_of_last_line(window * 0x023c7c00, long 1, int 1, int 1) line 7551 + 21 bytes end_of_last_line_may_error(window * 0x023c7c00, long 1) line 7646 + 17 bytes pixel_to_glyph_translation(frame * 0x01d1a000, int 239, int 355, int * 0x0082ad30, int * 0x0082ad24, int * 0x0082ad14, int * 0x0082ad18, window * * 0x0082ad34, long * 0x0082ad38, long * 0x0082ad10, long * 0x0082ad28, long * 0x0082ad2c, long * 0x0082ad20) line 8779 + 29 bytes event_pixel_translation(long 37521852, int * 0x00000000, int * 0x00000000, int * 0x00000000, int * 0x00000000, window * * 0x0082ad7c, long * 0x00000000, long * 0x00000000, long * 0x00000000, long * 0x00000000, long * 0x00000000) line 1825 + 66 bytes Fevent_window(long 37521852) line 1955 + 31 bytes Ffuncall(int 2, long * 0x0082ae0c) line 3528 + 66 bytes execute_optimized_program(const unsigned char * 0x01b57c10, int 5, long * 0x01ca2c10) line 746 + 16 bytes funcall_compiled_function(long 30230728, int 1, long * 0x0082b0f8) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082b0f4) line 3563 + 17 bytes call1(long 30217948, long 37521852) line 4183 + 11 bytes execute_internal_event(long 37521852) line 2938 + 16 bytes Faccept_process_output(long 39214592, long 28360708, long 28360708) line 2637 + 9 bytes Ffuncall(int 2, long * 0x0082b210) line 3528 + 127 bytes execute_optimized_program(const unsigned char * 0x0082b40c, int 10, long * 0x01c04610) line 746 + 16 bytes Fbyte_code(long 29310228, long 29378048, long 21) line 2405 + 38 bytes Feval(long 29385800) line 3331 + 187 bytes internal_catch(long 29248764, long (long)* 0x01070ea7 Feval(long), long 29385800, int * volatile 0x00000000) line 1317 + 7 bytes execute_rare_opcode(long * 0x0082b71c, const unsigned char * 0x01da01a8, int 141) line 1252 + 22 bytes execute_optimized_program(const unsigned char * 0x01da0110, int 9, long * 0x01be7910) line 656 + 17 bytes funcall_compiled_function(long 29246144, int 6, long * 0x0082ba08) line 518 + 53 bytes Ffuncall(int 7, long * 0x0082ba04) line 3563 + 17 bytes Fapply(int 6, long * 0x0082bafc) line 3804 + 13 bytes Ffuncall(int 7, long * 0x0082baf8) line 3549 + 14 bytes execute_optimized_program(const unsigned char * 0x01d28090, int 7, long * 0x01cd2890) line 746 + 16 bytes funcall_compiled_function(long 30440856, int 6, long * 0x0082bddc) line 518 + 53 bytes Ffuncall(int 7, long * 0x0082bdd8) line 3563 + 17 bytes Fapply(int 6, long * 0x0082bed0) line 3804 + 13 bytes Ffuncall(int 7, long * 0x0082becc) line 3549 + 14 bytes execute_optimized_program(const unsigned char * 0x025ad4d0, int 7, long * 0x01fa3b90) line 746 + 16 bytes funcall_compiled_function(long 33442804, int 3, long * 0x0082c1b4) line 518 + 53 bytes Ffuncall(int 4, long * 0x0082c1b0) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x024b3350, int 4, long * 0x01ffd310) line 746 + 16 bytes funcall_compiled_function(long 33578028, int 2, long * 0x0082c48c) line 518 + 53 bytes Ffuncall(int 3, long * 0x0082c488) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02565f90, int 5, long * 0x01ffc790) line 746 + 16 bytes funcall_compiled_function(long 33577496, int 1, long * 0x0082c768) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082c764) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02565490, int 6, long * 0x01ffc710) line 746 + 16 bytes funcall_compiled_function(long 33577524, int 0, long * 0x0082ca48) line 518 + 53 bytes Ffuncall(int 1, long * 0x0082ca44) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02341b70, int 1, long * 0x01ff4370) line 746 + 16 bytes funcall_compiled_function(long 33577356, int 0, long * 0x0082cd14) line 518 + 53 bytes Ffuncall(int 1, long * 0x0082cd10) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02341af0, int 2, long * 0x01ff4410) line 746 + 16 bytes funcall_compiled_function(long 33577048, int 0, long * 0x0082d0e8) line 518 + 53 bytes Ffuncall(int 1, long * 0x0082d0e4) line 3563 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x024d4400, int 1, long * 0x0082d0e4, int 0) line 4020 + 13 bytes run_hook_with_args(int 1, long * 0x0082d0e4, int 0) line 4033 + 23 bytes Frun_hooks(int 1, long * 0x0082d0e4) line 3887 + 19 bytes Ffuncall(int 2, long * 0x0082d0e0) line 3549 + 14 bytes execute_optimized_program(const unsigned char * 0x025b5210, int 5, long * 0x01c6d810) line 746 + 16 bytes funcall_compiled_function(long 29841944, int 2, long * 0x0082d3c0) line 518 + 53 bytes Ffuncall(int 3, long * 0x0082d3bc) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x0082d59c, int 3, long * 0x01c69690) line 746 + 16 bytes Fbyte_code(long 29855364, long 29791872, long 7) line 2405 + 38 bytes Feval(long 29503552) line 3331 + 187 bytes condition_case_1(long 29292432, long (long)* 0x01070ea7 Feval(long), long 29503552, long (long, long)* 0x0106e184 run_condition_case_handlers(long, long), long 28484812) line 1651 + 7 bytes condition_case_3(long 29503552, long 28484812, long 29292432) line 1732 + 27 bytes execute_rare_opcode(long * 0x0082d900, const unsigned char * 0x025b51ec, int 143) line 1271 + 19 bytes execute_optimized_program(const unsigned char * 0x025b5110, int 6, long * 0x01c6d910) line 656 + 17 bytes funcall_compiled_function(long 29841916, int 2, long * 0x0082dbe4) line 518 + 53 bytes Ffuncall(int 3, long * 0x0082dbe0) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x024d4210, int 3, long * 0x0207c610) line 746 + 16 bytes funcall_compiled_function(long 33781732, int 1, long * 0x0082debc) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082deb8) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02515010, int 8, long * 0x0207c810) line 746 + 16 bytes funcall_compiled_function(long 34171836, int 4, long * 0x0082e1a0) line 518 + 53 bytes Ffuncall(int 5, long * 0x0082e19c) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02188410, int 6, long * 0x022bd110) line 746 + 16 bytes funcall_compiled_function(long 36459452, int 1, long * 0x0082e480) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082e47c) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x024b1390, int 4, long * 0x022bd190) line 746 + 16 bytes funcall_compiled_function(long 36459592, int 1, long * 0x0082e758) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082e754) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02188410, int 6, long * 0x022bd110) line 746 + 16 bytes funcall_compiled_function(long 36459452, int 0, long * 0x0082ec14) line 518 + 53 bytes Ffuncall(int 1, long * 0x0082ec10) line 3563 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x024bc200, int 1, long * 0x0082ec10, int 0) line 4020 + 13 bytes run_hook_with_args(int 1, long * 0x0082ec10, int 0) line 4033 + 23 bytes Frun_hooks(int 1, long * 0x0082ec10) line 3887 + 19 bytes Ffuncall(int 2, long * 0x0082ec0c) line 3549 + 14 bytes Fapply(int 2, long * 0x0082ec0c) line 3747 + 13 bytes Ffuncall(int 3, long * 0x0082ec08) line 3549 + 14 bytes execute_optimized_program(const unsigned char * 0x021b88b0, int 3, long * 0x021e4750) line 746 + 16 bytes funcall_compiled_function(long 35554292, int 1, long * 0x0082eee0) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082eedc) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02438050, int 2, long * 0x023f9750) line 746 + 16 bytes funcall_compiled_function(long 37953088, int 0, long * 0x0082f1b0) line 518 + 53 bytes Ffuncall(int 1, long * 0x0082f1ac) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02252810, int 3, long * 0x0233bc10) line 746 + 16 bytes funcall_compiled_function(long 37953060, int 2, long * 0x0082f484) line 518 + 53 bytes Ffuncall(int 3, long * 0x0082f480) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x02188790, int 4, long * 0x02342d90) line 746 + 16 bytes funcall_compiled_function(long 36710404, int 1, long * 0x0082f75c) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082f758) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x0249d310, int 5, long * 0x0234bc10) line 746 + 16 bytes funcall_compiled_function(long 36710628, int 1, long * 0x0082fa34) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082fa30) line 3563 + 17 bytes Fcall_interactively(long 35763740, long 28360708, long 28360708) line 940 + 22 bytes Fcommand_execute(long 35763740, long 28360708, long 28360708) line 2970 + 17 bytes execute_command_event(command_builder * 0x01d15c80, long 31426496) line 3833 + 25 bytes Fdispatch_event(long 31426496) line 4124 + 70 bytes Fcommand_loop_1() line 583 + 9 bytes command_loop_1(long 28360708) line 495 condition_case_1(long 28360804, long (long)* 0x01050b66 command_loop_1(long), long 28360708, long (long, long)* 0x01050580 cmd_error(long, long), long 28360708) line 1651 + 7 bytes command_loop_3() line 256 + 35 bytes command_loop_2(long 28360708) line 269 internal_catch(long 28440700, long (long)* 0x010506d0 command_loop_2(long), long 28360708, int * volatile 0x00000000) line 1317 + 7 bytes initial_command_loop(long 28360708) line 305 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x01b43f30, char * * 0x01d2cf00, int 0) line 2233 main(int 1, char * * 0x01b43f30, char * * 0x01d2cf00) line 2666 XEMACS! mainCRTStartup + 180 bytes _start() line 169

2 participants
1 comments

Another minor focus problem 23 years, 3 months

Raymond Toy

Here is another minor focus problem. I connect to an imap server via gnus. After I've entered my password, the cursor becomes a hollow block instead of a solid block. However, I actually do have focus, since I'm typing this in with a hollow block cursor. (I'd show you, but then I'd need to move the mouse out of the window, and when I move back in, the cursor changes back to solid.) Perhaps this is a WM bug (fvwm2) instead of an XEmacs bug? Ray

2 participants
1 comments

Long File names in cygwin XEmacs 23 years, 3 months

Jeff Stuart

Has the long file name problem with the cygwin version of XEmacs been fixed? The last time I looked at it was around 21.2.28 I think it was. Back then; it was converting em into d:\progra~1\longdi~1\longfi~1.txt which caused MAJOR problems. This was especially apparent when you attempted to use gnuserv/gnuclient under cygwin. And then when you went to save it, it saved it under that short name rather than under the correct long name. I seem to remember some stuff going on in the archives about a fix being found BUT I don't remember seeing if the final patch was applied. -- Jeff Stuart jstuart(a)neo.rr.com

2 participants
1 comments

Common Lisp lambda list in help. 23 years, 3 months

Nickolay Pakoulin

Description. This paper contains proposal to include information on CL lambda list of defun*-ed functions in documentation. State of art. Current implementation of defun* and defmacro* does not allow user to learn function/macro arglist via documentation. Lets consider the following code: (defun* tmp-cl-func (x y &optional (a b c) &key d) "Some docs" (progn nil)) After evaluation of this code the documentation on tmp-cl-func says: ---------------------------------------- `tmp-cl-func' is a Lisp function (tmp-cl-func X Y &rest --REST--48142) Documentation: Some docs ---------------------------------------- This info stores no information on the actual arguments list of `tmp-cl-func'. Proposal. I propose to modify defun*/defmacro* -related code to add information on function/macro Common Lisp arguments list to on-line documentation on function/macros they produce. Simple implementation. One very simple way to solve the problem is to add arguments list directly to documentation strings. See patch below. In the case with `tmp-cl-func' it gives: ---------------------------------------- `tmp-cl-func' is a Lisp function (tmp-cl-func X Y &rest --REST--48144) Documentation: Common Lisp lambda list: (tmp-cl-func X Y &optional (A B C) &key D) Some docs ---------------------------------------- The drawback is that confusingly looking "&rest --REST--48144" is still displayed. The second observation is that argument list description should not be a part of doc string. Docstrings are written manually and describes functionality of function/macro. Arglist description is just signature of function and should be generated by system in run-time. Nick. Index: cl-macs.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/cl-macs.el,v retrieving revision 1.4.2.15 diff -u -r1.4.2.15 cl-macs.el --- cl-macs.el 2000/12/01 09:54:30 1.4.2.15 +++ cl-macs.el 2001/01/10 17:44:12 ＠＠ -150,11 +150,33 ＠＠ (defvar bind-block) (defvar bind-defs) (defvar bind-enquote) (defvar bind-inits) (defvar bind-lets) (defvar bind-forms) +(defun cl-upcase-arg (arg) + (cond ((symbolp arg) + (if (memq arg lambda-list-keywords) + arg + (intern (upcase (symbol-name arg))))) + ((listp arg) + (mapcar 'cl-upcase-arg arg)))) + +(defun cl-function-arglist (function agrlist) + (prin1-to-string + (cons function (cl-upcase-arg agrlist)))) + (defun cl-transform-lambda (form bind-block) (let* ((args (car form)) (body (cdr form)) (bind-defs nil) (bind-enquote nil) (bind-inits nil) (bind-lets nil) (bind-forms nil) - (header nil) (simple-args nil)) + (header nil) (simple-args nil) + (doc "")) + ;; Add CL lambda list to documentation + (if (stringp (car body)) + (setq doc (cl-pop body))) + (cl-push (concat "\nCommon Lisp lambda list:\n" + " " (cl-function-arglist bind-block args) + "\n\n" + doc) + header) + (while (or (stringp (car body)) (eq (car-safe (car body)) 'interactive)) (cl-push (cl-pop body) header)) (setq args (if (listp args) (copy-list args) (list '&rest args)))

1 participants
0 comments

Re: add ansi-color.el to XEmacs? 23 years, 3 months

Alexander Schroeder

Hrvoje Niksic <hniksic(a)arsdigita.com> writes: >"Alexander Schroeder" <ASC(a)bsiag.com> writes: > >> (put-nonduplicable-text-property start end 'face nil) >> (put-nonduplicable-text-property start end 'font-lock nil)) >> >> That looks as if all face text properties are removed, just like in >> Emacs. > >Text properties, yes. But not all extents. Text properties are >implemented using extents, but not all extents are those created by >the text properties compatibility layer. Ahh... Another level of indirection... OK, what should I change, then? I guess I can just change the doc string of ansi-color-unfontify-region: I'll just insert this after the first sentence: "This is not required by XEmacs as text-properties are implemented using extents." It seems unfortunate that ansi-color-apply uses text properties for strings, even in XEmacs, then. Maybe I can change that later... Alex.

1 participants
0 comments

Re: add ansi-color.el to XEmacs? 23 years, 3 months

Alexander Schroeder

Hrvoje Niksic <hniksic(a)arsdigita.com> writes: >> (defun ansi-color-unfontify-region (beg end &rest xemacs-stuff) >> "Replacement function for `font-lock-default-unfontify-region'. >> When font-lock is active in a buffer, you cannot simply add face >> text-properties to the buffer. Font-lock will remove the face >> text-property using `font-lock-unfontify-region-function'. > >I don't think this is the case under XEmacs. font-lock uses the >text-property functions, which in turn touch only the extents they >know about. If you create a new extent and apply a face to it, >font-lock will not touch it. Well, in Emacs it works like this: when text is inserted and overlays are added, they are not touched by font-lock. When strings with text properties are inserted, however, these text properties will be removed. This is relevant for ansi-color.el: when colors are added via ansi-color-apply-on-region, extents or overlays are used. No problem. When colors are added to string via ansi-color-apply and these strings are inserted into a buffer, font-lock-default-unfontify-region will remove *all* face text properties in Emacs. I looked at the implementation of font-lock-default-unfontify-region in XEmacs. It calls font-lock-remove-face, and there: (put-nonduplicable-text-property start end 'face nil) (put-nonduplicable-text-property start end 'font-lock nil)) That looks as if all face text properties are removed, just like in Emacs. The font-lock text property is not used to prevent this. >> (defun ansi-color-get-face-1 (ansi-code) >> "Get face definition from `ansi-color-map'. >> ANSI-CODE is used as an index into the vector." >> (condition-case nil >> (aref ansi-color-map ansi-code) >> ('args-out-of-range nil))) > ^ this quote is not needed. Cool, I'll do that. Alex.

2 participants
1 comments

stale CVS lock 23 years, 3 months

Martin Buchholz

There were a couple of stale CVS locks I removed which prevented people from doing CVS commits. My apologies that this happens occasionally. Martin

1 participants
0 comments

21.1.13 build problems (minor) on Tru64 Unix 23 years, 3 months

Kevin Oberman

A couple of minor problems building 21.1.13. Configuration command: configure --without-gcc --with-gnu-make '--cflags=-fast -std' --with-site-lisp --site-includes=/usr/local/include First, configure refuses to recognize V5.0, so I had to build on an old V4.0e system. Second, I regex.c would not compile. Type mismatch for alloca. I edited regex.c and modified line 289 which was "char *alloca" to "void *alloca". That was the only compiling problem, but it failed several times in building the finder database. For some reason about 5 files in my /usr/local/lib/xemacs/xemacs-packages/list directories had 640 protections, so could not be read. I'm baffled as to what happened there, but I chmoded them and the build completed. Note that the regex problem was the only compile problem I had using Tru64 C compiler. Is *alloca normally a char? Seems like void is what it should be. I'd try logging into my FreeBSD system and seeing how it's typed there, but the ＠Home connection seems to be down at the moment. :-( In any case, it looks pretty good. I really should have built from CVS before the release so the regex.c could have been patched. Sorry. Is there any hope of config.guess ever being updated to handle Tru64 UNIX V5? (Yes, I realize that this is not really an XEmacs issue.) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

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 January 2001