Fixes #3411.
Probably trivial enough so if there are no objections, Ill merge it in
about a week.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3412
-- Commit Summary --
* Map asciidoc level 5 section so it can be shown in the sidebar
> Does it matter that the enum
> [here](https://github.com/geany/geany/blob/ae1f499e3b2fa108d749942008431ec1aaf0294b/ctags/parsers/asciidoc.c#L43)
> does not go to level 5?
This is probably "correct" but extremely ugly. Those `K_CHAPTER` up to
`K_LEVEL4SECTION` aren't used anywhere in the
Yeah, we also don't have the kind mapped here (`tm_tag_undef_t` means unmapped):
https://github.com/geany/geany/blob/ae1f499e3b2fa108d749942008431ec1aaf0294b/src/tagmanager/tm_parser.c#L837
I'll prepare a patch.
--
Reply to this email directly or view it on GitHub:
> @techee something changed when it was upstreamed, the parser accepts level 5
> [here](https://github.com/geany/geany/blob/ae1f499e3b2fa108d749942008431ec1aaf0294b/ctags/parsers/asciidoc.c#L379)
> and it has a letter
>
Right now, when a config file from Tools-Configuration Files is edited for
the first time, the global config file is taken and all lines in it are
commented-out. When modified, such a file is copied into the users config
directory. The logic behind this is that the user typically wants to
Merged #1752 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1752#event-9017870545
You are receiving this because you are subscribed to this thread.
Message ID:
OK, I've just merged this PR so we are finally done with it. @Skif-off thanks
for your contribution and for your patience!
> @techee sure, that'd be fine as well (although it'd probably get forgotten
> for a decade or two until somebody notices it from scratch again)
@b4n I'm going to do it
Note that local variables seem to be local for the given file and
not local within a certain function so mapping them to `tm_tag_local_var_t`
isnt appropriate.
At the moment autocompletion doesnt work - this is caused by
https://github.com/universal-ctags/ctags/pull/3697
which I add to this
I'd say let's wait what @masatake thinks about
https://github.com/universal-ctags/ctags/pull/3696. If a solution like that is
accepted upstream, I'll backport the fix for Geany. If not, we'd have to figure
out what to do.
> I really think that's something we ought to fix before releasing at
This is the end of the end of the build log:
```
Command line defined:
"GEANY_INSTALLER_NAME=geany-1.39_ci_20230416143039_83b8f7b_setup.exe"
Command line defined: "GEANY_RELEASE_DIR=/build/geany-release"
Command line defined: "GEANY_THEMES_DIR=/build/geany-themes"
Command line defined:
By the way, I'm wondering whether we shouldn't use the filetype-specific
wordchars here
https://github.com/geany/geany/blob/7af6eafc0525bfafc8bdb2fbd29452b5f5409f56/src/editor.c#L2249-L2254
instead of the hardcoded `GEANY_WORDCHARS` macro.
--
Reply to this email directly or view it on
> @techee referencing to the build log for mingw here. Ctags seems to have a
> lot of size and signedness mismatch errors. Are they all safe? They don't
> show on an autotools CI mingw build (https://github.com/geany/geany/pull/3465
> for eg) maybe meson has more strict default flags, and they
> It seems the language does not support such constructs.
OK, I mentioned this because I noticed the use of `nestingLevel...()` and
`CORK` stuff in the parser which are used for scopes.
> Any part of code can be placed inside the #Region ... #EndRegion, but #Region
> ... #EndRegion is not a
OK, no worries. I haven't been able to reproduce this issue so I'll close it
now.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/19#issuecomment-1487527283
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #19 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/19#event-8869256507
You are receiving this because you are subscribed to this thread.
Message ID:
The reason for this bug are the `/* FIXME: Implement */` stubs of the functions
here:
https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/quartz/gdkdnd-quartz.c#L71
The DND GTK API that Scintilla uses just returns incorrect values because of
this.
--
Reply to this email directly or view
> Done.
Thanks. The PR looks good to go from my perspective.
> To be honest, I don't see the difference between TRUE and FALSE :)
You won't in this case because the language itself supports only one level of
nesting. The change is more for us so we know which languages support scope
I've created a bug report against GTK here:
https://gitlab.gnome.org/GNOME/gtk/-/issues/5716
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/18#issuecomment-1493052461
You are receiving this because you are subscribed to this thread.
Message ID:
@techee commented on this pull request.
> + {'g', tm_tag_undef_t},
+ {'l', tm_tag_undef_t},
I'd suggest that we address this in a separate PR (@b4n what do you think?).
This PR works well as it is and I can prepare a PR for the global and local
variables afterwards - it should be
> Ok, problem solved, the machine I am using temporarily had another Geany
> installed, explicit executable path fixed this :-)
I remember having this problem when switching between meson build and autotools
build - each of them installs `geany.so` to a different location - autotools to
Good catch!
The problem is actually #3268. After a closer inspection the ctags "local" flag
detection isn't very profound - it checks source file names and if the file
name has a header extension, then the flag is non-local, otherwise it's local.
So for the `*.foo` extension, it's assumed to
So I had a closer look at what ctags does and I think we can actually never be
sure whether the flag is valid or not so let's revert #3268 to be on the safe
side. See PR #3457.
--
Reply to this email directly or view it on GitHub:
While it would be nice to get rid of some extra tags, this field is generated
in ctags using file name and also some questionable heuristics which
doesnt lead to completely reliable results so better to avoid this field.
Reverts #3268.
Fixes #3454.
You can view, comment on, or merge this pull
@ntrel As @elextr said, I think you are not using an up-to-date Geany, the code
looks a bit different now. In #3413 I wasn't sure what to do with the non-conf
files and left the old code here
https://github.com/geany/geany/blob/5298f51f41bb29e41970456652d2314ce609bcce/src/ui_utils.c#L2166-L2171
> It's IMO a serious issue with the Meson setup if it install by default in
> /usr rather than /usr/local
I think this is not what @elextr meant - he meant that when using autotools,
it places things directly under `/user/local` and not under the
architecture-based subdirectory.
I had a look
Dammit, this was the anniversary 1th Geany commit - I wanted to be the one
who makes it ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/commit/b143e481ef472da1d49c8aabb3842ff20ba7b32c#commitcomment-108526081
You are receiving this because you are
I maybe have a better idea how to fix this issue - I think it's fixable in
uctags. Will try to prepare a patch.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3457#issuecomment-1504235949
You are receiving this because you are subscribed to this
> The thing that will complicate it is that a Geany user can set filetype, and
> really uctags should use that, not its own determination.
That would be hard to do with the hacky interface we have against uctags (and I
don't want to introduce too many Geany-specific things to uctags which is
Merged #3443 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3443#event-8949699570
You are receiving this because you are subscribed to this thread.
Message ID:
The current code uses an unreffed `TMSourceFile-short_name` as the key into
`source_file_map`. With Geany itself this is no problem as the `TMSourceFiles`
are always destroyed after their removal from the hash table.
However, if a plugin adds 2 different files to the TM using
```
@techee commented on this pull request.
> + {'g', tm_tag_undef_t},
+ {'l', tm_tag_undef_t},
Plus we want to have all the enabled tags covered by unit tests - I haven't
checked if the provided unit test contains local and global tags.
--
Reply to this email directly or view it on
@techee commented on this pull request.
> + {'g', tm_tag_undef_t},
+ {'l', tm_tag_undef_t},
Yes, that would be nice I think (I didn't mention this because I thought they
were disabled for some language-specific reason).
If you decide to enable local variables, please map them to
Now after looking at #3386 where the `in_block_comment()` is used, it's sole
purpose is to tell whether to add the initial `*` in multi-line block comment.
This now works only for `*` and `+` for D but no other character. Block
comments in Julia are introduced by `#=` so we'd have to do the
There are various weird problems related to GTK event handling on macOS which
we unfortunately cannot fix in Geany itself. I'm not sure if I saw this
particular problem but I've seen problems similar to this one in the past. I
recently made a new build of Geany with latest versions of libraries
@techee commented on this pull request.
> @@ -3526,10 +3526,13 @@ static void auto_multiline(GeanyEditor *editor, gint
> cur_line)
{ /* we are on the second line of a multi line comment, so we
have to insert white space */
whitespace = " ";
@techee commented on this pull request.
> @@ -3526,10 +3526,13 @@ static void auto_multiline(GeanyEditor *editor, gint
> cur_line)
{ /* we are on the second line of a multi line comment, so we
have to insert white space */
whitespace = " ";
Uh, that's weird, I don't see anything like that here. Do you use some plugins
that could possibly cause that? Have you tried disabling them?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/42#issuecomment-1427526942
You are receiving this because
I could imagine that for instance ProjectOrganizer could be the problem if you
let it index some huge project directory or the whole home directory but if you
say the same problem persists when it's disabled, it must be something else
then.
Do you have some big file open for instance? When you
> OK, I can try those suggestions, however the startup performance was not a
> problem with the Geany build I was using previously (as documented in my
> original post), with the same configuration, plugins and open files.
Would you try reinstalling the previous version to see if the problem
> The only file types I have open are .sql (Oracle PL/SQL scripts) and simple
> .txt
What happens if you close those files and re-launch Geany?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/42#issuecomment-1427624488
You are receiving this
OK, great. I suspect it will be some of the files you had open then. It would
be nice if you manage to figure out which one it was and will be able to share
it or create a shareable file with which you are able to reproduce the problem
so we can have a look at it.
--
Reply to this email
@techee commented on this pull request.
> @@ -3526,10 +3526,13 @@ static void auto_multiline(GeanyEditor *editor, gint
> cur_line)
{ /* we are on the second line of a multi line comment, so we
have to insert white space */
whitespace = " ";
I would first suggest trying the current ctags binary if it exhibits the same
problem so we are sure it's the ctags parser problem. You can for instance
install homebrew and use the ctags version here:
https://formulae.brew.sh/formula/universal-ctags
If you reproduce the problem (i.e. long
> I'm happy to provide the file, but directly to someone investigating the
> problem, e.g. via email, not as an attachment to a post where everyone can
> look at it.
I can do it if you send it to me (some time later today). You'll find my email
in Geany's git commit history if you clone it to
> Calltips have missing space after comma for parameters
Yeah, I've noticed that too after switching to the new parser. Does
https://github.com/geany/geany/pull/3478 fix that problem? If so, it should be
submitted to universal-ctags first and if it gets merged, we could then port it
to Geany.
I've just added the upstreamed patch dropping the `$` from variable names. From
my point of view this PR is ready to get merged.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3460#issuecomment-1527681769
You are receiving this because you are
@techee pushed 1 commit.
50e4f69b37535a8780baa1d9500d954aebbbd5a8 Autoit: drop $ from variable names
--
View it on GitHub:
https://github.com/geany/geany/pull/3460/files/3f56177435ea1d27671ecc23027d340126d929bb..50e4f69b37535a8780baa1d9500d954aebbbd5a8
You are receiving this because you are
Merged #1259 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1259#event-9767795769
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1255 as completed via #1259.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1255#event-9767795811
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #1252 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1252#event-9319599039
You are receiving this because you are subscribed to this thread.
Message ID:
As @elextr said, this isn't really a use of an uninitialized value. But if it
silences the warning, let's merge it so cppcheck shows only real problems.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1252#issuecomment-1559956919
You are
> Thank you. How about long returned from mio_tell and passed to mio_seek? I
> will introduce mio_long or mio_off_t. Is this acceptable?
We don't use MIO at all in Geany itself - its only use is through ctags and we
don't call any of its API directly. So you can do whatever you want with it in
Merged #3460 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3460#event-10078075361
You are receiving this because you are subscribed to this thread.
Message ID:
With the latest version of msys, the viw binary fails to link (most probably it
should be built as a C++ binary instead of the current plain C binary).
Since this binary is used just for testing purposes, theres no need to
build it on Windows so this patch skips the build there to avoid this
> CI passes!
Was the original problem reproducible with our CI (and the version of msys2 our
CI uses)?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1259#issuecomment-1616586025
You are receiving this because you are subscribed to this
> Or of course we could just not build viw on Windows, especially since there
> is a Vi for Windows called
> [viw](https://www.mkssoftware.com/docs/man1/viw.1.asp).
I just did that in #1259. @eht16 Would you test if it fixes the problem?
--
Reply to this email directly or view it on GitHub:
> Oh yeah, forgot to ping @techee
Always a wise things to do, I'm in a kind of dormant state otherwise ;-).
> But it looks like vimode uses more of Scintilla than other plugins and so it
> needs to be treated as C++, not C as it is at line 10650 (--tag=CC and ccache
> gcc). Note its the only
> Maybe this is related to https://github.com/geany/geany/pull/3049? @techee
Yeah, `typeref` isn't parsed at all now, #3049 should fix it.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3512#issuecomment-1595737182
You are receiving this because you
OK, the screencast is very blurry so I can't read it well and see what's
happening (and in the first place, I don't even know what exactly it should
do). In any case, it's most probably a GTK bug and not a bug of Geany itself. I
made some more recent builds with newer versions of GTK which
Closing as this PR is obsoleted by #3490.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3457#issuecomment-1538242734
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3457.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3457#event-9189611694
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #1240 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1240#event-9189824392
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1155 as completed via #1240.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1155#event-9189824590
You are receiving this because you are subscribed to this thread.
Message ID:
See #3490 for a possible fix of this issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3454#issuecomment-1538244012
You are receiving this because you are subscribed to this thread.
Message ID:
Yeah, I merged all I could from projectorganizer and vimode yesterday ;-)
Regarding quality control I think I could have prevented some of the vimode
problems before the release if the PRs got merged to master earlier as I didn't
notice the issues when I worked on the individual PRs and then
After some more thinking about it, we can fix #3454 very easily by ourselves by
checking whether the tag originates from a source file with a known/common
C/C++ extension - if not, always set local to FALSE.
The first patch adds `is_c_source` flag to TMSourceFile to indicate whether the
file
In tag manager, it's called "local", in uctags it's called "isFileScope" (which
is a better name). It's those definitions/declarations that are valid only
within a single file and which cannot be legally used outside of that file
(like static functions for instance).
--
Reply to this email
@techee pushed 2 commits.
db5d7e5cac00de7f9e2aee48b05bde5397370dd2 Add a flag indicating whether to
trust isFileScope from ctags
2fd242b94c41f9254b2288fdb39a1c20d819b53d For C/C++ only mark tag as local if
it originates from a source file
--
View it on GitHub:
@b4n I've just repushed a hybrid version of the patch - using the
`trust_file_scope` name but using `g_str_has_suffix()` as I used in the
original patch which I like a bit better (but I don't insist on that one too
much if the other version is preferred).
Now the hard stuff - someone has to
@techee pushed 2 commits.
0562f8edbcc2481b230e8f75c0df38db6d167238 autoit: use local/global variable tags
c62b87955c8ed52f0425f61b2b8e828dd5f273db Autoit: drop $ from variable names
--
View it on GitHub:
> Another year later...luckily we got some more feedback even though it doesn't
> make the decision for a suitable default theme not easier.
Great!
> I'm aware that some of the contributors of this issue are not happy with
> Prof-Gnome and might prefer Adwaita, Boomerang, Monokai or whatever
> @techee https://github.com/geany/geany-plugins/pull/1141 does not appear to
> have been merged yet?
I was waiting for for @frlan if he wants to merge it or have a look at it but I
guess he doesn't have time.
I think both #1139 and #1141 are quite important as they are serious
regressions -
@techee pushed 2 commits.
d6e3ac8d1d1be0fb52da6c3f3fce4059dc1f578a vimode: fix detection of missing EOL
at EOF
14f306bff5b699d5715fd166e194762e346978bc vimode: avoid caret position change
when inserting EOL at EOF
--
View it on GitHub:
@techee pushed 1 commit.
c4ea3105cd8b7aa2a37e095e5ddb3e9a62bcaf17 vimode: Set default height of excmd
popup to a small number
--
View it on GitHub:
https://github.com/geany/geany-plugins/pull/1137/files/463d345276dccfac11f1091d7b11af4bb4ff7865..c4ea3105cd8b7aa2a37e095e5ddb3e9a62bcaf17
You are
Let's merge these finally. @xiota Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1122#issuecomment-1537536301
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #1122 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1122#event-9184923293
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #1144 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1144#event-9184992829
You are receiving this because you are subscribed to this thread.
Message ID:
@techee pushed 3 commits.
a17d5128f777a679b97234d706886cda59ef977e projectorganizer: Remember selected
row in sidebar when reloading
6130bbe379e645b1a142bbcb67577db25568e422 projectorganizer: Store/load expanded
paths in the sidebar to project file
f822e69395f88a9c7df7139e2ced19d8486011ca
@techee pushed 1 commit.
20a0343120e7cee1366d1cd74c14d53eb9d62f7c vimode: fix escape not working when
numlock is on
--
View it on GitHub:
https://github.com/geany/geany-plugins/pull/1141/files/856f3f7ceaf54561a6fcca8707fe7ab5b44c..20a0343120e7cee1366d1cd74c14d53eb9d62f7c
You are receiving
Merged #1137 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1137#event-9184915429
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #1141 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1141#event-9184916203
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #1139 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1139#event-9184917500
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #1126 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1126#event-9184928799
You are receiving this because you are subscribed to this thread.
Message ID:
> I'm close to give up on this.
Would be a shame.
> It's more like that @nrikonomov's comment kills our efforts to find a better
> solution for most users.
I'm not sure what exactly @nrikonomov meant, I thought that with the "project
killing" comment he meant the use of those "250,250,250
> Please use only 255,255,255 for light background, no 250,250,250 shades and
> the like ... or I'll find you :)
Regarding the light background, it was done here:
https://github.com/geany/geany-osx/commit/9e2ec78fbbabc45717c30fc56a724a09b9a3a275
Also for Windows Enrico is planning to use
> Please use only 255,255,255 for light background, no 250,250,250 shades and
> the like ... or I'll find you :)
Regarding the light background, it was done here:
https://github.com/geany/geany-osx/commit/9e2ec78fbbabc45717c30fc56a724a09b9a3a275
Also for Windows Enrico is planning to use
Unfortunately we currently don't have a way to specify different keybindings
for Linux, Windows, or macOS so they are identical for these platforms (not a
big problem for Linux/Windows where the defaults don't differ too much but a
bigger problem for macOS where the default keybindings are
@techee commented on this pull request.
> + if (source_file->lang == TM_PARSER_C || source_file->lang ==
> TM_PARSER_CPP)
+ {
+ const gchar **ext;
+ const gchar *common_src_exts[] =
+ {".c", ".C", ".cc", ".cp", ".cpp", ".cxx", ".c++",
> Sometimes we include C files in other C files. Then static is not file-local.
> So we should probably also consider includes (not just files with header
> extension) or just revert the original change.
That's true, I'm just wondering how such files typically look like and for what
purpose
@techee pushed 2 commits.
6d68dfdaaab28669a5af35867abe62902b12b927 Add Raku (Perl 6) filetype support
(lexer and ctags parser)
5cdead43c65d866a3efc6e7fd2541b7f17c63d8d Update HACKING regarding adding a
lexer and using meson
--
View it on GitHub:
Also, regarding the ellipsize, I think it would be useful to split it into two
parts:
1. path plus line number - max length 40 with `PANGO_ELLIPSIZE_START`
2. signature - max length 40 with `PANGO_ELLIPSIZE_END`
and then join them for the resulting string. This way you'll always have the
file
I just marked this PR with the 2.0 milestone as it's needed on macOS which
doesn't have X11. From my point of view this PR can be merged.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1236#issuecomment-1676426508
You are receiving this because
I don't know but wouldn't it be better to do it the other way round - i.e.
display the file name and line number directly in the list as before and show
the signature as a tooltip? What I get right now doesn't seem very useful and
if you for instance want to navigate to gpointer data, one would
I meant to post the above to #3542 so I reposted it there too.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3475#issuecomment-1676441305
You are receiving this because you are subscribed to this thread.
Message ID:
I don't know but wouldn't it be better to do it the other way round - i.e.
display the file name and line number directly in the list as before and show
the signature as a tooltip? What I get right now doesn't seem very useful and
if you for instance want to navigate to `gpointer data`, one
@techee pushed 1 commit.
01cdc19725cd8acfd88b1d486394ad8b50be8a5c geanypg: Update because of Scintilla
5.1.5 SCI_GETSELTEXT change
--
View it on GitHub:
https://github.com/geany/geany-plugins/pull/1154/files/b8d8689f315f6b7c464de1d2ae90aeeba7758d1e..01cdc19725cd8acfd88b1d486394ad8b50be8a5c
This is to mitigate this change in Scintilla 5.1.5:
When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL
buffer argument to discover the length that should be allocated, do not include
the terminating NUL in the returned value. The value returned is 1 less than
previous
@techee pushed 1 commit.
52f3884823b247288f53fce00f1f0e27ed8a87fb geanypg: Update because of Scintilla
5.1.5 SCI_GETSELTEXT change
--
View it on GitHub:
https://github.com/geany/geany-plugins/pull/1154/files/01cdc19725cd8acfd88b1d486394ad8b50be8a5c..52f3884823b247288f53fce00f1f0e27ed8a87fb
@techee pushed 2 commits.
f8c11ecca5b47c40f76cc6392b01dcaf798ba0f0 Add Raku (Perl 6) filetype support
(lexer and ctags parser)
bde72f7fd692b83253dde38dd3abf8dcdb9723d8 Update HACKING regarding adding a
lexer and using meson
--
View it on GitHub:
I just noticed this problem and I personally also find it a little too verbose
and harder to use than the previous simple `filename: line_number`.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3475#issuecomment-1676107339
You are receiving this
401 - 500 of 750 matches
Mail list logo
