matterhorn-chat / matterhorn Goto Github PK
View Code? Open in Web Editor NEWA feature-rich Unix terminal client for the Mattermost chat system
License: BSD 3-Clause "New" or "Revised" License
A feature-rich Unix terminal client for the Mattermost chat system
License: BSD 3-Clause "New" or "Revised" License
We're getting an occasional ParseException "Failed reading: unknown opcode ..."
and it appears to be coming from the Websocket library.
To wit:
$ ag ParseException
websockets-0.9.7.0/src/Network/WebSockets/Stream.hs
156: go (Atto.Fail _ _ err) _ = throwIO (ParseException err)
websockets-0.9.7.0/src/Network/WebSockets/Types.hs
121: | ParseException String
websockets-0.9.7.0/tests/haskell/Network/WebSockets/Server/Tests.hs
133: handleClose _ (ParseException _) =
146: handler (ParseException _) = error "Unexpected parse exception"
Right now the direct message channel (user) list is long enough that you have to scroll it just to check on whether there are any unread messages. To make it easier to tell if there are unread messages (but to preserve the ability to message anyone by scrolling to their name), I propose we sort the user list by most recent communication. This could be annoying but it's also optimized for the common case by showing you users with whom you communicated most recently. And if we have a good /focus
command then it's no longer important to sort the list alphabetically.
Thoughts @dagit and @aisamanra?
Such as msg
. I'd suggest adding command aliases but in this case I think (say) msg
is a better name and is going to be less surprising.
Right now we don't expose a binding for scrolling the chat message area. This is easy to do but the bigger task is to figure out the UI focus behavior (if any). And when we implement scrolling in the message area, it has to interact well with the visibility request used to keep the window scrolled to the last message.
With only 16 colors we're going to have collisions. So this may not be fixable. This ticket is here to serve as a place to document ideas related to improving the coloring.
I'll go first, here is a vague rule I think would help:
batman
and badman
should preferably be different colors). We might compute similarity using hamming distance or levenshtein distance.If you can think of other heuristics then let's try to collect them here.
Right now we have a redundant username in such messages:
[10:51] tristan: tristan has joined the channel.
I'd like the client to show me which messages are new because it's often hard to remember what I last saw. So something like
[01:00] user1: foo
-- New messages --
[01:01] user2: bar
[01:02] user3: blah
It'd be nice if command dispatching handled invalid argument counts gracefully. It'd be nice to update the Command type with an argument list description so we can both validate input and generate help for the expected arguments (rather than just crashing on a pattern match failure).
We have lots of lists that should probably be sets. Particularly, I noticed this in ChatState
and transitively in the types of its fields.
From my chat messages: It occurs to me that the client could also greatly benefit from sending requests asynchronously, i.e. when we send a message it goes into a Chan and a worker thread sends it, rather than blocking the brick redraw on a mattermost-api library operation. That is most evident right now when you change channels, where we do a watermark update API call to the server and it causes a channel switch delay.
If you try to /dm <user>
where you have never messaged <user>
before you will get a crash because of an irrefutable pattern match failure, like this:
matterhorn: src/State.hs:156:3-45: Irrefutable pattern failed for pattern Just n'
So we can get color in usernames etc. while editing.
It'd be nice if I could tell who is actually online. An indicator next to the username in the user list is one way to do this. Alternatively we could split the user list into two groups:
----Users (online)-----
...
...
----Users (offline)----
...
...
Such as /topic
.
If your current channel is full of text and you are at the very bottom, typing /help
doesn't scroll the channel text. You have to hit page down to see the help text.
We need a screen that shows keybindings and commands.
We need editor tab-completion support for (at least):
I'm not sure what the best UI is for managing newline insertion vs. sending (e.g. Enter
confusion) and other considerations like modifier combinations in common terminal emulators, but we'll need this at some point.
E.g. if I run the command
/dm @ijones
then I get
[12:43] *matterhorn: No user named @@ijones
I propose that dm
accept usernames with or without @
.
Right now the client requires the config to provide a team name. This is nice if you know which one you want, but when you don't, it would be good to have the client mirror the web client UX and allow the user to choose the team interactively based on the user's team list. The API has been updated to provide this and the client now fetches that restricted team list, but it still uses the config file team. This task is to make the team selection interactive when there is no team in the config. As a bonus we could even update the config with the selected team so the user never has to deal with this.
For example, currently I get:
$ .cabal-sandbox/bin/matterhorn
matterhorn: security: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
because I stupidly ran this under linux where security
is not a valid command.
And let's make it render properly.
I'd like to add support for color theme configuration. To start with, this just means looking in the XDG directory (say) for a new theme.ini
and use the brick
attribute names as keys therein. Then we'd use that info to update the existing color theme attribute map.
We need to annotate normal and DM channels with unread message counts (and thus track watermarks of some kind).
Right now we have adjacent messages from different days and it isn't clear which days they are from. It'd be nice to turn
[23:59] user1: huh?
[00:04] user2: no.
into something like
[23:59] user1: huh?
-- Jan 1 2016 --
[00:04] user2: no.
with a configurable date format string just as with time formatting.
The client interface takes a few seconds (sometimes 3-5s for me) to appear while various data are fetched. I'd like to refactor things so that we can go ahead and show the UI with no channels and some status information like "Loading..." rather than staring at the shell wondering what is happening.
Right now we seem to be overriding the background color in the terminal. To reproduce use a light terminal color such as solarized light and then run matterhorn. When matterhorn runs the background color is dark.
We could handle this several different ways. My preference would be to simply not set the bg color, but if there are technical issues with that then we should allow the user to set a config option.
If the configuration doesn't specify a username and/or password method, prompt for one or both interactively on startup. We can take the same approach as for team selection: fire up a secondary Brick application to collect the values, then continue with the main application.
Right now we render all the chat messages we have for each channel, but as the client runs for longer and longer periods of time, we render them even though they're unlikely to ever get seen again (even once we implement scrolling up). The cost to this is that they get drawn and cropped rather than not drawn at all, so I think we should be evicting them (i.e. keeping at most N for reasonable N messages in the channel message lists).
It'd be nice to be able to see who is a member of a given channel (even if only the current one). Via a /members
command, say.
We have a bunch of boolean flags in our Message
type right now but most if not all of them are mutually exclusive. I think we can improve the Message structure and simplify its rendering routine (plus get some more functionality I want) by collapsing all of those booleans into a single message type field.
Either/or by using a color or text style attribute.
I don't see this as a core feature, but instead as a nice to have feature.
We should make an effort to detect when the websocket connection is dead and reconnect as soon as possible. The way glirc handles this is to use a ping + timer. If there is no response from a ping after N seconds (by default N = 60) the client initiates a reconnect.
I don't know if the websockets library exposes server pings or not. If it does not, then we could simulate it by periodically initiating benign requests such as mmGetMe
that just test our ability to fetch data that should always be available to us.
It's also worth noting that this connection health could correspond to both the one shot HTTP requests and the websocket connection. It's likely worth monitoring both. If we only test HTTP request we could hit an edge case where the internet connection dropped for just long enough to disrupt the websocket but came back fast enough to not interrupt HTTP requests.
For example:
more? ...
There is a lot of latency when pasting (and sometimes when typing).
When pasting a long line (let's say an 80 character url) you can watch the characters appear one by one. My subjective assessment is that it is worse in channels with a lot of visible scrollback. Sometimes I can even get ahead of the cursor while typing.
Right now we format time as [%HH:%MM]
where %HH
puts it in 24hour time. This might not appeal to all users. Allowing users to specify their favorite date formatting would be better and should be fairly easy to support given that we use the formatTime
function.
This applies to both standard channels and DM channels. (Right now the dm
command silently does nothing when you give it a DM channel name that does not already exist.)
This includes highlighting tokens of interest (usernames, URLs, etc.) and making this compose with line-wrapping.
Up and Down arrow keys in the editor (when it is not in some kind of multi-line editing mode) should cycle through the command history.
If I send a message to a channel and quickly switch to another channel, the channel I left appears to have unread messages. But I don't think it should, because I know I sent a message. I want to know when it has unread messages from anyone else. I think it makes sense to only update the unread status under that condition.
The user channel list includes the user that is logged in. I think we should probably filter that one out. :)
I think those are nice to have. There is probably a way we can display these unobtrusively.
Hi @aisamanra,
Saw your and everyone else's work for MatterHorn and we'd love to help share it with the Mattermost community. Would you be open to sharing more about your project? https://www.mattermost.org/share-your-mattermost-projects/
Also, we'd like to welcome everyone to join the integrations community on our nightly builds server, if anyone would like: https://pre-release.mattermost.com/core/channels/integrations
Wonderful work!
Such as:
M-Backspace
: delete word backwardM-d
: delete word forwardM-{Left,Right}
: move by wordC-k
, C-y
: kill and yankI found that I wanted to start typing a message in one channel, switch to another to get some information, and come back and finish. Right now that can't be done because we clear the editor on channel change. We'll need a map in the state to map from Channel ID to editor content and populate that on channel switch.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.