Better default values for some options

[pintassilgo]

Not important, as users are encouraged to change options as they please, but I'll use this topic to suggest some non-default values that I believe should be default, looking at how other popular editors behave.

• auto_close_brackets should include quotes (" for sure, maybe ').
• autocomplete_autoshow_chars should be 1 to suggest right from the first char.
• autocomplete_closing_delay should be 0, there's no reason to keep autocomplete popup open for a moment when there's nothing in the list, some users can even wonder if this is a bug or bad performance.
• autocomplete_commit_chars should be empty, it makes no sense for me to accept the suggestion when user types , or ; and none of the editors I tried behave this way. Edit: I just confirmed VSCode behaves like Cuda in this. I still find this weird, but if the most popular editor agrees with current Cuda, keep it as it is.
• key_end_to_nonspace should be true. I see no other editor using this and I see no advantage. Not stopping before spaces can even help to detect trailing spaces (when user don't use the option to print spaces).
• key_up_down_allow_edge should be true. I've never seen an editor with the default Cuda behavior and sounds like a bug, If you're at the middle of the last line and you press down, it's expected to jump to the end of the line.
• minimap_show this one is debatable, but it would be good to expose minimap by default, editors having this feature usually do this.
• py_caret_slow the delay to highlight brackets looks like a bug. I use 100 and it's way better, without hurting performance.
• show_cur_line this one is also debatable, but I believe it's a good feature to highlight current line to be easier to find where caret is.
• show_mouse_sel_frame the rect drawing when you're making a simple selection with mouse is ugly in my opinion, I don't like it and I've never seen any other editor doing the same.

---

Update: all but autocomplete_autoshow_chars, autocomplete_closing_delay, minimap_show and show_cur_line were changed as I suggested.

[Alexey-T]

show_mouse_sel_frame changed to false.

[Alexey-T]

key_up_down_allow_edge changed to true.

[Alexey-T]

key_end_to_nonspace should be true. I see no other editor using this and I see no advantage.

but it is true already! you mean false coz ST4 and VSCode works like with false. will change it.

[Alexey-T]

autocomplete_closing_delay should be 0, there's no reason to keep autocomplete popup open for a moment when there's nothing in the list, some users can even wonder if this is a bug or bad performance.

default-config writes the reason for non-zero!

Delay (in msec) of closing the auto-completion listbox, when there are no matching words.
If value=0, close the listbox immediately (but it gives flickering with LSP plugin,
when you press Left/Right arrows with LSP listbox).

[pintassilgo]

I use LSP and 0 for this value, but don't know how to reproduce this issue. all seems normal to me.

[Alexey-T]

autocomplete_autoshow_chars should be 1 to suggest right from the first char.

but it gives slowdown of usual work. now app will be trying to call autocompl-plugins on usual typing. bad!

[pintassilgo]

Have you confirmed that in recent Cuda versions? I type everyday in a textfile with >3k lines, with multiple phrases in each line, with "complete from text". There are probably thousands and thousands of different words, and everything is absolutely instant, not the very minimal signal of slowdown.

I had this kind of issue a year ago when I met Cuda, but there were infinite improvements since then. My hardware is still the same and it's now absolutely instant without any slowdown. Just as it should be, because if other editors can handle autocomplete on first char Cuda should be able too, and it is.

[Alexey-T]

I consider slow PCs. on slow PC, calling of autocomplete event is taking some small pause. I want to keep this off.

[pintassilgo]

calling of autocomplete event is taking some small pause

Just asking, have you recently confirmed this? Or are you remembering from old experience?

[Alexey-T]

I remember that Off is much better for me, I have Python LSP and calling of compl on typing was very bad for me. also I use "Python IntelliSense" plg on 2nd Cud installation, and it gives pauses.

[Alexey-T]

auto_close_brackets should include quotes (" for sure

added dbl-quote, OK.

[Alexey-T]

SF.net got new bad comment

This project is promising, but the UI is too sluggish. For example, after you toggle an option it takes like a second for the checkmark to show up. Also, when you put the caret on a bracket, it takes another split second for the bracket highlight to trigger. I admire the program for taking magnitudes less memory than VS Code, but VS Code feels a lot faster to work in. When you work in code at least eight hours a day, all that speed adds up.

I wrote at SF:

You mentioned 2 pauses: 1) menu checkmarks updating. Yes, app updates menu checkmarks not immediately but only on 'app is idle' event. This is made to prevent slowliness on editing the code. On purpose. We have option to change this pause: "ui_timer_idle" (default is 1000 msec). 2) pair brackets highlight. Yes, app finds and highlgithes brackets not immediately on caret move, but after a delay. This is made on purpose too, to avoid bigger CPU usage on caret moving. We have option to change this: "py_caret_slow", change it to e.g. 50 (msec) and brackets finder will be fast (but CPU usage may grow).

do you suggest to make smaller default of 'py_caret_slow'?
e.g. to 100 or 80.
if yes, measure CPU usage pls, when we move caret by holding the Down or Up arrow.

[pintassilgo]

I already talked about py_caret_slow in my initial comment, one of those you skipped in your comments.
On moving caret by holding up arrow, CPU increases from 0 to 5 or 6%, and it's the same no matter if I use 100 or 500 for that option.

Regarding these cases such as py_caret_slow and ui_timer_idle, I suggest the same I did here and you dismissed. Cuda should avoid using timers unless strictly needed. Handling things with events is always better, even if it can take a little bit of work to add to the code when compared to simple timers.

[pintassilgo]

For instance, why not update checkmarks under something like onshow event on menu (or something like that)? Or onmouseover menu... I don't know what are the available events, but surely there are many better options than using a timer.

[Alexey-T]

I guess the 'on_show' for top menu may fail, if user has custom menu (made by Config Menu plugin). it may fail already for disabling menuitems in File/Edit menu, with Config Menu. I only guess here.

[Alexey-T]

I reduced values of py_change_slow to 1500, py_caret_slow to 100. so bracket-hiliter must work much faster.

[Alexey-T]

Wait, in one of last 2 versions, I changed the updating of View/Edit menu checkmarks/enable-states. now they are updated W/O ANY PAUSE, instant. I forgot about it.
It maybe works ok with Config_Menu plug too.

add here that now, in 1.214.6 (updated w/o version change today), py_caret_slow is 100. very fast.

[pintassilgo]

Yes, in a quick test checkmarks look instant now, good.

[Alexey-T]

show_cur_line this one is also debatable, but I believe it's a good feature to highlight current line to be easier to find where caret is.

VSCode has it on. ST4 has it off. Not sure what is better. I keep it as is.