May 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [PATCH] backout to make kill-comilation work in native NT [Re: Fixing nt_create_process for MKS Toolkit shell] 24 years, 6 months

Adrian Aichner

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> adrian, i think the stderr changes are unrelated. you Ben> probably shouldn't back them out, just the Ben> enable_child_signals changes. My first reaction was just to revert the whole thing just to be safe. I'll send another patch if my testing works out. Now for something completely different: I would like to have an integrated solution of vc*.el to handle CVS, ClearCase, RCS. The XEmacs Packages vc and vc-cc are said to be incompatible. The best I could find was http://rwhitby.hplx.net/vc-clearcase.html since clearcase support works under Windows NT. However, this version is outdated regarding its support for custom. XEmacs's vcc-cc package has better custom support but is outdated in general functionality. emacs-20.6's vc.el is most advance regarding custom and OS-indepentant support but has NO clearcase support whatsoever. Can you give me an overview of the most reliable sources of *macs lisp packages? LCD Archive seems to be out-dated if not dead. Do you know anything about this? emacs-20.6/lisp found under ftp://ftp.gnu.org/pub/gnu/emacs/ has the GNU Emacs lisp sources. /ftp＠ftp.xemacs.org:/pub/tux/xemacs/packages is where the release XEmacs packages are. Did I miss anything? Best regards, Adrian

2 participants
1 comments

Re: [PATCH] backout to make kill-comilation work in native NT [Re: Fixing nt_create_process for MKS Toolkit shell] 24 years, 6 months

Adrian Aichner

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> adrian, i think the stderr changes are unrelated. you Ben> probably shouldn't back them out, just the Ben> enable_child_signals changes. OK, here's a revised patch tested against 21.1.10 vanilla. It retains STDERR handling improvements. Best regards, Adrian cd d:\tmp\21.1\xemacs\ cvs diff src Compilation started at Sun May 07 17:23:56 2000 +0200 (W. Europe Daylight Time) ? src/call-process.err ? src/cvs-update.err ? src/SATISFIED ? src/stat-fstat ? src/stat-fstat-h ? src/temacs.bsc ? src/temacs.map ? src/xemacs.opt cvs server: Diffing src Index: src/process-nt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-nt.c,v retrieving revision 1.15 diff -u -r1.15 process-nt.c --- process-nt.c 1999/12/04 04:13:05 1.15 +++ process-nt.c 2000/05/07 15:31:54 ＠＠ -49,7 +49,6 ＠＠ struct nt_process_data { HANDLE h_process; - int need_enable_child_signals; }; #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data)) ＠＠ -469,7 +468,7 ＠＠ /* Duplicate the stdout handle for use as stderr */ DuplicateHandle(GetCurrentProcess(), hprocout, GetCurrentProcess(), &hprocerr, - 0, TRUE, DUPLICATE_SAME_ACCESS); + 0, TRUE, DUPLICATE_SAME_ACCESS); /* Stupid Win32 allows to create a pipe with *both* ends either inheritable or not. We need process ends inheritable, and local ＠＠ -598,7 +597,7 ＠＠ { si.hStdInput = hprocin; si.hStdOutput = hprocout; - si.hStdError = hprocerr; + si.hStdError = hprocerr; si.dwFlags |= STARTF_USESTDHANDLES; } ＠＠ -613,7 +612,7 ＠＠ /* These just have been inherited; we do not need a copy */ CloseHandle (hprocin); CloseHandle (hprocout); - CloseHandle (hprocerr); + CloseHandle (hprocerr); } /* Handle process creation failure */ ＠＠ -640,18 +639,12 ＠＠ CloseHandle (pi.hProcess); } + if (!windowed) + enable_child_signals (pi.hProcess); + ResumeThread (pi.hThread); CloseHandle (pi.hThread); - /* Remember to enable child signals later if this is not a windowed - app. Can't do it right now because that screws up the MKS Toolkit - shell. */ - if (!windowed) - { - NT_DATA(p)->need_enable_child_signals = 10; - kick_status_notify (); - } - /* Hack to support Windows 95 negative pids */ return ((int)pi.dwProcessId < 0 ? -(int)pi.dwProcessId : (int)pi.dwProcessId); ＠＠ -670,18 +663,6 ＠＠ nt_update_status_if_terminated (struct Lisp_Process* p) { DWORD exit_code; - - if (NT_DATA(p)->need_enable_child_signals > 1) - { - NT_DATA(p)->need_enable_child_signals -= 1; - kick_status_notify (); - } - else if (NT_DATA(p)->need_enable_child_signals == 1) - { - enable_child_signals(NT_DATA(p)->h_process); - NT_DATA(p)->need_enable_child_signals = 0; - } - if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code) && exit_code != STILL_ACTIVE) { ＠＠ -782,14 +763,6 ＠＠ int current_group, int nomsg) { struct Lisp_Process *p = XPROCESS (proc); - - /* Enable child signals if necessary. This may lose the first - but it's better than nothing. */ - if (NT_DATA(p)->need_enable_child_signals > 0) - { - enable_child_signals(NT_DATA(p)->h_process); - NT_DATA(p)->need_enable_child_signals = 0; - } /* Signal error if SIGNO cannot be sent */ validate_signal_number (signo); Compilation exited abnormally with code 1 at Sun May 07 17:24:10 -- Adrian Aichner <adrian(a)xemacs.org>

