Shell-like prompt instead of M-x ement-room-send-message

[FrostyX]

First of all, hats down @alphapapa for casually writing not one but two Matrix clients for Emacs. You are a rockstar.

I would like to ask about your intentions about a (missing) prompt. I think it's fair to assume that a lot of Ement.el users are former IRC users, and every IRC client for Emacs I've seen has a shell-like prompt (I don't know how to describe it better). Basically something like

ERC>

or

[#channelname]

And the message is composed after the prompt. I see major advantages over the current M-x ement-room-send-message:

• One could send a quick message in some window while already composing a message in another one. Or do something else in Emacs.
• Key bindings - I don't know if this is significant for vanilla users, but the ability to use Evil key bindings when writing a message is one of the most killer features ever.
• Subjectively, it is more ergonomic to have a prompt in each chat window (I am looking to a window at the top-right, so I don't want to write a message in bottom-left)

I understand Matrix is not IRC and we are able to send replies, images, emojis, and all sorts of things, that the shell-like prompt is useless for. But I don't see this as a problem. The majority of messages are simple text and when one wants to send something different, he can use M-x ement-room-send-* commands.

Is the prompt on your roadmap or is it something you intentionally left out?

[alphapapa]

Hi Jakub,

Thanks for the kind words. I hope these projects are useful.

As you may have noticed, the matrix-client.el client does use an IRC-style prompt. It works fairly well and wasn't hard to code in Emacs.

When I decided to write a new Emacs client from scratch, I decided to try to follow Emacs's conventions more closely. One of the things I decided was to use the minibuffer for inputting messages.

I suppose it's debatable whether that actually follows Emacs's conventions more closely, since much of Emacs's input happens in full buffers rather than minibuffers. But since the room buffers aren't editable directly, it seems like it could be more consistent to not allow input directly into those buffers. It also significantly simplifies the implementation.

Another benefit of using the minibuffer is that users can reply to a message that is beyond the top of the window; if the prompt is only available at the bottom of the buffer, keeping the replied-to message visible would require some extra UI work.

But all of the points you make are true as well. And, being Emacs, I'm generally in favor of making software as customizable as possible. So I'm not opposed to also offering an input mode with a prompt at the bottom of buffers. I think the EWOC-based UI implementation would make that fairly simple; the complicated part would be in accounting for both paradigms in various places in the codebase.

Personally, I'm content with the minibuffer-based implementation; it's not perfect, but it's good enough for my use. So I probably wouldn't work on adding a prompt-based input system myself anytime soon. But I'd be glad to consider patches to that effect. (Although, as you may have noticed, I haven't had time to work on the project lately, so I couldn't promise a timeframe for reviewing or merging patches.)

If you're interested, feel free to use this issue for discussing and planning how this feature would work, and maybe that could lead to a PR in the future.

Thanks.

[piater]

much of Emacs's input happens in full buffers rather than minibuffers

There also is ement-room-compose-from-minibuffer for composing messages in a full "compose buffer". IMO this offers the best of both worlds: It addresses almost all of your (both of you) concerns while following a familiar Emacs paradigm (commit messages, org capture, ...). Personally I do not see any advantage in the minibuffer, but perhaps that's because my messages tend to be longer than a single line.

Perhaps RET can be made configurable to open a compose window at the bottom of the room window? This would be a separate enhancement request I guess.

[FrostyX]

There also is ement-room-compose-from-minibuffer

This fails for me with helm-M-x-execute-command: Assertion failed: (minibufferp), I didn't try to debug why yet. But there is M-x ement-room-compose-message which is a very helpful workaround for longer messages, thank you @piater.

If you're interested, feel free to use this issue for discussing and planning how this feature would work, and maybe that could lead to a PR in the future.

Thank you for the explanation @alphapapa. I am currently traveling but if nobody is faster than me, I will try to implement the prompt as an optional feature sometime next month.

[alphapapa]

@FrostyX That command is to be run when already composing a message in the minibuffer.

Thank you for the explanation @alphapapa. I am currently traveling but if nobody is faster than me, I will try to implement the prompt as an optional feature sometime next month.

Thanks.

[phil-s]

#140 is related; you may find the code there useful.

[phil-s]

#140 turned into #236 which has now been merged. I encourage any readers looking here because they'd like an IRC-style prompt to try out the options implemented in that PR and see whether that alternative meets their needs in practice.