commit/cc-mode: acm: Fix fontification of C++ declaration with type
FOO::FOO.
7 years
Bitbucket
Bitbucket
1 new commit in cc-mode:
https://bitbucket.org/xemacs/cc-mode/commits/42d965b3e891/
Changeset: 42d965b3e891
User: acm
Date: 2017-04-22 14:18:42+00:00
Summary: Fix fontification of C++ declaration with type FOO::FOO.
* cc-engine.el (c-find-decl-spots): Initialize cfd-top-level properly.
(c-forward-decl-or-cast-1): On finding FOO::FOO, check it is followed by "("
before deciding it is a constructor.
* cc-fonts.el (c-font-lock-complex-decl-prepare): Negate the result of the
c-bs-at-toplevel-p call passed to c-font-lock-declarators (simple bug fix).
Affected #: 2 files
diff -r 3aaa2fcb2d5bac9e1008403bc12a2366a85cf576 -r 42d965b3e8913f32d004a9cb170cf27ade0fb08f cc-engine.el
--- a/cc-engine.el
+++ b/cc-engine.el
＠＠ -5693,7 +5693,7 ＠＠
;; Whether the last position returned from `c-find-decl-prefix-search'
;; is at the top-level (including directly in a class or namespace,
;; etc.).
- cfd-top-level)
+ (cfd-top-level (c-bs-at-toplevel-p (point))))
;; Initialize by finding a syntactically relevant start position
;; before the point, and do the first `c-decl-prefix-or-start-re'
＠＠ -8379,7 +8379,11 ＠＠
(c-simple-skip-symbol-backward))
(>= (point) type-start)
(equal (buffer-substring-no-properties (point) end-1)
- name))
+ name)
+ (goto-char end-2)
+ (progn
+ (c-forward-syntactic-ws)
+ (eq (char-after) ?\()))
;; It is a (con|de)structor name. In that case the
;; declaration is typeless so zap out any preceding
;; identifier(s) that we might have taken as types.
diff -r 3aaa2fcb2d5bac9e1008403bc12a2366a85cf576 -r 42d965b3e8913f32d004a9cb170cf27ade0fb08f cc-fonts.el
--- a/cc-fonts.el
+++ b/cc-fonts.el
＠＠ -901,7 +901,7 ＠＠
(when (memq prop '(c-decl-id-start c-decl-type-start))
(c-forward-syntactic-ws limit)
(c-font-lock-declarators limit t (eq prop 'c-decl-type-start)
- (c-bs-at-toplevel-p (point)))))
+ (not (c-bs-at-toplevel-p (point))))))
(setq c-font-lock-context ;; (c-guess-font-lock-context)
(save-excursion
Repository URL: https://bitbucket.org/xemacs/cc-mode/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
- 1 participants
- 0 comments
commit/XEmacs: kehoea: Accept a vector PACKAGE in intern_string() too,
thank you Raymond Toy.
7 years
Bitbucket
Bitbucket
1 new commit in XEmacs:
https://bitbucket.org/xemacs/xemacs/commits/eec2a31de9d6/
Changeset: eec2a31de9d6
User: kehoea
Date: 2017-04-21 23:23:36+00:00
Summary: Accept a vector PACKAGE in intern_string() too, thank you Raymond Toy.
src/ChangeLog addition:
2017-04-21 Aidan Kehoe <kehoea(a)parhasard.net>
* elhash.c (intern_istring):
Accept a vector PACKAGE here too, thank you for the bug report,
Raymond Toy.
Affected #: 2 files
diff -r 513b2ed98e3ea153c0e65bce5a93994c48d10b42 -r eec2a31de9d67f78b606314136ed13abb364046d src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
＠＠ -1,3 +1,9 ＠＠
+2017-04-21 Aidan Kehoe <kehoea(a)parhasard.net>
+
+ * elhash.c (intern_istring):
+ Accept a vector PACKAGE here too, thank you for the bug report,
+ Raymond Toy.
+
2017-04-19 Aidan Kehoe <kehoea(a)parhasard.net>
* buffer.c:
diff -r 513b2ed98e3ea153c0e65bce5a93994c48d10b42 -r eec2a31de9d67f78b606314136ed13abb364046d src/elhash.c
--- a/src/elhash.c
+++ b/src/elhash.c
＠＠ -1862,6 +1862,20 ＠＠
Lisp_Hash_Table *ht;
htentry *entries, *probe;
+ /* Sigh, the poor old GNUs people went ahead and used
+ binding-obarray-dynamically-and-then-calling-#'read as a way to implement
+ a cache. I will send them a patch to avoid this, to, for example, write a
+ hash table object as a readable hash table object, but for the moment we
+ need to put up with it. */
+ if (VECTORP (package))
+ {
+ return call2 (Qxemacs_intern_in_vector,
+ /* call2() GCPROs the newly-heap-allocated string, that's
+ not an issue. */
+ STRINGP (reloc) ? reloc : make_string (str, len),
+ package);
+ }
+
lookup = oblookup (package, str, len);
if (FIXNUMP (lookup))
{
Repository URL: https://bitbucket.org/xemacs/xemacs/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
- 1 participants
- 0 comments
commit/XEmacs: kehoea: Sync API of #'generate-new-buffer-name with
GNU. Thank you GNU!
7 years
Bitbucket
Bitbucket
1 new commit in XEmacs:
https://bitbucket.org/xemacs/xemacs/commits/513b2ed98e3e/
Changeset: 513b2ed98e3e
User: kehoea
Date: 2017-04-19 17:00:16+00:00
Summary: Sync API of #'generate-new-buffer-name with GNU. Thank you GNU!
src/ChangeLog addition:
2017-04-19 Aidan Kehoe <kehoea(a)parhasard.net>
* buffer.c:
* buffer.c (get_buffer):
Vbuffer_alist is an internal list, no need to GCPRO and call
Fassoc.
* buffer.c (Fgenerate_new_buffer_name):
Update this to match GNU's current API; if NAME starts with a
space, generate the candidate new buffer names using get_random(),
start with suffixes of <2> rather than <1>.
Don't make new Lisp strings or call get_buffer() in the loop.
Copy string extent info to the new buffer name if NAME has extent
info.
man/ChangeLog addition:
2017-04-19 Aidan Kehoe <kehoea(a)parhasard.net>
* lispref/buffers.texi (Buffer Names):
Update documentation on #'generate-new-buffer-name to reflect
changes made to it today.
Affected #: 4 files
diff -r 74b4d4c11264e149d03d748b9c34f253a69801bf -r 513b2ed98e3ea153c0e65bce5a93994c48d10b42 man/ChangeLog
--- a/man/ChangeLog
+++ b/man/ChangeLog
＠＠ -1,3 +1,9 ＠＠
+2017-04-19 Aidan Kehoe <kehoea(a)parhasard.net>
+
+ * lispref/buffers.texi (Buffer Names):
+ Update documentation on #'generate-new-buffer-name to reflect
+ changes made to it today.
+
2017-03-09 Aidan Kehoe <kehoea(a)parhasard.net>
* widget.texi (Introduction):
diff -r 74b4d4c11264e149d03d748b9c34f253a69801bf -r 513b2ed98e3ea153c0e65bce5a93994c48d10b42 man/lispref/buffers.texi
--- a/man/lispref/buffers.texi
+++ b/man/lispref/buffers.texi
＠＠ -293,10 +293,13 ＠＠
This function returns a name that would be unique for a new buffer---but
does not create the buffer. It starts with ＠var{starting-name}, and
produces a name not currently in use for any buffer by appending a
-number inside of ＠samp{<＠dots{}>}.
+number inside of ＠samp{<＠dots{}>}. The numbers appended start at 2, or
+at a random value if ＠var{starting-name} begins with the space
+character, which indicates that a buffer is not visible to users.
-If ＠var{ignore} is given, it specifies a name that is okay to use (if it
-is in the sequence to be tried), even if a buffer with that name exists.
+If ＠var{ignore} is given, it should be a string. This means to consider
+＠var{ignore} as an acceptable buffer name, even if a buffer of that name
+already exists.
See the related function ＠code{generate-new-buffer} in ＠ref{Creating
Buffers}.
diff -r 74b4d4c11264e149d03d748b9c34f253a69801bf -r 513b2ed98e3ea153c0e65bce5a93994c48d10b42 src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
＠＠ -1,3 +1,17 ＠＠
+2017-04-19 Aidan Kehoe <kehoea(a)parhasard.net>
+
+ * buffer.c:
+ * buffer.c (get_buffer):
+ Vbuffer_alist is an internal list, no need to GCPRO and call
+ Fassoc.
+ * buffer.c (Fgenerate_new_buffer_name):
+ Update this to match GNU's current API; if NAME starts with a
+ space, generate the candidate new buffer names using get_random(),
+ start with suffixes of <2> rather than <1>.
+ Don't make new Lisp strings or call get_buffer() in the loop.
+ Copy string extent info to the new buffer name if NAME has extent
+ info.
+
2017-03-19 Aidan Kehoe <kehoea(a)parhasard.net>
* gc.c (GC_CONS_THRESHOLD):
diff -r 74b4d4c11264e149d03d748b9c34f253a69801bf -r 513b2ed98e3ea153c0e65bce5a93994c48d10b42 src/buffer.c
--- a/src/buffer.c
+++ b/src/buffer.c
＠＠ -395,13 +395,11 ＠＠
else
{
Lisp_Object buf;
- struct gcpro gcpro1;
CHECK_STRING (name);
name = LISP_GETTEXT (name);
- GCPRO1 (name);
- buf = Fcdr (Fassoc (name, Vbuffer_alist));
- UNGCPRO;
+ buf = Fcdr (assoc_no_quit (name, Vbuffer_alist));
+
if (NILP (buf) && error_if_deleted_or_does_not_exist)
nsberror (name);
return buf;
＠＠ -770,43 +768,98 ＠＠
Return a string that is the name of no existing buffer based on NAME.
If there is no live buffer named NAME, then return NAME.
Otherwise modify name by appending `<NUMBER>', incrementing NUMBER
-until an unused name is found, and then return that name.
-Optional second argument IGNORE specifies a name that is okay to use
-\(if it is in the sequence to be tried)
-even if a buffer with that name exists.
+\(starting at 2) until an unused name is found, and then return that name.
+
+Optional second argument IGNORE specifies a name that is okay to use (if it
+is in the sequence to be tried) even if a buffer with that name exists.
+
+If NAME begins with a space (i.e., a buffer that is not normally
+visible to users), then if buffer NAME already exists a random number
+is first appended to NAME, to speed up finding a non-existent buffer.
*/
(name, ignore))
{
- REGISTER Lisp_Object gentemp, tem;
- int count;
- Ibyte number[10];
+ Ibyte *candidate;
+ Bytecount csize, clen, ignore_length = -1;
+ EMACS_INT count;
CHECK_STRING (name);
- name = LISP_GETTEXT (name);
#ifdef I18N3
/* #### Doc string should indicate that the buffer name will get
translated. */
#endif
-
- tem = Fget_buffer (name);
- if (NILP (tem))
- return name;
-
- count = 1;
+ name = LISP_GETTEXT (name);
+
+ if (!NILP (ignore))
+ {
+ CHECK_STRING (ignore);
+ ignore_length = XSTRING_LENGTH (ignore);
+
+ if (ignore_length == XSTRING_LENGTH (name)
+ && !qxememcmp (XSTRING_DATA (name), XSTRING_DATA (ignore),
+ ignore_length))
+ {
+ return name;
+ }
+ }
+
+ if (NILP (Fget_buffer (name))) /* XEmacs; don't #'string-equal on nil, see
+ above for the IGNORE handling. */
+ {
+ return name;
+ }
+
+ csize = XSTRING_LENGTH (name) + DECIMAL_PRINT_SIZE (EMACS_INT)
+ + sizeof ("<>");
+ candidate = alloca_ibytes (csize);
+
+ count = itext_ichar_eql (XSTRING_DATA (name), ' ') ? get_random () : 2;
while (1)
{
- qxesprintf (number, "<%d>", ++count);
- gentemp = concat2 (name, build_istring (number));
- if (!NILP (ignore))
+ /* XEmacs; GNU worry about the performance of this function, and then
+ allocate a full new Lisp string on the heap for every iteration of
+ the loop, and call a full Fget_buffer, too. If the performance of
+ #'generate-new-buffer-name really matters--and I've seen no real
+ evidence that is the case--the approach below with snprintf() and
+ ALIST_LOOP_3() is better. */
+ clen = emacs_snprintf (candidate, csize, "%s<%ld>", XSTRING_DATA (name),
+ ++count);
+ if (clen == ignore_length &&
+ !qxememcmp (candidate, XSTRING_DATA (ignore), clen))
+ {
+ return ignore;
+ }
+ else
{
- tem = Fstring_equal (gentemp, ignore);
- if (!NILP (tem))
- return gentemp;
+ Boolint seen = 0;
+ ALIST_LOOP_3 (bufname, bufobj, Vbuffer_alist)
+ {
+ if (XSTRING_LENGTH (bufname) == clen
+ && !qxememcmp (candidate, XSTRING_DATA (bufname), clen))
+ {
+ seen = 1;
+ break;
+ }
+ }
+
+ USED (bufobj); /* Silence warning for this. */
+
+ if (!seen)
+ {
+ Lisp_Object result = make_string (candidate, clen);
+
+ if (string_extent_info (name) != NULL)
+ {
+ /* Despite what other code thinks, stretch_string_extents()
+ doesn't call Lisp, this is OK from the GC perspective. */
+ stretch_string_extents (result, name, 0, 0,
+ XSTRING_LENGTH (name), clen);
+ }
+
+ return result;
+ }
}
- tem = Fget_buffer (gentemp);
- if (NILP (tem))
- return gentemp;
}
}
Repository URL: https://bitbucket.org/xemacs/xemacs/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
- 1 participants
- 0 comments
commit/cc-mode: acm: Fix a loop in C Mode caused by inadequate
analysis of comments.
7 years
Bitbucket
Bitbucket
1 new commit in cc-mode:
https://bitbucket.org/xemacs/cc-mode/commits/3aaa2fcb2d5b/
Changeset: 3aaa2fcb2d5b
User: acm
Date: 2017-04-10 20:32:56+00:00
Summary: Fix a loop in C Mode caused by inadequate analysis of comments.
After M-;, and the insertion of the opening "/*", the CC Mode after-change
function got confused, since the new comment opener matched the end of a
subsequent comment, but moving back over that comment did not come back to the
starting point. Fix this.
* cc-engine.el (c-end-of-macro): Add a limit parameter, where point is left if
no end-of-macro is found before it.
(c-forward-sws): Change the `safe-start' mechanism. Now `safe-start' is
non-nil except where we have an unclosed block comment at the end of a macro.
This enables us to populate the cache more fully, at the cost of some run
time.
Affected #: 1 file
diff -r 715fefb0bc0a5083da72adb687f97289371cb017 -r 3aaa2fcb2d5bac9e1008403bc12a2366a85cf576 cc-engine.el
--- a/cc-engine.el
+++ b/cc-engine.el
＠＠ -324,34 +324,41 ＠＠
(goto-char here)
nil))))))
-(defun c-end-of-macro ()
+(defun c-end-of-macro (&optional lim)
"Go to the end of a preprocessor directive.
More accurately, move the point to the end of the closest following
line that doesn't end with a line continuation backslash - no check is
done that the point is inside a cpp directive to begin with.
+If LIM is provided, it is a limit position at which point is left
+if the end of the macro doesn't occur earlier.
+
Note that this function might do hidden buffer changes. See the
comment at the start of cc-engine.el for more info."
- (if (and (cdr c-macro-cache)
- (<= (point) (cdr c-macro-cache))
- (>= (point) (car c-macro-cache)))
- (goto-char (cdr c-macro-cache))
- (unless (and (car c-macro-cache)
- (<= (point) c-macro-cache-start-pos)
- (>= (point) (car c-macro-cache)))
- (setq c-macro-cache nil
- c-macro-cache-start-pos nil
- c-macro-cache-syntactic nil
- c-macro-cache-no-comment nil))
- (while (progn
- (end-of-line)
- (when (and (eq (char-before) ?\\)
- (not (eobp)))
- (forward-char)
- t)))
- (when (car c-macro-cache)
- (setcdr c-macro-cache (point))
- (setq c-macro-cache-syntactic nil))))
+ (save-restriction
+ (if lim (narrow-to-region (point-min) lim))
+ (if (and (cdr c-macro-cache)
+ (<= (point) (cdr c-macro-cache))
+ (>= (point) (car c-macro-cache)))
+ (goto-char (cdr c-macro-cache))
+ (unless (and (car c-macro-cache)
+ (<= (point) c-macro-cache-start-pos)
+ (>= (point) (car c-macro-cache)))
+ (setq c-macro-cache nil
+ c-macro-cache-start-pos nil
+ c-macro-cache-syntactic nil
+ c-macro-cache-no-comment nil))
+ (while (progn
+ (end-of-line)
+ (when (and (eq (char-before) ?\\)
+ (not (eobp)))
+ (forward-char)
+ t)))
+ (when (and (car c-macro-cache)
+ (bolp)
+ (not (eq (char-before (1- (point))) ?\\)))
+ (setcdr c-macro-cache (point))
+ (setq c-macro-cache-syntactic nil)))))
(defun c-syntactic-end-of-macro ()
;; Go to the end of a CPP directive, or a "safe" pos just before.
＠＠ -1846,13 +1853,10 ＠＠
(let (;; `rung-pos' is set to a position as early as possible in the
;; unmarked part of the simple ws region.
(rung-pos (point)) next-rung-pos rung-end-pos last-put-in-sws-pos
- rung-is-marked next-rung-is-marked simple-ws-end
+ rung-is-marked next-rung-is-marked simple-ws-end macro-start macro-end
;; `safe-start' is set when it's safe to cache the start position.
- ;; It's not set if we've initially skipped over comments and line
- ;; continuations since we might have gone out through the end of a
- ;; macro then. This provision makes `c-forward-sws' not populate the
- ;; cache in the majority of cases, but otoh is `c-backward-sws' by far
- ;; more common.
+ ;; This is the case except when we have an unterminated block comment
+ ;; within a macro.
safe-start)
;; Skip simple ws and do a quick check on the following character to see
＠＠ -1928,7 +1932,33 ＠＠
;; Now move over any comments (x)or a CPP construct.
(setq simple-ws-end (point))
- (c-forward-comments)
+ (setq safe-start t)
+ ;; Take elaborate precautions to detect an open block comment at
+ ;; the end of a macro. If we find one, we set `safe-start' to nil
+ ;; and break off any further scanning of comments.
+ (let ((com-begin (point)) com-end in-macro)
+ (when (and (c-forward-single-comment)
+ (setq com-end (point))
+ (save-excursion
+ (goto-char com-begin)
+ (c-beginning-of-macro)))
+ (setq in-macro t)
+ (goto-char com-begin)
+ (if (progn (c-end-of-macro com-end)
+ (< (point) com-end))
+ (setq safe-start nil)))
+ (if in-macro
+ (while (and safe-start
+ com-end (> com-end com-begin)
+ (setq com-begin (point))
+ (when (and (c-forward-single-comment)
+ (setq com-end (point)))
+ (goto-char com-begin)
+ (if (progn (c-end-of-macro com-end)
+ (< (point) com-end))
+ (setq safe-start nil))
+ safe-start)))
+ (c-forward-comments)))
(cond
((/= (point) simple-ws-end)
＠＠ -1939,6 +1969,7 ＠＠
((save-excursion
(and c-opt-cpp-prefix
(looking-at c-opt-cpp-start)
+ (setq macro-start (point))
(progn (skip-chars-backward " \t")
(bolp))
(or (bobp)
＠＠ -1949,8 +1980,20 ＠＠
(while (and (eq (char-before) ?\\)
(= (forward-line 1) 0))
(end-of-line))
+ (setq macro-end (point))
+ ;; Check for an open block comment at the end of the macro.
+ (goto-char macro-start)
+ (let (s in-block-comment)
+ (while
+ (progn
+ (setq s (parse-partial-sexp (point) macro-end
+ nil nil s 'syntax-table))
+ (< (point) macro-end))
+ (setq in-block-comment
+ (and (elt s 4) ; in a comment
+ (null (elt s 7))))) ; a block comment
+ (if in-block-comment (setq safe-start nil)))
(forward-line 1)
- (setq safe-start t)
;; Don't cache at eob in case the buffer is narrowed.
(not (eobp)))
＠＠ -1958,7 +2001,6 ＠＠
(looking-at c-noise-macro-name-re))
;; Skip over a noise macro.
(goto-char (match-end 1))
- (setq safe-start t)
(not (eobp)))))
;; We've searched over a piece of non-white syntactic ws. See if this
＠＠ -2021,8 +2063,7 ＠＠
(if (setq rung-is-marked next-rung-is-marked)
(setq rung-pos (1- (c-next-single-property-change
rung-is-marked 'c-is-sws nil rung-end-pos)))
- (setq rung-pos next-rung-pos))
- (setq safe-start t)))
+ (setq rung-pos next-rung-pos))))
;; Make sure that the newly marked `c-in-sws' region doesn't connect to
;; another one after the point (which might occur when editing inside a
Repository URL: https://bitbucket.org/xemacs/cc-mode/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
- 1 participants
- 0 comments