@itemize
-@item @command{cmd/start} creates @file{debug} FIFO, prepares
-configuration file for @command{tmux} (actually there is just single
-path to the command replaced with the real one) and runs it with single
-window split on two halves: one just shows debug messages (all raw MM
-messages for debugging), another one runs @command{cmd/mmc} itself.
+@item @command{cmd/start} creates @file{debug} and @file{users/status}
+FIFOs, prepares configuration file for @command{tmux} (actually there is
+just single path to the command replaced with the real one) and runs it
+with single window split on two three parts: one just shows debug
+messages (all raw MM messages), other shows colourized list of
+non-offline users, another one runs @command{cmd/mmc} itself.
@item @command{cmd/mmc} logs in to the server, fetches a list of all
known users and channels I am subscribed to. Then it creates necessary
I wrote it solely for my personal needs, but you may find its simplicity
and flexibility useful.
-Mattermost (MM) does not have any sane and convenient client. GUI,
-mobile versions and browser application requiring you to frequently
-update your Web-browser are not an option of course.
-
-@url{https://github.com/matterhorn-chat/matterhorn, Matterhorn} is the
-only known console/terminal client for me, but until there will be any
-official instructions how to bootstrap Haskell compiler, I can not even
-try it. @url{https://github.com/42wim/matterircd, matterircd} was the
-only possibility to use that platform (that is forced to be used by my
-employer) that acts like an ordinary IRC-server bridged with MM.
-
-But IRC-client (@url{https://irssi.org/, irssi} in my case) can not send
-long and multiline messages, because of IRC protocol limitations. And
-because of frequent cyrillic alphabet usage, that takes twice as long
-bytes per character, messages are relatively short and are often split
-on single word boundary. Also it has neither vi-editing capabilities,
-nor simple way to use/emulate @command{readline} or use external editor.
-@command{matterircd} converted attached files to URLs that can be used
-with supplementary utility to download them from the server with proper
-authorization.
-
-Fortunately MM is written on Go and has convenient simple library to
-deal with its API. So I tried to write my own console implementation
-from the scratch without those IRC-limitations. I thought about bridging
-to XMPP protocol, that won't have any noticeable limitations, even
-containing file transfer possibility, but denied the idea as yet another
-level of complication. Moreover I was not sure that I was satisfied with
-any known XMPP-client (although in general I liked
-@url{https://mcabber.com/, mcabber}). Writing an ordinary TUI
-application with high level library similar to @command{curses} seemed
-to be pretty complicated task and reinventing of yet another bicycle.
-Initially I was not a fan at all of
-@url{https://tools.suckless.org/ii/usage/, suckless} way of chat clients
-building, where you have bunch of FIFOs per channel you deal with. But
-more I thought, that idea started to look nicer and nicer.
-@ref{Architecture, Look} what I came to!
+@itemize
+@item @url{https://tools.suckless.org/ii/, Suckless} minimalist FIFO and
+filesystem-based backend. @url{https://github.com/tmux/tmux/wiki, tmux}
+based frontend with colourized output.
+@item Ability to store channel's whole message history, keeping
+threading meta information in both human and machine friendly format.
+@item Ability to send and retrieve files. Multiline messages support.
+@item All channels refreshing after the login.
+@end itemize
+
+@command{mmc} is
+@url{https://www.gnu.org/philosophy/pragmatic.html, copylefted}
+@url{https://www.gnu.org/philosophy/free-sw.html, free software}
+licenced under @url{https://www.gnu.org/licenses/agpl-3.0.html, GNU
+Affero GPLv3}.
@insertcopying
+@include why.texi
@include arch.texi
@include usage.texi
@include faq.texi
compile Go programs in @file{cmd} subdirectory.
@example
-for c (cmd/rd cmd/mmc cmd/sb cmd/ch-leave) @{
- pushd $c ; go build -ldflags=-s ; popd
-@}
+for c (cmd/rd cmd/mmc cmd/sb cmd/ch-leave) @{ pushd $c ; go build ; popd @}
@end example
@item Create and change to the directory where the state will be kept.
--- /dev/null
+@node Why
+@unnumbered Why
+
+Mattermost (MM) does not have any sane and convenient client. GUI,
+mobile versions and browser application requiring you to frequently
+update your Web-browser are not an option of course.
+
+@url{https://github.com/matterhorn-chat/matterhorn, Matterhorn} is the
+only known console/terminal client for me, but until there will be any
+official instructions how to bootstrap Haskell compiler, I can not even
+try it. @url{https://github.com/42wim/matterircd, matterircd} was the
+only possibility to use that platform (that is forced to be used by my
+employer) that acts like an ordinary IRC-server bridged with MM.
+
+But IRC-client (@url{https://irssi.org/, irssi} in my case) can not send
+long and multiline messages, because of IRC protocol limitations. And
+because of frequent cyrillic alphabet usage, that takes twice as long
+bytes per character, messages are relatively short and are often split
+on single word boundary. Also it has neither vi-editing capabilities,
+nor simple way to use/emulate @command{readline} or use external editor.
+@command{matterircd} converted attached files to URLs that can be used
+with supplementary utility to download them from the server with proper
+authorization.
+
+Fortunately MM is written on Go and has convenient simple library to
+deal with its API. So I tried to write my own console implementation
+from the scratch without those IRC-limitations. I thought about bridging
+to XMPP protocol, that won't have any noticeable limitations, even
+containing file transfer possibility, but denied the idea as yet another
+level of complication. Moreover I was not sure that I was satisfied with
+any known XMPP-client (although in general I liked
+@url{https://mcabber.com/, mcabber}). Writing an ordinary TUI
+application with high level library similar to @command{curses} seemed
+to be pretty complicated task and reinventing of yet another bicycle.
+Initially I was not a fan at all of
+@url{https://tools.suckless.org/ii/usage/, suckless} way of chat clients
+building, where you have bunch of FIFOs per channel you deal with. But
+more I thought, that idea started to look nicer and nicer.
+@ref{Architecture, Look} what I came to!