Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Python Code Completion
dmoore:
--- Quote from: darmar on October 30, 2012, 09:50:21 am ---
--- Code: ---Index: src/plugins/codecompletion/codecompletion.cpp
===================================================================
--- src/plugins/codecompletion/codecompletion.cpp (revision 8464)
@@ -727,8 +727,12 @@
if ( ParserCommon::FileType(filename) == ParserCommon::ftOther
&& Manager::Get()->GetPluginManager()->IsFileExtRegistered(filename) )
return;
--- End code ---
The idea is the same as in dmoore's patch. The function "IsFileExtRegistered" is doing similar thing as "IsProviderFor(ed)" in this patch.
--- End quote ---
I am a little confused by this. Is it only the plugins other than CC that register files? So only IsFileExtRegistered returns true only for Fortran files if only CC and fortran plugins are installed?
For python, I thought it made the most sense to rely on the lexer to decide what to offer python code completion for, but basing it on file extensions might make the most sense in other cases. The patch I proposed leaves it to the plugin to decide what it wants to do.
darmar:
--- Quote from: dmoore on October 30, 2012, 05:22:20 pm ---Is it only the plugins other than CC that register files? So only IsFileExtRegistered returns true only for Fortran files if only CC and fortran plugins are installed?
--- End quote ---
I think, currently only FortranProject plugin registers the file extensions for IsFileExtRegistered and, consequently, it returns 'true' only for Fortran files (if FortranProject plugin is active).
--- Quote ---For python, I thought it made the most sense to rely on the lexer to decide what to offer python code completion for, but basing it on file extensions might make the most sense in other cases.
--- End quote ---
The editor's highlighting (lexer) is based on file extensions anyway.
--- Quote ---The patch I proposed leaves it to the plugin to decide what it wants to do.
--- End quote ---
The same situation is in the current implementation: every CC plugin (FortranProject, PythonCC etc.) decides which files (recognized by file extension) it wants to handle and registers the file extensions accordingly.
I don't argue, that the current C::B implementation is better. If developers think that the new patch is better (simpler, shorter, easier to understand etc.), it is OK.
MortenMacFly:
I think in all cases, we can summarise:
- CC can be based on either file extension or lexer type (cbEditor)
- for file extensions we have a file extension registry, that might be mis-leading
- for CC, we have an own file extension registry, that must not be compatible with the global file extension registry
- the file extension registry is not error-free, as it does not offer constant ID's for groups of files
- solution 1 (dmoore) provides an cbEditor to the plugin to have the pugin decide what to do with it
- solution 2 (darmar) provides a file extension to the plugin to have the pugin decide what to do with it and plugins can/have to register file extemsions they care for
- solution 1 is implemented via patch, not yet fully tested
- solution 2 works already
Drawbacks I see for both are (for example): STL header files. Those files do not have no file extension and no lexer style.
However, a CC plugin might know by the file's name it if can be interpreted. cbEditor provides both: The (Scintilla) editor and the file name as backup. So unless we have use cases were we have no cbEditor (do we???) this seems like a more generic interface. (One case I can think of is querying for a file's function w/o having it opened.)
Maybe a combination of both approaches is the best?
dmoore:
Morten: agree with what you wrote above. Note that my patch is only attempting to solve the problem of what plugin should offer it's GUI when the user is editing a file. A separate issue is what files the plugin should parse to extract symbol information. E.g. for CC it is all project files and everything #included. In that case you can't rely on having an editor available. But I still think it is useful to have the option to use the language info of the editor for offering the UI if for no other reason than that the user can manually change it (this comes up a lot when editing python scripts that don't have an extension, but that could be solved with sniffing I guess)
darmar:
I have tested dmoore's patch. It works fine with some changes.
My comments:
1) If plugin cares for code-completion list and call-tips, it should care for tool-tips too. Therefore the call to 'IsProviderFor(ed)' should be added in 'OnEditorTooltip' function too.
2) The call to 'IsProviderFor(ed)' was added in 'CodeComplete()' function. I think, this call should be moved near to the start of function 'DoCodeComplete()', because 'DoCodeComplete()' cares for making the code-completion list for the C/C++ preprocessor ('#...') and then calls 'CodeComplete()' (no other function calls 'CodeComplete()'). In my opinion, CodeCompletion plugin should suggest CC list for preprocessor for C/C++ only (e.g. '#' is start of comment in Python).
I have attached a patch for codecompletion.cpp. I have deleted calls to 'IsFileExtRegistered' in this patch also.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version