Programmable status text

[notramo]

A readline built-in „notification” system would be cool. This would draw a line over the prompt line, similarly as it does when the user press an unbound key combination, or reaches end of history, but instead printing the next notification in a new line, the new notification would overwrite the old (so it would remain in the same line).

When the user hits Enter, the notification line would be deleted (similarly as the right prompt), and the left prompt would move a line up (into the place of the notification) before running the command.

Markup would be cool for highlighting some parts of the notification.

Use case: implementing a lot of powerful stuff.

• a long running command finishes in another instance

  'yay -S tokei-git exa-git' finished on workspace 2
  ~/ >>>

• git status information after cd-ing into a project dir

  4 modified files, 7 changes not staged for commit
  ~/elvish/dirhistfilter >>>

• next argument type:

  Usage: [global_options] [input_file_options] -i input_url [output_file_options] output_url
  ~/video >>> ffmpeg 

  after typing some arguments:

  Usage: [output_file_options] output_url
  ~/video >>> ffmpeg -i file.mkv

• a primitive autosuggestion until #507 gets solved It would print the command to insert in the notification line.

  Press Shift-Enter to insert this command into readline:
  git add src/launcher.cr; git commit
  ~/crystal/launcher/ >>> gi

The git status, and the long running command notification can be done simply with an echo, without using the readline, but if these informations are not enough important for somebody to make it persistent. So the user reads it, then it will be deleted by the autocompletion after starting typing a command.

Since the autocompletion, and the „next argument type” completion depends on the current readline buffer, and changes along with it, these could benefit from this feature.

It could be more powerful if it maintain a stack of notifications in memory. The notification command would return an unique id, then the notification can be deleted later. Example:

notification_id = (edit:notify "Shift-Enter to run: <bold>git add dirhistfilter.elv; git diff --cached</bold>")
sleep 1.5
edit:delete-notification $notification_id

So after 1.5 second, the previous notification would be visible again.

[zzamboni]

This might be cool, although I would suggest the notifications to appear below the prompt line, like when you enter a syntax error.

[xiaq]

I would like to make a distinction between notifications and status texts.

• Notifications correspond events that happened at some point. They should not overwrite each other, and they should appear above the prompt, so that they go into the scrollback buffer. Notifications are already programmable using edit:notify.

  Of the examples given in the original comment, the first use case (notifying that a long running operation has finished) should be in fact be a notification, not a status text. If you have two operations that finished, you want both messages present in the scrollback buffer. The remaining use cases should be status information.

• Status texts are contain information derived from the current status - typically the buffer, but could be from elsewhere, such as an active listing. Status texts should appear below the prompt, and they can disappear as soon as they no longer apply. Parse and compilation errors are status texts. In general, status texts are not programmable now.

Since notifications are already supported and the original description maps more into the status text category, I am going to reword this issue to reflect that.

[xiaq]

The easiest way to support this is adding another "below prompt" that appears below the buffer - like how rprompt appears to the right.

This way I can also outsource the business of maintaining which lines should appear - the editor itself just needs to know when to call the "below prompt", and the prompt callback is responsible for deciding which lines to show.