June 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Progress gauge review 23 years, 10 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > Screenshot attached as well. It takes a little getting used to, but > seems to work ok. I think I could get used to that look. It could be argued that it "wastes space", but it also separates the minibuffer and the echo area, two screen elements that should have been separate from the start.

1 participants
0 comments

Re: Progress gauge review 23 years, 10 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > I think we should change redisplay to know basically nothing about > these areas. Most of them don't make sense on a TTY anyway (maybe > menubars, but they typically take up too much valuable screen > real-estate on a tty). menubars do make sense on TTY's, especially for new users who happen to be stranded on a terminal. For instance, look at `links' (NOT lynx!) or other modern TTY programs -- most of them implements menubars to good use. It would be nice if XEmacs relied more on curses. In fact, even mandating ncurses for TTY support would probably be better than the half-assed TTY code we have now. > Writing a basic geometry manager for XEmacs on top of a decent > curses library wouldn't be too hard. If we make every redisplay > target _but_ TTYs easier, I think it would justify making the TTY > support a bit harder. I agree in theory, but we should be careful of such sweeping statements unless someone is willing to do the work. Our current TTY support is extremely shaky as it is, and noone has shown interest in fixing it himself.

1 participants
0 comments

Re: Progress gauge review 23 years, 10 months

William M. Perry

Ben Wing <ben(a)666.com> writes: > i definitely agree that this generalization of redisplay is necessary. > but we don't necessarily need to drop tty support -- we'd still need a > "redisplay" to display the text area, and in essence this is all a tty > frame is. [i'm assuming that the first round would not mess with the text > area, and just allow arbitrary layout with a monolithic "text area > widget" somewhere in it. furthermore, the geometry management part of > layouts should be completely implemented by xemacs, so we could use the > same under tty's, if anyone cared.] I would argue that the geometry management should be left up to the windowing system. This way things like detachable toolbars and menubars can be implemented on widget sets/platforms that support it. I _really_ don't think XEmacs should get into trying to do dockable toolbars/etc in its own way. For instance, I cannot find any good way to allow a dockable toolbar in XEmacs/GTK because the XEmacs redisplay reserves space at the top of the frame for it and expects you to draw into it. I originally used a 'real' GTK toolbar, but it was a pain in the !＠!＠$! to try and make it detachable because there was then a really big ugly blank spot where it used to be. I think we should change redisplay to know basically nothing about these areas. Most of them don't make sense on a TTY anyway (maybe menubars, but they typically take up too much valuable screen real-estate on a tty). Writing a basic geometry manager for XEmacs on top of a decent curses library wouldn't be too hard. If we make every redisplay target _but_ TTYs easier, I think it would justify making the TTY support a bit harder. If people want to see what a status-bar-using XEmacs would look like, I could hack the XEmacs/GTK to do it pretty easily. Would just need to change append-message to talk directly to a statusbar widget instead of using the ' Echo Area' nastiness. But this would entain ickiness with MULE text sent to those widgets, etc. Urk If people are interested in seeing it, let me know. I can probably implement it all in lisp, which will be nice. -Bill P.

1 participants
0 comments

11 seconds for garbage collection? 21.2-b34 23 years, 10 months

Hamish Macdonald

In XEmacs 21.2 (beta34) "Molpe" [Lucid] (sparc-sun-solaris2.7) of Tue May 30 2000 on rhea configured using `configure --prefix=/export/users/hamishm/xemacs --site-prefixes=/export/users/hamishm/gnome:/export/users/hamishm --pdump --with-athena=xaw --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=athena --with-widgets=athena --with-dragndrop=no --with-tooltalk=no' CVS updated at around 9:22 AM EDT May 30. Garbage collections are taking 11 seconds. This seems excessive. auto-gc-threshold -> 10000 gc-cons-threshold -> 5000000 XEmacs has a shell running, gnus, a number of other packages loaded. Running for less than 24 hours. Result of (garbage-collect) : ((340668 . 224373) (25965 . 1448) (3028 . 20518) 2451818 980624 (conses-used 340668 conses-free 224377 cons-storage 6798344 symbols-used 25965 symbols-free 1448 symbol-storage 660212 bit-vectors-used 0 bit-vectors-total-length 0 bit-vector-storage 0 compiled-functions-used 7398 compiled-functions-free 362 compiled-function-storage 219136 short-strings-used 88964 long-strings-used 4 strings-free 45264 short-strings-total-length 2395830 short-string-storage 3022848 long-strings-total-length 55988 string-header-storage 2152052 floats-used 459 floats-free 4403 float-storage 79560 markers-used 3028 markers-free 20518 marker-storage 568232 events-used 105 events-free 1158 event-storage 148200 extents-used 12915 extents-free 17391 extent-storage 851968 faces-used 198 face-storage 15048 glyphs-used 153 glyph-storage 6732 image-instances-used 5220 image-instance-storage 647280 font-instances-used 9 font-instance-storage 324 color-instances-used 43 color-instance-storage 1032 popup-datas-used 5162 popup-data-storage 123888 gui-items-used 29280 gui-items-freed 94 gui-item-storage 1873920 window-configurations-used 39 window-configurations-on-free-list 3 window-configurations-freed 12 window-configuration-storage 57608 windows-used 33 windows-freed 7 window-storage 17952 frames-used 4 frame-storage 1376 devices-used 2 device-storage 336 consoles-used 4 console-storage 416 specifiers-used 2637 specifier-storage 155592 timeouts-used 2 timeouts-on-free-list 2 timeout-storage 80 command-builders-used 2 command-builder-storage 112 keymaps-used 525 keymaps-freed 9 keymap-storage 21000 extent-auxiliarys-used 349 extent-auxiliarys-freed 25 extent-auxiliary-storage 19544 extent-infos-used 135 extent-infos-freed 50 extent-info-storage 2700 buffers-used 409 buffers-freed 14 buffer-storage 116156 opaque-ptrs-used 1 opaque-ptrs-on-free-list 6 opaque-ptr-storage 16 opaques-used 2825 opaques-freed 6 opaque-storage 290162 range-tables-used 1 range-table-storage 16 char-tables-used 76 char-tables-freed 4 char-table-storage 79648 processes-used 5 process-storage 360 streams-used 9 streams-on-free-list 5 stream-storage 947 hash-tables-used 1236 hash-tables-freed 56 hash-table-storage 79104 weak-lists-used 2676 weak-list-storage 64224 lcrecord-lists-used 17 lcrecord-list-storage 408 vectors-used 17264 vectors-freed 72 vector-storage 977968 symbol-value-buffer-locals-used 530 symbol-value-buffer-local-storage 19080 symbol-value-varaliases-used 16 symbol-value-varalias-storage 448))

