Menu
▾
▴
#1542 Support for Scintilla-based command consoles
Platform: Not platform specific
BACKGROUND
Hello,
Scintilla is an excellent component for creating technical text editors.
With a couple of additions, it could also be used as an excellent front-end client for custom command consoles.
By custom command console, I mean a terminal-like input (similar to Bash, Powershell, etc) that is embedded within a host app.
The user types commands in the console, and the host app interprets that input as text-based commands.
Throughout my programming career, I've always needed/wanted to add command console capabilities to many apps.
A console is a simple way to add an input interface without having to add the related gui code.
It's specially good for prototyping.
But, it usually ends up being a single line input, with basic output to a scrolling window.
The reason being that creating the console is not the main purpose of the app, but only tangential for development.
Scintilla has almost all the capabilities needed to enable the input interface of a custom command console.
I think it only needs a couple of extra capabilities to have all the pieces needed to fullfill that space.
Most of the consoles, terminals, command-line processors that I've used exhibit the following behavior:
A. When you enter a command and execute it, the new text is scrolled up (which signifies
that is has been executed), a possible output is echoed to the window, and the caret is
moved to a newly created input-line.
B. It is not possible to edit or navigate to a line that is before the current input-line.
However, it is possible to add, edit, and delete new-lines after the input-line.
That enables crafting commands that are span multiple lines.
C. The console can respond to some shortcuts. For example, ENTER or Ctrl+ENTER is
commonly used for executing the current input; Crtl+Tilde might hide the console; etc.
REQUEST
To support using Scintilla as the interface for custom command consoles, I place this feature
request for 4 new related commands (command names are tentative):
1) SCI_SETBARRIER (int line)
Assign a line as the current barrier. It is not possible to navigate to a line before the barrier line,
nor is it possible to modify the contents before the barrier.
However, it is possible to select and copy text before the barrier.
Even when selecting and copying content before the barrier, the cursor remains at or after the barrier line.
The barrier can be removed by passing -1 as the line.
2) SCI_ASSIGNSHORTCUT (int keyDefinition, int userValue)
Adds the ability to listen to specific shortcut keys, to receive notifications of shortcut commands.
This behaves similar to 'SCI_ASSIGNCMDKEY' but, instead of invoking a builtin Scintilla command,
it emits a 'SCN_SHORTCUT' message.
The 'userValue' is an arbitrary int that is send to 'SCN_SHORTCUT', to determine which shortcut was activated.
3) SCI_CLEARSHORTCUT(int keyDefinition)
Unregisters a shortcut.
4) SCN_SHORTCUT
A notification that is sent when Scintilla intercepts a previously registered shortcut, defined via SCI_ASSIGNSHORTCUT.
The key and the modifiers are present in the 'SCNotification' object, as well as the 'userValue' associated with the shortcut.
Whenever this notification is emitted, the state of the modifier keys (Ctrl,Alt,Shift) is passed within SCNotification.
This way, a developer can register "Ctrl+Enter" as a shortcut, but can implement additional actions if
the SCN_SHORTCUT handler detects that 'Shift' was also held.
A new field is added to the SCNotification struct: 'int result'.
This new 'result' field is used to communicate info back to Scintilla. It represents the
return value of the SCN_SHORTCUT notification.
Set 'result' to 0 to represent that the shortcut was not handled by SCN_SHORTCUT, and thus
Scintilla should perform whatever default action is associated with that shortcut.
Set 'result' to 1 to represent that SCN_SHORTCUT did handle the event, and Scintilla should
not interpret the shortcut keys any further.
Before emitting SCN_SHORTCUT, Scintilla sets 'result' to 0.
Example use of the 'result' field:
The developer registers the ENTER key as a shortcut. The user writes text in the Scintilla-based
console and presses ENTER. The SCN_SHORTCUT handler is invoked. At this point, the host command processor
inspects the current input-buffer to determine if the command can be executed, or if the command
is not delineated and thus ENTER should be interpreted as a new line. The SCN_SHORTCUT handler
sets 'result' value to 0 if it executed the input-buffer, or to 1 if Scintilla should output a newline.
Please, consider the following portion removed (I can't edit the post), as I realized that this is problematic:
Applications have complete control over keyboard input so I don't see the need for the
*SHORTCUTAPIs. The application may handle keyboard input in the message pump or by intercepting the events going to Scintilla. Even if they are needed, they should be in a separate issue to allow this issue to concentrate on the barrier behaviour which I see as complex and needing further definition.Scintilla, like most GUI text editor widgets, combines the caret (text cursor) with the selection such that one end of the selection is the caret. This is baked deeply into a lot of the code and API so any change will likely require resolution in many places. If you scroll the pre-barrier text and select some of it, are you not 'navigating' to this text?
Can you use the arrow keys to select pre-barrier text? Can you use the mouse to select text that straddles the barrier? I presume there is only ever a single selection: that is, there can not be a pre-barrier selection and post-barrier selection at the same time as that would complicate the meaning of commands (like copy).
Scintilla currently supports styles that are not changeable with the
SCI_STYLESETCHANGEABLEAPI. For the desired behaviour, the pre-barrier text could be styled with a non-changeable style or set of styles. Currently, non-changeable styles disallow selections inside that text although it is possible to select a range over a whole non-changeable piece of text along with neighbouring changeable text. There could be a new attribute (or global flag) that allows selection inside non-changeable text.Thank you for the reply.
If, in your opinion, the shortcut functions are of no value, then I'll defer to your judgment. In this case, please consider them removed from this ticket. The crux of the feature is the barrier functionality, so I'll focus on that.
Overall, the idea is to enable Scintilla to emulate the basic functionality of terminals. I'm sure that, like myself, you have used plenty of terminals and consoles, so I'll presume that both of us have the same general idea of their usual behavior.
I understand that, for technical reasons, there might be challenges that could prevent some of the implemented behavior to be as initially idealized. The functionality need not be perfect in order to be useful. Personally, I would be perfectly content with a reasonable approximation of common terminal behavior.
To me, it's joyful to think that doing SCI_SETBARRIER(line) would give you 80% of the behavior of a basic terminal. The rest of the 20% is dealing with the current input buffer and interpreting possible shortcuts. There is something magical about the idea that a single command could provide so much functionality.
With regards to your queries:
If you scroll the pre-barrier text and select some of it, are you not 'navigating' to this text?
From a conceptual perspective, I don't consider that navigating to the text. From the POV of a GUI user, the "caret" is still at the input-line (even if Scintilla considers it moved). It would be helpful if there is still a "blinking caret" at the input-line, but I could accept it as technical limitation if it's not possible. If it is the case that selecting text causes the caret to temporarily disappears, then I would just consider that as unorthodox, but acceptable, behavior. However, it would be important that if the user starts typing, that input does happen at the input-line. If there is a selection when typing happens, then the selection is lost.
Can you use the arrow keys to select pre-barrier text?
No. Only the mouse can be used to select pre-barrier text.
Can you use the mouse to select text that straddles the barrier?
If by this you mean a selection where part of it is before the barrier line, and part of it is at or after, then: I am completely fine with either allowing it or not allowing it. I think that behavior is of little consequence. In this case, I would say that the implementation should take the simplest route.
I presume there is only ever a single selection: that is, there can not be a pre-barrier selection and post-barrier selection at the same time
Correct
Regarding the 'SCI_STYLESETCHANGEABLE'. I've spent a certain amount of time trying to implement the behavior I've described using existing facilities. I've come to believe that the proper solution requires native support from Scintilla. I can only point to a 'feeling' as a programmer that the correct answer is to do SCI_SETBARRIER(line) and boom! Scintilla is now a command console.
My initial impression is that
SCI_SETBARRIERhas too narrow a purpose while touching too much code. Smaller changes to existing features are more likely to be achieved and stay maintained. I expect a limited addition of selection toSCI_STYLESETCHANGEABLEor an equivalent using indicators will provide a large portion of the desired behaviour and experience with that can inform further work.A disappointing outcome. I thank you for having consider it.
Regards
You can, of course, implement whatever you want in your own fork. It's possible your requirements can be achieved in a way that has less impact than I foresee.