Scide Optional Help Popup Request

[smrg-lm]

Hi

This is a request.

For many purposes the in-code complex help popups are fine, but they can also be annoying for typing while watching the context of the code. Being an visually intrusive feature it could be optional, also because they apply to an specific workflow.

Best
Lucas

[jamshark70]

It is already optional. I think it's in the view menu.

The on/off switch isn't in Preferences. I argued once that it was confusing to put it in a menu rather than the preferences panel, but was voted down. So I have to note with a bit of "told you so" that here is another user who overlooked the option.

I'll keep the issue open, as it may be appropriate to change it into a request to move the pop-up help option into preferences.

[miczac]

On 25.Nov 2015, at 6:19 , jamshark70 notifications@github.com wrote:

It is already optional. I think it's in the view menu.

uh .. View -> Show Autocomplete Help (cheers!)

The on/off switch isn't in Preferences. I argued once that it was confusing to put it in a menu rather than the preferences panel, but was voted down. So I have to note with a bit of "told you so" that here is another user who overlooked the option.

+1 - overlooked it :\

[smrg-lm]

...that is good.

My experience was:

• Sin
• a pop up shows with possible classes
• SinOsc
• verbose help pops up
• SinOsc.
• methods
• SinOsc.ar(
• argument tool tip (in white over yellow).

My thinking was:

• ok IDE, that was too much :-)

I would suggest make all that help optional because they can be visual noise. I know that is common in some code editors, and that is fine, but personally, if they are not visually pleasing or they don't show in the right moment, they can clog.

Lately I'm using emacs, all the help is shown in a different frame which doesn't clog the main visual field. I think the problem is in the dynamic of the shown information and the heavy feel of the scroll (down/right) popup widgets.

That is my thought.

[smrg-lm]

I argued once that it was confusing to put it in a menu rather than the preferences panel, but was voted down.

Who? Why? The preferences are the first place where users search... menus are for common actions/tools/shortcuts... or restaurants...

[telephon]

At that time I also argued for putting it in a menu as well, because (just like line numbers) it is something that you may want to switch fore and back, dependent on the situation. So if someone would add a pull request putting it there, I'd be happy, too.

[jamshark70]

I tend to associate the View menu with showing/hiding elements of the interface -- which, to an extent, presupposes that those elements will be persistent onscreen once activated. Pop-up class help isn't like that. It feels to me more like a matter of editor behavior, which I expect to control through Preferences rather than View options.

[telephon]

someone may want to connect a keyboard shortcut to toggling it on and off though.

[smrg-lm]

For me it is ok that being in the menu so it can be switchable, but it should be also in the preferences. And my "complaint" was for all that help to be switchable. Maybe not the tool tip for arguments, but I found myself hitting the scape key because it obtrudes (what a word hu!).