With bracketed paste, "a\nb" will result in two lines being pasted,
because it's a single thing, with an end marker which the timeout based
pastes don't have.
Due to the way term_gets() counts lines, that input will have
paste_line_count == 1. This can be misleading.
This code adjusts it by looking at the last character, and increasing
the count if it finds anything that isn't a newline.
The function "static void paste_buffer_join_lines(GArray *buf)" in
"src/fe-text/gui-readline.c" is supposed to join lines from the GArray
pointed to by *buf under certain circumstances.
In the code of the function "buf" is actually used for getting the length
of the GArray, but to get a pointer to the data, "paste_buffer->data" is
used; paste_buffer is defined in the scope of the whole file.
This delivers the desired result, because this function is only called
once, with "paste_buffer" as the argument. If paste_buffer_join_lines()
will ever be used with a different argument, it will fail.
term_addstr() had a long-standing fixme that suggested it didn't
take into account the string encoding when calculating the string
length.
The BIG5 code path is untested.
Both cases were off-by-one mistakes erring on the side of being too
conservative. This fixes these two harmless issues:
- For a single empty paste, it required another keystroke before
processing it
- For a sequence of themcase, a single '~' was left in the input
This actually workarounds a bug with the "st" terminal, for which i've
already submitted a patch, but irssi needs to be able to handle it
decently too.
http://bugs.irssi.org/index.php?do=details&task_id=905
Not using the patch from that ticket, the issue turned out to be that
(dest - last_lf_pos) returned number of unichr, not bytes, so that's 4
times less than what the size parameter of memmove() should be.
We disable the ICRNL flag to make Enter independent from ^J from the
keybinding point of view since the former will now send ^M, leaving the
user free to remap ^J without trapping itself into the irssi session
because of a broken Enter key.
Also disable the software flow control because we don't expect anyone to
run irssi over a serial console; we gain some more freedom by having ^Q
and ^S freely mappable by the user.
Enter the "application" mode when setting up the terminal, this improves the
compatiblity with the standards; as a side effect now DEL key works ootb when
irssi is run in the suckless's st terminal.
By temporarily raising the fatal log level to critical during irssi
start-up, we make it fail when the config file is broken. This is then
re-set so that /reload of a broken config file will not crash irssi and
just report the errors and gracefully continue instead.
this adds the CONFIG_REC * to the config_node_section and
config_node_section_index APIs as they will require access to the config
cache later on to make the config parser more robust.
Before this, doing "TERM=vt100 irssi" showed all text as bold and
blinking because of a failed check of window->term->TI_colors that
was doing (value & 8) and not expecting a value of 0.
The changed lines themselves look a bit weird, but they make more sense
in the context of the original commit, 96a292d4.
this fixes a crash due to illegal memory access that can occur if
something is printed to the screen on the "terminal resized"
handler. It is not clear to me whether this race condition can be
triggered by external incoming messages, but it might be better safe
than sorry.
Fixes FS#721
This makes Ctrl+^ and ^ bindable again as different keys. We do this
by escaping single `^` as `^-`, which is not a valid control character
(unlike `^^`)
The original approach suggested in FS#721 is insufficient, it will
break bindings such as `meta-^` because Irssi is convinced that `^`
introduces a Control-key ("key combo") so it is waiting for what may
follow.
the colour 0 was broken by the extended colours patch because it needs
an explicit bit check (lower bits will be false since it is 0)
Thanks to lhynes for the report
Fixes Github issue #97https://github.com/irssi/irssi/issues/97
Fix proposed by ailin-nemui, built and tested on Debian Jessie using
0.8.15 source, tested by GeertHauwaerts as well.
It's tricky to make the banner show first in all cases and it's unlikely
to be seen if someone is connecting to a server already, so just don't
show it.
256 colour patch is cleaned up and the remaining cases are made work,
this includes especially Theme support, which was not implemented
before. Changes not related to colours were reverted again, making a
review of the two patches against master easier to follow.
As a byproduct of the Hex-colour code parser, the 24bit colours are
also implemented. Actually using them in the terminal is guarded by a
compile time switch (as well as a run time switch), as it breaks the
existing colour protocol and requires additional storage.
To make a seamless usage, down-conversion is provided for 8 and 16
colours.
Diverging from Tom's approach, the colour protocol is reverted back to
the original one. Unfortunately, the changes required in the Theme
engine will break the API.
For more details, please refer to the patch documentation at either
http://irssi-docs.wikispaces.com/Notes-256-Colour or
https://github.com/shabble/irssi-docs/wiki/Notes-256-Colour
This patch implements some 256 colour support for Irssi up from the
previous 16 colours. Initial parsing of the %x/%X format codes is
implemented and the parser accounts in advances the char* for
that.
The colour attributes are widened from 4 to 8 bit. The colour protocol
is changed to a new format. Some pointers to remaining work are
written in the comment in textbuffer.h.
Note that Irssi already does support requesting 256 colours from the
terminal in the original source code, so this part did not have to be
touched.
