Comment/Uncomment plus other Smart Editing for alternative languages

[dmoore]

I'd like to make the comment/uncomment commands on the editor menu use lexer specific comments rather than "//"

the current code for uncomment is:

Code

            while( startLine <= endLine )
            {
                // For each line: if it is commented, uncomment.
                wxString strLine = stc->GetLine( startLine );
                wxString Comment = _T("//");
                int commentPos = strLine.Strip( wxString::leading ).Find( Comment );
                if( commentPos == 0 )
                {      // we know the comment is there (maybe preceded by white space)
                    int Pos = strLine.Find(Comment);
                    int start = stc->PositionFromLine( startLine ) + Pos;
                    int end = start + Comment.Length();
                    stc->SetTargetStart( start );
                    stc->SetTargetEnd( end );
                    stc->ReplaceTarget( wxEmptyString );
                }
                ++startLine;
            } // end while

it looks like this is just a simple matter of replacing Comment= _T("//") with a lookup to the Scintilla lexer...
is there an easy way to grab the comment token(s) from the currently active Scintilla lexer?

In addition, I'd like to add some "smart editor" features when editing python code. Most important of these is to indent one level deeper after pressing Return/Enter on a line ending in ":" . Can someone recommend an easy way to do this/some related code to look at? Should I do it in a separate plugin (i.e. in my python plugin) or in the core C::B code?

[Ceniza]

There's a method to get the current file's contents + the style/token of each character used by the current lexer, but you'll need to find which one applies to comments. If you think that's of any help check the Exporter plugin.

[dmoore]

thanks. I'll take a look.

[dmoore]

unless I'm mistaken, there is no consistent labelling of comment styles/tokens in scintilla for all languages. so to query scintilla for the comment token would seem to require different code for each language supported by cb, which is no better than simply hard coding the comment token for each language...

this leaves two alternatives:
1. add a comment (or "CommentBlock") property to each lexer property file (i.e. the xml files in CodeBlocks\share\CodeBlocks\lexers) containing the token or tokens. (Question: are these xml files available from cb's Config Manager?)
2. write a function that returns a hard coded token for each supported lexer, or nothing if the current language doesn't hasn't been hard coded (I've implemented this)

obviously 1 is better than 2, but 2 is still better than the current code... any thoughts?

also, can someone guide me on the preferred way to intercept keyboard input in the cb editor? As I said in my first post, I want to auto-indent python code when the user presses enter on a line ending with ":".

[mandrav]

also, can someone guide me on the preferred way to intercept keyboard input in the cb editor? As I said in my first post, I want to auto-indent python code when the user presses enter on a line ending with ":".

It all happens in cbEditor::OnEditorCharAdded() (cbeditor.cpp:2271). If you want to patch C::B for this, that's the code you should be hacking.
If you want to process these events outside C::B, see the documentation in the EditorHooks namespace (editor_hooks.h).

[dmoore]

thanks Mandrav

I'm happy to hack CB for the smart indenting, if you think this is best That might minimize the potential for clashes between CBs current c/c++ smart indenting and what is required for python (and other languages...)

For the comment blocking, I will definitely submit as a patch for CB since it should work for most languages. There's also a 3rd option:

3. create a single xml file containing the comment tokens for all supported languages (so as not to pollute the lexer files, if that's an issue)

[dmoore]

ok, I have a patch ready that does two things:

1. comment/uncomment for every language that supports single line comments. presently, I have done this by hard coding the comment tokens for each language. In a subsequent patch I will change this by adding the comment token to the lexer property xml files. I could also write a more general comment/uncomment to handle languages that only support comment token pairs (e.g. html uses <!-- and -->) by placing the each line within a pair (or placing the whole block in a pair)

2. smart indent for python code (any line whose last non-white space char is a colon will indent one level deeper). this also mean smart indent now only operates on files whose lexer is either cpp or python. I don't use other languages often enough to want to think about an appropriate smart indent for them, but I'll take requests. maybe there is a case designing a more flexible smart indent whose properties could be specified in the lexer property xml files? for example, the ideal smart indent in c++ would be to indent the next line following any flow control statement, but then dedent if the user presses { (and indent the next line, instead) although this might be impossibly messy to specify in xml...

as arbiter of cb taste, mandrav, what are your thoughts on:

a) if i submit the patch in its present form does it have any chance of acceptance? I imagine hard coding the comment tokens might be an issue, but i can always repatch later...

b) should i be using styledtextctrl::getlexer or cbeditor::getlanguage to determine the active language? I'm using the former because the language codes are clear cut in scintilla, whereas i couldn't find a well-defined list of strings describing each language for the latter (not that i spent a long time looking)

[mandrav]

as arbiter of cb taste, mandrav, what are your thoughts on:

a) if i submit the patch in its present form does it have any chance of acceptance? I imagine hard coding the comment tokens might be an issue, but i can always repatch later...

b) should i be using styledtextctrl::getlexer or cbeditor::getlanguage to determine the active language? I'm using the former because the language codes are clear cut in scintilla, whereas i couldn't find a well-defined list of strings describing each language for the latter (not that i spent a long time looking)

I would say go ahead. We can always refine the rough edges later. What's important is Getting Things Done .

[dmoore]

patch here: http://developer.berlios.de/patch/?func=detailpatch&patch_id=1839&group_id=5358

(i had a bad day and had to resubmit a few times. should work with latest svn now)