2 participants
1 comments

Re: Fixing nt_create_process for MKS Toolkit shell 24 years, 6 months

Adrian Aichner

>>>>> "Mike" == Mike Alexander <mta(a)arbortext.com> writes: Mike> Here are some patches to make nt_create_process work properly with Mike> the Korn shell that comes with the MKS Toolkit from Mortice-Kern Mike> Systems (and perhaps with other programs). With this patch, running Mike> that shell under XEmacs works ok. Without it any attempt to start a Mike> subshell causes an error message about "Forked child base mismatch". Mike> This is apparently because XEmacs creates a thread in the newly Mike> started process and executes code in that thread before starting the Mike> main thread. I fixed this by deferring this call until after the Mike> main thread has a chance to get started. Hello Mike, this patch of yours breaks (interrupt-process ...) for processes running under a shell. This is why kill-compilation is fails to fulfill its purpose in 21.1.9, 21.1.10, 21.2-b3x. First I verified today that kill-compilation works in 21.1.7. Secondly I verified kill-compilation not to work in 21.2 (beta33) Thirdly I backed out following part of your patch manually (relative to 21.2-b33: Sure enough kill-compilation works again in 21.2-b33! Could you please come up with a patch which makes MKS shell working without breaking kill-compilation. You may use (compile "sleep 600") (interrupt-process "compilation") as a test-case. This can also be used to verify your fix: (start-process "shell" nil "cmd" "/c" "sleep" "5") (message "before: %S" (get-process "shell")) (interrupt-process "shell" t) (message "after: %S" (get-process "shell")) Please note that running above four sexps inside a defun will not work stably. Even intervening (sit-for 1) calls didn't work reliably for me. Please just evaluate them in order with C-x C-e (eval-last-sexp). Best regards, Adrian === cd d:\tmp\21.2\xemacs\src\ === C:\cvs\cvs diff -u process-nt.c Index: process-nt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-nt.c,v retrieving revision 1.11.2.18 diff -u -u -r1.11.2.18 process-nt.c --- process-nt.c 2000/03/29 18:35:34 1.11.2.18 +++ process-nt.c 2000/05/07 10:56:10 ＠＠ -923,17 +923,31 ＠＠ CloseHandle (pi.hProcess); } + if (!windowed) + enable_child_signals (pi.hProcess); + ResumeThread (pi.hThread); CloseHandle (pi.hThread); - /* Remember to enable child signals later if this is not a windowed - app. Can't do it right now because that screws up the MKS Toolkit - shell. */ +#if 0 + /* + APA: Back-out + Message-Id: <v04220805b45fd4ac8e03(a)[148.59.233.133]> + Date: Tue, 23 Nov 1999 00:36:47 -0500 + To: xemacs-patches(a)xemacs.org + From: Mike Alexander <mta(a)arbortext.com> + Subject: Fixing nt_create_process for MKS Toolkit shell + + Remember to enable child signals later if this is not a windowed + app. Can't do it right now because that screws up the MKS Toolkit + shell. + */ if (!windowed) { NT_DATA(p)->need_enable_child_signals = 10; kick_status_notify (); } +#endif return ((int)pi.dwProcessId); } === Exit status: 1 Mike> There is also a problem with pipes in the shell (in the Mike> shell sense, e.g. "ls | sort"). XEmacs passes the same Mike> handle for stdout and stderr and this confuses the shell Mike> when it creates the pipes to connect the two programs Mike> together. Instead XEmacs needs to pass two separate handles Mike> to the same end of the same pipe. This doesn't affect the Mike> rest of XEmacs since both stderr and stdout still come back Mike> on the same pipe, but it avoids confusing the shell. Mike> This patch has been sent to the xemacs-nt list before, but I'm Mike> sending it to xemacs-patches to make it official. Mike> Mike Alexander Mike> Index: src/process-nt.c Mike> =================================================================== Mike> RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-nt.c,v Mike> retrieving revision 1.11.2.6 Mike> diff -u -r1.11.2.6 process-nt.c Mike> --- process-nt.c 1999/10/24 09:25:03 1.11.2.6 Mike> +++ process-nt.c 1999/11/23 04:35:20 Mike> ＠＠ -53,6 +53,7 ＠＠ Mike> struct nt_process_data Mike> { Mike> HANDLE h_process; Mike> + int need_enable_child_signals; Mike> }; Mike> #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data)) Mike> ＠＠ -421,7 +422,7 ＠＠ Mike> Lisp_Object *argv, int nargv, Mike> Lisp_Object program, Lisp_Object cur_dir) Mike> { Mike> - HANDLE hmyshove, hmyslurp, hprocin, hprocout; Mike> + HANDLE hmyshove, hmyslurp, hprocin, hprocout, hprocerr; Mike> LPTSTR command_line; Mike> BOOL do_io, windowed; Mike> char *proc_env; Mike> ＠＠ -472,6 +473,10 ＠＠ Mike> CreatePipe (&hprocin, &hmyshove, &sa, 0); Mike> CreatePipe (&hmyslurp, &hprocout, &sa, 0); Mike> + /* Duplicate the stdout handle for use as stderr */ Mike> + DuplicateHandle(GetCurrentProcess(), hprocout, Mike> GetCurrentProcess(), &hprocerr, Mike> + 0, TRUE, DUPLICATE_SAME_ACCESS); Mike> + Mike> /* Stupid Win32 allows to create a pipe with *both* ends either Mike> inheritable or not. We need process ends inheritable, and local Mike> ends not inheritable. */ Mike> ＠＠ -599,7 +604,7 ＠＠ Mike> { Mike> si.hStdInput = hprocin; Mike> si.hStdOutput = hprocout; Mike> - si.hStdError = hprocout; Mike> + si.hStdError = hprocerr; Mike> si.dwFlags |= STARTF_USESTDHANDLES; Mike> } Mike> ＠＠ -614,6 +619,7 ＠＠ Mike> /* These just have been inherited; we do not need a copy */ Mike> CloseHandle (hprocin); Mike> CloseHandle (hprocout); Mike> + CloseHandle (hprocerr); Mike> } Mike> /* Handle process creation failure */ Mike> ＠＠ -640,12 +646,18 ＠＠ Mike> CloseHandle (pi.hProcess); Mike> } Mike> - if (!windowed) Mike> - enable_child_signals (pi.hProcess); Mike> - Mike> ResumeThread (pi.hThread); Mike> CloseHandle (pi.hThread); Mike> + /* Remember to enable child signals later if this is not a windowed Mike> + app. Can't do it right now because that screws up the MKS Toolkit Mike> + shell. */ Mike> + if (!windowed) Mike> + { Mike> + NT_DATA(p)->need_enable_child_signals = 10; Mike> + kick_status_notify (); Mike> + } Mike> + Mike> /* Hack to support Windows 95 negative pids */ Mike> return ((int)pi.dwProcessId < 0 Mike> ? -(int)pi.dwProcessId : (int)pi.dwProcessId); Mike> ＠＠ -664,6 +676,18 ＠＠ Mike> nt_update_status_if_terminated (struct Lisp_Process* p) Mike> { Mike> DWORD exit_code; Mike> + Mike> + if (NT_DATA(p)->need_enable_child_signals > 1) Mike> + { Mike> + NT_DATA(p)->need_enable_child_signals -= 1; Mike> + kick_status_notify (); Mike> + } Mike> + else if (NT_DATA(p)->need_enable_child_signals == 1) Mike> + { Mike> + enable_child_signals(NT_DATA(p)->h_process); Mike> + NT_DATA(p)->need_enable_child_signals = 0; Mike> + } Mike> + Mike> if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code) Mike> && exit_code != STILL_ACTIVE) Mike> { Mike> ＠＠ -764,6 +788,14 ＠＠ Mike> int current_group, int nomsg) Mike> { Mike> struct Lisp_Process *p = XPROCESS (proc); Mike> + Mike> + /* Enable child signals if necessary. This may lose the first Mike> + but it's better than nothing. */ Mike> + if (NT_DATA(p)->need_enable_child_signals > 0) Mike> + { Mike> + enable_child_signals(NT_DATA(p)->h_process); Mike> + NT_DATA(p)->need_enable_child_signals = 0; Mike> + } Mike> /* Signal error if SIGNO cannot be sent */ Mike> validate_signal_number (signo);

3 participants
2 comments

still hosed with 21.2 cvs 24 years, 6 months

Michael Harnois

The latest CVS still fails as per below, in case anyone is interested ... I have rolled my tree back to r21-2-32 and that builds and works without incident. Program received signal SIGSEGV, Segmentation fault. 0x8087c62 in Fcons (car={...}, cdr={...}) at /usr/src/xemacs-21.2/src/alloc.c:922 922 ALLOCATE_FIXED_TYPE (cons, Lisp_Cons, c); (gdb) where #0 0x8087c62 in Fcons (car={...}, cdr={...}) at /usr/src/xemacs-21.2/src/alloc.c:922 #1 0x808d8c8 in list2 (obj0={...}, obj1={...}) at /usr/src/xemacs-21.2/src/alloc.c:972 #2 0x80aaaf1 in dead_wrong_type_argument (predicate={...}, value={...}) at /usr/src/xemacs-21.2/src/data.c:110 #3 0x80e97ff in Fget_coding_system (name={...}) at /usr/src/xemacs-21.2/src/file-coding.c:549 #4 0x8092ff4 in dfc_convert_to_external_format (source_type=DFC_TYPE_DATA, source=0xbfffd9e4, coding_system={...}, sink_type=DFC_TYPE_DATA, sink=0xbfffd9dc) at /usr/src/xemacs-21.2/src/buffer.c:1881 #5 0x8170840 in std_handle_out_va (stream=0x404818e0, fmt=0x821a700 "malloc_set_state failed, rc = %d\n", args=0xbffffa18) at /usr/src/xemacs-21.2/src/print.c:177 #6 0x8170904 in stderr_out ( fmt=0x821a700 "malloc_set_state failed, rc = %d\n") at /usr/src/xemacs-21.2/src/print.c:193 #7 0x80be06d in main (argc=1, argv=0xbffffaa4, envp=0xbffffaac) at /usr/src/xemacs-21.2/src/emacs.c:2271 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org God made everything out of nothing, but the nothingness shows through. -- Paul Valery

1 participants
0 comments

More XEmacs gtk stuff... 24 years, 6 months

William M. Perry

I just checked in a whole slew of changes that make the foreign-function-interface pretty usable. I have converted gtkwidget.h, gtkbutton.h, gtkcontainer.h, gtkhpaned.h, gtkvpaned.h, gtkpaned.h, and gtkwindow.h to lisp, and implemented a whole slew of marshalling routines. There is also an automated script in ..../lisp/ui/gtk-marshal.el that will automatically generate the C code from a signature for you. With the current CVS, this test program works: (progn (require 'gtk-ffi) (require 'gtk-window) (require 'gtk-container) (require 'gtk-widget) (require 'gtk-button) (require 'gtk-vpaned)) (let ((win (gtk-window-new GTK_WINDOW_TOPLEVEL)) (pane (gtk-vpaned-new)) (button-1 (gtk-button-new-with-label "Testing widget...")) (button-2 (gtk-button-new-with-label "Another test widget..."))) (gtk-container-add win pane) (gtk-paned-add1 pane button-1) (gtk-paned-add2 pane button-2) (gtk-widget-show-all win)) There are certain things that I need to finish hacking out before you can fully access some functions. The main one is dealing with 'boxed' types, which are typed pointers for things like GdkEvent, GdkBar, etc. None of these structures has accessor/settor functions that you can just import. Lame. I have encapsulated these in their own lisp type (gtk-boxed), and plan on making the 'put' and 'get' routines work on them (somehow). Either that or just write a bunch of accessor/settor functions in C that you can import as normal. Other work to finish includes converting 'GList' objects into lisp lists, and dealing with 'GtkArg' attributes, which can be done by converting them to a list as well. All the widgets should be able to be imported by monday night (I think). Then I go to work on the abstraction layer. Then menus and toolbars get top priority. The upside to doing it this way is I should be able to finish 2 milestones at once (getting from 50% of widgets imported to 90% should take all of 3 hours), and the project can be finished that much sooner. Being able to do the entire abstraction layer in lisp will kick some serious ass. :) I'm going to be gone most of the day - have to hit the bookstore and try to convince liam to try his new bicycle without training wheels. :) -Bill P.

