@M0JXD @yangsfang
So now can any Dart users try #3973 which includes the Lexilla highlighter. Of course it needs Geany to be built with the PR included so its harder to test.
There may be a [Windows installer](https://github.com/geany/geany/actions/runs/11167700273) including the PR, @eht16 I didn't find any instructions on the website, but maybe I skimmed too fast?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/371#issuecomment-2392447881
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/371/2392447881(a)github.com>
@asifamin13 pushed 1 commit.
a99f196faaaff437170d53304348aee746b56f0a bracketcolors: Handle when bracematching occurs across different styles
--
View it on GitHub:
https://github.com/geany/geany-plugins/pull/1221/files/44de64d1050b2f32c574…
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1221/before/44de64d1050b2f32c574c842e7ffdc80dda59084/after/a99f196faaaff437170d53304348aee746b56f0a(a)github.com>
I don't know if either of you saw but I fixed the merge conflict with #3968.
Turns out it was a very easy fix, given @yangsfang did all the work with filetype it'd be nice to have your PR merged instead as you deserve the credit. If you have a few minutes it'd be great for you to fix it in your fork and I'll close my PR :)
@elextr I understand what you mean now. I think there is probably a bit of a Chicken and Egg issue where if someone installs Geany and sees there is zero Dart support out of the box (not even syntax highlighting) they will probably go find something else before trying to find PRs that implement the language, even if it is easy to add the filetype. Doubly so given that the Dart/Flutter teams encourage using VSCode, IntelliJ and Android Studio.
As mentioned I'm learning Dart/Flutter now with intent to use it in a project - while Dart/Flutter with the VSCode plugin is very good and what I will likely use most of the time, I'll be sure to use Geany throughout the process and report back and maybe add improvements, so it can be merged with confidence.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/371#issuecomment-2391502792
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/371/2391502792(a)github.com>
Hi. I can fix the PR #3372 if you'd like. I wasn't sure why it wasn't merged back in 2023. I vaguely recall it was waiting for approval, but I could be wrong. Anyway, I see another PR already. If you don't get any traction I can revive #3372.
To be clear, the preliminary support is only for syntax highlighting. It doesn't take into account the parenthesis and other source level information unlike Scintilla. But to get full language support such as meaningful autocomplete you would need to attach a language server.
I don't really use geany as my primary Dart editor. I only use it once in a while to view Dart code where I do not need language support. On my machine geany is patched with my changes, and I never update it. That's why I haven't needed to merge the PR urgently.
It is still useful (in my opinion) to have some kind of Dart support in geany, because geany is built by many Linux distros in the main software repo, as opposed to having to add non-free software repoes for VSCode or another editor.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/371#issuecomment-2391342042
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/371/2391342042(a)github.com>
All time I run geany from console, I have lo tof this error displayed.
```
(geany:7373): Gtk-CRITICAL **: 09:43:32.534: _gtk_css_image_get_surface: assertion 'surface_width > 0' failed
(geany:7373): Gtk-CRITICAL **: 09:43:32.535: _gtk_css_image_get_concrete_size: assertion 'default_width > 0' failed
(geany:7373): Gtk-CRITICAL **: 09:43:32.535: _gtk_css_image_get_surface: assertion 'surface_width > 0' failed
(geany:7373): Gtk-CRITICAL **: 09:43:32.535: _gtk_css_image_get_concrete_size: assertion 'default_width > 0' failed
(geany:7373): Gtk-CRITICAL **: 09:43:32.535: _gtk_css_image_get_surface: assertion 'surface_width > 0' failed
(geany:7373): Gtk-CRITICAL **: 09:43:32.551: _gtk_css_image_get_concrete_size: assertion 'default_width > 0' failed
```
Geany look to work fine, maybe an icon is note displayed but I don't see it.
## about my geany
Installed package: manjaro extra/geany 2.0-1
```
$ geany -V
geany 2.0 (construit le Oct 23 2023 avec GTK 3.24.38, GLib 2.78.0)
```
```
Geany-INFO: 09:47:25.924: Geany 2.0, unknown
Geany-INFO: 09:47:25.924: GTK 3.24.43, GLib 2.80.5
Geany-INFO: 09:47:25.924: OS: Manjaro Linux
Geany-INFO: 09:47:25.924: System data dir: /usr/share/geany
Geany-INFO: 09:47:25.924: User config dir: /home/didier/.config/geany
Geany-INFO: 09:47:26.071: Loaded GTK+ CSS theme '/usr/share/geany/geany.css'
```
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3969
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3969(a)github.com>
I tried to code a plugin for copilot but soon realized that your api doesn't allow low level control of scintilla or I'm too noob to realize how. Copilot only needs to grab context from current cursor position (say 200 chars before and after), then it will suggest autocompletion options. Btw, Copilot is not the only tool for the task, I plan to add and OpenAI backend that can be gracefully replaced by LocalAI for 100% private and off-line coding (so no IP issues). Devs can choose to train/finetune their own LLM if they wish, plug it into LocalAI and let the geany plugin take care of the rest.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3543
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3543(a)github.com>
Ahh, but the emoji indicates that it is not intended as a serious statement.
But being serious for a moment, there is no panel or individual who judges if a language is worth adding to Geany, it depends on someone with merge permission either wanting the filetype themselves, or volunteering their own time to merge a PR submitted by someone else, which they do not benefit from.
It would make it easier to get someone to merge a PR for a new filetype that they don't use if some users of the filetype try the PR and contribute that it is safe and useful (within whatever its limits are). And the PR is kept up to date if other merges cause clashes.
That reduces or even removes the need for testing by a person who does not use the filetype, has no code in that language to test with, and does not know if it is actually doing the correct thing anyway. If it is judged that enough testing is happening by people who know the filetype it means all that is needed is a merge and that is more likely to happen as it uses much less of the volunteer's time.
Dart seems to have been unfortunate that even though the PR is a data file only, so no code needs compilation, no Dart users tried it and commented that it was useful (until you now) before other changes caused clashes which were not fixed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/371#issuecomment-2390307469
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/371/2390307469(a)github.com>
So I recently decided to abandon my old gtk2-based editor after some +15 years,
largely because I can no longer compile gtk2 from source, for reasons related
to the glib stack (something has been deprecated and I don't know the workaround,
but I can no longer wait for anyone upstream patching gtk2, so I now took the
full dive finally).
I toyed with the idea of sublime, but I think I am less likely to adjust sublime towards
behaviour I am quite use, as opposed to geany, which is open source. So I'll give
geany a more serious try this time. I used it in the past, e. g. for C++ files, but not
yet for all files. Right now I am using geany for ALL files.
There are many small issues but I don't want to spam the issue tracker with tons
of ideas that are possibly only for my own use case. Nonetheless I hope to be
able to convince the geany devs towards more flexibility in general, via options
and preferences we could toggle as-is. Geany already supports quite many
options, so I hope we can support even more options - if they make sense.
Alright - now to the issue here.
First, have a look at this screenshot:
https://i.imgur.com/mWzOafF.png
You can see the open files. Evidently I am currently modifying a german exam
question test for evolution of hominids / hominidae :D - the key issue, though,
is the pop-up widget that shows the opened files.
The currently selected file is shown in bold - that is nice.
However had, often I can not tell WHERE the files are. Some may be same-named
or similarly-named, so I would like to also have the option to show the full path
right there (left-padded, e. g. all are aligned towards the left-side, but on the
right side we may allow overflow; the full widget width would thus be determined
by the file with the longest name.)
I am very much used to that behaviour from my old editor, where I can see the
full path at all times.
So, my issue request would be for geany to add an option to show the FULL
path instead, rather than the truncated path (in ruby, the filename itself
would be obtained via File.basename(), so instead I would be looking for
File.absolute_path() - not sure how C does this but perhaps gtk has some
method that shows the full path).
In the option dialogue, we would then have to add a new entry at
**Preferences -> Files**; perhaps call it, as a check-button, "Show full
path of files". This would NOT be the default, so everyone could enjoy
the current behaviour of geany, rather than adjust to the one proposed
in this issue request.
As for a more objective rationale for this feature: we would instantly
know where the file resides at. (Actually, my old editor not only made
the current file bold, but used different colours too. But I am perfectly
fine without colours here too, I just need the feature that I know the
full path at all times, as this is less confusing to me than merely the
short-filename itself as such.)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3800
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3800(a)github.com>
My apologies, my phrasing was poor on that. You said:
"Only one query for dart since 2014 doesn't seem much support for adding yet another built in language. Just because you added it to Lexilla isn't an argument to build a wasted language to Geany 😜 ."
What I'm trying to say is I don't think it would be a wasted language 🙂
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/371#issuecomment-2389886592
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/371/2389886592(a)github.com>
