| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
| |
toki ni li jo ala e nimi 'jan', la ona li pakala e nasin toki pi toki
pona. ike la, toki sin ni li sama ala lukin toki pi wile toki.
sina wile pona e ni la, sina ante mute e kon inputUpdate...
[if these words [action messages] do not have the word jan, they break
toki pona's system of speaking [grammar]. unfortunately, this new
message does not have the same look as the message in the prompt.
if you want to improve this, you have to greatly change the inputUpdate
code...]
|
|
|
|
|
| |
tenpo pini la, toki tan pali toki /setname li sama toki tan pali toki
/nick; tenpo ni la mi sona e ante ona.
|
|
|
|
|
| |
toki ni la toki "kama jo" li ike.
toki sin ni li sama mute toki ni lon toki Inli.
|
|
|
|
|
|
| |
toki tan toki pini li toki e ni (insa toki Inli): "This room has a sixth
person". toki li wile toki e ni: "This room has six people". tenpo pini
la, kepeken mi pi nimi nanpa li pona ala!
|
| |
|
|
|
|
|
| |
toki ni li lukin pona. toki pini li lukin nasa; nimi 'jan' li jo e
kule, taso la ona li wile jo ala e kule; nimi jan taso li jo e kule.
|
| |
|
| |
|
| |
|
|
|
|
| |
How did this normal sounding format string get in there!
|
|
|
|
| |
<https://modern.ircdocs.horse/index.html#rplwhoisspecial-320>
|
|
|
|
|
|
|
|
|
|
|
|
| |
POSIX does not define a %F for strptime[1], but does define %F for
strftime[2]. Afaik most libc's implement %F for both, but musl is very
standards-compliant and does not have %F on strptime, leading to
unparsed message tag times, which causes all backlog sent from bouncer
on startup to have a timestamp of the current time, instead of the
actual timestamp sent.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html
|
|
|
|
|
|
| |
Only the first colon should be replaced with a null byte.
Ported from pounce.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Used by Solanum for "actually using host".
|
|
|
|
| |
Missed this one.
|
|
|
|
| |
The format of the reply is defined as "<nick> :{[@|+]<channel><space>}".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`-H 0,0`/"hash = 0,0" makes catgirl mostly colorless which is great,
but topic changes still hardcode brown/green colors to show differences
which is usually not desired by users (like me) disabling colors.
Go for a less eye stressing topic change message that shows both old
and new in reverse video with default terminal colors.
This isn't perfect, other parts of catgirl still hardcode colors and
`-H 0,0`/"hash = 0,0" was never meant to disable colors completely, but
topics change often enough that avoiding less readable^Waccessible topic
diffs seems sensible enough.
NB: parseHash() is brittle and "0,0" is not the only value disabling
colors...
|
| |
|
|
|
|
| |
It should have 4, but the handler only uses 3.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This feature is rarely used, so just skip STATUSMSG prefixes in the
target so messages get routed correctly.
|
|
|
|
|
|
| |
This restores showing the topic and names for automatic joined
channels, while still avoiding touching the windows, by using Cold
heat.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is used by InspIRCd to indicate if a user is a bot (if it set
user mode +B).
|
|
|
|
|
| |
Otherwise they are invisible with M-+ and commands having no output
is confusing.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I'm not sure about that replies check in handleStandardReply. If more of
those are added the reply counter system will definitely need
refactoring.
|
| |
|
|
|
|
|
| |
Not totally clear under what conditions 437 is returned, but if it
happens during registration, we should pick a new nick.
|
| |
|
| |
|
|
|
|
| |
"%.*ls" is useless.
|
|
|
|
|
|
| |
While the automatic search via LESS is neat, I don't think it's very
useful. Just always open the manual to the COMMANDS section, and fix it
to append to LESS rather than replace it.
|
|
|
|
| |
Accumulate names in a buffer and show away status.
|
|
|
|
|
|
| |
It's pretty awkward with large channels since NAMES isn't sorted by
prefixes or anything... But having it accumulate names across many
replies would require more reworking.
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where if you send a private message before joining any
channels, your message will be routed to the <network> window. That
happens because without a JOIN, self.user remains unset, which means
that require will copy self.nick (set by echoMessage) to self.host. The
easiest solution is to go back to checking for '.' and add a '.' to the
default nick, so now if a server sends a NOTICE with no origin it will
look like -*.*- which is kinda cute.
|
| |
|
|
|
|
|
|
| |
The mention coloring code already matches case-sensitively, and any
proper ping should be using tab-complete anyway so there's no reason for
differing case. And the month of June should not ping me.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also determine if a message is from the server by if the host field has
been copied from the nick field.
EFNet sends NOTICEs with no origin during registration.
RFC 1459 has this to say:
> If the prefix is missing from the message, it is assumed to have
> originated from the connection from which it was received.
I suppose a more correct implementation would be to set the origin to
the hostname of the server, but we don't store that globally, so this
is good enough.
|