1 participants
0 comments

Re: XEmacs 21.1.10 "Capitol Reef" has been Released 24 years, 6 months

Vin Shelton

1 participants
0 comments

[PATCH] backout to make kill-comilation work in native NT [Re: Fixing nt_create_process for MKS Toolkit shell] 24 years, 6 months

Adrian Aichner

>>>>> "Mike" == Mike Alexander <mta(a)arbortext.com> writes: Mike> Index: src/process-nt.c Mike> =================================================================== Mike> RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-nt.c,v Mike> retrieving revision 1.11.2.6 Mike> diff -u -r1.11.2.6 process-nt.c Mike> --- process-nt.c 1999/10/24 09:25:03 1.11.2.6 Mike> +++ process-nt.c 1999/11/23 04:35:20 Following hunk breaks kill-compilation in native NT XEmacs 21.1.10, 21.2-b33 and some earlier versions (21.1.7 does not have the problem yet). Here is a backout patch (Mike's original patch was broken due to line-wrapping and is not cleanly --reverse -ible) to fix 21.1.10 and 21.2-b33 until Mike gives it another shot. Please advise, Adrian Mike> ＠＠ -640,12 +646,18 ＠＠ Mike> CloseHandle (pi.hProcess); Mike> } Mike> - if (!windowed) Mike> - enable_child_signals (pi.hProcess); Mike> - Mike> ResumeThread (pi.hThread); Mike> CloseHandle (pi.hThread); Mike> + /* Remember to enable child signals later if this is not a windowed Mike> + app. Can't do it right now because that screws up the MKS Toolkit Mike> + shell. */ Mike> + if (!windowed) Mike> + { Mike> + NT_DATA(p)->need_enable_child_signals = 10; Mike> + kick_status_notify (); Mike> + } Mike> + cd d:\tmp\21.1\xemacs\ cvs diff src Compilation started at Sun May 07 14:15:35 2000 +0200 (W. Europe Daylight Time) ? src/call-process.err ? src/cvs-update.err ? src/SATISFIED ? src/stat-fstat ? src/stat-fstat-h ? src/temacs.bsc ? src/temacs.map ? src/xemacs.opt cvs server: Diffing src Index: src/process-nt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-nt.c,v retrieving revision 1.15 diff -u -r1.15 process-nt.c --- process-nt.c 1999/12/04 04:13:05 1.15 +++ process-nt.c 2000/05/07 12:23:18 ＠＠ -49,7 +49,6 ＠＠ struct nt_process_data { HANDLE h_process; - int need_enable_child_signals; }; #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data)) ＠＠ -416,7 +415,7 ＠＠ Lisp_Object *argv, int nargv, Lisp_Object program, Lisp_Object cur_dir) { - HANDLE hmyshove, hmyslurp, hprocin, hprocout, hprocerr; + HANDLE hmyshove, hmyslurp, hprocin, hprocout; LPTSTR command_line; BOOL do_io, windowed; char *proc_env; ＠＠ -467,10 +466,6 ＠＠ CreatePipe (&hprocin, &hmyshove, &sa, 0); CreatePipe (&hmyslurp, &hprocout, &sa, 0); - /* Duplicate the stdout handle for use as stderr */ - DuplicateHandle(GetCurrentProcess(), hprocout, GetCurrentProcess(), &hprocerr, - 0, TRUE, DUPLICATE_SAME_ACCESS); - /* Stupid Win32 allows to create a pipe with *both* ends either inheritable or not. We need process ends inheritable, and local ends not inheritable. */ ＠＠ -598,7 +593,7 ＠＠ { si.hStdInput = hprocin; si.hStdOutput = hprocout; - si.hStdError = hprocerr; + si.hStdError = hprocout; si.dwFlags |= STARTF_USESTDHANDLES; } ＠＠ -613,7 +608,6 ＠＠ /* These just have been inherited; we do not need a copy */ CloseHandle (hprocin); CloseHandle (hprocout); - CloseHandle (hprocerr); } /* Handle process creation failure */ ＠＠ -640,18 +634,12 ＠＠ CloseHandle (pi.hProcess); } + if (!windowed) + enable_child_signals (pi.hProcess); + ResumeThread (pi.hThread); CloseHandle (pi.hThread); - /* Remember to enable child signals later if this is not a windowed - app. Can't do it right now because that screws up the MKS Toolkit - shell. */ - if (!windowed) - { - NT_DATA(p)->need_enable_child_signals = 10; - kick_status_notify (); - } - /* Hack to support Windows 95 negative pids */ return ((int)pi.dwProcessId < 0 ? -(int)pi.dwProcessId : (int)pi.dwProcessId); ＠＠ -670,18 +658,6 ＠＠ nt_update_status_if_terminated (struct Lisp_Process* p) { DWORD exit_code; - - if (NT_DATA(p)->need_enable_child_signals > 1) - { - NT_DATA(p)->need_enable_child_signals -= 1; - kick_status_notify (); - } - else if (NT_DATA(p)->need_enable_child_signals == 1) - { - enable_child_signals(NT_DATA(p)->h_process); - NT_DATA(p)->need_enable_child_signals = 0; - } - if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code) && exit_code != STILL_ACTIVE) { ＠＠ -782,14 +758,6 ＠＠ int current_group, int nomsg) { struct Lisp_Process *p = XPROCESS (proc); - - /* Enable child signals if necessary. This may lose the first - but it's better than nothing. */ - if (NT_DATA(p)->need_enable_child_signals > 0) - { - enable_child_signals(NT_DATA(p)->h_process); - NT_DATA(p)->need_enable_child_signals = 0; - } /* Signal error if SIGNO cannot be sent */ validate_signal_number (signo); Compilation exited abnormally with code 1 at Sun May 07 14:15:49 -- Adrian Aichner <adrian(a)xemacs.org>

2 participants
1 comments

ghost specifiers... 24 years, 6 months

William M. Perry

Ok, I tried to find info on these, but couldn't decipher the code in specifier.c and there seems to be no code that actually uses this. The only place I could find was in scrollbar-msw.c, but that wasn't much help. Can any specifier have ghost specifications added to it? How would I go about making the foreground and background of a face be tied to a ghost specifier that would look up the right thing dynamically in the window system? Specifiers have always made me a bit queasy when you hit the big magic. -Bill P.

3 participants
2 comments

Modeline info inconsistence? 24 years, 6 months

Nick V. Pakoulin

Whether it is a bug or not, it seems to be undocumented how the extents are handled in the modeline format. Looking in info I found descriptions the following: -------------------------- Start quote ----------------------------------- `STRING' A string as a modeline construct is displayed verbatim in the mode line except for "`%'-constructs". Decimal digits after the `%' specify the field width for space filling on the right (i.e., the data is left justified). *Note %-Constructs::. `SYMBOL' A symbol as a modeline construct stands for its value. The value of SYMBOL is used as a modeline construct, in place of SYMBOL. However, the symbols `t' and `nil' are ignored; so is any symbol whose value is void. There is one exception: if the value of SYMBOL is a string, it is displayed verbatim: the `%'-constructs are not recognized. `(STRING REST...) or (LIST REST...)' A list whose first element is a string or list means to process all the elements recursively and concatenate the results. This is the most common form of mode line construct. `(SYMBOL THEN ELSE)' A list whose first element is a symbol is a conditional. Its meaning depends on the value of SYMBOL. If the value is non-`nil', the second element, THEN, is processed recursively as a modeline element. But if the value of SYMBOL is `nil', the third element, ELSE, is processed recursively. You may omit ELSE; then the mode line element displays nothing if the value of SYMBOL is `nil'. `(WIDTH REST...)' A list whose first element is an integer specifies truncation or padding of the results of REST. The remaining elements REST are processed recursively as modeline constructs and concatenated together. Then the result is space filled (if WIDTH is positive) or truncated (to -WIDTH columns, if WIDTH is negative) on the right. For example, the usual way to show what percentage of a buffer is above the top of the window is to use a list like this: `(-3 "%p")'. -------------------------- End quote ------------------------------------ And what about `(EXTENT REST)'? Moreover, in documentation to `modeline-buffer-identification' there is written -------------------------- Start quote ----------------------------------- Setting it would make its value buffer-local. Documentation: Modeline control for identifying the buffer being displayed. Its default value is "XEmacs: %17b" (NOT!). Major modes that edit things other than ordinary files may change this (e.g. Info, Dired,...) -------------------------- End quote ------------------------------------ Note that particular `NOT' ;) Am I missing something? TIA Nick.

2 participants
1 comments

Re: XEmacs 21.1.10 "Capitol Reef" has been Released 24 years, 6 months

Hans de Graaff

Vin Shelton <acs(a)xemacs.org> writes: > A patch to upgrade from 21.1.9 is also available: > > ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.9-21.1.10.patch.gz It looks to me like the patch is incomplete? It seems to stop with the Changelog for the src directory and the first patched file in that directory. All the other cool bugfixes there seem to be missing, though. Thanks for putting these releases together! Hans

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 May 2000