OK, it appears to be some problem when ProjectOrganizer is enabled - I'll
investigate more.
> Are you SURE you don't have one of your developmental ctags/tagmangler
> patches present?
Yeah, pretty sure, tag manager is for losers. I now have a
When filetype is changed to a compatible filetype (such as C-C++ and then
possibly back to C), colorization is lost. It seems that with Scintilla 5, when
language-specific highlighting changes, SCI_SETKEYWORDS has to be called again
to take effect.
By setting keyword_hash to 0 we force Geany
OK, to trigger the problem, one has to change the filetype to a compatible type
(which currently is just C and C++). So when you change the filetype from C to
C++ (and then possibly back), the highlighting disappears. See #3553.
--
Reply to this email directly or view it on GitHub:
> LSP is old school, should interface to ChatGPT to have it write the code for
> you
Yeah, but coding will be trivial then. I'll just start with `write a better
editor than Geany` followed by a sequence of `write a better editor than the
one you have just written`. Can't go wrong ;-).
--
> Have you checked if this is perhaps a bug in scintilla and maybe fixed by
> https://github.com/geany/geany/pull/3551?
I just tried and no, it doesn't fix it unfortunately.
It's hard to say whether this is really a bug on the Scintilla side - I didn't
investigate what exact Scintilla API gets
> But since 0 is a valid hash value maybe keyword_hash should be incremented to
> get a different hash value so the comparison fails, otherwise the problem
> might still appear one in every 2^32 times the user swaps C and C++ types on
> the file .
There's already this "problem" where two
> Edit: Yes, the situation won't happen often, but it comes under the heading
> of "Why do the theoretically wrong thing when the right thing is probably not
> materially worse"
Yes, but does it really happen in practice? This isn't like a hash table where
you have say 1000 entries so
> Oh wait, its the "every file can see every other files symbols even if they
> are not used" problem isn't it
Yes.
I think this should actually be configurable because the colorization of types
is kind of random based on what files you have open (unless you let the tag
manager index all
Yeah, but despite the default "Complete word" combination, macOS takes
precedence in my case and triggers the keyboard switch.
You could also check if some other application doesn't do something strange
with keyboard input (these applications typically need the Accessibility
permission or the
I've just noticed that typenames don't get colorized for newly opened documents
(this is from editor.h):
https://github.com/geany/geany/assets/713965/8255c38b-096b-400b-a035-f772cc504566;>
However, when Geany gets restarted and this file is opened from the session
list (and not manually),
> My personal (very arbitrary) benchmark of speed acceptability would be that
> there shouldn't be any significant lags when editing a 1000 LOC source on
> Raspberry Pi 4.
I just had a brief look at the parser and there are very few and simple regexes
so I don't expect any performance
> I have evaluated the performance of the .ctags based Forth parser with
> https://github.com/universal-ctags/codebase.
Thanks! This will be totally fine for Geany.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3557#issuecomment-1716100404
You are
> I've tried to compile the forth.c generated from forth.ctags and I got a
> compilation error in geany, then I supposed that it was because the ctags
> code was out of date in geany.
Yes, we are like two years behind I'm afraid :-(. In general we want to make an
update to the latest ctags
> @techee should comment on if the C file generated by optlib that I see is
> part of https://github.com/universal-ctags/ctags/pull/3812 can be directly
> used by Geany, that is beyond my pay grade.
I don't think there's any issue with these parsers (apart from possible speed
problems, depends
> I closed this PR because I think using the official ctags file format is "the
> future" and that we should ship those with Geany and encourage users to use
> it.
Which brings me to one more thing - we should document which format is the
recommended one. So in #3049 I added one more commit
> It would appear that the marker is added to the shared buffer
Oh, I misread the code - I thought it was using `SCI_GETCHARACTERPOINTER` and
that would be sharing just `gchar *`. But it's `SCI_GETDOCPOINTER` so it's the
Scintilla's "document" which is shared and it probably stores the
I closed this PR because I think using the official ctags file format is "the
future" and that we should ship those with Geany and encourage users to use it.
The TM tag file format is good for our unit tests so we know to what internal
value the mapping happened.
> Its ok having the original
For instance, in the screenshot below, the split view shows a circle where the
git-changebar shows a diff and these markers are life-added/removed as the code
is edited.
I had a look at the code but I don't understand how it is possible that the
split window's Scintilla gets affected by the
@techee pushed 1 commit.
bc49cd2750dacf0bb5f82b7f30d328df79f23e9e Document the recommended way of
generating tags files
--
View it on GitHub:
https://github.com/geany/geany/pull/3049/files/43ee190b8ff0886a4b55313a7f75ba0da4c6083d..bc49cd2750dacf0bb5f82b7f30d328df79f23e9e
You are receiving
> Do the change markers have to be set up in each Scintilla individually? If so
> it probably isn't being done on the split because the plugins don't know
> about its existence (as its a plugin itself).
This is what I would expect - but then the markers shouldn't appear at all. I
would expect
Closed #3208.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3208#event-10664842109
You are receiving this because you are subscribed to this thread.
Message ID:
To keep a healthy amount of breakages before the release, here's one for
git-changebar. After updating Scintilla to 5.3.7, the popup that shows the
diff when a mouse cursor is placed on the marker in the sidebar shows a wrong
thing:
@eht16 Thanks for doing the boring job!
> I left out names for Jiří and Thomas as you count as core developers for long
> I'd say. This doesn't mean your work is less appreciated ❤️
No problem at all :-).
> @techee are tere any macOS specific items missing?
There were some fixes but nothing
@techee commented on this pull request.
> @@ -1689,12 +1689,13 @@ Global tags files can have three different formats:
* Pipe-separated format
* CTags format
-The first line of global tags files should be a comment, introduced
-by ``#`` followed by a space and a string like ``format=pipe``,
@techee commented on this pull request.
> case-sensitive. This helps Geany to read the file properly. If this
line is missing, Geany tries to auto-detect the used format but this
-might fail.
+might fail. Tag files using the CTags format should be left unmodified in the
OK.
--
Reply to
@techee commented on this pull request.
> @@ -1785,6 +1786,25 @@ This works basically the same as on other platforms::
"c:\program files\geany\bin\geany" -g c:\mytags.php.tags
c:\code\somefile.php
+Generating tags files using ctags
+*
+Geany supports
Ugh, ugly one. I could make some excuses that I took it over from #3542 but I
missed it completely myself as well. Quick merge to cover the shame.
Thanks, GCC.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3604#issuecomment-1765374954
You are
Merged #3604 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3604#event-10671311822
You are receiving this because you are subscribed to this thread.
Message ID:
Is there a way to set the file extension for the plugins built using
`shared_module()`? On macOS it defaults to ".dylib" but Geany expects that the
extension is ".so" so these plugins don't load. geany-plugins still use
autotools which produce ".so" those load alright.
Not critical for the
@techee pushed 1 commit.
69ad323270615947ae6249c9eab2396c7301cf43 Add a remark about tag file naming
when 'l' field is used
--
View it on GitHub:
https://github.com/geany/geany/pull/3049/files/bc49cd2750dacf0bb5f82b7f30d328df79f23e9e..69ad323270615947ae6249c9eab2396c7301cf43
You are receiving
> Probably should use .dylib on mac
But Geany won't load them. And geany-plugins are still using autotools and
generate ".so". So I think it would be easier if meson could generate ".so"
instead of ".dylib" so we'd have the same extension coming both from geany and
geany-plugins.
--
Reply to
Sounds good.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3605#issuecomment-1765401203
You are receiving this because you are subscribed to this thread.
Message ID:
> Apart the small doc changes, LGTM.
Committed now.
Alright, I'll wait for @elextr if he has some more comments to the
documentation, then squash the commits a bit and merge the result afterwards.
--
Reply to this email directly or view it on GitHub:
Great, so I've just re-pushed the squashed version in case someone wants to
have a look at it. I'll merge it tomorrow (well, actually later today) but feel
free to merge it earlier if you want.
--
Reply to this email directly or view it on GitHub:
@cousteaulecommandant Sorry for the late response :-(
If it's not a big problem (and it shouldn't be, you should be able to simulate
what the regex parser does), I'd suggest that you update your parser with all
features that the universal-ctags regex parser has (otherwise it won't be
accepted)
@techee pushed 1 commit.
9ad218bcdd6f57550bbcc2932c01bc71d89f2316 git-changebar: Re-set first visible
line after Scintilla size request
--
View it on GitHub:
@techee commented on this pull request.
> + if (sci_get_line_from_position(sci, pos_next) == line)
+ char_width = SSM(sci, SCI_POINTXFROMPOSITION, 0, pos_next) - x;
> I went ahead and implemented the more basic version that is similar to what
> was there but don't produce
@techee commented on this pull request.
> @@ -878,6 +878,10 @@ get_widget_for_buf_range (GeanyDocument *doc,
MIN (width + 2, alloc.width),
MIN (height + 1, alloc.height));
+ /* Size request seems to scroll Scintilla view so we
> Thanks a lot for debugging this up to that point!
Essential plugin, life would be unbearable without it :-).
> I somehow didn't notice this until fairly recently, and was puzzled (and
> frightened) at what it could be, yet didn't have time to dig in.
I was worried it could be some
> Maybe
> https://mesonbuild.com/Reference-manual_functions.html#library_name_suffix
Cool, thanks, that appears to be it, I'll test.
> I was thinking of people who download plugins from the internet, most will be
> for linux, will they work? I guess so far there has been no complaint, so
>
> "improved support of ctags file format" could be mentioned so users know they
> can use these files and there should be no issues with them.
Maybe also worth mentioning that this is the recommended way of generating tag
files.
--
Reply to this email directly or view it on GitHub:
@techee pushed 1 commit.
4ca132618802e4114c5ee08cbd8a7e55c8609e4c Improve wording of geany.txt
--
View it on GitHub:
https://github.com/geany/geany/pull/3049/files/bb64384a6af2631ff6f4168118ff27e0dff1c4b5..4ca132618802e4114c5ee08cbd8a7e55c8609e4c
You are receiving this because you are
Yeah, done now.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/commit/c79e60f1cc0c25106ab803b2b4c9e61926ce12fa#r130019403
You are receiving this because you are subscribed to this thread.
Message ID:
@techee commented on this pull request.
> +Generating tags files using ctags
+*
+Geany supports loading tag files generated using the ``ctags`` command-line
+tool from the universal-ctags project
(https://github.com/universal-ctags/ctags).
+Even though Geany
The condition is wrong and for version 2.0 it will constantly report
theres an update available when upgrading from 1.x (where x 0).
I had a visionary moment regarding possible 2.0 problems and had a
look at the updatechecker plugin if it handles major versions - id does, but
wrongly (in
Geany currently loads only plugins with the .so extension on macOS.
This extension is still needed since we use autotools for geany-plugins which
also generate .so.
I tested it and it does nothing on linux while on macOS it changes the
extension correctly to .so.
Unless its a big a problem,
Could at least the part setting the version in meson.build to "2.0" be merged?
geany-plugins now depend on 2.0 and this prevents a successful build when meson
is used for Geany.
(I'd like to test if everything is alright for the macOS build before the
release.)
--
Reply to this email
This should be fixed in Geany 2.0.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/18#issuecomment-1771608558
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #18 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/18#event-10716334628
You are receiving this because you are subscribed to this thread.
Message ID:
Seems to be fixed in macOS 14.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3369#issuecomment-1771687080
You are receiving this because you are subscribed to this thread.
Message ID:
@techee pushed 1 commit.
f53b82cd6747495062d3e44ea710c9cd03b3ff0d Use identical style for compactiri
and propertyname
--
View it on GitHub:
https://github.com/geany/geany/pull/3647/files/2298cac67b23fdf7d087a57b099cd0136ea8b3c0..f53b82cd6747495062d3e44ea710c9cd03b3ff0d
You are receiving this
@techee commented on this pull request.
> @@ -0,0 +1,59 @@
+# For complete documentation of this file, please see Geany's main
documentation
+[styling]
+# Edit these in the colorscheme .conf file instead
+default=default
+number=number_1
+string=string_1
+stringeol=string_eol
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3670
-- Commit Summary --
* HACKING: use the correct function name to be updated for highlighting
-- File Changes --
M HACKING (2)
-- Patch Links --
@b4n Thanks! Just tested and it fixes the problem on linux and does the right
thing on macOS too. So I think you can just commit the patch to master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3649#issuecomment-1789814995
You are receiving this
@techee commented on this pull request.
Thumbs up for fixing the only warning that we, ordinary humans with no special
compiler options, see during Geany compilation :-).
Looks good _but_ I didn't check if the actual lexer names are correct - but see
the related comment in the review.
> @@
@techee approved this pull request.
@b4n Thanks for having a look at those! Happy Colomban, happy everyone around
:-).
Apart from the minor suggestion regarding the parentheses, everything looks
good to me.
> @@ -906,7 +906,12 @@ static gint sort_found_tags(gconstpointer a,
> gconstpointer
Merged #3670 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3670#event-10848253434
You are receiving this because you are subscribed to this thread.
Message ID:
@techee pushed 6 commits.
76f093fefec295958fc212d95aedb798b650b50e Add API for LSP plugins
e330c6274db1affa6d4953c90216c929565d4a32 Add padding for possible future
extensions
7a83035787cad519ed8568fe6b83fe6f83683fda LSP interface for document symbol
queries
@techee pushed 6 commits.
00d9357fe5f359a3a901cfc2dcc0f41d4536c6ef Add API for LSP plugins
74f7d0b9900b43622c1a6caa9ae86a805efcc2bb Add padding for possible future
extensions
2ca122762d68cfcf1c4cc8dbe6f1404c3cbb64a8 LSP interface for document symbol
queries
I've just re-pushed on top of current master and with additional API for the
symbol tree generation and typename colorization plus related implementation
changes at various places in Geany and from what I have seen, I think this is
all that's need for LSP plugins. All additional features of LSP
@techee pushed 1 commit.
eab9cc19ab8280f2eef24675c621fe78352595af Add "document-before-save-as" signal
--
View it on GitHub:
https://github.com/geany/geany/pull/3572/files/bd9e5c092b2f223f7b5651c19ac24db3020e107a..eab9cc19ab8280f2eef24675c621fe78352595af
You are receiving this because you are
> …and you could check this patch using this:
Wizardry :-)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3668#issuecomment-1792883141
You are receiving this because you are subscribed to this thread.
Message ID:
Creating all lexers takes between 200-300 microseconds on my ARM macBook and
1500-1800 microseconds on Raspberry Pi 4. So probably not something to worry
about.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3673
-- Commit Summary --
*
Oh and by the way, I'm now playing with LSP support for Geany, see
https://github.com/techee/geany-lsp (the API is not yet part of Geany itself so
now it's an all-in-one Geany+plugin repo). Since you wanted an improved kotlin
support in Geany, you might want to try
> The log shows that the parser really runs twice.
Then I'd suggest having a look if files are already open when the
"project-open" signal runs - if not, it would explain this problem (but I'm not
sure what to do about it).
--
Reply to this email directly or view it on GitHub:
I don't think this happens (there may of course be some bug). When collecting
the files to be parsed, the plugin checks whether the file is open here:
https://github.com/geany/geany-plugins/blob/efd1f00dfa5af6d34680a1b92923687e254dc376/projectorganizer/src/prjorg-project.c#L298
and only passes
@techee commented on this pull request.
> {
- g_warning("Failed to find lexer for ID %u", lexer_id);
+ g_warning("Failed to find lexer for name %s", lexer_name);
To avoid speculations regarding the speed of creation of all lexers, I created
#3673 testing it
@techee commented on this pull request.
> {
- g_warning("Failed to find lexer for ID %u", lexer_id);
+ g_warning("Failed to find lexer for name %s", lexer_name);
> I was wondering whether, now that we use a name for the lexers, if we'd want
> to avoid
I can reproduce this problem but it doesn't seem to be Geany-specific. I tried
disabling the complete processing of keybindings in the code and it didn't
help. Then I tried the gtk3-demo application which is part of GTK3 and it
suffers from the same problem so it's probably something with
I haven't checked your patch and what exactly happens in Geany yet but wouldn't
it be possible to just add `g_idle_add()` (or better `plugin_idle_add()`) to
the "project-open" handler and do what is done now in the idle callback? Geany
could then open the files before the idle callback is
> I'm not a huge fan of this. I use plugins that depend on tagmanager,
> therefore I cannot use LSP.
That's not how it works - TM is still active and running in parallel to the LSP
server. It's just the individual GUI features you see that get switched to LSP.
You can even combine TM with LSP
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:
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:
> 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
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
@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'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
> 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
> 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,
> 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
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
Maybe one thing to add which I didn't mention previously because I didn't want
the discussion to become too off-topic. But this is one of those PRs where the
discussion got out of control so to hell with it :-).
I think it would make a lot of sense to make a LSP server from the tag manager
and
> I think we always need something like TM to have an in-process cache for
> symbols/tags. We're still a lightweight IDE so a my requirement would be to
> not exchange megabytes of json text on every keystroke.
It's definitely not megabytes. If you are curious about how typical
communication
> The sidebar symbols both offer goto-implementation (click on a function) and
> calltips (mouse-over tooltip). But in the sidebar you don't have a cursor
> position. I do not see how you can possibly implement the two functionalities
> using the LSP interfaces designed for that purposes, but
Regarding GTK4 I think the biggest problem is the non-GTK4 Scintilla:
https://sourceforge.net/p/scintilla/feature-requests/1433/
I'm not sure if there has been any progress in that respect.
--
Reply to this email directly or view it on GitHub:
Merged #3587 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3587#event-10745589156
You are receiving this because you are subscribed to this thread.
Message ID:
> Do we have to convert the existing filetype to a builtin filetype?
I guess the answer is yes because the lexer_filetype setting can only reference
existing filetypes in Geany?
This is what I thought too.
> I don't want to say we should not do this, but maybe we should remind us
> ourselves
> I think understand the intention of the LSP interfaces. That's why I'm pretty
> clear that they cannot be used itself for implementing goto-definition and
> tooltip on the symbols sidebar. These functionalities in Geany have to be
> implemented using other LSP interfaces or the TM fallback.
> However one thing that does relate to you is the approach and attitude. You
> come across as very aggressive and demanding.
That may be a language proficiency thing, but your English is generally good so
its hard not to make that interpretation. You also say a lot of "I want" "I
use" ignoring
> Please propose how you will make synchronous TM work with asynchronous LSP
> servers. There is a fundamental divide which is why @techee handled it by
> having individual user facing functions use either TM or LSP, they have to
> adapt to the API paradigm, asynchronous LSP is not a drop in
> 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.
> @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,
>> On the other hand, if we follow-up on your other idea and use LSP even to
>> interface with the ctags parsers then documentSymbol ought to be sufficient
>> for all existing features (except maybe where we can specialized LSP
>> interfaces like goto-implementation), right?
> I was thinking
> it looks good if I believe the docs that a value of [] make it use the
> default behavior.
Yeah, kind of weird because otherwise it expects a string but it works. I
tested it on linux, using some crazy suffix in the "darwin" branch and it gets
ignored and plugins with the "so" extension are
Merged #3608 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3608#event-10682898554
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3606 as completed via #3608.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3606#event-10682898784
You are receiving this because you are subscribed to this thread.
Message ID:
> Indeed the check is wrong in many aspects -- event 0.0.2 would be < then
> 1.38.1
Here you'll be saved by the copy-paste error of the current code where the last
digit is ignored ;-).
The current code won't behave as bad as I thought originally because for
releases the value on the server
I'm not sure if I understand the problem correctly. "root" for the plugin is
- either the project directory itself, e.g. `/home/techet/projects/geany`
- or added external directories, e.g. `/home/techet/projects/geany-plugins` and
possibly some more
Since `/home/techet/projects/geany` is the
Merged #1284 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1284#event-10681174674
You are receiving this because you are subscribed to this thread.
Message ID:
> Well, one issue is that people using the plugin won't be notified about 2.0
> anyway, as it'll make it older than basically whatever their version is… but
> we can't do anything about that.
They should get notified because of
```
geany_running.major < geany_current.major
```
The problem was
1 - 100 of 694 matches
Mail list logo
