I guess if "somebody" made a PR it would get accepted.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3674#issuecomment-1793626965
You are receiving this because you are subscribed to this thread.
Message ID:
You can return `77` to tell Automake that the test was skipped.[^1][^2]
[^1]: https://docs.gtk.org/glib/func.test_run.html
[^2]:
https://www.gnu.org/software/automake/manual/automake.html#index-Exit-status-77_002c-special-interpretation
--
Reply to this email directly or view it on GitHub:
IIUC the call to `gtk_init_func()` is not inside a test, so `g_test_skip()`
will do nothing. The example you pointed out is inside a function that is
registered as a test. And that still leaves the question of what to return to
your test environment, pass or fail. As I said, returning pass
I was thinking it could work with
[`g_test_skip`](https://docs.gtk.org/glib/func.test_skip.html) (_"Indicates
that a test was skipped."_), like [used
here](https://github.com/geany/geany/blob/2.0.0/tests/test_sidebar.c#L71). It
looks like that isn't a GTK function, thus it should be safe to
Well, the test program should test the result of `gtk_init_check()` and early
out, but what to return, if it returns failure any environment where it doesn't
init is left with a failure to handle, but on the other hand return success
isn't right either as it gives the impression the test ran.
Hi, I'm working on updating the Geany package in nixpkgs from 1.38 to 2.0:
https://github.com/NixOS/nixpkgs/pull/265362.
With Geany 2.0,
[`tests/test_sidebar.c`](https://github.com/geany/geany/blob/2.0.0/tests/test_sidebar.c)
fails on nixpkgs' automatic PR builder (ofborg) on macOS, but not on
@kugel- as @techee said, but more bluntly, you do not seem to understand what
the Language Server Protocol (LSP, not Language Server Process for removal of
doubt) is designed for and are making yourself look stupid by arguing without
that knowledge. Please stop being disruptive, if you have
I'm not sure if I want to continue in this but one more round...
> So you're suggesting that any one editor or IDE may only implement features
> for that a specialized interface in the LSP exists, and no more? I.e.
> features that are blessed by the the LSP (=VSCode) folks?
Anyone can
> Using LSP only as an alternative source of tags doesn't make sense to me
> because it won't bring any better autocompletion or symbol goto so why bother.
Sorry, I didn't want to suggest to only grab tags from LSP. My point is that we
should grab tags from LSP at a minimum (and maybe use LSP
I like LSP in general. I have a problem with your narrow view ("in a way that
the LSP interface is supposed to be used", whoever defines what "supposed to be
used" means) that leaves the TM infrastructure behind for anyone that depends
on it. TM is still active but there is no provision that
@kugel- I'm really getting tired of these endless discussions that don't lead
anywhere. On the one hand you say "I like LSP because it seems to be industry
standard by now with lots of server-implementations", on the other hand you say
"Maybe if LSP severely limits the features we may implement
> I've just tried that but it parses all files at once right?
I believe the behavior is still the same. I just moved the code around a bit,
so only difference should be in timing. It parses each file separately, storing
the result in `data->source_files` and
> > I just don't like this proposal because it "hacks" LSP support into each
> > relevant use case instead of augmenting the existing TM infrastructure with
> > LSP information. It adds individual band-aids for each use case and leaves
> > behind other uses of the TM infrastructure (in other
Is the original performance problem with double-parsing too big? For fast
parsers like C or basically all the hand-written parsers unless you have some
really huge file open, parsing say 100 files is done in a fraction of second so
kind of irrelevant.
I think this problem is visible with the
> I've drafted the code for parsing each file separately in idle handler
> (https://github.com/geany/geany-plugins/pull/1291), to avoid blocking the UI
> for too long.
I've just tried that but it parses all files at once right? And adding all
files to TM is actually a feature. In the past
> Thank you, but my intended point was that it should be done offline before
> release (if not in CI), not when being used by a user, thats too late.
Yeah, but that would happen. If we do it every time Geany starts, it will also
happen for unit tests because these too launch the Geany binary,
Closed #3673.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3673#event-10863308834
You are receiving this because you are subscribed to this thread.
Message ID:
Closing, for anyone interested can be accessed from
https://github.com/geany/geany/pull/3668
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3673#issuecomment-1793507218
You are receiving this because you are subscribed to this thread.
Message ID:
I've drafted the code for parsing each file separately in idle handler (#1291),
to avoid blocking the UI for too long.
It would actually be great if something like this could be used in Geany itself
as well - only the current document needs to be fully parsed when opened, other
files might be
Another attempt at solving #1289, by deferring the parsing to idle time after
all files are open. It is far from elegant, but works.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1291
-- Commit Summary --
* load files when idle
> From my rather limited (10 mins) go knowledge func (bar int) string is the
> signature of a [function](https://go.dev/ref/spec#Function_types) that takes
> an int and returns a string. And when the programmer declared it they
> probably didn't even specify the string and it was inferred.
I
The current version of the protocol is a bit overwhelming - for easier
understanding what basic calls it offers, I suggest having a look at its first
version:
https://github.com/microsoft/language-server-protocol/blob/main/versions/protocol-1-x.md
--
Reply to this email directly or view it on
> You seem to misunderstand my point. I'm not at all against LSP, quite the
> opposite. I like LSP because it seems to be industry standard by now with
> lots of server-implementations (of varying quality) that loosens our "ctags
> lock-in".
Yet you don't seem to get the point of LSP. The
You seem to misunderstand my point. I'm not at all against LSP, quite the
opposite. I like LSP because it seems to be industry standard by now with lots
of server-implementations (of varying quality) that loosens our "ctags lock-in".
I just don't like *this* proposal because it "hacks" LSP
@dolik-rce pushed 1 commit.
6cb68a7ae16f5b4496fefdd7f59e119bfe2d8ccd avoid parsing opened files when
loading project #1289
--
View it on GitHub:
https://github.com/geany/geany-plugins/pull/1290/files/f8771f6df63e32d7d98d78fbc7893ff1d81a5950..6cb68a7ae16f5b4496fefdd7f59e119bfe2d8ccd
You are
@dolik-rce pushed 1 commit.
f8771f6df63e32d7d98d78fbc7893ff1d81a5950 avoid parsing opened files when
loading project #1289
--
View it on GitHub:
https://github.com/geany/geany-plugins/pull/1290/files/ef7efb98d5feb98de678f3cfb3ed56aa96cd72c5..f8771f6df63e32d7d98d78fbc7893ff1d81a5950
You are
@rdipardo commented on this pull request.
> @@ -276,13 +276,24 @@ static GeanyFiletype *filetypes_detect(const gchar
> *utf8_filename)
}
+static gboolean string_exists_in_array(gchar **array, gchar *str) {
> I'm pretty sure this function already exists in glib or somewhere...
Perhaps
> First, you can't be sure that the LSP server returns all the fields or that
> it even support certain feature.
True, but then we don't know exactly what capabilities each ctags parser has,
especially regex or peg ones and we seem to get along "ok".
> You can't be sure if it contains
> @techee
> TM gives you more info than what you can obtain from LSP using its API
> What extra does TM have?
I should maybe have said "incompatible" or vaguely described. First, you can't
be sure that the LSP server returns all the fields or that it even support
certain feature. For instance,
> I mean with TM we have all data required to implement the features locally
> available. We can do smart things before the user triggers things or after
> based on that. With your LSP proposal we ask the external entity only when
> the user triggers the action and we have to hope for the best.
30 matches
Mail list logo
