Version: (using KDE KDE 3.5.0) Installed from: Compiled From Sources OS: Linux When using the autobrackets feature in katepart, if I type e.g. std::string s = " then kate will happily insert a closing double quote for me. If, however, I type std::wstring s = L" (i.e. a 'wide' string using wchar_t as its base character), kate will not insert a closing double quote. I believe it should.
This is the bug I've waited for since the official release ;) It was changed due to a request, see bug 101213 - what do we do about it? Revert to old behavior? Kate devs? :)
The question is what occurs more often, I think writing wchar's is much less common than just trying to end braces at end of word one missed to insert. I am not sure if revert would be a good idea.
Is there any way to see if we are already within a string if the quote char is typed? E.g.: "editing some string| (cursor at eol) and then type " should just give a single character. But: functionCall(L|) (cursor after L) and then type " should give: functionCall(L"|") (cursor within quotes). Perhaps we could interact with the syntax highlighting in some way, since that knows when we're in a string?
i know the code isn't perfect of course, I was assuming that if you input a quote after a letter, chance are you want to terminate a string. I never saw something like this before ( L"" ) and still don't sure what that is. just like Christoph Cullmann said, odds are more the user is ending a string. do we want to add the character L to an exclusive list ? make custom settings either when should the autobracket works ? make predefine settings, like he is writting C, so L is a potential prefix for a widestring. i think its very hard to write perfect code for such a feature, nevertheless, I think the current behaviour is better than the previous. but my opinion would be WONTFIX, because widestring are not that common as far as I know, and pressing the double-quote character twice in this specific case isn't too big of a deal. but this is only my opinion. I'm curious to see next complains/bugs we will encounter considering this. thanks
Laurence, since you seems to be using the AutoBracket feature and you were probably using it already before, what do you think ? is it overall better ?
#4: you are aware that there is a wchar_t type, for storing wide characters? Well, you can also have wide strings: char ch = 'x'; // 8 bits -- only ASCII chars here wchar_t ch2 = L'x'; // 32 bits -- you can specify unicode chars here const char* string = "ascii string"; // or std::string const wchar_t* str2 = L"unicode string"; // or std::wstring As a simplification, you can consider the encoding of wide strings as UCS-4 (not sure about 16-bit platforms, but...) #5: Overall it seems to be better. This problem in particular I don't think can be solved without context-sensitive parsing (i.e. going back along the line and looking to see if there is a matching open-quote; if not, inserting two). I have a couple of other ideas and I'll file a separate wish for those. So, what do you guys think? WONTFIX or LATER or...?
On further reflection, this has actually caused me to disable autobrackets. The problem lies when typing a string from scratch, e.g.: std::wstring p = L"...| (the cursor is at |). If I now type the closing bracket, I'm left with: std::wstring p = L"..."|" forcing me to delete the newly-inserted quote character. This unfortunately means the feature wastes more time than it saves on average, so I have disabled it. Obviously you can't cater for everyone's varied needs, but can anybody see an acceptable way forward?
*** Bug 120253 has been marked as a duplicate of this bug. ***
*** Bug 128680 has been marked as a duplicate of this bug. ***
Rejection of inserting double quotes is reverted. Should work again...