| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This commit adds a new url field to a lexer, which can be used to link
to the language website, instead of relying on having the link in either
languages.rst or the docstring of the lexer. Additionally, it changes the
languages.rst file to auto-generate the list of lexers from the actual
source code, using the provided URL.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* NF: adding an example of use of simple filter
@simplefilter is great, but also not very intuitive. Indeeds, the syntax seems
to indicate that you define a function with four arguments while in reality you
define a class whose constructor takes arbitrary keyword arguments. I believe in
this case an example to show how to instantiate this filter is really necessary.
Regarding simplefilter, I also believe that it could be improved in two simple
ways:
* accepting any method which takes lexer and stream as a filter. That would be
sufficient as long as there is no option
* the @simplefilter decorator could deal with `self` so that the user do not
have to add it themselves. Probably not worth doing it no, as it would break
compatibility with current version, but would be even simpler to use
* NF: clarifying get_..._options
get_bool_opt's documentation seems to indicate that the key is interpreted as a
Boolean. While a quick look at the code shows clearly that the value associated
to the key is what is interpreted as a Boolean. I hope I made the code clearer
to any people who know python by indicating that it is essentially `.get` but
with extra features
* NF: clarifying Filter
`filter` has already a specific behavior in general python, or for any people
used to functional programing (and even if some dom processor). So indicating
that a filter is not something that remove some tokens seems really useful to
try to explain what is going on.
* NF: adding details regarding states in lexer
I found the state explanation confusing. I do know what a state machine
is. However, reading the code, I first thought that there were two distinct
variables:
* the current state
* the stack
that are somehow related but distinct. Explaining that the current state is the
top of the stack was lacking in my opinion. That also help explain #push. In
particular that if you define in state "s" an operation whose new state is
"#push", the behavior can be quite different than if the new state was "s".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pyupgrade is a tool to automatically upgrade syntax for newer versions
of the Python language.
The project has been Python 3 only since
35544e2fc6eed0ce4a27ec7285aac71ff0ddc473, allowing for several cleanups:
- Remove unnecessary "-*- coding: utf-8 -*-" cookie. Python 3 reads all
source files as utf-8 by default.
- Replace IOError/EnvironmentError with OSError. Python 3 unified these
exceptions. The old names are aliases only.
- Use the Python 3 shorter super() syntax.
- Remove "utf8" argument form encode/decode. In Python 3, this value is
the default.
- Remove "r" from open() calls. In Python 3, this value is the default.
- Remove u prefix from Unicode strings. In Python 3, all strings are
Unicode.
- Replace io.open() with builtin open(). In Python 3, these functions
are functionally equivalent.
Co-authored-by: Matthäus G. Chajdas <Anteru@users.noreply.github.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* all: remove "u" string prefix
* util: remove unirange
Since Python 3.3, all builds are wide unicode compatible.
* unistring: remove support for narrow-unicode builds
which stopped being relevant with Python 3.3
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Remove Python 2 compatibility
* remove 2/3 shims in pygments.util
* update setup.py metadata
* Remove unneeded object inheritance.
* Remove unneeded future imports.
|
| | |
|
| |
|
|
| |
fixes #1506
|
| | |
|
|
|
This introduces support for some missing features to the Handlebars lexer:
Partials and path segments. Partials mostly appeared to work before, but the
`>` in `{{> ... }}` would appear as a syntax error, as could other
components of the partial. This change introduces support for:
* Standard partials: `{{> partialName}}`
* Partials with parameters: `{{> partialName varname="value"}}`
* Ddynamic partials: `{{> (partialFunc)}}`
* Ddynamic partials with lookups: `{{> (lookup ../path "partialName")}}`
* Partial blocks: `{{> @partial-block}}`
* Inline partials: `{{#*inline}}..{{/inline}}`
It also introduces support for path segments, which can reference content in
the current context or in a parent context. For instance, `this.name`,
`this/name`, `./name`, `../name`, `this/name`, etc. These are all now tracked
as variables.
|
