Hello there,
I have various issues assigned to me in the tracker, and many of them need
no further work. When I click “Your Issues” to the left, they currently
appear in the list; I would prefer them not to. I could assign all to our
correspondent from Tsukuba, and I imagine they would disappear from my list,
but that seems sub-optimal. What status do I need to choose for them to
disappear from that list, so I only see those issues I actually need to work
on?
Best,
Aidan
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi Marcus,
I’m looking into making a few changes to some NEW_GC only code, and am
attempting to compile XEmacs 21.5 on OS X/Intel. I get the following errors:
vdb-mach.c: In function 'vdb_install_signal_handler':
vdb-mach.c:166: error: 'ppc_thread_state_t' undeclared (first use in this function)
vdb-mach.c:166: error: (Each undeclared identifier is reported only once
vdb-mach.c:166: error: for each function it appears in.)
vdb-mach.c:166: error: 'exc_thread_state' undeclared (first use in this function)
vdb-mach.c:167: warning: ISO C90 forbids mixed declarations and code
vdb-mach.c:199: error: 'PPC_THREAD_STATE' undeclared (first use in this function)
vdb-mach.c:219: error: expected expression before ')' token
vdb-mach.c:224: error: 'PPC_THREAD_STATE_COUNT' undeclared (first use in this function)
gmake[1]: *** [vdb-mach.o] Error 1
gmake: *** [src] Error 2
And, sure enough, there are very-PPC-specific things like:
exc_thread_state->srr0 = (unsigned int) exception_thread;
exc_thread_state->r1 = (unsigned int) subthread_stack;
retval = thread_set_state (exc_thread, PPC_THREAD_STATE,
(thread_state_t) exc_thread_state,
PPC_THREAD_STATE_COUNT);
Did you ever do the work to have the VDB implementation work on Intel/Mach?
Best,
Aidan
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
apparently there are significant compatibility problems with Python-mode and
xemacs.
https://bugs.launchpad.net/bugs/829442
These bugs are severe enough that they keep me from using the navigation
features that have been added in my attempts to create a more accessible Emacs.
Unfortunately, I need to get work done so that means go find another editor. I
really regret because I was looking to help out. I may still do so after I get
set up with a new editor.
I really appreciate the help all of you have given me and I'll probably be back
as I can't stay away from Emacs. :-)
--- eric
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi, XEmacs!
CC Mode 5.32 has been released. It's licensed under GPL-3+. It's been
tested with XEmacs 21.4.22 and 21.5.b31. I'm going to merge it into
XEmacs ASAP, which should be PDQ.
More information, including links to download the source, are available
on the CC Mode web page:
<http://cc-mode.sourceforge.net/>
Send email correspondence to bug-cc-mode(a)gnu.org.
The new features are (cut and paste into an outline-mode buffer):
* Changes in 5.32
This version contains few, but big, new features, and significant
internal
improvements.
** CC Mode is now licensed under the GPL version 3 or any later version.
** Emacs 21 is no longer supported,
although CC Mode might well still work with it. The minimum versions
supported are Emacs 22 and XEmacs 21.4.
** It is now possible for CC Mode to "guess" an existing buffer's style.
This style can then be used in other buffers. Contributed by Masatake
YAMATO, after original code by Barry Warsaw.
** Java Mode has been enhanced to support Java 5.0 (Tiger) and Java 6
(Mustang). Contributed by Nathaniel Flath.
** c-beginning-of-defun and c-end-of-defun now respect nested scopes.
Thus C-M-a will, by default, go to the beginning of the immediate
function, not the top level.
** "Macros with semicolons" can be registered, for correct indentation.
Where such a macro ends a line (no semicolon), the next statement is no
longer parsed as a statement continuation.
** Many bugs have been fixed, font locking has become more accurate,
angle brackets are better handled, and sluggish code has been optimised.
* Changes in 5.31
This version contains only a few new visible features, but significant
internal improvements.
** The CC Mode manual has been extensively revised.
The information about using CC Mode has been separated from the larger
and more difficult chapters about configuration.
*** There are now two variants of the manual - for GNU Emacs and XEmacs.
The only difference between them is where some cross references point
(e.g. GNU Emacs Manual vs. XEmacs Manual). The default variant is for
GNU. To build an XEmacs version, you must define the texinfo symbol
"XEMACS". See README and cc-mode.texi.
** Changes in Key Sequences
*** c-toggle-auto-hungry-state is no longer bound to C-c C-t.
*** c-toggle-hungry-state is no longer bound to C-c C-d.
This binding has been taken over by c-hungry-delete-forwards.
*** c-toggle-auto-state (C-c C-t) has been renamed to
c-toggle-auto-newline. c-toggle-auto-state remains as an alias.
*** c-hungry-backspace has been renamed to c-hungry-delete-backwards.
c-hungry-backspace remains as an alias.
*** c-hungry-delete-backwards and c-hungry-delete-forwards
now have permanent key bindings, respectively C-c C-DEL (or C-c DEL, for
the benefit of TTYs) and C-c C-d (or C-c C-<delete> or C-c <delete>).
These commands delete entire blocks of whitespace with a single
key-sequence. [N.B. "DEL" is the <backspace> key.]
*** The new command c-toggle-electric-mode is bound to C-c C-l.
*** The new command c-subword-mode is bound to C-c C-w.
** C-c C-s (`c-show-syntactic-information') now highlights the anchor
position(s).
** The new GtkDoc Doc Comment style has become the default for C Mode.
Contributed by Masatake YAMATO.
** New Minor Modes
*** Electric Minor Mode toggles the electric action of non-alphabetic
keys.
The new command c-toggle-electric-mode is bound to C-c C-l. Turning the
mode off can be helpful for editing chaotically indented code and for
users new to CC Mode, who sometimes find electric indentation
disconcerting. Its current state is displayed in the mode line with an
'l', e.g. "C/al".
*** Subword Minor Mode makes Emacs recognize word boundaries at upper
case letters in StudlyCapsIdentifiers. You enable this feature by C-c
C-w. It can also be used in non-CC Mode buffers. :-) Contributed by
Masatake YAMATO. Subword Minor Mode doesn't (yet?) work in Emacs 20.n.
** New clean-ups
*** `comment-close-slash'.
With this clean-up, a block (i.e. c-style) comment can be terminated by
typing a slash at the start of a line.
*** `c-one-liner-defun'
This clean-up compresses a short enough defun (for example, an AWK
pattern/action pair) onto a single line. "Short enough" is configurable.
** AWK support
AWK Mode is now better integrated into CC Mode as a whole. In detail:
*** Comment and line-breaking commands now work for AWK.
*** M-a and M-e (c-beginning/end-of-statement) now work for AWK.
*** "awk" style, Auto-newline insertion, special AWK initialization hook.
A new style, "awk" has been introduced, and this is now the default
style for AWK code. With its introduction, Auto-newline insertion can
be used freely for AWK code, and there is no longer a need for the
special initialization function in the AWK Mode hook.
*** The standard Line-up functions still haven't been adapted for AWK.
Some of these may work serendipitously. There shouldn't be any problems
writing custom indentation functions for AWK mode.
*** AWK Font Locking still hasn't been fully integrated into CC Mode.
There is just a single level of font locking in AWK mode.
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
**The menu problem still remains thought. Hacking it away in the mode
**either conditionally or permanently is of course a way to fix it.
**
**I'm thinking if we should implement the :help keyword as a nop and
**ignore it. I don't know if it is easy but guess/hope it is. So that we
**just don't trip on it. Proper implementation of :help could then be
**done later if it is needed.
Mats,
I agree with you, if we could implement :help as a keyword doing nothing now,
we could always add code to implement tooltips at some later time if we want
to. I for one would like to have tool tips implemented and working now too, but
am not sure how much effort that would take.
Supporting tooltips might integrate XEmacs closer to those windowing systems
that use tooltips now (and that run XEmacs), making XEmacs more similar to
the look/feel that users of those windowing systems get with other applications.
Steve Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2011-08-16 - 2011-08-23)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
545 open ( +2) / 251 closed ( +0) / 796 total ( +2)
Open issues with patches: 12
Average duration of open issues: 910 days.
Median duration of open issues: 990 days.
Open Issues Breakdown
new 206 ( +2)
deferred 6 ( +0)
napping 4 ( +0)
verified 54 ( +0)
assigned 153 ( +0)
committed 30 ( +0)
documented 3 ( +0)
done/needs work 24 ( +0)
Issues Created Or Reopened (2)
______________________________
carbon xemacs mach port leak 2011-08-17
http://tracker.xemacs.org/XEmacs/its/issue797 created stephen
BUFFER TABS & MODELINE NOT UPDATED W/SAVE AS 2011-08-18
http://tracker.xemacs.org/XEmacs/its/issue798 created anonymous
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
APPROVE COMMIT 21.5
Revision 5543:fbe90e6f7a43 "Initialize start and end properly (to new
markers, not Qnil)" introduced a bad performance regression, resulting
in map_extents (a fairly expensive function) being called ~15,000,000
times instead of ~100,000 times while fontifying python-mode.el.
xemacs -vanilla -eval '(find-lib "python-mode")'
-eval "(profile-command 'font-lock-fontify-buffer)"
to see the evil for yourself. :-/
All versions up to 5551:40a52efbf3a3 "Reflect change of location of
packages to share/" are affected. I recommend you avoid using those
versions if possible. If you must use one and run into performance
problems, setting `lookup-syntax-properties' to nil will probably help
performance (untested) but will definitely break cc-mode and cperl.
The attached patch fixes the issue, and due to the performance
regression, I'm going to commit it now. There's a bunch of other
stuff in there, refactoring and docs etc. Sorry about that, but I
needed to do most of the refactoring to figure out what was going
wrong.
FWIW, I'm fairly sure that the hunk "@@ -344,22 +381,37 @@" is what
actually fixes the regression.
diff -r 40a52efbf3a3 src/ChangeLog
--- a/src/ChangeLog Sun Aug 14 13:51:14 2011 +0200
+++ b/src/ChangeLog Tue Aug 23 04:32:35 2011 +0900
@@ -1,3 +1,41 @@
+2011-08-23 Stephen Turnbull <stephen(a)xemacs.org>
+
+ Fix performance regression in refactored syntax cache setup.
+ More doc improvements.
+
+ * syntax.h (enum syntax_source):
+ New. Specify whether syntax is from property or buffer.
+ (struct syntax_cache):
+ Use enum syntax_source source, instead of no_syntax_table_prop
+ and use_code.
+ Improve comments.
+ (SOURCE_IS_TABLE):
+ New predicate.
+ (SYNTAX_CODE_FROM_CACHE):
+ Use it instead of use_code, and adjust logic.
+
+ * syntax.c (syntax_cache_table_was_changed):
+ Check cache->source (cache->no_syntax_table_prop is gone).
+ (reset_syntax_cache_range):
+ All information about OBJECT and BUFFER is in CACHE already.
+ Also reset markers in OBJECT if it is a buffer.
+ Rename INFINITE to VALID_EVERYWHERE.
+ (init_syntax_cache):
+ Initialize source (cache->no_syntax_table_prop is gone).
+ Maybe initialize start and end to null markers.
+ Initialize cache range with reset_syntax_cache_range.
+ (update_syntax_cache):
+ Use source instead of no_syntax_table_prop and use_code.
+ (setup_syntax_cache):
+ Add header comment. Improve other comments.
+ Make calls to reset_syntax_cache_range and init_syntax_cache match
+ their prototypes.
+ (init_buffer_syntax_cache):
+ Use init_syntax_cache to do the work.
+ (signal_syntax_cache_extent_changed):
+ Make call to reset_syntax_cache_range match its prototype.
+ Improve local variable naming.
+
2011-08-08 Stephen J. Turnbull <stephen(a)xemacs.org>
* syntax.c (update_syntax_cache):
diff -r 40a52efbf3a3 src/syntax.c
--- a/src/syntax.c Sun Aug 14 13:51:14 2011 +0200
+++ b/src/syntax.c Tue Aug 23 04:32:35 2011 +0900
@@ -273,7 +273,7 @@
syntax_cache_table_was_changed (struct buffer *buf)
{
struct syntax_cache *cache = buf->syntax_cache;
- if (cache->no_syntax_table_prop)
+ if (cache->source == syntax_source_buffer_table)
{
cache->syntax_table =
BUFFER_SYNTAX_TABLE (buf);
@@ -284,59 +284,96 @@
static void
reset_syntax_cache_range (struct syntax_cache *cache, /* initialized cache */
- Lisp_Object object) /* string or buffer */
+ int valid_everywhere) /* non-zero if we can assume
+ syntax-table properties
+ never need be respected
+ in the life of the cache */
{
- /* reinitialize cache parameters */
- if (BUFFERP (object))
+ if (BUFFERP (cache->object))
{
/* make known region zero-length and reset insertion behavior */
- Fset_marker (cache->start, make_int (1), object);
- Fset_marker (cache->end, make_int (1), object);
+ Fset_marker (cache->start, make_int (1), cache->object);
+ Fset_marker (cache->end, make_int (1), cache->object);
Fset_marker_insertion_type (cache->start, Qnil);
Fset_marker_insertion_type (cache->end, Qt);
}
- else
+ /* #### Should reset "cache->source" here?
+ If so, also reset tables. */
+ if (valid_everywhere)
{
- /* invalidate the known region markers */
- Fset_marker (cache->start, Qnil, Qnil);
- Fset_marker (cache->end, Qnil, Qnil);
+ cache->prev_change = EMACS_INT_MIN;
+ cache->next_change = EMACS_INT_MAX;
}
- cache->no_syntax_table_prop = 1;
- if (lookup_syntax_properties)
+ else /* valid nowhere */
{
cache->prev_change = -1;
cache->next_change = -1;
}
- else
- {
- cache->prev_change = EMACS_INT_MIN;
- cache->next_change = EMACS_INT_MAX;
- }
}
-/* init_syntax_cache
- Arguments:
- cache: pointer to a zero-ed struct syntax_cache
- object: a Lisp string or buffer
- buffer: NULL or the struct buffer of buffer */
static void
-init_syntax_cache (struct syntax_cache *cache, /* cache must be zero'ed */
+init_syntax_cache (struct syntax_cache *cache, /* xzero'ed memory */
Lisp_Object object, /* string or buffer */
- struct buffer *buffer) /* may not be NULL */
+ struct buffer *buffer) /* buffer; if OBJECT is a
+ buffer, this is the same */
{
- /* initialize cache resources */
cache->object = object;
cache->buffer = buffer;
+
+ cache->source = syntax_source_buffer_table;
cache->syntax_table =
BUFFER_SYNTAX_TABLE (cache->buffer);
cache->mirror_table =
BUFFER_MIRROR_SYNTAX_TABLE (cache->buffer);
- cache->start = Fmake_marker();
- cache->end = Fmake_marker();
+
+ /* Qnil avoids GC'ing markers, which are useless for strings. */
+ cache->start = BUFFERP (object) ? Fmake_marker () : Qnil;
+ cache->end = BUFFERP (object) ? Fmake_marker () : Qnil;
+
+ reset_syntax_cache_range (cache, 0);
}
/* external syntax cache API */
+/* At this time (hg rev 5551:dab422055bab) setup_syntax_cache() is called
+ directly once in setup_buffer_syntax_cache and twice in regex.c. The
+ calls in regex.c are obfuscated, so it's hard to tell, but it looks like
+ they can be called with OBJECT being a buffer.
+
+ "You are in a confusing maze of initializations, all alike."
+
+ reset_syntax_cache_range (3 uses in setup_syntax_cache,
+ signal_syntax_cache_extent_changed, and init_buffer_syntax_cache)
+ reinitializes:
+ 1. if BUFFERP(OBJECT), marker positions to 1 (giving a null range)
+ 2. if BUFFERP(OBJECT), marker movement type
+ 3. cache range per VALID_EVERYWHERE
+
+ init_syntax_cache (2 uses in init_buffer_syntax_cache and
+ setup_syntax_cache) initializes:
+ 1. source to syntax_source_buffer_table
+ 2. syntax_table and mirror_syntax table to BUFFER's tables
+ 3. marker members to BUFFERP(OBJECT) ? markers w/o position : Qnil
+ 4. cache range with VALID_EVERYWHERE==0
+ 5. object and buffer to corresponding arguments.
+
+ init_buffer_syntax_cache (1 use in buffer.c) initializes:
+ 0. allocation of buffer's cache memory (done by allocator)
+ 1. cache memory to zero (done by allocator)
+ 2. cache to buffer's cache
+ 3. cache members by init_syntax_cache with object==buffer==BUF.
+
+ setup_buffer_syntax_cache (1 call in font-lock.c, 1 use in search.c,
+ and 7 uses in this file) initializes:
+ 0. buffer's syntax cache by calling setup_syntax_cache.
+
+ setup_buffer_syntax_cache and setup_syntax_cache are called by functions
+ that analyze text using character syntax. They are called repeatedly on
+ the same cache. init_syntax_cache and init_buffer_syntax_cache are
+ conceptually called once for each cache. reset_syntax_cache_range may
+ be called repeatedly on the same cache. The last three are for internal
+ use by the syntax setup code and buffer initialization. */
+
struct syntax_cache * /* return CACHE or the cache of OBJECT */
setup_syntax_cache (struct syntax_cache *cache, /* may be NULL only if
OBJECT is a buffer */
@@ -344,22 +381,37 @@
is associated with */
struct buffer *buffer, /* the buffer to use as source
of the syntax table */
- Charxpos UNUSED (from), /* initial position of cache */
- int UNUSED (count)) /* direction? see code */
+ Charxpos from, /* initial position of cache */
+ int count) /* direction? see code */
{
- /* If OBJECT is a buffer, use its cache, otherwise use CACHE.
- Initialize CACHE. Invalidate the cache if the syntax-table property is
- being respected, otherwise make it valid for the whole object. */
+ /* If OBJECT is a buffer, use its cache; else use CACHE and initialize it.
+ Invalidate the cache if the syntax-table property is being respected;
+ else make it valid for the whole object. */
if (BUFFERP (object))
{
cache = XBUFFER (object)->syntax_cache;
+ if (!lookup_syntax_properties)
+ reset_syntax_cache_range (cache, 1);
}
else
{
xzero (*cache);
init_syntax_cache (cache, object, buffer);
}
- reset_syntax_cache_range (cache, object);
+
+ if (lookup_syntax_properties)
+ {
+ if (count <= 0)
+ {
+ --from;
+ from = buffer_or_string_clip_to_accessible_char (cache->object,
+ from);
+ }
+ /* If lookup_syntax_properties && BUFFERP (object), this
+ optimization may matter. */
+ if (!(from >= cache->prev_change && from < cache->next_change))
+ update_syntax_cache (cache, from, count);
+ }
#ifdef NOT_WORTH_THE_EFFORT
update_mirror_syntax_if_dirty (cache->mirror_table);
@@ -454,24 +506,21 @@
if (!NILP (Fsyntax_table_p (tmp_table)))
{
- cache->use_code = 0;
+ cache->source = syntax_source_property_table;
cache->syntax_table = tmp_table;
cache->mirror_table = XCHAR_TABLE (tmp_table)->mirror_table;
- cache->no_syntax_table_prop = 0;
#ifdef NOT_WORTH_THE_EFFORT
update_mirror_syntax_if_dirty (cache->mirror_table);
#endif /* NOT_WORTH_THE_EFFORT */
}
else if (CONSP (tmp_table) && INTP (XCAR (tmp_table)))
{
- cache->use_code = 1;
+ cache->source = syntax_source_property_code;
cache->syntax_code = XINT (XCAR (tmp_table));
- cache->no_syntax_table_prop = 0;
}
else
{
- cache->use_code = 0;
- cache->no_syntax_table_prop = 1;
+ cache->source = syntax_source_buffer_table;
cache->syntax_table = BUFFER_SYNTAX_TABLE (cache->buffer);
cache->mirror_table = BUFFER_MIRROR_SYNTAX_TABLE (cache->buffer);
#ifdef NOT_WORTH_THE_EFFORT
@@ -501,14 +550,15 @@
void
init_buffer_syntax_cache (struct buffer *buf)
{
+ struct syntax_cache *cache;
#ifdef NEW_GC
- buf->syntax_cache = XSYNTAX_CACHE (ALLOC_NORMAL_LISP_OBJECT (syntax_cache));
+ cache = XSYNTAX_CACHE (ALLOC_NORMAL_LISP_OBJECT (syntax_cache));
#else /* not NEW_GC */
- buf->syntax_cache = xnew_and_zero (struct syntax_cache);
+ cache = xnew_and_zero (struct syntax_cache);
#endif /* not NEW_GC */
- init_syntax_cache (buf->syntax_cache, wrap_buffer(buf), buf);
- reset_syntax_cache_range (buf->syntax_cache, wrap_buffer(buf));
+ init_syntax_cache (cache, wrap_buffer (buf), buf);
+ buf->syntax_cache = cache;
}
/* finalize the syntax cache for BUF */
@@ -535,18 +585,18 @@
void
signal_syntax_cache_extent_changed (EXTENT extent)
{
- Lisp_Object buffer = Fextent_object (wrap_extent (extent));
- if (BUFFERP (buffer))
+ Lisp_Object object = Fextent_object (wrap_extent (extent));
+ if (BUFFERP (object))
{
- struct syntax_cache *cache = XBUFFER (buffer)->syntax_cache;
- Bytexpos start = extent_endpoint_byte (extent, 0);
- Bytexpos end = extent_endpoint_byte (extent, 1);
- Bytexpos start2 = byte_marker_position (cache->start);
- Bytexpos end2 = byte_marker_position (cache->end);
+ struct syntax_cache *cache = XBUFFER (object)->syntax_cache;
+ Bytexpos extent_start = extent_endpoint_byte (extent, 0);
+ Bytexpos extent_end = extent_endpoint_byte (extent, 1);
+ Bytexpos cache_start = byte_marker_position (cache->start);
+ Bytexpos cache_end = byte_marker_position (cache->end);
/* If the extent is entirely before or entirely after the cache
range, it doesn't overlap. Otherwise, invalidate the range. */
- if (!(end < start2 || start > end2))
- reset_syntax_cache_range (cache, buffer);
+ if (!(extent_end < cache_start || extent_start > cache_end))
+ reset_syntax_cache_range (cache, 0);
}
}
diff -r 40a52efbf3a3 src/syntax.h
--- a/src/syntax.h Sun Aug 14 13:51:14 2011 +0200
+++ b/src/syntax.h Tue Aug 23 04:32:35 2011 +0900
@@ -234,20 +234,21 @@
#### sjt sez: I'm not sure I believe that last claim. That seems to
require that we use directional information, etc, but that is ignored in
the current implementation. */
+
+enum syntax_source { syntax_source_property_code = 0,
+ syntax_source_property_table = 1,
+ syntax_source_buffer_table = 2 };
+#define SOURCE_IS_TABLE(source) (source)
+
struct syntax_cache
{
#ifdef NEW_GC
NORMAL_LISP_OBJECT_HEADER header;
#endif /* NEW_GC */
- int use_code; /* Non-zero if a syntax-table property
- specified a syntax code. When zero, the
- syntax_code member is invalid. Otherwise
- the syntax_table member is invalid. */
- int no_syntax_table_prop; /* If non-zero, there was no `syntax-table'
- property on the current range, and so we're
- using the buffer's syntax table.
- Then we must invalidate the cache if the
- buffer's syntax table is changed. */
+ enum syntax_source source; /* Source of syntax information: the buffer's
+ syntax table, a syntax table specified by
+ a syntax-table property, or a syntax code
+ specified by a syntax-table property. */
Lisp_Object object; /* The buffer or string the current syntax
cache applies to, or Qnil for a string of
text not coming from a buffer or string. */
@@ -260,6 +261,7 @@
Lisp_Object mirror_table; /* Mirror table for this table. */
Lisp_Object start, end; /* Markers to keep track of the known region
in a buffer.
+ Both are Qnil if object is a string.
Normally these correspond to prev_change
and next_change, respectively, except when
insertions and deletions occur. Then
@@ -269,7 +271,8 @@
We'd like to use an extent, but it seems
that having an extent over the entire
buffer causes serious slowdowns in extent
- operations! Yuck! */
+ operations! Yuck!
+ #### May not be true any more. */
Charxpos next_change; /* Position of the next extent change. */
Charxpos prev_change; /* Position of the previous extent change. */
};
@@ -341,9 +344,10 @@
#define SYNTAX_FROM_CACHE(cache, c) \
SYNTAX_FROM_CODE (SYNTAX_CODE_FROM_CACHE (cache, c))
-#define SYNTAX_CODE_FROM_CACHE(cache, c) \
- ((cache)->use_code ? (cache)->syntax_code \
-: SYNTAX_CODE ((cache)->mirror_table, c))
+#define SYNTAX_CODE_FROM_CACHE(cache, c) \
+ (SOURCE_IS_TABLE ((cache)->source) \
+ ? SYNTAX_CODE ((cache)->mirror_table, c) \
+: (cache)->syntax_code)
#ifdef NOT_WORTH_THE_EFFORT
/* If we really cared about the theoretical performance hit of the dirty
@@ -356,9 +360,10 @@
functions and could execute arbitrary Lisp very easily), etc. The QUIT
problem is the biggest one, probably, and one of the main reasons it's
probably just not worth it. */
-#define SYNTAX_CODE_FROM_CACHE(cache, c) \
- ((cache)->use_code ? (cache)->syntax_code \
-: SYNTAX_CODE_1 ((cache)->mirror_table, c))
+#define SYNTAX_CODE_FROM_CACHE(cache, c) \
+ (SOURCE_IS_TABLE ((cache)->source) \
+ ? SYNTAX_CODE_1 ((cache)->mirror_table, c) \
+: (cache)->syntax_code)
#endif
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Sometime ago I added issue 730 about updating eldoc in xemacs.
Anything I can do to make that happen? I've been using eldoc from emacs 22
and 23 just fine with xemacs. My testing has been limited to just what
slime uses eldoc for, but it works just fine.
All that's needed is a copy of eldoc.el and help-fns.el. There is one
change needed in eldoc.el to work with xemacs 21.4. In eldoc, there is
(require 'help-mode), which doesn't work with 21.4. I just changed that to
(load-library "help"). Then everything works in 21.4.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I assume there's still nobody actually working on the OSX version of xemacs, but just for posterity I thought I'd point out that there seems to be a mach port leak somewhere. After about a week it gets up to 17k ports (according to Activity Monitor) and other programs (notably Mail.app) start crashing until I restart xemacs.
Carbon xemacs 21.5.28, which I haven't touched in a couple of years. MacOS 10.6.8.
I use shell buffers a lot, so that's a likely suspect.
--
Jamie Zawinski http://www.jwz.org/http://www.dnalounge.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Using the hg repo from a few days ago, selecting parenthesis highlighting
from the menu bar doesn't actually do anything. It seems to me that this
used to work.
Recipe: xemacs -vanilla. Use the menu Options->Display->Paren Highlighting
and select any of the options. Edit your favorite C or Lisp file and place
the cursor on some closing brace/paren. No highlighting is done.
But use customize-group to enable paren highlighting, and paren highlighting
is actually enabled. I'm not exactly sure what the problem is, but if you
used the menu to enable paren highlighting and then save it to the custom.el
file, you get something like
(paren-mode 'sexp t)
But if you use customize, you get
(paren-mode 'sexp nil (paren))
which seems to work when restarting xemacs.
Also, the documentation for paren-mode mentions sexp-expression (and the
unimplemented nested), but the menu option doesn't list sexp-expression. It
should probably mention that.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta