Implement Markdown definition lists (+ migration) (#20333)
Implements definition lists Markdown extension adopted in a few implementations including: * [Pandoc]( https://pandoc.org/MANUAL.html#definition-lists) * [kramdown]( https://kramdown.gettalong.org/quickref.html#definition-lists) * [PHP extra Markdown]( https://michelf.ca/projects/php-markdown/extra/#def-list) Also affected files have been migrated. RST definition lists are turned off for Markdown: this solves the problem of broken formatting mentioned in https://github.com/nim-lang/Nim/pull/20292.
This commit is contained in:
parent
846cc746a2
commit
088487f652
15 changed files with 266 additions and 97 deletions
|
|
@ -72,10 +72,10 @@ The replace filter replaces substrings in each line.
|
|||
Parameters and their defaults:
|
||||
|
||||
* `sub: string = ""`
|
||||
the substring that is searched for
|
||||
: the substring that is searched for
|
||||
|
||||
* `by: string = ""`
|
||||
the string the substring is replaced with
|
||||
: the string the substring is replaced with
|
||||
|
||||
|
||||
Strip filter
|
||||
|
|
@ -87,14 +87,14 @@ each line.
|
|||
Parameters and their defaults:
|
||||
|
||||
* `startswith: string = ""`
|
||||
strip only the lines that start with *startswith* (ignoring leading
|
||||
: strip only the lines that start with *startswith* (ignoring leading
|
||||
whitespace). If empty every line is stripped.
|
||||
|
||||
* `leading: bool = true`
|
||||
strip leading whitespace
|
||||
: strip leading whitespace
|
||||
|
||||
* `trailing: bool = true`
|
||||
strip trailing whitespace
|
||||
: strip trailing whitespace
|
||||
|
||||
|
||||
StdTmpl filter
|
||||
|
|
@ -109,19 +109,19 @@ statements need `end X` delimiters.
|
|||
Parameters and their defaults:
|
||||
|
||||
* `metaChar: char = '#'`
|
||||
prefix for a line that contains Nim code
|
||||
: prefix for a line that contains Nim code
|
||||
|
||||
* `subsChar: char = '$'`
|
||||
prefix for a Nim expression within a template line
|
||||
: prefix for a Nim expression within a template line
|
||||
|
||||
* `conc: string = " & "`
|
||||
the operation for concatenation
|
||||
: the operation for concatenation
|
||||
|
||||
* `emit: string = "result.add"`
|
||||
the operation to emit a string literal
|
||||
: the operation to emit a string literal
|
||||
|
||||
* `toString: string = "$"`
|
||||
the operation that is applied to each expression
|
||||
: the operation that is applied to each expression
|
||||
|
||||
Example::
|
||||
|
||||
|
|
|
|||
|
|
@ -45,30 +45,30 @@ Or::
|
|||
nim idetools --trackDirty:DIRTY_FILE,FILE,LINE,COL <switches> proj.nim
|
||||
|
||||
`proj.nim`
|
||||
This is the main *project* filename. Most of the time you will
|
||||
: This is the main *project* filename. Most of the time you will
|
||||
pass in the same as **FILE**, but for bigger projects this is
|
||||
the file which is used as main entry point for the program, the
|
||||
one which users compile to generate a final binary.
|
||||
|
||||
`<switches>`
|
||||
This would be any of the other idetools available options, like
|
||||
: This would be any of the other idetools available options, like
|
||||
`--def` or `--suggest` explained in the following sections.
|
||||
|
||||
`COL`
|
||||
An integer with the column you are going to query. For the
|
||||
: An integer with the column you are going to query. For the
|
||||
compiler columns start at zero, so the first column will be
|
||||
**0** and the last in an 80 column terminal will be **79**.
|
||||
|
||||
`LINE`
|
||||
An integer with the line you are going to query. For the compiler
|
||||
: An integer with the line you are going to query. For the compiler
|
||||
lines start at **1**.
|
||||
|
||||
`FILE`
|
||||
The file you want to perform the query on. Usually you will
|
||||
: The file you want to perform the query on. Usually you will
|
||||
pass in the same value as **proj.nim**.
|
||||
|
||||
`DIRTY_FILE`
|
||||
The **FILE** parameter is enough for static analysis, but IDEs
|
||||
: The **FILE** parameter is enough for static analysis, but IDEs
|
||||
tend to have *unsaved buffers* where the user may still be in
|
||||
the middle of typing a line. In such situations the IDE can
|
||||
save the current contents to a temporary file and then use the
|
||||
|
|
|
|||
|
|
@ -398,11 +398,11 @@ Runtime type information
|
|||
programming language:
|
||||
|
||||
Garbage collection
|
||||
The old GCs use the RTTI for traversing arbitrary Nim types, but usually
|
||||
: The old GCs use the RTTI for traversing arbitrary Nim types, but usually
|
||||
only the `marker` field which contains a proc that does the traversal.
|
||||
|
||||
Complex assignments
|
||||
Sequences and strings are implemented as
|
||||
: Sequences and strings are implemented as
|
||||
pointers to resizable buffers, but Nim requires copying for
|
||||
assignments. Apart from RTTI the compiler also generates copy procedures
|
||||
as a specialization.
|
||||
|
|
|
|||
|
|
@ -1023,24 +1023,24 @@ Pre-defined integer types
|
|||
These integer types are pre-defined:
|
||||
|
||||
`int`
|
||||
the generic signed integer type; its size is platform-dependent and has the
|
||||
: the generic signed integer type; its size is platform-dependent and has the
|
||||
same size as a pointer. This type should be used in general. An integer
|
||||
literal that has no type suffix is of this type if it is in the range
|
||||
`low(int32)..high(int32)` otherwise the literal's type is `int64`.
|
||||
|
||||
`int`\ XX
|
||||
additional signed integer types of XX bits use this naming scheme
|
||||
: additional signed integer types of XX bits use this naming scheme
|
||||
(example: int16 is a 16-bit wide integer).
|
||||
The current implementation supports `int8`, `int16`, `int32`, `int64`.
|
||||
Literals of these types have the suffix 'iXX.
|
||||
|
||||
`uint`
|
||||
the generic `unsigned integer`:idx: type; its size is platform-dependent and
|
||||
: the generic `unsigned integer`:idx: type; its size is platform-dependent and
|
||||
has the same size as a pointer. An integer literal with the type
|
||||
suffix `'u` is of this type.
|
||||
|
||||
`uint`\ XX
|
||||
additional unsigned integer types of XX bits use this naming scheme
|
||||
: additional unsigned integer types of XX bits use this naming scheme
|
||||
(example: uint16 is a 16-bit wide unsigned integer).
|
||||
The current implementation supports `uint8`, `uint16`, `uint32`,
|
||||
`uint64`. Literals of these types have the suffix 'uXX.
|
||||
|
|
@ -1135,12 +1135,12 @@ Pre-defined floating-point types
|
|||
The following floating-point types are pre-defined:
|
||||
|
||||
`float`
|
||||
the generic floating-point type; its size used to be platform-dependent,
|
||||
: the generic floating-point type; its size used to be platform-dependent,
|
||||
but now it is always mapped to `float64`.
|
||||
This type should be used in general.
|
||||
|
||||
`float`\ XX
|
||||
an implementation may define additional floating-point types of XX bits using
|
||||
: an implementation may define additional floating-point types of XX bits using
|
||||
this naming scheme (example: `float64` is a 64-bit wide float). The current
|
||||
implementation supports `float32` and `float64`. Literals of these types
|
||||
have the suffix 'fXX.
|
||||
|
|
@ -2092,52 +2092,52 @@ that expects a proc of the calling convention `closure`.
|
|||
Nim supports these `calling conventions`:idx:\:
|
||||
|
||||
`nimcall`:idx:
|
||||
is the default convention used for a Nim **proc**. It is the
|
||||
: is the default convention used for a Nim **proc**. It is the
|
||||
same as `fastcall`, but only for C compilers that support `fastcall`.
|
||||
|
||||
`closure`:idx:
|
||||
is the default calling convention for a **procedural type** that lacks
|
||||
: is the default calling convention for a **procedural type** that lacks
|
||||
any pragma annotations. It indicates that the procedure has a hidden
|
||||
implicit parameter (an *environment*). Proc vars that have the calling
|
||||
convention `closure` take up two machine words: One for the proc pointer
|
||||
and another one for the pointer to implicitly passed environment.
|
||||
|
||||
`stdcall`:idx:
|
||||
This is the stdcall convention as specified by Microsoft. The generated C
|
||||
: This is the stdcall convention as specified by Microsoft. The generated C
|
||||
procedure is declared with the `__stdcall` keyword.
|
||||
|
||||
`cdecl`:idx:
|
||||
The cdecl convention means that a procedure shall use the same convention
|
||||
: The cdecl convention means that a procedure shall use the same convention
|
||||
as the C compiler. Under Windows the generated C procedure is declared with
|
||||
the `__cdecl` keyword.
|
||||
|
||||
`safecall`:idx:
|
||||
This is the safecall convention as specified by Microsoft. The generated C
|
||||
: This is the safecall convention as specified by Microsoft. The generated C
|
||||
procedure is declared with the `__safecall` keyword. The word *safe*
|
||||
refers to the fact that all hardware registers shall be pushed to the
|
||||
hardware stack.
|
||||
|
||||
`inline`:idx:
|
||||
The inline convention means the caller should not call the procedure,
|
||||
: The inline convention means the caller should not call the procedure,
|
||||
but inline its code directly. Note that Nim does not inline, but leaves
|
||||
this to the C compiler; it generates `__inline` procedures. This is
|
||||
only a hint for the compiler: it may completely ignore it, and
|
||||
it may inline procedures that are not marked as `inline`.
|
||||
|
||||
`fastcall`:idx:
|
||||
Fastcall means different things to different C compilers. One gets whatever
|
||||
: Fastcall means different things to different C compilers. One gets whatever
|
||||
the C `__fastcall` means.
|
||||
|
||||
`thiscall`:idx:
|
||||
This is the thiscall calling convention as specified by Microsoft, used on
|
||||
: This is the thiscall calling convention as specified by Microsoft, used on
|
||||
C++ class member functions on the x86 architecture.
|
||||
|
||||
`syscall`:idx:
|
||||
The syscall convention is the same as `__syscall`:c: in C. It is used for
|
||||
: The syscall convention is the same as `__syscall`:c: in C. It is used for
|
||||
interrupts.
|
||||
|
||||
`noconv`:idx:
|
||||
The generated C code will not have any explicit calling convention and thus
|
||||
: The generated C code will not have any explicit calling convention and thus
|
||||
use the C compiler's default calling convention. This is needed because
|
||||
Nim's default calling convention for procedures is `fastcall` to
|
||||
improve speed.
|
||||
|
|
|
|||
|
|
@ -63,10 +63,10 @@ a location. A query location consists of:
|
|||
|
||||
|
||||
``file.nim``
|
||||
This is the name of the module or include file the query refers to.
|
||||
: This is the name of the module or include file the query refers to.
|
||||
|
||||
``dirtyfile.nim``
|
||||
This is optional.
|
||||
: This is optional.
|
||||
|
||||
The `file` parameter is enough for static analysis, but IDEs
|
||||
tend to have *unsaved buffers* where the user may still be in
|
||||
|
|
@ -77,11 +77,11 @@ a location. A query location consists of:
|
|||
|
||||
|
||||
``line``
|
||||
An integer with the line you are going to query. For the compiler
|
||||
: An integer with the line you are going to query. For the compiler
|
||||
lines start at **1**.
|
||||
|
||||
``col``
|
||||
An integer with the column you are going to query. For the
|
||||
: An integer with the column you are going to query. For the
|
||||
compiler columns start at **0**.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue