Hi, reporting in =)
I'm also using UseTab=false, TabIndents=true, TabSize=4.
I not only can confirm this, but while reproducing it, I encountered 3 bugs :shock: in cbEditor.
1) The one noticed by jweathers is caused by Smart Indent, and you can reproduce it by typing "{" followed by ENTER.
Note that when I say "{" is the brace without quotes.
You also can see it that is a TAB instead of 4 spaces without leaving C::B (and I double checked it in SciTE and WinHEX):
Go to Editor->General->Whitespace options->View whitespaces (tabs and spaces) and set it to ALWAYS.
Well, I found that this bug was a Yiannis's TODO :) in sdk/cbeditor.cpp @ cbEditor::OnEditorCharAdded():
In if (smartIndent) block ...
// Original code:
if (b == '{')
indent << '\t'; // TODO: decide between spaces/tabs
// Must be something like this:
if (b == '{')
{
if(m_pControl->GetUseTabs())
indent << '\t'; // 1 tab
else
indent << wxString(' ', m_pControl->GetTabWidth()); // n spaces
}
2) This other bug is very ugly (and it took me a while to reproduce it)
How to reproduce it: Press "{" and ENTER and ENTER (without writting anything more than ENTER).
You can continue pressing ENTER and the indentation goes forever.
I guess that the bug this time is also in cbEditor::OnEditorCharAdded()'s @ else if (ch == '\n').
3) The 3rd isn't really a bug, but a design flaw.
The "{", "}", "<", and a lot of other chars in cbEditor are hardcoded to C/C++, but a lot of things in C::B are hardcoded to C/C++, so it's not THAT important.
But if you are writting a plain TXT or something, you wouldn't need Smart Indent and other things enabled.
So I think that all the Indentation and Auto-Completion functionality <maybe> can be moved to the Code-Completion Plugin.
Overall, I noticed that if something appears to be a bug of Scintilla/cbEditor, check it first if that happens in the Scintilla Editor SciTE (http://www.scintilla.org/SciTE.html).
The 3 bugs above aren't found in SciTE, so you can suppose that the bug isn't in Scintilla, but in cbEditor.
A side note: I use a lot of times SciTE instead of C::B because of minor flaws that C::B haves but SciTE Does It Right (TM) :(.
(Specially the margin thing: http://sourceforge.net/tracker/index.php?func=detail&aid=1201664&group_id=126998&atid=707419)
Bug submitted to tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1253490&group_id=126998&atid=707416 :)
Patch submitted here (http://sourceforge.net/tracker/index.php?func=detail&aid=1253699&group_id=126998&atid=707418)
1227c1227,1232
< indent << _T('\t'); // TODO: decide between spaces/tabs
---
> {
> if(m_pControl->GetUseTabs())
> indent << _T('\t'); // 1 tab
> else
> indent << wxString(_T(' '), m_pControl->GetTabWidth()); // n spaces
> }
About the diff app, the best is to use diff -u (unified format) right?
I mean the more secure, the less likely to mess if the files changes too much
:D, well, from what I understand:
For creating a diff/patch file in Windows:
download the diff utils at http://gnuwin32.sourceforge.net/packages/diffutils.htm
diff -u oldfile.cpp newfile.cpp > oldnew.diff
For applying a diff/patch file in Windows:
download the patch util at http://gnuwin32.sourceforge.net/packages/patch.htm
I'm not going to upload the separated files, SourceForge Grandfather :) reccommends (http://sourceforge.net/docman/display_doc.php?docid=24202&group_id=1#patches) diff for text patches and xdelta for binary patches. Although I found bsdiff (http://www.daemonology.net/bsdiff/) that appears to compress better than xdelta.
We'll need binary patchs for devpacks upgrading and C::B minor upgradings (ie. non-cumulative).
Coming back to #4 three weeks later... :)
After removing stale spaces from 6 header files for the 3rd time today, I wanted to know at least what made it go wrong.
This is one out of a several constellations (all related to preprocessor directives) which provoke the no-newline-at-end-of-file error:
#ifdef __cplusplus
extern "C"
{
PLUGIN_EXPORT cbPlugin* GetPlugin();
};
#endif
Another strange effect is duplication of the last line in the file if you additionally wrap the above into a standard multiple-inclusion protection. Funnily, that phenomenon does not occur if the curly braces are wrapped into individual #ifdefs.
That, however, I think is a known bug which has already been fixed in either HEAD or 1.0 (and merged?).