[PATCH 0/8] SymbolView: Be a little smarter and avoid cpu last

[Kåre Särs]

Hi,

On måndag 23 juli 2018 kl. 13:21:44 EEST loh.tar wrote:
> 1st
> Sorry that my reply to Christoph goes to the wrong place.
> Copy&Paste of the reply link to mutt seams not to work properly.
> Now I try it with a change of some & to ? and a little edit, but the mutt
> doc is a bit confusing, sorry in advance if it goes wrong again.
> 
> Yes, of cause, I should simply join this list.
> 
> 2nd
> Thanks Dominik for your invitation/motivation.
> 
> I'm not sure to take the challenge to improve the code by it's logic, but
> when I would start with a whole reformat and perhaps some search&replace.
> If you like I can do it independent to some further codings.
> 
> So any advice to that?
> 
> I would reformat with astyle as noted here
> https://community.kde.org/Policies/Kdelibs_Coding_Style
> 
> For search&replace I have now no concrete example but that may affect
> naming of variables, functions and perhaps the whole plugin name.
> 
> Above link says...
> 
> > Each new word in a variable name starts with a capital letter (so-called
> > camelCase)
> 
> ...which is what I like but there are some member variable (re)named to
> m_foo (see d8c8c47723) which is not noted in above link and I dislike. I
> would rename these to mFoo but perhaps is m_foo the way a member variable
> has to be named by some rule.

The m_ prefix is used to clearly distinguish class-member variables from the 
local variables in a function. Personally I have also sometimes used u_ prefix 
for ui-member-variables when a class is inherited from a .ui file and not just 
used as a member variable in a class.

I don't think changing m_foo to mFoo would be a good idea. 

> 
> To the plugin name "Symbol View" I have no image, no clue why it is named
> this way, but maybe can someone give me a hint.
I guess it comes from the fact that it shows the "symbols" of the source file. 
I'm not sure "Symbol" is the best word for it, but that's what it has been ;)

> 
> "Structure View" or shorter "Structure" would make more sense. The caption
> on the tab can change e.g. to "Parts" when the current view mode change
> from tree to list.
I don't think it is a good idea to rename a plugin-tab depending on it's 
settings. You have to remember what state you left the plugin in when you 
visually search for the tab.

"Structure" is not the best alternative if the user enables sorting.

> 
> Last thought: Is the whole concept of the current parsing perhaps bad? I'm
> not sure but exist there not smart ways in syntax highlighting? It's only a
> gut feeling that this is very similar to the needs here.

I think the Symbol List/Viewer does have a problem with the c++ hardcoded 
parsing of the files. Most of the stuff is already parsed in the highlighting 
and I wonder if it would not be better to get the information from there. It 
would also enable adding support for new file types without compiling the 
plugin. The plugin seems to have worked good enough for the current users, but 
maybe you have an itch to write a new plugin that does the same but uses the 
suntax-highlighting to help find the interesting "symbols" ;)

> 
> 3rd
> As noted in the wrong placed reply to Christoph, needs these home page a
> review. Not only https://kate-editor.org/build-it/ but /join-us/ too.
> The link there to the coding style is e.g. outdated and there is again the
> invitation to send patches to his list.
> 
> (No, I will not report this at some other place again if you like to suggest
> that)
> 
> Greetings, Lothar

Greetings,
  Kåre