-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overhaul code highlighting #278
base: master
Are you sure you want to change the base?
Conversation
@oae Do you have an auto branch protection rule in some way, if the branch isn't named |
The first option with pygments sounds good to me too |
I have changed some settings now. Can you try again? |
Same error, strange, it seems, that I can't push to any branch on this repo, but I could earlier this day 🤔 Edit: indeed, it is fixed ❤️ |
I think it should be fixed now |
3c71dc7
to
141b7d7
Compare
- use interface that permits multiple highlighters in the future
925b926
to
3001330
Compare
- fix many settings errors, so that they behave correctly - use setter of `sensitive` instead of `set_sensitive` - correctly connect settings and the core `_markdownDetector` of the extension - display code items as text items, if there is no code highlighter, or he is disabled
- change paths, that now require async routes in the code flow - add LoadingPanoItem, that shows up, before an item is loaded
…another way: make an not highlighted version of the code item, and after the highlighting returns, set the correct markdown - type metaData of all items explicitly with new TS wrapper methods to JSOn.parse and JSON.stringify
- always catch errors - add load status to PangoMarkdown
- add mor logger types and use them - add a slider(Gtk4.Scale) to set the relevance threshold for the highlighter - fix Promisified types - add some more inline comments about (not needed atm) not implemented features - chnage CodeItem handling of later initialization
…etector is loaded
…nous scanning - fix createDropdownRowForHighlighter, it had some errors in using some outer scope variables incorrectly
- fix scale issue, when resetting - fix small issue in panoItemFactor - refactor how teh style in codePanoItem is handled, it now also listens to text events and can mimic text style, only if it's set to code it display the code
… environment only)
… way to build it - add Pipenv, to install poetry, for the build step - change the directory, where it's locally installed (it's optional now) - set the PYTHONPATH nevertheless, since if it's not there, it doesn't matter, later we can offer the wheel for users to install globally, so that it's opt-in (we porblay can also publish it to pypi?
- change the PYTHONPATH location in the code
578ba28
to
28f7afe
Compare
…is intended like that)
- pygments styles, add more colors and bump version
- add more sophisticated scheduled job handling: now they can be cancelled, which is done at disabling and also, if we disable the code highlighter, so that no unnecessary tasks are run
2d3b82d
to
ed68ae5
Compare
…hlighter gets it's options at the start from teh settings - add SpinRow for the Highlighter settings - add relevanceLength setting to pygments, taht replaces a hardcoded value
- completely reinstall the dependencies, to get newer sub-dependencies
Not really experienced with anything gnome, but was wondering if this would be a viable and much cleaner solution. It could be an optional lib install and also has bindings for js. Or it could be required and could be used as a default text view?(think it might be preinstalled with gnome, not too sure) I am just throwing out an idea, never really worked with anything remotely close to this. |
I think I saw this in my research, but It isn't half as good as pygments in autodetecting languages and it's ballpark is nearly the same as source-highlight. It has integrated GTK support, but it's not themeable (at least easily) and it has no "real" autodetection feature, you have to create a widget to get the language, which is not suitable for our purpose 😓 |
a844754
to
26dbcd6
Compare
Overhaul code highlighting
Description
As described in #271 code highlighting should become optional, so that user need to install an additional package or something similar to make it work.
There are a few options, I'll test all of them and list benefits from them and shortcomings
Overview
We need an option that can do these things:
Our options are:
1. Option
Pros:
Cons:
Feature Table
Notes
source-highlight
:It can not detect languages without filename or shebang, it also can't tell you, how confident it was (there is a option to infer the language, but it only works on file extensions / shebangs or similar metadata)
It can't output to markdown, but to simple html, which would be styleable in some way
You can specify custom css or similar things, but it's not that easy, but maybe doable.
pygments
(python3-pygments)It is good at detecting creating languages (like python) but when I tried JS, or HTML or some other ones it failed ... i didn't test 100 files, but it wasn't that good, the one good thing was, that it's better than highlight.js in many cases and the detected languages all seem to look similar, when highlighted.
It has support for many many languages, it is easy styleable and can output pango markdown out of the box.
update: after some modification to the detection logic, it seems really stable and robust when working with more than ~ +- 200 characters. The shortcoming of it is, that it has no real relevance value, but we can emulate that, by using that charaacter length. After that it is really good.
2. Option
Pros:
Cons:
3. Option
Pros:
Cons:
Current state
I would focus on option 1, since it's the best choice atm. I tested
source-highlight
but it's quite bad. So I'll be usingpygments
(python3-pygments) for now.TODOs:
optional:
Type of change
Checklist