aumerle

19 ms·

151.
by aumerle 8y ago
Rendering images using unicode block symbols does not make them text, it just makes them pixelated. And you can always down sample images to reduce the bandwidth cost and still get a much better rendering than you achieve currently. For exa
152.
by aumerle 8y ago
You might want to consider adding support for displaying proper terminal graphics, instead of using pixelated ones (which I assume are done using unicode block drawing symbols?). See https://sw.kovidgoyal.net/kitty/grap
153.
by aumerle 8y ago
See https://sw.kovidgoyal.net/kitty/graphics-protocol.html for a much more comprehensive terminal graphics protocol
154.
Show HN: Side-by-side diff in the terminal with images and syntax highlighting(github.com)
3 points by aumerle 8y ago|0 comments
155.
by aumerle 8y ago
Links are already supported in many terminals, see https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3c... and are actually used by the ls program, ls --hyperlinks The overhead of an HTML DOM vs the typical cel
156.
by aumerle 8y ago
The only difference between "rich text" and what you can do in a terminal is changing font families/sizes. And that is not even close to useful enough to justify runnig a terminal on top of a browser. As for familiar HTML, it
157.
by aumerle 8y ago
All these features are already possible in modern terminals. 1) True color support 2) Bold and italic fonts 3) Emojis, Ligatures, unicode in general 4) copy/paste across SSH 5) the ability to split windows into tmux like panes and sen
158.
by aumerle 8y ago
That's because alacritty claim's are pure bullshit: https://github.com/jwilm/alacritty/issues/289
159.
by aumerle 8y ago
Simply remap Ctrl+Enter to send some other key combination and bind that in zsh. You can do the remapping either in X or using the terminals native remapping features many terminals have them, for instance kitty.
160.
by aumerle 9y ago
http://html5-parser.readthedocs.io/en/latest/#html5_parser.p...
161.
by aumerle 9y ago
https://github.com/kovidgoyal/html5-parser
162.
Kitty v0.4 terminal emulator adds graphics support(github.com)
2 points by aumerle 9y ago|0 comments
163.
by aumerle 9y ago
https://github.com/kovidgoyal/kitty and as for moving the state of terminals forward: https://github.com/kovidgoyal/kitty/blob/master/protocol-ext...
164.
by aumerle 9y ago
calibre has been able to convert arbitrary HTML files to PDF with Table of Contents with page numbers, links, embedded fonts, arbitrary headers/footers for years, all rendered using WebKit, without a running X server, for years. ebook-
165.
by aumerle 9y ago
Simply pass the argument treebuilder='soup' to the parse function. But note that you wont get as much of a performance boost, because the besutifulsoup tree has to be built in python, not C.
166.
by aumerle 9y ago
Yeah, I have to deal with what we have in the real world, not in spec land. Yielding blank documents on a <title/> just isn't going to cut it :)
167.
by aumerle 9y ago
You do know that by default bs4 uses lxml.html to do its parsing, which is also a big blob of C, right? For example, running the following: BeautifulSoup('<p>a')
168.
by aumerle 9y ago
-Werror is used only when building on the continuous integration servers, not in the released code. That way, you get the best of both worlds. Your code wont break on new compiler releases, but it also wont have neglected warnings.
169.
by aumerle 9y ago
This has a hard dependency on libxml2. If your language of choice has a libxml2 based tree, it can be ported to that. Basically your language needs an equivalent of lxml
170.
by aumerle 9y ago
I use this pattern a lot. For example, in https://github.com/kovidgoyal/kitty where the UI layer is in python and the performance critical code is in C. I find this pattern gives me an optimum in performance + maintain
171.
by aumerle 9y ago
Yes, since I wrote html5-parser for use in calibre (i.e. to parse the HTML in e-books), sigil-gumbo is a more appropriate upstream for me. I have no objectsion to merging in changes from gumbo-parser that are not in sigil-gumbo over time, b
172.
by aumerle 9y ago
https://html5-parser.readthedocs.io/en/latest/#benchmarks
173.
by aumerle 9y ago
Indeed, I developed html5-parser to eventually replace html5lib in calibre
174.
by aumerle 9y ago
@nostrademons: Thank you for gumbo, which is an excellent project.
175.
by aumerle 9y ago
I encounter self closed <title> tags in malformed XHTML files all the time. In fact I encounter them so often, I used to use a dedicated sanitization pass before passing int he html to html5lib, for that reason alone.
176.
by aumerle 9y ago
I have not tested it, but it is probably slower. The advantage of this is that is follows the HTML 5 parsing spec, so it gives you the same results as a browser when parsing malformed HTML
177.
by aumerle 9y ago
:) Try parsing the following snippet using HTML 5 parsing algorithm and see what you get: <html><head><title /></head><body><p>foo
178.
by aumerle 9y ago
Yes, the lack of maintenance of gumbo-parser was another reason I decided to include a private copy. You are welcome to make your PR against html5-parser's copy of gumbo-parser, and I will review it.
179.
by aumerle 9y ago
Because it uses a modified version of gumbo to support parsing not-well formed XHTML as well
180.
by aumerle 9y ago
As permissive as html5lib, which is as permissive as a modern browser, since both are base don the HTML 5 parsing spec.

More ›