> 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.
> @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
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
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:
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
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
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:
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
> 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
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
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
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
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
> 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
> 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
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:
@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
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
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
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:
> 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
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:
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:
> 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
Reopened #18.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/18#event-8847336407
You are receiving this because you are subscribed to this thread.
Message ID:
Hmm, I just tried the latest builds and this bug is back, reopening :-(.
It would be worth investigating what exactly Scintilla does with the
autocompletion popup and if there isn't any workaround.
--
Reply to this email directly or view it on GitHub:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
Maybe a question - by just having a look at the parser (and not knowing the
language), it seems that the parser supports scopes (i.e. nesting one tag
inside other tag). The provided unit test only shows some simple script without
this. But if scopes are supported, then it should be mentioned
Closed #2685 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2685#event-8845848075
You are receiving this because you are subscribed to this thread.
Message ID:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
Closed #27 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/27#event-8845844960
You are receiving this because you are subscribed to this thread.
Message ID:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
Closed #40 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/40#event-8845842694
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #41 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/41#event-8845835181
You are receiving this because you are subscribed to this thread.
Message ID:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some
extra fixes which I plan to release as the official macOS build on the
Downloads page unless there are some problems with it:
Closed #42 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/42#event-8845832359
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #3433 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3433#event-8843302539
You are receiving this because you are subscribed to this thread.
Message ID:
Nah, you were just lucky that I noticed this quickly and had time to test it
and reply (@elextr on the other hand seems to be always on :-).
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/43#issuecomment-1481030985
You are receiving this because
> Ventura, whatever version that is
OK, so it's 13 (I remember the numbers, not the names ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/43#issuecomment-1480217216
You are receiving this because you are subscribed to this thread.
Message ID:
OK, great. Just curious, are you using macOS 13?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/43#issuecomment-1479998557
You are receiving this because you are subscribed to this thread.
Message ID:
> Yes, and IIRC in some SQLs `$thing` is also meaningful, but only plain `$$`
> strings can clash with keywords that are going to be looked up in the table.
Oh yeah, totally, and these can also be keywords and looked up in the table - I
just added support to the parser for C-preprocessor-like
Interesting. I see the same problem with the official releases but recently I
made new binaries with the latest gtk-osx here and these don't seem to exhibit
the problem:
https://download.geany.org/snapshots/geany-1.38_osx_arm64.dmg
https://download.geany.org/snapshots/geany-1.38_osx.dmg
These
> But the point was that the real problem is the parser, and that should be
> fixed to be smarter, as you say:
> 1. see $$
> 2. scan until first non-keyword character
> 3. now look it up in the keyword table
> 4. if not keyword skip string to $$
This part of the parser is quite tricky. The
Maybe just to be clear, when storing values in the hash table, the `1000` here
https://github.com/geany/geany/blob/dea43baf477ab71650cdfc54fa976714def9c170/ctags/main/keyword.c#L121
means "infinity", not a real limit (the table is used for keywords only, there
will, hopefully, be no languages
> after the patch it still goes through strlen characters and computes the hash
> (at least up to maxlen)
The key is that it's up to maxLen and not potentially the whole-file-len.
Assume, for instance, that you have a 1MB file and this problem happens at the
beginning of the file. Also assume
Fixed by #3413 (apart from the documentation, but IMO this would just add a
noise to the manual).
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2689#issuecomment-1466546751
You are receiving this because you are subscribed to this thread.
Message
Closed #2689 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2689#event-8734273571
You are receiving this because you are subscribed to this thread.
Message ID:
Great, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3413#issuecomment-1466312299
You are receiving this because you are subscribed to this thread.
Message ID:
> My personal feeling is that we shouldn't use them in our conffiles,
Agree. I think that apart from the reasons mentioned above, it just looks nicer
in the conf file when all commented-out lines start with `#`.
> but that we should support them in the file type; I don't see any reason why
>
@techee commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
@techee pushed 1 commit.
1adb0baec35b054eb6bce275b94a32589ddf4347 fixup! Improve code commenting-out
global config files
--
View it on GitHub:
https://github.com/geany/geany/pull/3413/files/94c3e110e1a9b5da60faaa81be42759d95365886..1adb0baec35b054eb6bce275b94a32589ddf4347
You are receiving
@techee commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
@techee commented on this pull request.
> @@ -2096,6 +2096,33 @@ void ui_table_add_row(GtkTable *table, gint row, ...)
}
+/* comment-out all lines that are not already commented out except sections */
+static void comment_conf_files(ScintillaObject *sci)
+{
+ gint line, line_count;
+
These are two improvements of the comments discussed in #3413:
1. The indented `#command_example();` in
```ini
# set to false if a comment character/string should start at column 0 of a
line, true uses any
# indentation of the line, e.g. setting to true causes the following on
pressing CTRL+d
>> Wait, if we don't need to handle leading whitespaces (which we don't need
>> AFAIK, although it might be nice), the logic is merely if (*line && *line !=
>> '[' && *line != '#') comment();, isn't it?
> Yes, but I also think we shouldn't add # on empty lines or lines containing
> only
> IMO, just use one single # as you did at the start, and don't worry about the
> comment_use_indent comment comment comment (oops, got carried away ).
> `#` as documentation comments in conffiles is most common
> `#`key=value as commented-out default/suggestion is common (many things in
>
> all I lose is the Symbols tab, and that's a bit flakey anyway for PL/SQL code
The biggest problem with the parser was that the file you provided was filled
with conditional code that had this form:
```
$IF $$VERSION > 1 $THEN
...
$END
```
The `$$VERSION` clashed with PostgreSQL's "dollar
This enables a family of word-related text object commands such as:
ciw, diw, viw etc.
Fixes https://github.com/geany/geany-plugins/issues/1155.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1240
-- Commit Summary --
* vimode:
I'm not sure we should do that. If the decision is to use LuaJIT with a Lua 5.1
fallback, we should support just these versions. Supporting tons of lua
versions each with slight language modifications could really become hard to
maintain. I don't think anyone of us will have time to test the
Thubms up for having a look at this! I didn't have a detailed look at the code
but I shamelessly stole the patch and applied during the macOS binary build here
https://github.com/geany/geany-osx/blob/master/geany_patches/08-geany_plugins_geanylua_remove_x11_dependency.patch
and this function
Closed #3411 as completed via #3412.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3411#event-8683212698
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #3412 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3412#event-8683212390
You are receiving this because you are subscribed to this thread.
Message ID:
@Syntonica I've just created an arm64 binary of Geany with the Lua plugin
enabled:
https://download.geany.org/snapshots/geany-1.38_osx_arm64.dmg
Would you give it a try? If you have a x86_64 mac, please let me know and I'll
create a binary for it too.
--
Reply to this email directly or view
Closed #1 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/1#event-8679938153
You are receiving this because you are subscribed to this thread.
Message ID:
I think this isn't an issue any more with the latest GTK drawing improvements
on macOS. Closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/1#issuecomment-1457206864
You are receiving this because you are subscribed to this thread.
Message
Closed #38 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/38#event-8679918012
You are receiving this because you are subscribed to this thread.
Message ID:
Because of some problems with the macOS build of git master, I just modified it
that instead of cloning the repo it just downloads the current master from
https://github.com/geany/geany/archive/refs/heads/master.tag.gz. The tarball,
however, doesn't contain a git repository and the build fails
> True, and https://github.com/geany/geany-plugins/pull/1235 suggests the
> changes are simple enough that both 5.1 and 5.4 C APIs could be supported
> within the #ifdef pain threshold. As a wise man once said, if offered a
> questionable choice, take all three (at least until a winner is
I just tried and on my other linux VM geanylua with the PR runs with Lua 5.4
without any modifications needed.
I'm not really convinced by the performance argument - I just don't see how
anyone would notice. The whole Geany except Scintilla lexers and ctags parsers
could be written in a
OK, I just tried on another VM and it compiles and runs with Lua 5.4 too,
without any modifications. The only time some modifications were needed was for
5.1->5.2 transition, the 5.2->5.3 transition didn't require any change either.
--
Reply to this email directly or view it on GitHub:
@elextr @xiota I think we maybe didn't understand each other - I have no real
problem with using LuaJIT, I just think it's more beneficial to migrate to a
new Lua version than being stuck at 5.1 - IMO it's just a workaround and not a
real fix.
I just created this PR migrating GeanyLua to Lua
This PR migrates geanylua to Lua 5.3 (my oldish distro doesnt provide lua
5.4 so I didnt test, maybe it works too). There were mostly just simple
changes. From my limited testing, everything seems to work.
Posting as an (in my opinion better) alternative to #1233
You can view, comment on, or
> My understanding is that it's an ARM64e processor feature/issue.
Yes, but I have a macbook with this processor already and I provide macOS
binaries of Geany for it here
https://download.geany.org/geany-1.38_osx_arm64.dmg which, if geanylua is added
(I've just managed to get it running), will
OK, so I had a detailed look at what the problems with building this plugin
might be and did run into these two issues:
1. lua is only built as a static library by the provided makefile and GeanyLua
checks for the dynamic library of lua provided by distributions. I think this
isn't a big
I'm just wondering - what problem does the migration to luajit try to solve? As
far as I can say, Lua 5.1 is available as a package and offered by
distributions. I've just checked luajit's open bugs and one of them is this one
https://github.com/LuaJIT/LuaJIT/issues/559
where it doesn't
> Lua 5.4 is not a drop-in replacement for Lua 5.1, so it would require major
> rewrites.
Just out of curiosity, what are the changes that make it hard to migrate to the
new version?
--
Reply to this email directly or view it on GitHub:
It's not included for macOS - I don't remember why, if it was just that I
didn't try or know how to use the plugin, or if there was some actual problem.
Right now the macOS binary uses the "hardened runtime" where JIT is disabled
but one can easily add a certain flag and enable it so it
Seems to work on macOS without any problems. And I agree that we should start
using GtkApplication (if, in the far future, we switch to GMenuModel for menus,
we could avoid using the mac-integration library because the global menu should
be then handled by GtkApplication).
--
Reply to this
> Oh ok, but having added a parser I wonder why the creator of the Typescript
> filetype didn't go the whole hog and make a built-in filetype.
This is because there was no typescript parser originally and I added it in the
final "ctags sync" PRs but I did it in a lazy way only.
--
Reply to
I just had a look at a few filetype's configurations and it's really a mixed
bag of styles. I think it would make most sense to document all the config
options in `filetypes.common` _only_ and language-specific config files would
contain only those values they override to some other value than
> Looks good to me, and its simple, just add # to every line except headings.
And also except empty lines.
> I would not worry about the indented example, after adding a #, it is no
> longer an accurate example whichever way its done.
I actually don't think this is even a valid conf file
@techee pushed 1 commit.
94c3e110e1a9b5da60faaa81be42759d95365886 fixup! Improve code commenting-out
global config files
--
View it on GitHub:
https://github.com/geany/geany/pull/3413/files/766f756495e0704e7656773bdbf29f096ef45d16..94c3e110e1a9b5da60faaa81be42759d95365886
You are receiving
I wouldn't make the setting variable comments too similar to the actual
comments - they then become hard to distinguish, see:
```ini
# set to false if a comment character/string should start at column 0 of a
line, true uses any
# indentation of the line, e.g. setting to true causes the
@techee pushed 1 commit.
766f756495e0704e7656773bdbf29f096ef45d16 fixup! Improve code commenting-out
global config files
--
View it on GitHub:
https://github.com/geany/geany/pull/3413/files/d43357f8cf8d08abda80a767c462c778e3e60683..766f756495e0704e7656773bdbf29f096ef45d16
You are receiving
> Kudos for the new source layout btw, makes for a very clean patch
You missed all the fun of the final "ctags sync" pull requests ;-).
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3412#issuecomment-1445209091
You are receiving this because you are
> Probably not to new users who are the ones fiddling with conf files, using #
> for a comment is "well known", but whats this #~ thing? And do I leave the ~
> or what? Have had all those during various support interactions.
This is definitely a good reason to use just the simple `#` then.
>
> Just a comment [Edit: pun intended :-)], the original concept was that it
> used the toggle comment marker so blocks of settings could just be toggled.
I could do it too with this patch too - right now the patch only inserts `#`
but it could also be `#~ `. Maybe it's a good idea also because
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
> 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
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
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:
> No its named right, its the count of the number of characters the same, it
> needs one subtracted because C is 0 based indexing, but having 0 characters
> the same is hard to detect as markup :-)
Yep, I got this one wrong.
> Although
>
801 - 900 of 1933 matches
Mail list logo
