FR: Multi-line Commands

[chrisgrieser]

This would be useful for more complex commands. Right now, cramming everything into one file is a bit cumbersome.

Also, with the import/export feature, you would want to make commands more "thorough" or with a variable-configuration block at the top.

[Taitava]

Yes!

UI

From the UI point of view, I guess the shell command field could be a text area with a default height of one line. If a user types a newline there, then the textarea would grow in height.

But if the user is scrolling through many shell commands, then these long textareas can be bad. Should there be some way to collapse them into one line height? What would be a simple way to implement the collapsing? Edit 2022-04-17: No collapsing will be implemented at this point. I'll add a setting that can limit the height of the command fields (user defineable max count of visible lines).

Newlines

We also need to think about different newline characters in different OS's, especially if shell commands get shared between devices with different operating systems (via the import/export feature, or just by copying the data.json settings file). A solution to this could be simply to convert all newlines during execution to the newlines supported by the current operating system. Edit 2022-04-17: I think I'll just see how it goes without any conversions. If there will be reports about problems regarding newlines when sharing settings between multiple OSes, (i.e. if there's a shell that does not support all the possible newlines), then I'll do some conversion. I'm trying to avoid extra conversions (= clutters up code) if it's not actually needed.

Newlines in different OSes:
carriage return + line feed: Windows
line feed: Linux, and if I have understood correctly, in recent versions of macOS?
carriage return: Old versions of macOS?

[Taitava]

A problem with the autocomplete menu

kraaden/autocomplete, the library that SC uses to produce the autocomplete menu, does not officially support textarea elements.

I can force the autocomplete element appear on a textarea, but at least one problem is that when hitting Enter to use an item in the menu, a newline is also added to the textarea. It's a small glitch, but I don't know if it's the only one.

And for non technical people: a textarea means a multiline text input element. The current single line input element needs to be changed to a textarea element in order to make multiline work.

I can see two solutions here:
a) Fork the library and add the needed support for textareas. Edit 2022-04-16: I did this.
b) Create a setting for users to choose:
- A multiline shell command field with a slightly buggy autocomplete menu.
- Or: a singleline shell command field with a better working autocomplete menu, just like it is now. This would be the default option.

In the case of b, the setting would be removed later, if the autocomplete library would ever bring official support for textareas, or if I would end up forking it.

[Taitava]

Solved

• I was able to solve the enter key problem. Need to use preventSubmit setting; and also need to have this modification I made: Fix not being able to create newlines in a textarea when `preventSubm… denis-taran/autocomplete#89
• And to make it easier to use textareas with the library, I made another modification: Support for HTML <textarea> elements denis-taran/autocomplete#90

I'll see if those get merged to the library or not. If they won't, I'll use them for SC anyway.

I hope no more problems will occur with textareas.

[Taitava]

Beta test

#228

[Taitava]

Released

@chrisgrieser please let me know if you have any comments. 🙂