<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 14/07/19 09:27, Dominik Haumann
wrote:<br>
</div>
<blockquote
cite="mid:CALi_srBW6wwMkwtWYfokQ+MebpuRSP+Ffmj=Yz+Amt0v01tdHg@mail.gmail.com"
type="cite">
<div dir="auto">I symlinked compile_commands.json in my
KTextEditor git folder to the existing one in the build folder.
Have to investigate whether any wrong paths appear...
<div dir="auto"><br>
</div>
<div dir="auto">I am not using the cmake kate generator, I only
have the option -DCMAKE_COMPILE_COMMANDS enabled...</div>
<div dir="auto"><br>
</div>
<div dir="auto">Have to check again...</div>
<div dir="auto"><br>
</div>
<div dir="auto">Best regards</div>
<div dir="auto">Dominik</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Christoph Cullmann <<a
moz-do-not-send="true" href="mailto:christoph@cullmann.io">christoph@cullmann.io</a>>
schrieb am Sa., 13. Juli 2019, 17:07:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
> For "Goto Declaration", this is actually "normal" and
that also<br>
> happens here. That is because a (slightly older) clangd
does not<br>
> support that method, as reported in the (error) reply.
Unfortunately<br>
> there is no (spec'ed) way to detect that client-side,
which is why the<br>
> action is still enabled. So as long as "Goto Definition"
and the<br>
> others still work, then it is about as OK as it can be
...<br>
> <br>
> More generally, there will always be some cases where the
server does<br>
> not handle something in some way, and where it may feel
that is due to<br>
> kate/lspclient. In this case it might be detected by the
error reply<br>
> but there are other cases as well. For instance, the<br>
> "includeDeclaration" (for Find References) is checkable,
but neither<br>
> clangd nor python-language-server consider that setting
(when<br>
> translated to protocol level), and so the result of "Find
References"<br>
> will be the same whether or not enabled ... So no way at
all to<br>
> detect that, which is why I was considering disabling
that<br>
> configuration option, but then again other servers might
properly<br>
> support it (or also clangd in some time) ...<br>
> <br>
> The "Failed to find compilation database" part that
clangd reports<br>
> might also be a bit worrying here, but may or may not be
relevant ...<br>
<br>
For me the plugin didn't work with clangd because I did setup
my <br>
development<br>
stuff via symlinks and therefore the compilation database file
names <br>
didn't match<br>
the "canonical" file names Kate provided.<br>
<br>
I changed my config to use the canonical file names for the <br>
kdesrc-buildrc and<br>
since then this errors vanished.<br>
<br>
Btw., I just tried the current state, very nice!<br>
<br>
Find references is really useful!<br>
<br>
Highlight with the jump list is nice, too.<br>
<br>
Greetings<br>
Christoph<br>
<br>
-- <br>
Ignorance is bliss...<br>
<a moz-do-not-send="true" href="https://cullmann.io"
rel="noreferrer noreferrer" target="_blank">https://cullmann.io</a>
| <a moz-do-not-send="true" href="https://kate-editor.org"
rel="noreferrer noreferrer" target="_blank">https://kate-editor.org</a><br>
</blockquote>
</div>
</blockquote>
<tt><br>
If files have "several identities" due to symlinks, then things
might get confused indeed.<br>
<br>
I pushed some more commits that add support for diagnostics; a tab
to display those as well as adding highlighting and marks
(configurable in either case). On that topic, I selected
markType30 (and markType31 for "references" and so on), not clear
on if/how this is coordinated in some way, but looks like those
are not yet in use elsewhere, so I picked those (for now at least)
along with the predefined for Error, Warning.<br>
<br>
Perhaps some of the presentation could be improved (also not on my
best points ;-) ), but it should be ok-ish as it is ... If
enabled (by default), and the compilation database is not properly
found, things might turn quite colorful real fast ;-)<br>
<br>
Along the way I noticed that a 'showToolView' call seems to move
focus away (to where??) from the main (text) window if the
toolview is not yet shown (otherwise focus stays on text). The
same happens when clicking around on one of the toolview tabs.
Perhaps that is intentional, but also a bit surprising when only
showing a listing (in a toolview) that needs no focus, and have
not found a way around that.<br>
<br>
In next steps, I will probably tweak some configuration a bit,
consider "document revision id" (as mentioned earlier) and use
those in positions and dealing with TextEdit (as to be returned
from e.g. (range)formatting commands and "fixit" commands).<br>
<br>
</tt><tt>Regards,<br>
Mark<br>
</tt>
</body>
</html>