1 participants
0 comments

Can't launch java applications 23 years, 10 months

Ittay Freiman

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta32) "Kastor and Polydeukes" [Lucid] (i586-pc-win32) of Fri Apr 14 2000 on NEVERYON configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I used XEmacs 21.1.9 and downloaded JDE 2.1.6, this version has a debugger interface which I wanted to test. But, it can't launch the debugger (it seems to launch it, then waits the timeout and gives an error message). I was told by the JDE developer that this is a bug in native XEmacs. I also saw there was a patch in 21.1.18. So I downloaded this version, but I still get the same behaviour. Thanx, Ittay Recent keystrokes: left Sh-end Sh-left Sh-left Sh-left Sh-left Sh-left Sh-left BS down home Sh-down Sh-down Sh-down Sh-up Sh-down Sh-down Sh-up DEL down down down down down down down down down C-s misc-user misc-user C-end up up up right down right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right ( s ) C-s misc-user button1 button1up f5 C-g C-o C-g misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done Quit Loading emacsbug... Show buffer by configuration "files" Wrote d:\users\ittay\dev\utils\test_analyze_resampling.pl Wrote d:\users\ittay\dev\utils\test_analyze_resampling.pl Wrote d:\users\ittay\dev\utils\test_analyze_resampling.pl Wrote d:\users\ittay\dev\utils\test_analyze_resampling.pl Wrote d:\users\ittay\dev\utils\test_analyze_resampling.pl

