| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past, Chawan would read global mailcap (/etc/mailcap, ...) too,
but every now and then that would run entries that I didn't even know
existed and definitely didn't intend to run. So I changed it to only
use ~/.mailcap, but this meant users now had to add mailcap entries for
every single mime type.
At some point I also changed application/octet-stream to always save to
disk, which is usually nice except when a text file is misrecognized as
binary. Often times I just want to decide myself what to do.
So now there are two layers. First, the global mailcap files (path as
per RFC) prompt before executing. Then there is ~/.chawan/auto.mailcap
(or ~/.config/chawan/auto.mailcap) which runs entries automatically.
If you press shift before selecting an option in the prompt, the
corresponding entry gets copied to auto.mailcap. It's also possible to
type a new entry on the fly. Overall I think it's quite convenient.
One unfortunate side effect is that existing users will have to migrate
their entries to auto.mailcap, or redefine external.auto-mailcap to e.g.
~/.mailcap, but this seems acceptable.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
isearch feels quite janky in general, and I think there's still a race
lurking here... for now it's ok, but like buffer display, this really
belongs in a state machine (not promises)
|
|
|
|
| |
We can do this now that xminwidth is more accurate.
|
|
|
|
| |
better
|
|
|
|
| |
still not quite right, but it's slowly taking shape
|
|
|
|
|
|
|
|
| |
not completely, because that would break the existing API :/
this also fixes the broken interruptHandler - it no longer crashes,
but it's still inefficient... probably it should "just" handle SIGINT
instead
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It gets copied once anyway, so just use a blob.
I guess I could skip the copy with some effort, but the 4 lines
implementation is too attractive :P
This is still an improvement, as it doesn't needlessly zero-fill the
buffer on realloc.
(I've also removed the final realloc from blob, as it seemed quite
pointless. Using Content-Length could help... except it doesn't,
because it refers to the encoded length. Ugh.)
|
|
|
|
| |
yeah idk
|
|
|
|
| |
another case of "the object model was unnecessarily complex"
|
| |
|
|
|
|
|
| |
Seems more compatible with websites that use smaller fonts + padding
for styled code tags.
|
|
|
|
| |
ctx can be HTML even if we take `this'
|
|
|
|
| |
In my defense, it was broken in the spec too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So I thought this was just a simple z-ordering issue, but silly me,
it's never simple with images. In this case it turns out Kitty can't
really do z-ordering with text the way Sixel can - in short, you must
pick if the image is below text, or above text, but never both.
I imagine you could also get something to work with z=-1 and stretched
1-pixel colored images or some similarly horrifying hack. It seems very
annoying to code and maintain, so I won't.
(In some way this is impressive, because Sixel z-ordering sucks too.
Somehow we got into a situation where both viable image display
protocols are incapable of expressing some useful ways of image
layering, of course in a mutually incompatible way.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unconditionally registering output handles on resume could result in a
failed assertion on double-register.
The bug would appear like:
resume (register) -> handleRead -> pushBuffer -> currentBuffer is nil ->
register again
handleWrite had a very high likelihood of occurring between resume and
handleRead, and that hid the bug by immediately unregistering the handle
after resume. In fact, I haven't been able to reproduce the bug at all
today, and only found it after poring over the source...
Fix this by not registering output handles that are empty (except
if the istream is already finished, in which case it will just be
unregistered).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* use PosixStream/mmap for mailcap reading too; this finally lets us get
rid of std/streams in the entire codebase
* split up recvDataLoopOrMmap into 3 functions: one that can fall back
to recvAll, one that falls back to recvDataLoop, and one that does not
fall back to anything
* use MAP_PRIVATE in mmap for read (we don't care if changes are
propagated, as we do no changes to cached files)
|
|
|
|
|
|
|
|
|
|
|
|
| |
* remove std/streams use from mime.types; mmap and parse directly
* use mime.types for inline image extensions
* add some jpeg file extensions
Latter came up because I was trying to add a format locally and it
wouldn't recognize it on images from my file system (i.e. by extension).
As a security measure we still do not allow additional extensions for
predefined inline image types.
|
|
|
|
| |
it's unambiguous anyway
|
|
|
|
|
| |
* fall back to recvAll on ilen = -1
* handle zero-length files
|
| |
|
|
|
|
|
|
|
|
| |
Gets rid of rounding errors when positioning images.
Theoretically this is possible with Sixel too, but as always, it's
ten times as difficult to implement as with Kitty, so I'll leave it
for later.
|
| |
|
|
|
|
|
|
|
|
| |
Roughly halves the object's size, and gets rid of a large number of
allocations.
It could be compressed further into a bitmap, but I'm not sure if it's
worth the complexity.
|
|
|
|
|
|
|
| |
one std/streams less
I used mmap for reading the user config. It shouldn't matter in any
realistically sized config, but who knows.
|
|
|
|
|
|
| |
so for max-width it's called "none", but for min-width it's "auto".
why :(
|
|
|
|
|
|
|
|
|
|
|
|
| |
ugly, but better than the status quo.
the core issue is that width, min-width should clamp xminwidth too, but
it doesn't. this hadn't been an issue until recently, but since I made
<pre> stretch out xminwidth too it had the unfortunate result that you
now have to scroll on pages that nest pre in a flex.
this still isn't a proper fix, in particular it won't work if min-width
is set to 0, but on the sites I tried it happens to work anyway.
|
| |
|
| |
|
|
|
|
| |
ref. https://todo.sr.ht/~bptato/chawan/29
|
| |
|
| |
|
|
|
|
|
| |
no idea what that reconsume was doing there; probably a refactoring
mistake
|
| |
|
|
|
|
| |
only the most basic form; no media queries yet
|
|
|
|
| |
whoops
|
|
|
|
|
|
|
| |
with buffer.images enabled, we already cache them, so we can skip the
additional request
also, add saveImage, bound to sI
|
|
|
|
| |
They are UA style.
|
|
|
|
|
|
|
|
| |
Probably a remnant from back when startOffset meant (and was used for)
something different.
Interestingly, there was already a test case for this, but it was also
wrong.
|
|
|
|
|
| |
This couldn't get into system.nim for technical reasons, but it's still
pretty useful when iterating over non-mutable openArrays.
|
| |
|
|
|
|
| |
it's author style too
|
|
|
|
|
|
|
| |
Useful when an x-htmloutput handler needs styling for the HTML output to
be formatted correctly (as a sort of pseudo-ua style sheet).
ref. https://todo.sr.ht/~bptato/chawan/28
|