CCManager settings dialogue plan

[Alpha]

I will be trying to draft up a settings page for CCManager as soon as I am able.  Before then, I wanted to ask some opinions.
Settings belong in different categories; program interface choices should be in CCManager, language specific choices should be in the relevant plugin.  My current thoughts (restricting to items that are not implemented) are:

CCManager/sdk side:

• enable code completion (global)
• enable tooltips (+display options)
• enable documentation popups (+display options)
• autolaunch CC after typing x characters
• timer delay for autolaunch after trigger character (generally scope/member type operators)
• case (in)sensitive CC
• autoselect on single match
• sort method... someday that YCM code path will be cleaned up and committed..

Plugin side:

• "fillup characters" - typing one will autocancel CC
• enable CC - (different than in sdk) this is if two CC plugins can provide for the same editor; CCManager will still only execute one of them, but this would allow a deterministic choice of which one

Is there anything I am missing?  Items you think should be in a different category?

[oBFusCATed]

You've forgotten to mention the c++ parser settings and the settings for the symbol browser.

Do you plan to make a separate dialog or you'll keep the one in the Settings -> Editor?

[ollydbg]

You've forgotten to mention the c++ parser settings and the settings for the symbol browser.

These options are language specific, right?
So, they should be in plugin's configure panel.

[oBFusCATed]

These options are language specific, right?
So, they should be in plugin's configure panel.

Probably.

[Alpha]

Yes, those were my thoughts as well.  (I did not bother mentioning since those settings are already implemented.)

• timer delay for autolaunch after trigger character (generally scope/member type operators)

How many people would actually make use of such an option?  I think the interface looks cleaner without this, and maybe a reasonable default is good enough for everyone?

Since there is extra room under general settings, I think we can fit the options there:

(The combo box contains "disable", "enable", "force single page".)

[oBFusCATed]

How do you plan to handle the per-plugin panels?
Are they going to be a part of the CC settings or every plugin will register a separate item in the list in the dialog?

[Alpha]

Plugin settings pages I plan to leave as is.  They are still their own plugin, so I see no reason not to.

As for panels (such as scope and symbol tree), I hope to create a generic interface that plugins can share someday.. but that will have to wait.

[oBFusCATed]

Plugin settings pages I plan to leave as is.  They are still their own plugin, so I see no reason not to.

This will be quite messy from the user friendliness point of view, but I guess it is OK as first step.

[Alpha]

Has anyone timed how expensive (or cheap) ConfigManager::ReadXXX() calls are?  Should I avoid using them during CC operations (caching settings instead)?

[oBFusCATed]

It depends how often they are called. If it is million times per second, I suppose it will make a difference, otherwise I doubt it.

[Alpha]

Committed.

@ollydbg: Are you still working on remove unused variables in CC, they are mostly in CCManager(SDK)?  The other part of these settings is to remove the redundancy from CC, but I do not want to duplicate your work.

[ollydbg]

Committed.

Good job.

@ollydbg: Are you still working on remove unused variables in CC, they are mostly in CCManager(SDK)?  The other part of these settings is to remove the redundancy from CC, but I do not want to duplicate your work.

I will work on it. But there are some extra code changes. If you look at the option of "case sensitive", each parser instance has such option, and if we have many cbps opened by CC, we can set them differently for each parser instance. But now it becomes a global option. Maybe, there are other options we need to handle, so it will take some time to handle those issues.

I will post a patch when I finish the work in one or two days in that thread.

[scarphin]

May I suggest a 4th option under 'settings -> editor -> general settings -> editor settings -> code completion -> tooltips' called 'enable on keypress only'? The reason being is my autohotkey shortcuts for navigation doesn't play nice when the mouse pointer unintentionally comes over a piece of code when scrolling by keyboard and shows a tooltip automatically which screws up the navigation completely. It would be nice to have an option to activate both tooltips and calltips (I think they are different as calltips can only be activated on function names) only by shortcuts.

Btw if someone can point me to the piece of code where popup window colours are handled, I'd like to submit a patch to register them in 'settings -> environment -> colours'. Thanks.

[afc888ny]

May I suggest a 4th option under 'settings -> editor -> general settings -> editor settings -> code completion -> tooltips' called 'enable on keypress only'? The reason being is my autohotkey shortcuts for navigation doesn't play nice when the mouse pointer unintentionally comes over a piece of code when scrolling by keyboard and shows a tooltip automatically which screws up the navigation completely. It would be nice to have an option to activate both tooltips and calltips (I think they are different as calltips can only be activated on function names) only by shortcuts.

I hereby support the above motion! 
The option to activate both tooltips and calltips must be included, this truly is a regression!

[Alpha]

Apologies for not being able to respond earlier.  I will look into this over the weekend, and see what is possible.