Mercurial > hg > xemacs-beta
view etc/ETAGS.EBNF @ 5014:c2e0c3af5fe3
cleanups to debug-print, try harder to make it work during GC
-------------------- ChangeLog entries follow: --------------------
src/ChangeLog addition:
2010-02-08 Ben Wing <ben@xemacs.org>
* emacs.c:
* emacs.c (assert_failed):
Fix comments about when inhibit_non_essential_printing_operations
is set and how used. Increment/decrement in assert_failed rather
than just setting/resetting to avoid hosing things in case we're
called when the value is already non-zero. Similarly increment/
decrement in_assert_failed.
* gc.c (gc_prepare):
* gc.c (gc_finish):
Increment/decrement inhibit_non_essential_printing_operations
rather than setting/resetting.
* print.c:
* print.c (debug_out):
* print.c (write_string_to_alternate_debugging_output):
* print.c (restore_inhibit_non_essential_conversion_operations):
* print.c (debug_print_exit):
* print.c (debug_print_enter):
* print.c (debug_prin1):
* print.c (debug_p4):
* print.c (ext_print_begin):
* print.c (ext_print_end):
* print.c (external_debug_print):
* print.c (debug_p3):
* print.c (debug_backtrace):
* print.c (debug_short_backtrace):
* print.c (vars_of_print):
Lots of cleanup. Fix debug_out() so it binds
inhibit_non_essential_printing_operations around it to ensure no
conversion. Remove many other places that set the same var since
the lower-level functions now all do it. A few other places, add
inhibit_non_essential_printing_operations bindings.Extract the
code out that sets up and resets lots of bindings in debug_prin1()
so that debug_backtrace() can use it, and rewrite it to use the
new STORE_VOID_IN_LISP() rather than having to have a single
static opaque structure holding all the bindings (and not handling
reentrancy). Fix raw `char' to be `CIbyte' in the declaration of
`alternate_do_string'.
* signal.c (check_what_happened):
Fix bug: Don't try to check for QUIT when
inhibit_non_essential_printing_operations or we may screw things
up if QUIT happens during debug printing.
author | Ben Wing <ben@xemacs.org> |
---|---|
date | Mon, 08 Feb 2010 07:00:24 -0600 |
parents | a827a51c3241 |
children | 308d34e9f07d |
line wrap: on
line source
-*- indented-text -*- See the end of this file for copyright information. This file contains two sections: 1) An EBNF (Extended Backus-Naur Form) description of the format of the tags file created by etags.c and interpreted by etags.el; 2) A discussion of tag names and implicit tag names. ====================== 1) EBNF tag file description ===================== Productions created from current behaviour to aid extensions Francesco Potorti` <pot@gnu.org> 2002 ---------------- FF ::= #x0c /* tag section starter */ LF ::= #x0a /* line terminator */ DEL ::= #x7f /* pattern terminator */ SOH ::= #x01 /* name terminator */ regchar ::= [^#x0a#x0c#x7f] /* regular character */ regstring ::= { regchar } /* regular string */ unsint ::= [0-9] { [0-9] } /* non-negative integer */ tagfile ::= { tagsection } /* a tags file */ tagsection ::= FF LF ( includesec | regularsec ) LF includesec ::= filename ",include" [ LF fileprop ] regularsec ::= filename "," [ unsint ] [ LF fileprop ] { LF tag } filename ::= regchar regstring /* a file name */ fileprop ::= "(" regstring ")" /* an elisp alist */ tag ::= directtag | patterntag directtag ::= DEL realposition /* no pattern */ patterntag ::= pattern DEL [ tagname SOH ] position pattern ::= regstring /* a tag pattern */ tagname ::= regchar regstring /* a tag name */ position ::= realposition | "," /* charpos,linepos */ realposition ::= "," unsint | unsint "," | unsint "," unsint ==================== end of EBNF tag file description ==================== ======================= 2) discussion of tag names ======================= - WHAT ARE TAG NAMES Tag lines in a tags file are usually made from the above defined pattern and by an optional tag name. The pattern is a string that is searched in the source file to find the tagged line. - WHY TAG NAMES ARE GOOD When a user looks for a tag, Emacs first compares the tag with the tag names contained in the tags file. If no match is found, Emacs compares the tag with the patterns. The tag name is then the preferred way to look for tags in the tags file, because when the tag name is present Emacs can find a tag faster and more accurately. These tag names are part of tag lines in the tags file, so we call them "explicit". - WHY IMPLICIT TAG NAMES ARE EVEN BETTER When a tag line has no name, but a name can be deduced from the pattern, we say that the tag line has an implicit tag name. Often tag names are redundant; this happens when the name of a tag is an easily guessable substring of the tag pattern. We define a set of rules to decide whether it is possible to deduce the tag name from the pattern, and make an unnamed tag in those cases. The name deduced from the pattern of an unnamed tag is the implicit name of that tag. When the user looks for a tag, and Emacs finds no explicit tag names that match it, Emacs then looks for an tag whose implicit tag name matches the request. etags.c uses implicit tag names when possible, in order to reduce the size of the tags file. An implicit tag name is deduced from the pattern by discarding the last character if it is one of ` \f\t\n\r()=,;', then taking all the rightmost consecutive characters in the pattern which are not one of those. ===================== end of discussion of tag names ===================== Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. COPYING PERMISSIONS: This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA