| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Uses an additional lower-case map for O(1) case-insensitive comparisons.
|
|
|
|
|
| |
now I sort of understand how it works. basically maxh and maxw represent
the inner area occupied by the widget at any time.
|
|
|
|
|
|
|
|
| |
* correct action on M-b
* add external.bookmark option
* move openFileExpand functionality into unquote
* add menu items
* update docs
|
|
|
|
|
|
|
|
| |
Both are quite useful.
readFile and writeFile got a small makeover in error handling; in
particular, readFile now returns null instead of the empty string when
the file is missing and writeFile throws a TypeError on I/O errors.
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented using proprietary selectors -cha-first-node and
-cha-last-node, modeled after -moz-first-node and -moz-last-node.
I think they are compatible.
That does mean this is more limited than w3m's trimming, e.g. it can't
really deal with nesting or empty tags. I think this is fine, as it's
mainly meant for unstyled documents in the first place (which are
unlikely to have e.g. MAIN tags).
|
| |
|
|
|
|
| |
file:/// is the standard serialization.
|
|
|
|
|
|
|
|
| |
Cookie jar separation is already enough to mitigate tracking issues
in this case. (Also, the fact that third-party-cookie controlled this
made things even more confusing.)
Also, add the previously missing host-only flag.
|
|
|
|
|
|
|
|
| |
Not quite sure why I had assumed that this is broken. At least on XTerm,
the previous behavior definitely was, e.g. with a white-ish background
and white foreground it would end up correcting the contrast to purple
even with black CSS color (thus breaking the "no fgcolor with bgcolor"
assumption anyway.)
|
| |
|
|
|
|
|
|
|
| |
Instead, just define the actual value over the getter function on the
first use.
Also, avoid accidentally creating the attributes NamedNodeMap on adopt.
|
|
|
|
|
|
| |
using div instead of / is sort of weird, but it makes it clearer if
we're dividing floats or layoutunits (and is already what the code
uses).
|
| |
|
|
|
|
| |
I no longer need it
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* fix broken newline skipping logic in consume
* remove reconsume char buffer (it's not needed with mmap)
* pass on backslash to unquote - this makes backslashes in
unquoteCommand work as expected (since it parses the command again)
* close ps on write failure
* add entries even before parse error - this drops a pointless copy of
mailcaps. (we could theoretically just use old behavior without the
copy, but this feels more intuitive anyway)
|
|
|
|
|
| |
"Computed" was redundant; other types of values don't have a common
type.
|
|
|
|
| |
we hadn't before, and it's annoying when using cha as a pager
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|