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:
Andrey Makarov 2022-09-11 20:52:43 +03:00 • committed by GitHub
commit 088487f652
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
15 changed files with 266 additions and 97 deletions

View file

@ -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::

View file

@ -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

View file

@ -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.

View file

@ -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.

View file

@ -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**.