| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
* skip whitespace in some places where we didn't but should
* fix crash in get_tok when eof comes after whitespace
|
| |
|
|
|
|
|
|
| |
so that e.g.
a<span style="background-color: red"> </span>b
makes the span width exactly one space.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> The right outer edge of a left-floating box may not be to the right
> of the left outer edge of any right-floating box that is next to
> it. Analogous rules hold for right-floating elements.
says the standard
therefore it does not really matter where the beginning of the float is;
if it's float: left, then `left' must be set to the right edge, and if
it's float: right, then `right' must be set to the left edge.
(this was breaking some negative margin float abominations such that
floats were suddenly overlapping and that's certainly not what we want)
|
| |
|
|
| |
it's a good idea to use the return value, but it must substitute atEnd.
|
| |
|
|
|
|
|
| |
buffering output kind of defeats the purpose of the entire loader select
machinery
(we don't buffer streams either for the same reason)
|
| |
|
|
|
| |
slightly more efficient, but more importantly does not choke on NUL and
weird \r\n
|
| | |
|
| |
|
|
| |
this is more or less how it works in w3m
|
| |
|
|
|
|
| |
setCursorX only moves the screen backwards if the intended X position is
lower than the actual X position. Pass it -1 so that this is true even
with zero-width lines.
|
| |
|
|
|
|
|
|
| |
left/right never really worked correctly, is non-standard, and the
only browser that supported it (Firefox) removed it years ago.
bottom was adding the table width to its offset instead of the height,
that is now fixed.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is an ancient bug, but it got much easier to trigger with mouse
scrolling support so it's time to fix it.
(The bug itself was that since both the client and buffer ends of the
controlling stream are blocking, they could get stuck when both were
trying to send() data to the other end but the buffer was full. So now
we set the client end to non-blocking.)
|
| |
|
|
| |
background & list-style did not override unspecified values
|
| | |
|
| |
|
|
|
| |
should finally convert the code to strictDefs, implicit result is a
horrible footgun
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we are going to round things in layout, let's do it properly. Adding
fake height has negative utility (things get more annoying to read),
so now we don't.
TODO: finding the correct positioning of the baseline after adding
padding is an open question. Probably have to revise the algorithm
somewhat to get it right.
(This should also fix the bug where error correction would make inline
box backgrounds shift into unrelated text, causing much confusion for
the reader.)
|
| |
|
|
|
|
|
| |
Split up load into loadSubmit, gotoURL: loadSubmit is a replacement for
load(s + '\n'), and gotoURL is a load that does no URL expansion.
Also, fix a bug where load("\n") would crash the browser.
|
| |
|
|
|
| |
it is useful to round them so that they don't get positioned somewhere
in the middle of a line (which is rounded to the same precision as well)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The previous retrofitting of the old renderdocument error correction
usually worked, but it still had a horrible flaw in that it assumed that
all line boxes are of equal height. So if error was lower for some line
than another, it would move *all* lines by a somewhat lower error, and
that resulted in overlapping lines.
Now we do something much simpler: in flushLine, round each line's height
downwards before moving on to the next line. This gets rid of any blanks
inbetween lines, and also works much better with cleared floats.
|
| |
|
|
|
|
|
|
|
| |
* fix cursor jumping back to the start of the line (instead of the end
of the line) when it is outside the viewport and a leftwards update is
requested
* save setxsave too when line is not loaded yet
* always set needslines in onMatch when hlon (this was causing a blank
screen when incremental search was jumping around in large documents)
|
| |
|
|
|
|
|
|
|
|
| |
It is in fact quite simple to calculate: charwidth is the width
of printing characters until now, and whitespacenum the number of
(non-flushed) spaces. So we just have to subtract this from the target
width to get the number of spaces missing from the next tab stop.
(Of course, it gets much harder to understand when the whole thing is
formatted as a convoluted multi-line equation...)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* rename buffer enums
* fix isAscii for char 0x80
* remove dead code from URL
|
| |
|
|
|
|
|
|
| |
Ensure that a) dead outputs do not continue to get more data from
istream and b) if all outputs are dead, istream is immediately closed.
Also, remove that pointless loop in loadStreamRegular (it did nothing
that handleRead did not).
|
| |
|
|
|
|
|
|
| |
reshape must do a render from zero, as it's a last resort for users to
fixup the page on a rendering bug.
switchCharset must reset prevStyled for obvious reasons (it refers to
a dead document).
|
| | |
|
| |
|
|
|
| |
they will replace the target container on connection, so inserting them
in a different place first results in strange navigation bugs
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* reduce onload result size to a single int
* clean up mess that was the container onload handler
This fixes automatic refresh in console. Before, the client would
only request a screen update after receiving the number of bytes read,
but before the screen was actually reshaped (which obviously resulted
in a race condition). Now, "I've reshaped the document" is a separate
response (and is the only occasion where the screen is updated before
the final render).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Get rid of sostream hack
This is no longer needed, and was in fact causing loadStream to get
stuck with redirects on regular files (i.e. the common case of receiving
<file on stdin without a -T content type override).
* Unify loading from cache and stdin regular file code paths
Until now, loadFromCache was completely sync. This is not a huge
problem, but it's better to make it async *and* not have two separate
procedures for reading regular files. (In fact, loadFromCache had
*another* bug related to its output fd not being added to outputMap.)
* Extra: remove ansi2html select error handling
It was broken, because it didn't handle read events before the
error. Also unnecessary, since recvData breaks from the loop on n == 0.
|
| |
|
|
| |
whoops
|
| |
|
|
|
|
|
|
|
| |
Some terminal emulators (AKA vte) refuse to set ws_xpixel and ws_ypixel
in the TIOCGWINSZ ioctl, so we now query for CSI 14 t as well. (Also CSI
18 t for good measure, just in case we can't ioctl for some reason.)
Also added some fallback (optionally forced) config values for width,
height, ppc, and ppl. (This is especially useful in dump mode.)
|
| | |
|
| |
|
|
| |
no open/closed logic yet, but at least this fixes the display: property
|
| |
|
|
|
|
|
|
|
| |
This was my original intention, but there wasn't a way to do it until
now. The difference is that this respects user-configured color values.
(Now that I think of it, it may be better to automatically detect
prefers-color-scheme based on the default background color, and then use
blue for bright backgrounds and yellow for dark backgrounds. Hmm.)
|
| |
|
|
|
| |
`confidence' becomes ccCertain when PRES_STOP is returned, so asserting
the opposite is incorrect (and was resulting in crashes).
|
| |
|
|
|
|
|
|
|
|
| |
This way, we do not end up with ugly contrast-corrected white on
terminals with arbitrary backgrounds by default. (Now we get the native
-cha-ansi(default) instead).
(We leave background-color as transparent; this should have the same
effect, since defaultColor as bgcolor is ignored, but makes more sense
(and will allow us to un-ignore defaultColor as bgcolor in the future.))
|
| | |
|
| |
|
|
|
|
|
|
| |
Cache mailcap entry output too, then delete it when the buffer can no
longer read from it.
(Maybe it would be useful to instead preserve it and allow viewSource
for HTML output too? Hmm.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handling text/plain as ANSI colored text was problematic for two
reasons:
* You couldn't actually look at the real source of HTML pages or text
files that used ANSI colors in the source. In general, I only want
ANSI colors when piping something into my pager, not when viewing any
random file.
* More importantly, it introduced a separate rendering mode for
plaintext documents, which resulted in the problem that only some
buffers had DOMs. This made it impossible to add functionality
that would operate on the buffer's DOM, to e.g. implement w3m's
MARK_URL. Also, it locked us into the horribly inefficient line-based
rendering model of entire documents.
Now we solve the problem in two separate parts:
* text/x-ansi is used automatically for documents received through
stdin. A text/x-ansi handler ansi2html converts ANSI formatting to
HTML. text/x-ansi is also used for .ans, .asc file extensions.
* text/plain is a separate input mode in buffer, which places all text
in a single <plaintext> tag. Crucially, this does not invoke the HTML
parser; that would eat NUL characters, which we should avoid.
One blind spot still remains: copiousoutput used to display ANSI colors,
and now it doesn't. To solve this, users can put the x-ansioutput
extension field to their mailcap entries, which behaves like
x-htmloutput except it first pipes the output into ansi2html.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The -cha-ansi color type now sets ANSI colors in CSS.
Also, color correction etc. has been improved a bit:
* don't completely reset output state in processFormat for new colors
* defaultColor is now separated from ANSI color type 0
* bright ANSI colors are no longer replaced with bold + dark variant
* replaced ANSI color map to match xterm defaults
|
| |
|
|
| |
aaaaaa
|
| |
|
|
| |
:/
|
| | |
|
| |
|
|
|
|
|
|
| |
It's better to not implement them at all than to implement them badly.
(In particular, making fixed act like absolute breaks horribly on
websites that actually use it. Fixing it is not really possible without
changinge the way we currently draw things to the screen.)
|