GitLab

To only run if the pound/hash sign is at the start of the line.

This reverts commit e4fb53e8.

Should have gone into master, not into the 2.0 release branch.

By moving the completion settings into the TextEditor plugin, so that
both the CppTools and the QmlJSEditor plugins can access the settings.

The user-interface to edit the settings is still in the CppTools plugin,
since we're in string freeze at the moment. It should be moved to the
TextEditor plugin later.

For now the QML completion only supports the case-sensitivity and
partial completion options, since there is no automatic insertion of
brackets.

Task-number: QTCREATORBUG-1327
Reviewed-by: Daniel Molkentin <daniel.molkentin@nokia.com>

Reviewed-by: mae

The fake tooltip duplication is not nice.

Reviewed-by: mae
Merge-request: 133

The problem was that for

Foo::Foo
(|)

when the user triggers completion at |, startOfLine() returns a token
that's not on the current line and not yet tokenized by that instance
of the BackwardScanner.

As a fix I explicitly ask the instance to tokenize up to the given
index.

Task-number: QTCREATORBUG-673
Reviewed-by: Roberto Raggi

Fixes QTCREATORBUG-787

Reviewed-by: Erik Verbruggen

This reverts commit 2a59d2ae.

Because apparently, while designing the Objective-C language, somebody
thought it was a world-class idea to allow any white-space between the
'@' character and the subsequent keyword. With this fix, we now
correctly parse:
    @  dynamic
and:
    @
      selector
and:
    @"foo"
     "bar"
    @"mooze"
(This last one is 1 single string split over multiple lines.)
Wonderful, isn't it?

What we (and Clang) do not support, but what GCC supports is something
like:
   @"foo"@@  "bar"  @"mooze"  @@
which is equivalent to @"foobarmooze".

foreach()-Loops.

Avoids some annoyance for people using case-sensitive completion, when
unrelated completions items would get higher relevance because they
start with the typed string when matched case-insensitively.

In case-insensitive mode, a case-sensitive prefix match now does get a
higher relevance than a case-insensitive match.

Reviewed-by: con

Even when an upper case character can also match a lower case one, it
should only be treated as a CamelCase match when the matched character
is also upper case. This avoids some false positives.

Also, the part that allows a word in a CamelCase identifier to be
truncated should never be matched case-insensitively.

By default now only the first letter is case-sensitive. It is still
possible to choose full or no case-sensitivity as well.

Task-number: QTCREATORBUG-236
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>