matterhorn-chat / matterhorn Goto Github PK

Using e.g. https://hackage.haskell.org/package/cheapskate

We need to annotate normal and DM channels with unread message counts (and thus track watermarks of some kind).

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.)

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"

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

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.

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'

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.

Such as /topic.

I think those are nice to have. There is probably a way we can display these unobtrusively.

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).

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.

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.

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)----
...
...

And let's make it render properly.

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.

I 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.

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:

• Use different colors for different length nicks, especially when the nicks have similarity (eg., 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.

The user channel list includes the user that is logged in. I think we should probably filter that one out. :)

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!

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.

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).

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.

Such as:

• M-Backspace: delete word backward
• M-d: delete word forward
• M-{Left,Right}: move by word
• C-k, C-y: kill and yank

We need editor tab-completion support for (at least):

• Channel names
• Command names (and possibly arguments)
• User names

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.

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.

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.

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?

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.

Right now we have a redundant username in such messages:

[10:51] tristan: tristan has joined the channel.

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.

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.

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 @.

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.

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.

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.

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.

So we can get color in usernames etc. while editing.

For example:

• jump to channel with oldest unread activity (this is M-a in glirc2)
• jump back to previous channel (this is M-s in glirc2)

more? ...

We need a screen that shows keybindings and commands.

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.

Either/or by using a color or text style attribute.

We have lots of lists that should probably be sets. Particularly, I noticed this in ChatState and transitively in the types of its fields.

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.