| Summary: | Auto-brackets does not work with double quotes and 'wide' strings | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | Laurence Withers <l> |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | m.lukosius, opensource, t.bergmann |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Laurence Withers
2005-12-05 13:29:21 UTC
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... |