Support for different programming and text processing languages is still under construction. In general, these have a notion of string and literals such as "this is a string"
by using double quotes, similar to C.
Single quotes for character constants are not generalized to other languages, because they would conflict with the the ' character's common use as apostrophe.
Source files with the following extensions are interpreted as files of type empty:
.dirs .txt .text
Even if the source and target language is not given (or not recognized) eĿlipsis can directly be used as a macro preprocessor by providing macro values on the command line
this allows a basic level of configuration, for example, or an access to external information such as the time (using __TIME__
) or similar builtin and predefined macros, see ellipsis-builtins.dirs and ellipsis-predefined.dirs.
You may also use the character ⎔ (codepoint 0x2394, Software-Function Symbol) at the start of a line, much as you would use #
in C to start a line with a directive. Examples
This would produce something like the following, but probably with more empty lines than are shown here:
This syntax works in all languages and allows to include macro packages that are independent of the target language, see for example the include directory.
Note that this approach is line oriented and may not be properly adapted for languages where new lines have not much of a significance, see below.
If you'd like to avoid too many empty lines appearing in the output you might collect all directives in a file (using e.g the extension .dirs) and then just include this file
Other than #include, this would throw away all produced output lines. On the other hand, this still defines all macros that have definitions, there. Only one empty line, for the #include_directives directive remains in the output.
In general, C's include syntax with <
and >
will not be supported for other languages; these characters may have different syntactic properties. Instead, we use left- and right-pointing angle brackets as in
Since the #
character has a special meaning in some languages that we want to handle, we cannot use it for the special operators in macro definitions, either. We use ⌗
(VIEWDATA SQUARE, ⌗
) for stringification, and ⨝
(JOIN, ⫑
) for token concatenation.
defines the macro PAIR
suitable for all languages. The corresponding C-only definition would be
Source files with the following extensions are interpreted as files of type c:
.c .h
The support for the preprocessing part of the C language should be quite complete, including comment syntax and string and character literals.
eĿlipsis may be used for C in two different flawors:
As a replacement for the preprocessing phase of an existing C compiler. Note that this needs knowledge about the target architecture and the target compiler. For the latter, we have in particular to know about support for attributes, such that we can implement the ::__has_c_attribute feature test correctly. The data that is needed for that can entirely be provided by predefined macros. The subdirectory "c" already contains a bunch of such header files with the necessary definitions for gcc and clang, and the Makefile there can be used to produce files for new versions of these.
Source files with the following extensions are interpreted as files of type lex:
.l
Lex has no preprocessor that would already be defined. Our current implementation only adds two features
%
:
token instead of #
to introduce the directive at the start of the line.Everything that is not directive or comment is just passed through
Source files with the following extensions are interpreted as files of type html:
.htm .html
Support for html is rudimentary.
<!--
and -->
as usual.<!--#
and -->
markers. So here directives are not line oriented but just constructs that appear in the usual flow of text.Source files with the following extensions are interpreted as files of type markdown:
.md
eĿlipsis is quite usable already to be used as a filter for pandoc. In my makefiles I have something similar to the following rule:
I use this regularly to include some basic configuration such as document numbers and other macros.
This can afterwards be use as the following
Which results in the a table and links as follows
document number | date | comment |
---|---|---|
n3190 | 202406 | this paper, original proposal |
Builtins and predefined macros are documented in the following source files: ellipsis-builtins.dirs and ellipsis-predefined.dirs.
This is also partially used for the documentation here. This documentation is written for doxygen, which supports a markdown dialect that has some rough edges. Nevertheless, the collection of information from different parts of the project (such as on this page for the different languages) seems to work quite well.
Markdown inherits comments and directives from html. Html comments are already commonly used for markdown, so this seemed the easiest way to establish these features, here.
In addition to that, we support code snippets within the flow of text with backticks as in "`func(34)`". Per default, these are supposed to be code snippets written in the C programming language. This language can be overwritten:
{}
construct (does not work for doxygen!)-DSOMETHING={.fortran}
Additionally, features that are introduced in markdown starting at the beginning of a new line are also supported:
#
, ##
…>
, >>
, …-
, +
, and *