| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |/ / / / |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | | |
Numbered ones go up to 9, Perl ones may have 1p or 3pm suffixes.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | | |
Fixes https://github.com/pygments/pygments/issues/1040
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* Update asm lexer for --no-show-raw-insn
* Update asm lexer for #-style comments in Nasm
Co-authored-by: Pierre Wilke <pierre.wilke@centralesupelec.fr>
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
ABNF rulename can be 1 character wide
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Make the demo awesome
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
For large files it's better to have a viewport because
then you can view both the form as well as the part of
the output you are interested in at the same time.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* "Try out Pygments!" is more descriptive than "Try it out!"
* Moved the description of the implementation to the end.
* Added a <noscript> tag suggesting `pip install` and pygmentize.
* Added a <label> for the textarea.
* Disable spell checking for the textarea.
* Reduced the scope of the reset button to the file input.
* Added autofocus for the language select.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Use the modern navigator.clipboard API instead.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously highlighting a large file with a complex lexer just hung the
whole browser tab (meaning you couldn't interact with the page anymore).
This commit outsources the higlighting to another thread by using a web
worker. Depending on web workers shouldn't reduce browser compatability
since the page already depends on WASM (and according to caniuse.com any
browser that supports WASM also supports web workers).
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously the form could only be filled out after Pyodide finished
loading (since the <select> options were generated via Pyodide).
This commit changes this, so that the <select> options are already
in the static HTML. The "Loading Python..." form overlay is removed,
instead just the Highlight button is disabled, letting users fill
out the form while Pyodide is loading.
When a ?code query parameter is given a "Loading Python..." message
is displayed below the form, since in that case users probably want
to wait for the highlighted code (instead of filling out the form).
|
| | | | | | | |
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
(Atom, Vim, Alacritty, etc) using the same theme (#1979)
* Refine the One Dark a bit, for consistency with other projects using One Dark.
* Revert the unintentional change in Operator's bold style.
|
| |_|/ / /
|/| | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* lexers: add Elpi
* test: elpi
* Fix copyright
* address code review
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This includes a new structural diff which is more robust, as it handles
changes like different attribute order.
|
| |\ \ \ \ \
|/ / / / / /
| | | | | |
| | | | | | |
dschwoerer-master
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* 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".
|
|\ \ \ \ \ \ |
|
| | | | | | | |
|