I have no reStructured Text file for testing, but I think the following syntax highlighting wordfile would be better.
Note: The spaces between
" and
' must be replaced after copy and paste into a Sphinx.uew file by a horizontal tab character. Web browsers display and copy a horizontal tab character according to HTML specification as sequence of spaces.
Code: Select all
/L20"Sphinx" Nocase Block Comment On = ** Block Comment Off = ** Block Comment On Alt = `` Block Comment Off Alt = `` String Chars = *` EnableMLS EnableCFByIndent EnableSpellasYouType File Extensions = rst rsti
/Delimiters = ! " '*`._<>[]|"
/Function String = "%.. |^([a-z]+^)| "
/Function String 1 = "%.. _^([a-z]+^):"
/Function String 2 = "%.. `^([a-z]+^)`_"
/Open Brace Strings = "<" "["
/Close Brace Strings = ">" "]"
/Indent Strings = ":"
/Unindent Strings = "no_unindent"
/Marker Characters = "<>||_:"
/C1"Keywords" STYLE_KEYWORD
acks:: autoattribute:: autoclass:: autoexception:: autofunction:: automethod:: automodule:: autosummary::
c:function:: c:macro:: c:member:: c:type:: c:var:: centered:: class:: clsdir:: cmdoption:: code-block::
compound:: confval:: contents:: cpp:class:: cssclass:: currentmodule::
data:: deprecated:: describe::
envvar:: epigraph:: event:: exception::
figure:: funcdir:: function::
glossary::
highlight:: highlightlang:: highlights:: hlist::
image:: include:: index::
js:attribute:: js:data:: js:function::
literalinclude::
math:: meta:: method:: module:: moduleauthor::
note::
object:: only:: option::
parsed-literal:: productionlist:: program:: pull-quote:: py:function::
replace:: rst:directive:: rst:role:: rubric::
sectionauthor:: seealso:: sidebar:: sourcecode::
table:: tabularcolumns:: testcleanup:: title:: toctree:: todo:: todolist:: topic::
userdesc::
versionadded:: versionchanged::
/C2"Attributes" STYLE_ATTRIBUTE
:align: :alt: :figclass: :figwidth: :glob: :header: :height: :hidden: :maxdepth: :name: :numbered: :scale:
:subtitle: :target: :titlesonly: :width: :widths:
/C3"Styled Text"
<>
_:
||
/C4"Semantic Style"
:abbr: :any: :code: :command: :dfn: :doc: :download: :dudir :emphasis: :envvar: :file: :guilabel: :kbd:
:keyword: :literal: :mailheader: :makevar: :manpage: :math: :menuselection: :mimetype: :newsgroup:
:numref: :option: :pep-reference: :pep: :program: :raw: :ref: :regexp: :rfc-reference: :rfc: :samp:
:strong: :subscript: :superscript: :term: :title-reference: :token:
/C5"Admonitions"
:admonition: :attention: :caution: :danger: :error: :hint: :important: :note: :tip: :warning:
/C6"Operators" STYLE_OPERATOR
.
/C7"Interpreted Text"
`
The syntax for wordfiles does not specify any line comment. Therefore it is impossible to add comments into the wordfile itself. A wordfile like this one which needs additional information for users who want to use it should be compressed with ZIP together with a readme.txt into a ZIP file. The readme.txt file should contain the additional information, not the *.uew file itself.
Everything after
File Extensions = is interpreted as file extension string. Keywords for first line like
Noquote must be therefore specified always left to
File Extensions = or
File Names = if that is used instead.
The regular expressions are in UltraEdit syntax. Therefore
/Regexp Type = Perl is removed by me. I replace also
* by
+ after each
[a-z] as
* means
0 or more and
+ means
1 or more characters as defined in the character class. You surely want to see a string on each line in function list and not empty lines.
My
ultimate syntax highlighting tools package contains HTML file
TestForInvalid.htm which explains how the syntax highlighting engine of UE/UES works in detail. The delimiters break up the character stream of a text file into strings for being searched in the database created in memory according to the strings in used *.uew file. A human calls those strings "words". It depends on the language which characters are interpreted as delimiters and which one as "word" characters. The Unicode standard defines for the human languages which character belongs to which character group. There are the groups word character, punctuation mark, ... For syntax highlighting in UltraEdit there are only 2 character groups: delimiter or non delimiter. If it is suitable for Spinx / reStructured Text to put the colon to list of non delimiters for better highlighting, it is of course okay to do so.
I changed language name to just
Spinx. I suggest a short language name as it is displayed in status bar in a small field. Although it is possible to use a character like
/ in a language name, I prefer not making use of special characters not allowed for a file name in case of a syntax language based template file is created where language name becomes part of the file name. UltraEdit is forced to replace each character in a language name not allowed for a file name by an underscore. So usage of
/ is no problem for UE, but if it is easy possible to avoid it, such a character should be avoided.
Spinx syntax is based on Python syntax. But as far as I understood from the referenced page, reStructured Text files are not Python scripts. Therefore I suggest not to use language marker
PYTHON_LANG and use just
EnableCFByIndent if that makes sense for code folding.
If an indent string is specified, an unindent string should be also specified. Even if the specified unindent string never exists in a file, such a definition makes often nevertheless sense.
Syntax highlighting of UltraEdit is based on simple strings ("words"). Highlighting blocks is possible only with strings and block comments for multi-line blocks, and line comments and marker characters for single line blocks.
With the definitions above
- bold text is highlighted with the settings for comments;
- literal text is highlighted with the settings for alternate block comments;
- italic text is highlighted with the settings for strings (EnableMLS used for multi-line string highlighting);
- interpreted text is highlighted with the settings of color group 7.
Yes, it is possible to specify 2 characters for begin/end of strings and define different settings for one of the two string types by putting one of the 2 string characters into a color group.
The single-line strings between
<...
>,
|...
| and
_...
: are highlighted using the marker characters definition and color group 3.
And last as
. is a "word" delimiting character, defining
.. as "word" is invalid resulting in
.. never being highlighted with settings of color group 6. It is only possible to specify a single dot as "word".
The .htm files I did read and they were quite informative. That's ultimately how I discovered the need to remove : from the delimiters field otherwise the color groups using : in the keywords didn't function.