Using the +draft/reply client tag, which is supported by BitBot.
This hides the bot's replies to ignored users or ignored bot command
messages.
This commit is dedicated to the land of Estonia.
I avoided defaulting MANDIR to /usr/local/man because I thought it
didn't work on GNU/Linux and users would be confused, but it turns
out man-db's default configuration includes both /usr/local/man and
/usr/man, so ${PREFIX}/man is a sensical default.
At least in InspIRCd's implementation, you only get invite-notify
INVITEs if you are op, so inviting with no op (where allowed by a
channel mode) results in only a 341. On the other hand, inviting
as an op produces both a 341 and an INVITE, so will be displayed
twice, but showing something sometimes twice is better than not
showing it at all.
The recent addition of "#{source_files}" allows us to avoid hardcoding
the file name and instead ask tmux itself for the very file it used to
create the session in the first place, i.e. "-f ./chat.tmux.conf".
Apparently these are common. There's no terminfo for these, so
manually define the xterm sequences.
There's no documentation in the manual for the "intuitive" keys...
I'm not sure if that should continue to be the case or not.
A_BLINK has probably always existed, but there's no good reason to
ever use it, so make it do italics instead. Normally all attributes
are set by a single set_attributes string if it's set, so clear it
to force ncurses to use the reassigned enter_blink_mode string. If
the terminal has no enter_italics_mode string, then nothing will
happen.
This makes setting multiple attributes a bit less efficient, but I
don't think it's likely to make much of a difference since using
multiple attributes at once is so uncommon.
OpenBSD's xterm doesn't have bracketed paste mode, and it would be
nice to still be able to paste in several lines and collapse them
with M-q, provided one remembers to type C-z p first...
Otherwise it could hit the assertion in editBuffer while converting
to mbs for consumption by the rest of the program.
It's possibly to trigger this with LC_ALL=C and typing C-z C-v M-a,
for example.
Provide a hotkey to browser the manual in its own window.
After input, nicm (tmux upstream) added "-S" to tmux(1) such that
the "new-window" command (in combination with "-d") first looks
for the given window name and selects the window if it exists
instead of trying to create a window that already exists.
Given that this makes chat.tmux.conf idempotent, we can now also reload
it at runtime to refresh settings.
In other words, only automatically switch to an automatically joined
channel window if there's only one. Otherwise, stay on the <network>
window and avoid touching the channel windows with their automatic
topic and names replies.
This fixes unintentionally clearing saved window unread counts when
rejoining channels automatically by switching to them as they are
joined.
A little annoying to make it a "chord" like this, but C-v is already
used for scrolling, following Emacs-style key bindings (in order
to have a way to scroll without using "special" keys like the arrows
and page up/down), and C-z is at least already in the business of
inserting control characters. This makes it possible to manually
enter some things that are otherwise only possible with /exec printf.
With the early return, mainUpdate doesn't get called in cases where
other functions expect windowShow to call it, such as when closing
or moving windows.
I don't know why I ruled this out originally, it's more visually
pleasing to me now especially that threshold is likely to remain
set at "+" for a long time.
Finally! Changing the message visibility threshold doesn't totally
screw up scroll position. Neither do horizontal resizes, but vertical
resizes drift because the value of windowTop() changes before and
after...
The scroll position is anchored to the top of the window. It's
arbitrary whether to anchor the top or the bottom, but other scrolling
commands like M-p and C-r are anchored to the top, so this is
consistent.
This directly correlates hard-wrapped lines with the soft lines
they were wrapped from.
Choosing uint here because it doesn't change the size of struct
Line. It doesn't at all matter since buffers only hold 1024 lines
at a time anyway.