We already detected that `slint!` in a comment should not be interpreted
as a slint macro, but that detection failed for `slint::slint!` or if
`slint` was twice in the same line.
Basically same as e88b07997f but in the
set_binding_command function.
(made the code more similar to remove_binding_command, I think the two
function should be merged in the future)
This fix editing binding within the root component when it inherits from
something.
Stop the LSP from reporting progress information on file loading. This
caused problems with VSCode: First it triggered popups in the UI and
secondly it caused problems for the LSP that was asked to process
requests while calling back into the client.
Adapt the online editor and the two VSCode plugins to work with the
updated code.
Note: I did leave in the progress reporting code that can be used to
handle progress initiated by the _client_ side. That is just
notifications which will not block the LSP in any way and we might need
to support that at some point.
I did remove the Middleware code from the client side though that acted
on the progress information.
Currently, the reported range is the range of the root element, which
doesn't include the name of the component itself.
While the Name of the component itself is used as the selection range.
Vscode assrts that the selection range is within the range:
```
ERR selectionRange must be contained in fullRange: Error: selectionRange must be contained in fullRange
```
So use the full component range for the range instead
This changes how the selection range is picked: Instead of using the
`QualifiedName` of the root element, look at the Component's
`DeclaredIdentifier`.
This fixes component declarations without `inherits` clause and is also
nicer than the old approach: We would use the Component id as a name of
the DocumentSymbol and set the inherited type name as selection range.
This is simpler than the previous version and will be easier to
reuse for line-wise deletion, too.
It does sacrifice indention level based (line-) comment splitting, but I
think that will not be missed...
Any comments up to a blank line _before_ a property will be considered to
belong to that property and any comment _after_ the property that starts
without a line break are part of a property now.
There is some extra magic to work when several properties are in the
same line: Basically all comments then refer to the following property.
Update tests accordingly...
Find the elements indentation level and make sure the following property
is indented.
This is a simplistic though as it indents 4 spaces more than the
Element's indentation level.
- Make the browser extention preview work
- Enable the properties tab on rust files
- Only call `offset_to_position_mapper` if the token is valid,
otherwise we might get an error visible in the UI.
This allows the OffsetToPositionMapper to not have a lifetime and
prevents it from holding a reference to the DocumentCache.
This makes things a lot as the OffsetToPositionMapper does not block
other uses of the DocumentCache anymore!
Extend the setBinding command of the LSP to also handle properties that
were declared but not defined yet.
This will enable us to add new properties (that were already declared
before).