mathall
rim exits without error message when saving to file without permission
If you open a file which your user has read permission, but no write permission, and then try to save it (:w) rim exists with code 101 and no explanation.
I think rim should show a message to the user and should not exit when failing to write in file.
In the case of vim there's a line at the bottom that's "reserved" for showing warnings and erros, as well as the "vim prompt". I think I'd be nice for rim to have this "message bar" as well.
What do you think?
You're right, we're not failing gracefully when there's a write error, as you can see on src/rim.rs:367 when handling WinCmd::SaveBuffer.
Yes, rim should do whatever vim is doing in this case. That is, show an error in the prompt.
This would require a new module, and my only thoughts for now is that intuitively I'd like to see it being conceptually closer to a console than a message bar.
closer to a console
Could you elaborate on what's you "vision" for this console? What a simple version would look like? Which would you think are the "steps" to get there?
A simple version would be able to display notifications, like this write error. It would also be able to take focus, receive input, and mock-execute a command.
A first step might be to just let it display a notification.
Well actually before that we'd need to fiddle with the frame. I'd think this bar, whatever shape it may take, would make up a special kind of "window" outside of the actual frame for the buffers.
Anyway, once there's screen space for the thing and it's able to output messages, I'm thinking (but not necessarily) that the same module would handle written commands on the prompt and such.
Basically : would be bound to some new command, say Cmd::EnterConsole. Handling this would shift focus to the console and set a new mode of input, similar to the insert mode for a buffer. You'd type, it'd show up on the prompt, and pressing enter would cause the line to be executed. This last step could be super trivial for now though, just checking for "w" or something and then write.
That's my spontaneous "vision" anyway. I don't think extending a pure message bar to be more of a console in this manner is a huge extra burden. (and imo it sounds way more fun even)
My concern with simply making a message bar is that it wouldn't "fit" when taking it one step further. (the prompt) Sure you could make the same argument that this "console" I described may not "fit" when taking that to the next level by supporting actual scripting.. but I think this is a reasonable "leap" forward, not taking on too much or too little in one go.. :) Thoughts?
So the "special window" would be part of the screen::Screen, but would be outside of the frame::Frame, correct?
Half correct, I think. Screen is almost only used for output, it doesn't care if we're displaying a buffer or a console or something else anywhere. So nothing would "be part" of the screen. As it is now, rim gives the entire screen area to the frame when the screen says its size changed. (see main loop) This would have to change so that a row at the bottom is assigned to the console. If rim itself or some new struct will keep track of this screen allocation, I don't know. But my point earlier was that it's probably better doing it this way, than using the frame to split out a window for the console.
I got it to print a message in the last line (while diminishing the frame by one line). The code is in https://github.com/diogovk/rim/tree/rim_console . Please share your thoughts.
Now I'm not sure how should I proceed. In rim.rs when handling command::WinCmd::SaveBuffer, I have access to the "console" but I have no access to the screen::Screen instance. It seems the access to screen is done in the draw() functions. Should I add a buffer to the Console, and "draw" the message in the buffer during the main loop?
Nice! :) I like the looks of it. Yes exactly, the console would need some sort of buffer/state to know what to display when later being asked to draw to the screen. Ideally this would create a pure divide between logic and presentation, but you may also need to mark the console dirty and such somewhere to make sure updates are seen and not rendered needlessly etc.