So, punctuation always delimits in some way, but we also want to have some indication of it's real use... at the same time we want to indicate the textual manner in which the punctuation is used.  Maybe splitting the scope's second and thir levels up into syntax.function makes sense - as in:

* punctuation.section.(quote|paragraph|comment|scope|function|etc)
   
    The start/end of a structured section of some sort (comment, paragraph, opening and
    closing braces in code, etc).  Any potentially large (multi-lined?) section that can
    be described as serving a single function.  Could possibly become
    punctuation.block.begin.foo and punctuation.block.end.foo, but I'm not sure there is a
    real use in such specificity (especially since there is not always a literal end).
   

* punctuation.separator.(valuepair|list|arguments|etc)

    Any punctuation intended to separate two internal parts of a logical whole.  This
    includes key/value pairs in things like HTML/XML/YAML (but not true assignment), as
    well as items in a literal list ([1, 2, 3]).

* punctuation.definition.(string|table|array|token|header|list|etc)

    Punctuation that is intended to delimit the bounds of a single item, generally
    something that will become a real singular object in compiled/interpreted code.  Can
    also be used in markup languages for delimiters that define small conceptual units
    (headers, list items, etc).

* punctuation.terminator

    Punctuation that terminates a statement, rule, line, etc. (the ; in [print "foo\n";])

* punctuation.other...

    Every scope needs an other.  There are simply too many languages and too many uses to
    be confident that a set second level will capture everything appropriately.  It should, of course
    be highly limited in its use.
   

For clarity - I'm including the remainder of the old definitions and where I see them slotting in this system:

 * punctuation.delimiter.comment - bit of an outlier (inline vs. block) but can probably be reasonably handled as punctuation.section.comment
 * punctuation.delimiter.embedded - punctuation.section.embedded
 * punctuation.delimiter.group - punctuation.definition.group (punctuation.definition.regexp.group)
 * punctuation.delimiter.markup.header - punctuation.definition.header
 * punctuation.delimiter.markup.item - punctuation.definition.list ,item, etc
 * punctuation.delimiter.markup.table.(column|row) - punctuation.definition.table.row,col
 * punctuation.delimiter.section.(rule|function|etc) - punctuation.section
 * punctuation.delimiter.separator.argument - punctuation.separator.argument
 * punctuation.delimiter.separator.relationship - punctuation.separator.relationship
 * punctuation.delimiter.string - punctuation.definition.string
 * punctuation.delimiter.tag - punctuation.definition.tag
 * punctuation.delimiter.markup.image - punctuation.definition.link.image




On 8/21/06, Michael Sheets < [EMAIL PROTECTED]> wrote:
> 1.  I don't really see the difference between
> "punctuation.delimiter.block" and "punctuation.delimiter.section".
> I'm in favor of collapsing "section" into "block", since "block"
> sounds nicer.

I'm leaning in this direction, should simplify things a bit.

> 2.  I'm of the opinion that "punctuation.delimiter" is actually
> redundant.  It seems obvious to me that punctuation characters are
> used to delimit things.  Do we really need excessively wordy scope
> names?  "punctuation.delimiter.separator" is even more redundant.

Realistically I'm against this, but I think it may be best usability
wise. Played around a bit with them tonight:

punctuation.delimiter.embedded.comment.django-template

That's quite long, really getting too unwieldy to be practical. Think
I'll be removing .delimiter

> 3.  How would you scope the single quotes in a single-quoted Erlang
> atom (equivalent to a Lisp or Ruby symbol)?  'This is an example'.
> Note that this definitely has nothing to do with a string.

Still havn't figured this out; humph.



_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev

_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev

Reply via email to