@techee pushed 1 commit.
bccb605030dda0bafedb0b91e31e220c94285c58 Modify the LSP interface to return
position for the symbol goto
--
View it on GitHub:
https://github.com/geany/geany/pull/3571/files/7ea99e1ff84d7f2a733eef48606a8992ab666707..bccb605030dda0bafedb0b91e31e220c94285c58
You are rece
>> Sorry, a little busy with the LSP plugin :-).
> Yeah, "somebody" keeps raising issues on it (sorry) :-)
That's totally great.
By "busy" I actually meant "doing this new exciting thing and neglecting the
old boring tag manager" :-)
> I like the suggestion to move the ctags into a separate pr
Sorry, a little busy with the LSP plugin :-).
> 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
> tm_workspace_add_source_files(data->source_fil
After Geany launch a filename not corresponding to the current file is shown in
the title bar - see the screenshot below. It gets fixed as active document
changes. I'm wondering if something similar to
https://github.com/geany/geany/issues/3609 should be also done for the titlebar.
https://gith
Closed #65 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-themes/issues/65#event-10939401752
You are receiving this because you are subscribed to this thread.
Message ID:
Fixed, thanks for reporting.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-themes/issues/65#issuecomment-1807812254
You are receiving this because you are subscribed to this thread.
Message ID:
> No problem with having extra features, but the only use-case I can see for
> workspace/symbols is if the user does not have the symbol in the code in
> front of them, if its in front of them then goto definition/declaration, or
> if adding autocomplete will do it, maybe to lookup something unr
>> For my "look up symbols in a dialog" use case: LSP's goto-implementation
>> cannot be used for that, and other LSP interfaces are not really sutiable
>> either, as you pictured above. So what can we do to keep such functionality?
> Do I imagine correctly it shows some entry with symbols below
> Why would the user want to goto the wrong place? If LSP says the name is not
> visible going to the definition/declaration of some random thing invisible at
> that point in the code, but which happens to have the same name, doesn't make
> sense.
Yeah, right. Too late, I start making errors. G
> the sidebar lists a symbol and you can click on it to go to the defintion
> (because fed by ctags) but you cannot click on the same symbol in the editor
> (because goto-definition in editor is implemented by LSP).
Actually, in this particular case, if we wanted, we could fall back to trying
T
> Note the in the editor, where LSP will indeed only goto (or show on hover)
> the declaration/definition only if it is valid and error it if it is invalid.
Ah, right, so it was me who misunderstood it :-).
But really, when someone configures the plugin to use symbols in the sidebar
from the ta
>> 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 ab
> 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 rep
> 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
> 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.
B
> 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 us
> 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 lo
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:
https://github.com/geany/geany/discussions/3675#dis
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'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 implement
@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
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 ra
> 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 files
> 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, an
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:
> 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 wa
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 point
> @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.
> 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 -
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 called
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 proces
> …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:
@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 hard-cod
@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 (l
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 --
* T
> 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:
https://github.c
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
https://github.com/fwcd/kotli
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 t
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 s
@techee pushed 6 commits.
00d9357fe5f359a3a901cfc2dcc0f41d4536c6ef Add API for LSP plugins
74f7d0b9900b43622c1a6caa9ae86a805efcc2bb Add padding for possible future
extensions
2ca122762d68cfcf1c4cc8dbe6f1404c3cbb64a8 LSP interface for document symbol
queries
576e4bb153086d90f098ad9a3231c9af87a
@techee pushed 6 commits.
76f093fefec295958fc212d95aedb798b650b50e Add API for LSP plugins
e330c6274db1affa6d4953c90216c929565d4a32 Add padding for possible future
extensions
7a83035787cad519ed8568fe6b83fe6f83683fda LSP interface for document symbol
queries
50594a7694da24a5371dd7a1851718bf433
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 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.
> @@ -6
@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 b,
@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 be
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 --
https://github.com/geany/geany/pul
@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
+propertyname=attr
@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 b
> Maybe move the above comment to a separate issue so it doesn't get lost when
> this is merged (maybe with ticklist of filetypes to add).
Yep, done in https://github.com/geany/geany/issues/3651
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3171#issue
I went through the various open PRs and open issues providing/requesting
support of certain languages because some seem to be a bit neglected:
1. There's this PR adding Prolog support.
2. There's the Raku language support in #3169 which is hopefully in a mergable
state.
3. I created #3647 (Scinti
@b4n @eht16 OK to merge this PR? I'd like to avoid the situation like with the
Raku parser (#3169, also updated on top of 2.0 now) where it rots in open PRs
and then, before the release, it's too late to get merged.
I went through the various open PRs and open issues providing/requesting
suppor
> It's everything I would want, thanks! But where are the symbols? Or is tag
> parsing still on the TODO list?
Not on my todo list :-).
But if you want to create something, I can imagine a super-simple approach of
implementing the parser which works just based on the common way prolog files
ar
> It might be better to map one consistent style to property names and compact
> IRIs (even though the latter are really a [component of
> JSON-LD](https://www.w3.org/TR/json-ld/#dfn-compact-iri)).
I didn't read the specs of JSON-LD but are those always present in the keys of
json dicts?
> Did
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:
@techee requested changes on this pull request.
@killerbees19 Thanks for all your work and your patience! I'll try to assist
you to get this merged to Geany finally.
A few more general comments apart from those commenting specific code:
1. It would be good to rebase this pull request on top of c
> 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 by
Looks good - I just tested this PR and it works as described (no way for a
human being to review the XML diff itself).
In the future we could introduce some tab like "Behavior" which is so
generic-sounding we'd be free to place there just anything :-).
--
Reply to this email directly or view i
Merged #3641 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3641#event-10744028554
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3441.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3441#event-10742666505
You are receiving this because you are subscribed to this thread.
Message ID:
We already have a newer version of Scintilla. Closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3441#issuecomment-1775468908
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3481.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3481#event-10742647509
You are receiving this because you are subscribed to this thread.
Message ID:
I think something like that is already part of the updated HACKING. Closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3481#issuecomment-1775465878
You are receiving this because you are subscribed to this thread.
Message ID:
This appears as if you explicitly enabled it somehow using
`-Dmac-integration=enabled` or `auto_features=enabled`.
What is the last `--m` option? I have only meson 1.0.1 and this one is
unrecognised.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/36
In addition to JSON, the other lexer we don't use yet is for the Nim
language (these are the only ones I'm aware of). I'm not a Nim language
user myself but I tried to modify the external filetype config file to the
internal one so most of the stuff is preserved and should work correctly.
You ca
I think we should switch to using dedicated lexers where these lexers are
available in Lexilla. This allows better highlighting, where for instance for
JSON we can color the keys differently from the values and also provide
optional comment support.
The exact highlighting mapping is open for di
@techee commented on this pull request.
> @@ -658,7 +658,7 @@ https://github.com/universal-ctags/ctags
Method
``
-* Add foo.c to SRCS in Makefile.am and meson.build.
+* Add foo.c to SRCS in ctags/Makefile.am and meson.build.
Done, thanks.
--
Reply to this email directly or view it on
@techee pushed 1 commit.
cb10577f633e178ad533f4fc79cc797618d9d004 Update HACKING
--
View it on GitHub:
https://github.com/geany/geany/pull/3641/files/def46d39d25627285f93f0d195e9d0f688f6921d..cb10577f633e178ad533f4fc79cc797618d9d004
You are receiving this because you are subscribed to this thre
@techee pushed 1 commit.
1f3c9d53effcf0c242430f4cdd5ab843d9b4c1bd fixup! Add Raku (Perl 6) filetype
support (lexer and ctags parser)
--
View it on GitHub:
https://github.com/geany/geany/pull/3169/files/a9363bc15d2c66ea91eeec923961f93e41bff216..1f3c9d53effcf0c242430f4cdd5ab843d9b4c1bd
You are r
@rdipardo I just rebased this PR on top of master and also made the necessary
updates related to the updated lexer. Since you are probably the most
proficient prolog user around, would you have a look at it if it looks alright?
--
Reply to this email directly or view it on GitHub:
https://githu
@techee pushed 2 commits.
76925635112c447415142b31d69abf573efeed29 Add Prolog filetype support
b4e795754e32a59081eb8e819516b988b4893096 Update to the latest Prolog lexer
--
View it on GitHub:
https://github.com/geany/geany/pull/3171/files/823ee03f5948d9ef79352bd68072a574866ace09..b4e795754e32a
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3641
-- Commit Summary --
* Update some paths in HACKING
-- File Changes --
M HACKING (10)
-- Patch Links --
https://github.com/geany/geany/pull/3641.patch
https://github.com/geany/ge
@techee pushed 1 commit.
a9363bc15d2c66ea91eeec923961f93e41bff216 Add Raku (Perl 6) filetype support
(lexer and ctags parser)
--
View it on GitHub:
https://github.com/geany/geany/pull/3169/files/eb6efa91e364c40a841000ceb3e5fa4463120d56..a9363bc15d2c66ea91eeec923961f93e41bff216
You are receivin
> @techee plug in a bigger screen, or better get a theme that doesn't include
> so much padding. Or both 😀
Or none of these and use my normal solution "don't use Windows" :-) Testing
Geany was just a good opportunity to install one and half years worth of
updates...
> Seriously though, compare
While resizing the main window or dialogs like the preferences dialog, they
disappear at certain sizes:
https://github.com/geany/geany-osx/assets/713965/99af9540-3d8d-4a2c-b43a-0a0b7531cc6b";>
When the cursor is moved over the dialog or the window is minimized and then
re-shown, it starts showi
> Where is "unknown" set? I pinged you on the assumption it was deep in the
> bowels of tagmanager?
It's outside the tag manager:
https://github.com/geany/geany/blob/fefef55569424b72e540bafa4bec514e7e2fd6f5/src/symbols.c#L1947
--
Reply to this email directly or view it on GitHub:
https://githu
> Perhaps it should show something that is less
> commonly[1](https://github.com/geany/geany/issues/3632#user-content-fn-1-6f42eafda92f7637071dab0f8cb444e5)
> a valid scope, perhaps - @techee?
Can be. (I personally don't care much as I use Geany with hidden statusbar.)
--
Reply to this email d
> @techee might be the macOS builds affected by this as well?
I used meson for Geany itself (not usre if it suffers from the same problem)
and autotools for plugins. In any case I made a completely clean build from
release tarballs so I hope it's alright.
--
Reply to this email directly or vi
> One more guess: did you pass /tmp/geanytest with --prefix to ./configure? If
> not, Geany would load the geany.glade file from your old installation and
> this would explain at least the missing filter entry @techee mentioned.
Really good guess - that could probably explain about everything be
I don't seem to be able to reproduce the issue here - switching to the other
file shows its own symbols immediately. I'm also a bit puzzled by how your
Symbols tab looks like - with Geany 2.0 you should see a filter entry in this
tab, yet there is none in your case which looks like some older Ge
By the way this is how the settings page looks on my (older) Dell XPS 13 on
Windows 11:
The top of the window is aligned with the top of the screen and at the bottom
one has to gu
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:
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:
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:
> sorry
Don't worry. Crashes caused by my commits will start appearing _after_ the
release :-)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3615#issuecomment-1770933340
You are receiving this because you are subscribed to this thread.
Message ID:
@rdipardo @b4n Thanks! Crash fixed and I agree it's safer to check if we manage
to get the lexer.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3616#issuecomment-1770927557
You are receiving this because you are subscribed to this thread.
Message ID:
> @techee yeah, but here just using the icon name won't solve it, you also need
> to use the symbolic version for the problematic icons.
Ah, OK, I missed that. But then it's really a problem of the icon theme I think.
--
Reply to this email directly or view it on GitHub:
https://github.com/gean
> although @techee has a point that as the icons that please Adwaita are used
> by GTK itself, it's likely not to cause much trouble.
I was looking for this page (which I couldn't find yesterday) for stock icons
and their replacements:
https://developer-old.gnome.org/gtk3/stable/gtk3-Stock-Item
> [elextr](https://github.com/elextr) closed this as
> [completed](https://github.com/geany/geany/issues?q=is%3Aissue+is%3Aclosed+archived%3Afalse+reason%3Acompleted)
> [9 hours ago](https://github.com/geany/geany/issues/3610#event-10700778434)
Is it fixed though and is this a problem of the use
> Or we mention it somewhere in the announcement email? @eht16 😆
It's not new to 2.0 though. I just tried Geany 1.38 packaged with Debian
Bookworm and the issue is there too - yet, nobody is complaining. So maybe
people use another icon theme or older distributions (or maybe we are the only
peo
> This needs to be tested on a wide range of distros, not just Debian, and not
> just Gnome, Cinnamon, XFCE, etc and Windows.
I don't think it needs to be tested on all thinkable distributions (just tried
briefly on macOS and it seems to work), it should work the same way everywhere.
On the oth
At least GTK seems to have a test for these icon names so I think their
presence is kind of required:
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/testsuite/gtk/check-icon-names.c
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3613#issuecomment-17
> Might there be any risk that other themes may not work well with the changed
> icon references? I guess this is hard to answer; the icon loading mechanism
> are big mystique to me and so I'm just wondering how much we could break with
> this change.
Just speculating but `gtk_image_new_from_st
@techee commented on this pull request.
>
/* necessary to set it to TRUE for project session support */
main_status.opening_session_files++;
- i = file_prefs.tab_order_ltr ? 0 : (session_files->len - 1);
- while (TRUE)
+ file_prefs.tab_order_beside = FALSE;
> You guys like to have me updating screenshots I guess...
Nah, it could have totally stayed the way it was.
> The screenshot for the prefs dialog with the changed default for the tab
> label length is updated for 1000 chars, pixels, apples, Euros 😄.
We are aiming for 1000 screenshot updates in
Regardless of whether it is an Adwaita icon theme bug (I just tried with other
icon themes and apart from the Adwaita one, all work well), I think if the
patch is as simple as you propose (possibly covering more instances), we should
do it - otherwise we might get flooded with bug reports regard
@techee approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3611#pullrequestreview-1685192114
You are receiving this because you are subscribed to this thread.
Message ID:
601 - 700 of 1626 matches
Mail list logo