1 participants
0 comments

Re: Progress gauge review 23 years, 10 months

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > i have seen no other application that intrusively resizes the main > window in order to display a progress gauge. both vc++ and ie, > which are modern, fully gui apps, use a much smaller progress gauge > that fits in the status bar [the echo area equivalent]. > > why can't we do the same? I strongly agree here -- in fact I've asked the same question myself. IMO a progress gauge should be located in the echo area, replacing the traditional echo area messages. Or, the messages can remain on the right-hand side of the gauge. Something like: | | | | +----modeline---------------------+ |<------%------> Fontifying... | +---------------------------------+ My `small' progress gauge was modeled after that, but it still displayed in a gutter rather than in the echo area where it should be.

4 participants
5 comments

new file compat.el 23 years, 10 months

Ben Wing

i created this awhile ago and mentioned it on the lists, but no one responded. i've fixed this up a bunch and tested it, and added it to lisp/. we really should fix up fsf-compat.el to use this; then, we have no problems putting it in the sumo. -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/chronic-pain/ Index: ChangeLog =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/ChangeLog,v retrieving revision 1.156.2.370 diff -u -r1.156.2.370 ChangeLog --- ChangeLog 2000/06/05 08:42:46 1.156.2.370 +++ ChangeLog 2000/06/06 03:57:13 ＠＠ -1,5 +1,8 ＠＠ 2000-06-05 Ben Wing <ben(a)xemacs.org> + * compat.el: new file. provides a clean, non-intrusive way to + define compatibility functions. + * process.el (shell-quote-argument): temporary fix for lack of nt-quote-process-args. #### I need to put back the overall structure of that mechanism but redo the guts of it using the Index: auto-autoloads.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/auto-autoloads.el,v retrieving revision 1.16.2.19 diff -u -r1.16.2.19 auto-autoloads.el --- auto-autoloads.el 2000/04/28 09:25:14 1.16.2.19 +++ auto-autoloads.el 2000/06/06 03:57:14 ＠＠ -276,95 +276,123 ＠＠ (defcustom font-lock-maximum-size (* 250 1024) "*If non-nil, the maximum size for buffers for fontifying.\nOnly buffers less than this can be fontified when Font Lock mode is turned on.\nIf nil, means size is irrelevant.\nIf a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE),\nwhere MAJOR-MODE is a symbol or t (meaning the default). For example:\n ((c++-mode . 256000) (c-mode . 256000) (rmail-mode . 1048576))\nmeans that the maximum size is 250K for buffers in `c++-mode' or `c-mode', one\nmegabyte for buffers in `rmail-mode', and size is irrelevant otherwise." :type '(choice (const :tag "none" nil) (integer :tag "size") (repeat :menu-tag "mode specific" :tag "mode specific" :value ((t)) (cons :tag "Instance" (radio :tag "Mode" (const :tag "all" t) (symbol :tag "name")) (radio :tag "Size" (const :tag "none" nil) (integer :tag "size"))))) :group 'font-lock) (defvar font-lock-keywords nil "\ -A list of the keywords to highlight. -Each element should be of the form: +A list defining the keywords for `font-lock-mode' to highlight. - MATCHER - (MATCHER . MATCH) - (MATCHER . FACENAME) - (MATCHER . HIGHLIGHT) - (MATCHER HIGHLIGHT ...) - (eval . FORM) - -where HIGHLIGHT should be either MATCH-HIGHLIGHT or MATCH-ANCHORED. - -FORM is an expression, whose value should be a keyword element, -evaluated when the keyword is (first) used in a buffer. This feature -can be used to provide a keyword that can only be generated when Font -Lock mode is actually turned on. + FONT-LOCK-KEYWORDS := List of FONT-LOCK-FORM's. -For highlighting single items, typically only MATCH-HIGHLIGHT is required. -However, if an item or (typically) items is to be highlighted following the -instance of another item (the anchor) then MATCH-ANCHORED may be required. - -MATCH-HIGHLIGHT should be of the form: - - (MATCH FACENAME OVERRIDE LAXMATCH) + FONT-LOCK-FORM :== MATCHER + | (MATCHER . MATCH) + | (MATCHER . FACE-FORM) + | (MATCHER . HIGHLIGHT) + | (MATCHER HIGHLIGHT ...) + | (eval . FORM) + + MATCHER :== A string containing a regexp. + | A variable containing a regexp to search for. + | A function to call to make the search. + It is called with one arg, the limit of the search, + and should leave MATCH results in the XEmacs global + match data. + + MATCH :== An integer match subexpression number from MATCHER. + + FACE-FORM :== The symbol naming a defined face. + | Expression whos value is the face name to use. If you + want FACE-FORM to be a symbol that evaluates to a face, + use a form like \"(progn sym)\". + + HIGHLIGHT :== MATCH-HIGHLIGHT + | MATCH-ANCHORED + + FORM :== Expression returning a FONT-LOCK-FORM, evaluated when + the FONT-LOCK-FORM is first used in a buffer. This + feature can be used to provide a FONT-LOCK-FORM that + can only be generated when Font Lock mode is actually + turned on. + + MATCH-HIGHLIGHT :== (MATCH FACE-FORM OVERRIDE LAXMATCH) + + OVERRIDE :== t - overwrite existing fontification + | 'keep - only parts not already fontified are + highlighted. + | 'prepend - merge faces, this fontification has + precedence over existing + | 'append - merge faces, existing fontification has + precedence over + this face. + + LAXMATCH :== If non-nil, no error is signalled if there is no MATCH + in MATCHER. + + MATCH-ANCHORED :== (ANCHOR-MATCHER PRE-MATCH-FORM \\ + POST-MATCH-FORM MATCH-HIGHLIGHT ...) + + ANCHOR-MATCHER :== Like a MATCHER, except that the limit of the search + defaults to the end of the line after PRE-MATCH-FORM + is evaluated. However, if PRE-MATCH-FORM returns a + position greater than the end of the line, that + position is used as the limit of the search. It is + generally a bad idea to return a position greater than + the end of the line, i.e., cause the ANCHOR-MATCHER + search to span lines. + + PRE-MATCH-FORM :== Evaluated before the ANCHOR-MATCHER is used, therefore + can be used to initialize before, ANCHOR-MATCHER is + used. Typically, PRE-MATCH-FORM is used to move to + some position relative to the original MATCHER, before + starting with the ANCHOR-MATCHER. + + POST-MATCH-FORM :== Like PRE-MATCH-FORM, but used to clean up after the + ANCHOR-MATCHER. It might be used to move, before + resuming with MATCH-ANCHORED's parent's MATCHER. + +For example, an element of the first form highlights (if not already highlighted): + + \"\\\\<foo\\\\>\" Discrete occurrences of \"foo\" in the value + of the variable `font-lock-keyword-face'. + + (\"fu\\\$bar\\\$\" . 1) Substring \"bar\" within all occurrences of + \"fubar\" in the value of + `font-lock-keyword-face'. + + (\"fubar\" . fubar-face) Occurrences of \"fubar\" in the value of + `fubar-face'. + + (\"foo\\\\|bar\" 0 foo-bar-face t) Occurrences of either \"foo\" or \"bar\" in the + value of `foo-bar-face', even if already + highlighted. + + (fubar-match 1 fubar-face) The first subexpression within all + occurrences of whatever the function + `fubar-match' finds and matches in the value + of `fubar-face'. + + (\"\\\\<anchor\\\\>\" (0 anchor-face) (\"\\\\<item\\\\>\" nil nil (0 item-face))) + -------------- --------------- ------------ --- --- ------------- + | | | | | | + MATCHER | ANCHOR-MATCHER | +------+ MATCH-HIGHLIGHT + MATCH-HIGHLIGHT PRE-MATCH-FORM | + POST-MATCH-FORM + + Discrete occurrences of \"anchor\" in the value of `anchor-face', and + subsequent discrete occurrences of \"item\" (on the same line) in the value + of `item-face'. (Here PRE-MATCH-FORM and POST-MATCH-FORM are nil. + Therefore \"item\" is initially searched for starting from the end of the + match of \"anchor\", and searching for subsequent instance of \"anchor\" + resumes from where searching for \"item\" concluded.) -Where MATCHER can be either the regexp to search for, a variable -containing the regexp to search for, or the function to call to make -the search (called with one argument, the limit of the search). MATCH -is the subexpression of MATCHER to be highlighted. FACENAME is either -a symbol naming a face, or an expression whose value is the face name -to use. If you want FACENAME to be a symbol that evaluates to a face, -use a form like \"(progn sym)\". - -OVERRIDE and LAXMATCH are flags. If OVERRIDE is t, existing fontification may -be overwritten. If `keep', only parts not already fontified are highlighted. -If `prepend' or `append', existing fontification is merged with the new, in -which the new or existing fontification, respectively, takes precedence. -If LAXMATCH is non-nil, no error is signalled if there is no MATCH in MATCHER. - -For example, an element of the form highlights (if not already highlighted): - - \"\\\\\\=<foo\\\\\\=>\" Discrete occurrences of \"foo\" in the value of the - variable `font-lock-keyword-face'. - (\"fu\\\$bar\\\$\" . 1) Substring \"bar\" within all occurrences of \"fubar\" in - the value of `font-lock-keyword-face'. - (\"fubar\" . fubar-face) Occurrences of \"fubar\" in the value of `fubar-face'. - (\"foo\\\\|bar\" 0 foo-bar-face t) - Occurrences of either \"foo\" or \"bar\" in the value - of `foo-bar-face', even if already highlighted. - -MATCH-ANCHORED should be of the form: - - (MATCHER PRE-MATCH-FORM POST-MATCH-FORM MATCH-HIGHLIGHT ...) - -Where MATCHER is as for MATCH-HIGHLIGHT with one exception; see below. -PRE-MATCH-FORM and POST-MATCH-FORM are evaluated before the first, and after -the last, instance MATCH-ANCHORED's MATCHER is used. Therefore they can be -used to initialize before, and cleanup after, MATCHER is used. Typically, -PRE-MATCH-FORM is used to move to some position relative to the original -MATCHER, before starting with MATCH-ANCHORED's MATCHER. POST-MATCH-FORM might -be used to move, before resuming with MATCH-ANCHORED's parent's MATCHER. - -For example, an element of the form highlights (if not already highlighted): - - (\"\\\\\\=<anchor\\\\\\=>\" (0 anchor-face) (\"\\\\\\=<item\\\\\\=>\" nil nil (0 item-face))) - - Discrete occurrences of \"anchor\" in the value of `anchor-face', and subsequent - discrete occurrences of \"item\" (on the same line) in the value of `item-face'. - (Here PRE-MATCH-FORM and POST-MATCH-FORM are nil. Therefore \"item\" is - initially searched for starting from the end of the match of \"anchor\", and - searching for subsequent instance of \"anchor\" resumes from where searching - for \"item\" concluded.) - -The above-mentioned exception is as follows. The limit of the MATCHER search -defaults to the end of the line after PRE-MATCH-FORM is evaluated. -However, if PRE-MATCH-FORM returns a position greater than the position after -PRE-MATCH-FORM is evaluated, that position is used as the limit of the search. -It is generally a bad idea to return a position greater than the end of the -line, i.e., cause the MATCHER search to span lines. - -Note that the MATCH-ANCHORED feature is experimental; in the future, we may -replace it with other ways of providing this functionality. +For highlighting single items, typically only MATCH-HIGHLIGHT is required. +However, if an item or (typically) several items are to be highlighted +following the instance of another item (the anchor) then MATCH-ANCHORED may be +required. These regular expressions should not match text which spans lines. While -\\[font-lock-fontify-buffer] handles multi-line patterns correctly, updating -when you edit the buffer does not, since it considers text one line at a time. +\\[font-lock-fontify-buffer] handles multi-line patterns correctly, updating when you +edit the buffer does not, since it considers text one line at a time. -Be very careful composing regexps for this list; -the wrong pattern can dramatically slow things down!") +Be very careful composing regexps for this list; the wrong pattern can +dramatically slow things down! +") (make-variable-buffer-local 'font-lock-keywords) Index: cl-seq.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/cl-seq.el,v retrieving revision 1.3 diff -u -r1.3 cl-seq.el --- cl-seq.el 1998/03/31 20:11:02 1.3 +++ cl-seq.el 2000/06/06 03:57:15 ＠＠ -65,6 +65,23 ＠＠ ;;; this file independent from cl-macs. (defmacro cl-parsing-keywords (kwords other-keys &rest body) + "Helper macro for functions with keyword arguments. +This is a temporary solution, until keyword arguments are natively supported. +Declare your function ending with (... &rest cl-keys), then wrap the +function body in a call to `cl-parsing-keywords'. + +KWORDS is a list of keyword definitions. Each definition should be +either a keyword or a list (KEYWORD DEFAULT-VALUE). In the former case, +the default value is nil. The keywords are available in BODY as the name +of the keyword, minus its initial colon and prepended with `cl-'. + +OTHER-KEYS specifies other keywords that are accepted but ignored. It +is either the value 't' (ignore all other keys, equivalent to the +&allow-other-keys argument declaration in Common Lisp) or a list in the +same format as KWORDS. If keywords are given that are not in KWORDS +and not allowed by OTHER-KEYS, an error will normally be signalled; but +the caller can override this by specifying a non-nil value for the +keyword :allow-other-keys (which defaults to t)." (cons 'let* (cons (mapcar

1 participants
0 comments

RE: Patches for lrecords to support dynamic modules which define new types. 23 years, 10 months

Andrew Begel

> -----Original Message----- > From: Ben Wing [mailto:ben＠666.com] > Sent: Monday, June 05, 2000 7:56 PM > To: Andrew Begel > Cc: 'xemacs-beta(a)xemacs.org' > Subject: Re: Patches for lrecords to support dynamic modules which > define new types. > > > this looks pretty good, although you should definitely > eliminate the references > to pgresult and instead use a dummy enum at the end of the > table. also, send > patches to xemacs-patches(a)xemacs.org. > Here are updated patches: Index: ChangeLog =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/ChangeLog,v retrieving revision 1.154.2.610 diff -u -r1.154.2.610 ChangeLog --- ChangeLog 2000/06/05 10:35:19 1.154.2.610 +++ ChangeLog 2000/06/06 03:18:08 ＠＠ -1,3 +1,22 ＠＠ +2000-06-05 Andrew Begel (abegel(a)cs.berkeley.edu> + * lrecord.h (lrecord_types): Changed lrecord_type_count to an + unsigned int and changed the last enum to + lrecord_type_last_built_in_type. + (lrecord_implementations_table): changed prototype to know how + long the array is supposed to be. + (lrecord_type_count): new unsigned int to keep track of the + current number of lisp lrecord types. + (DEFINE_EXTERNAL_LRECORD): + (DECLARE_EXTERNAL_LRECORD): Added these two for external + dynamic-modules to declare new lisp types. They are the same + as the non-EXTERNAL forms, but declare an lrecord_type unsigned + int for each new type, and increment lrecord_type_count by 1. + + * alloc.c (lrecord_implementations_table): Changed to reference + lrecord_type_last_built_in_type for the size of the array. + Moved MODULE_DEFINABLE_TYPE_COUNT to lrecord.h. + + 2000-06-05 Yoshiki Hayashi <yoshiki(a)xemacs.org> * data.c (Faset): Don't cast XCHAR() to unsigned char. Index: alloc.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/alloc.c,v retrieving revision 1.42.2.61 diff -u -r1.42.2.61 alloc.c --- alloc.c 2000/05/01 11:00:02 1.42.2.61 +++ alloc.c 2000/06/06 03:07:25 ＠＠ -2349,8 +2349,9 ＠＠ /* All the built-in lisp object types are enumerated in `enum lrecord_type'. Additional ones may be defined by a module (none yet). We leave some room in `lrecord_implementations_table' for such new lisp object types. */ -#define MODULE_DEFINABLE_TYPE_COUNT 32 -const struct lrecord_implementation *lrecord_implementations_table[lrecord_type_count + MODULE_DEFINABLE_TYPE_COUNT]; +const struct lrecord_implementation *lrecord_implementations_table[(unsigned int)lrecord_type_last_built_in_type + MODULE_DEFINABLE_TYPE_COUNT]; + +unsigned int lrecord_type_count = (unsigned int)lrecord_type_last_built_in_type; Index: lrecord.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lrecord.h,v retrieving revision 1.8.2.28 diff -u -r1.8.2.28 lrecord.h --- lrecord.h 2000/04/14 07:54:42 1.8.2.28 +++ lrecord.h 2000/06/06 03:07:26 ＠＠ -186,9 +186,15 ＠＠ lrecord_type_ldap, lrecord_type_pgconn, lrecord_type_pgresult, - lrecord_type_count /* must be last */ + lrecord_type_last_built_in_type /* must be last */ }; +extern unsigned int lrecord_type_count; + struct lrecord_implementation { const char *name; ＠＠ -258,7 +264,16 ＠＠ unsigned int basic_p :1; }; -extern const struct lrecord_implementation *lrecord_implementations_table[]; +/* All the built-in lisp object types are enumerated in `enum lrecord_type'. + Additional ones may be defined by a module (none yet). We leave some + room in `lrecord_implementations_table' for such new lisp object types. */ +#define MODULE_DEFINABLE_TYPE_COUNT 32 + +extern const struct lrecord_implementation *lrecord_implementations_table[(unsigned int)lrecord_type_last_built_in_type + MODULE_DEFINABLE_TYPE_COUNT]; #define XRECORD_LHEADER_IMPLEMENTATION(obj) \ LHEADER_IMPLEMENTATION (XRECORD_LHEADER (obj)) ＠＠ -454,7 +469,34 ＠＠ getprop, putprop, remprop, plist, size, sizer, \ lrecord_type_##c_name, basic_p } + + +#define DEFINE_EXTERNAL_LRECORD_IMPLEMENTATION(name,c_name,marker,printer,nuker,equa l,hash,desc,structtype) \ +DEFINE_EXTERNAL_LRECORD_IMPLEMENTATION_WITH_PROPS(name,c_name,marker,printe r,nuker,equal,hash,desc,0,0,0,0,structtype) + +#define DEFINE_EXTERNAL_LRECORD_IMPLEMENTATION_WITH_PROPS(name,c_name,marker,printer ,nuker,equal,hash,desc,getprop,putprop,remprop,plist,structtype) \ +MAKE_EXTERNAL_LRECORD_IMPLEMENTATION(name,c_name,marker,printer,nuker,equal ,hash,desc,getprop,putprop,remprop,plist,sizeof (structtype),0,0,structtype) + +#define DEFINE_EXTERNAL_LRECORD_SEQUENCE_IMPLEMENTATION(name,c_name,marker,printer,n uker,equal,hash,desc,sizer,structtype) \ +DEFINE_EXTERNAL_LRECORD_SEQUENCE_IMPLEMENTATION_WITH_PROPS(name,c_name,mark er,printer,nuker,equal,hash,desc,0,0,0,0,sizer,structtype) + +#define DEFINE_EXTERNAL_LRECORD_SEQUENCE_IMPLEMENTATION_WITH_PROPS(name,c_name,marke r,printer,nuker,equal,hash,desc,getprop,putprop,remprop,plist,sizer,structty pe) \ +MAKE_EXTERNAL_LRECORD_IMPLEMENTATION(name,c_name,marker,printer,nuker,equal ,hash,desc,getprop,putprop,remprop,plist,0,sizer,0,structtype) \ + +#define MAKE_EXTERNAL_LRECORD_IMPLEMENTATION(name,c_name,marker,printer,nuker,equal, hash,desc,getprop,putprop,remprop,plist,size,sizer,basic_p,structtype) \ +DECLARE_ERROR_CHECK_TYPECHECK(c_name, structtype) \ +unsigned int lrecord_type_##c_name = lrecord_type_count++; \ +const struct lrecord_implementation lrecord_##c_name = \ + { name, marker, printer, nuker, equal, hash, desc, \ + getprop, putprop, remprop, plist, size, sizer, \ + (enum lrecord_type)lrecord_type_##c_name, basic_p } + + extern Lisp_Object (*lrecord_markers[]) (Lisp_Object); #define INIT_LRECORD_IMPLEMENTATION(type) do { \ lrecord_implementations_table[lrecord_type_##type] = &lrecord_##type; \ ＠＠ -466,7 +508,7 ＠＠ #define XRECORD_LHEADER(a) ((struct lrecord_header *) XPNTR (a)) #define RECORD_TYPEP(x, ty) \ - (LRECORDP (x) && XRECORD_LHEADER (x)->type == (ty)) + (LRECORDP (x) && (((unsigned int)(XRECORD_LHEADER (x)->type)) == ((unsigned int)(ty)))) /* NOTE: the DECLARE_LRECORD() must come before the associated DEFINE_LRECORD_*() or you will get compile errors. ＠＠ -491,6 +533,10 ＠＠ } \ extern Lisp_Object Q##c_name##p +# define DECLARE_EXTERNAL_LRECORD(c_name, structtype) \ +extern unsigned int lrecord_type_##c_name; \ +DECLARE_LRECORD(c_name, structtype) + # define DECLARE_NONRECORD(c_name, type_enum, structtype) \ INLINE_HEADER structtype * \ error_check_##c_name (Lisp_Object obj); \ ＠＠ -515,6 +561,10 ＠＠ # define DECLARE_LRECORD(c_name, structtype) \ extern Lisp_Object Q##c_name##p; \ +extern const struct lrecord_implementation lrecord_##c_name +# define DECLARE_EXTERNAL_LRECORD(c_name, structtype) \ +extern Lisp_Object Q##c_name##p; \ +extern unsigned int lrecord_type_##c_name; \ extern const struct lrecord_implementation lrecord_##c_name # define DECLARE_NONRECORD(c_name, type_enum, structtype) \ extern Lisp_Object Q##c_name##p

1 participants
0 comments

Progress gauge review 23 years, 10 months

Hrvoje Niksic

Some time ago I started using lesstif on my Linux machine. I noticed that the progress bar looks like a slider. Is that intentional? On the cool side, the flicker is much less noticable than with Athena, which flickers horribly. Also, the `Stop' button does not seem to do anything. I don't know if that's lesstif-specific. Thirdly, it causes weird stuff in empty files. It might as well be a font-lock bug, but slider/progress-gauge makes it very noticable. Try opening a new .c file: C-x C-f ~/a.c RET Now start typing characters into it. What I notice is the bottom of the screen flashing like mad because a gutter forms to create a progress bar, and immediately disappears. The problem goes away once you insert a newline character. Either font-lock should be fixed so that it doesn't attempt to display the spurious progress, or the progress bar should be adapted to handle the case more gracefully.

6 participants
10 comments

Another font-lock progress gauge problem 23 years, 10 months

Hrvoje Niksic

One thing that annoys me about the font-lock progress gauge is that in some cases the buffer shows up as unfontified, the gauge runs to 100%, and then the colors flash into place. You can't notice this with `C-x C-f', but try pressing `a' or `m' in a Gnus buffer. For me, that brings up a message buffer with the problem described above.

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