This fixes #3362.
I added the keywords from Fortran 2018 with the help of a python script (if this has to be done again in the future).
The current standard and keywords can be found here:
https://j3-fortran.org/doc/year/18/18-007r1.pdfhttps://github.com/cdslaborg/FortranKeywords
<details>
<summary>Script</summary>
```python
old_f = open("filetypes.fortran", "r")
old_lines = old_f.read().splitlines()
old_primary = set()
old_intrinsic_functions = set()
old_user_functions = set()
for line in old_lines:
s = line.split("=")
if s[0] == "primary":
for w in s[1].split():
old_primary.add(w)
elif s[0] == "intrinsic_functions":
for w in s[1].split():
old_intrinsic_functions.add(w)
elif s[0] == "user_functions":
for w in s[1].split():
old_user_functions.add(w)
old_f.close()
f = open("FortranKeywords2018.txt", "r")
lines = f.read().splitlines()
primary = set()
intrinsic_functions = set()
user_functions = set()
types_primary = {"specifier", "statement", "attribute"}
types_intrinsic_functions = {
"function_elemental",
"function_transformational",
"function_inquiry",
"function_void",
"subroutine",
"subroutine_atomic",
"subroutine_pure",
"constant",
"subroutine_collective",
"type_derived",
"module_intrinsic",
}
types_user_functions = {}
old_maping = {
"primary": set(),
"intrinsic_functions": set(),
"user_functions": set(),
"unspecified": set(),
}
for line in lines:
s = line.split(",")
ws = s[0].replace("(", " ").replace(")", " ").replace(".", " ").split()
# check old maping
for w in ws:
wl = w.lower()
if wl in old_intrinsic_functions and not wl in old_primary :
old_maping["intrinsic_functions"].add(s[1])
elif wl in old_primary and not wl in old_intrinsic_functions:
old_maping["primary"].add(s[1])
# elif wl in old_user_functions:
# old_maping["user_functions"].add(s[1])
old_maping["unspecified"].add(s[1])
old_maping["unspecified"] = (
old_maping["unspecified"]
- old_maping["primary"]
- old_maping["intrinsic_functions"]
- old_maping["user_functions"]
)
if s[1] in types_primary:
for w in ws:
primary.add(w.lower())
elif s[1] in types_intrinsic_functions:
for w in ws:
intrinsic_functions.add(w.lower())
elif s[1] in types_user_functions:
for w in ws:
user_functions.add(w.lower())
else:
print("not added:", s)
if s[0] in old_primary:
print("old_primary")
if s[0] in old_primary:
print("old_intrinsic_functions")
f.close()
old_dubs = old_intrinsic_functions.intersection(old_primary)
wrong = (
primary.intersection(old_intrinsic_functions).union(
intrinsic_functions.intersection(old_primary)
)
- old_dubs
)
print("wrong:", wrong)
# print("old duplicates:", old_dubs)
# dubs = primary.intersection(intrinsic_functions)-old_dubs
# print("dubs:",' '.join(dubs))
print("\nmissing primary:", " ".join(primary - old_primary))
print(
"\nmissing intrinsic_functions:",
" ".join(intrinsic_functions - old_intrinsic_functions),
)
print("\n approximate old maping:", old_maping)
# print("legacy:")
# print("primary:", old_primary-primary)
# print("intrinsic_functions:", old_intrinsic_functions-intrinsic_functions)
```
</details>
Some if the keywords are added to both primary and intrinsic_functions, but this was also the case in the past. I mapped keyword categories (from the standard) to "primary" and "intrinsic_functions" like it has been in the past, and new categories like "module_intrinsic" have been added to the most fitting one.
As far as I can tell, it is correct and all keywords are handled. Also, I didn't remove any of the existing keywords to keep compatibility to older Fortran versions.
<details>
<summary>Category Mapping</summary>
```python
primary = {"specifier", "statement", "attribute"}
intrinsic_functions = {
"function_elemental",
"function_transformational",
"function_inquiry",
"function_void",
"subroutine",
"subroutine_atomic",
"subroutine_pure",
"constant",
"subroutine_collective",
"type_derived",
"module_intrinsic",
}
```
</details>
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3656
-- Commit Summary --
* update fortran keywords
-- File Changes --
M data/filedefs/filetypes.fortran (4)
-- Patch Links --
https://github.com/geany/geany/pull/3656.patchhttps://github.com/geany/geany/pull/3656.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3656
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3656(a)github.com>
According to b0b0ebb469a6b7eb74d321e6f5d7fe6f0bfcf6ba we guard against proxying the widget more than once for some Windows reasons, but this breaks the case where the same GeanyEntryAction has to re-create a fresh proxy, like when moving the item around.
So, move the guard value to the proxied widget, not the action.
Fixes #3831.
As this is Windows-related (see b0b0ebb469a6b7eb74d321e6f5d7fe6f0bfcf6ba), it could be nice if somebody could actually check that this patch doesn't break anything there. I likely won't, at least in a yearly manner.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3838
-- Commit Summary --
* Fix search entry after editing the toolbar
-- File Changes --
M src/geanyentryaction.c (6)
-- Patch Links --
https://github.com/geany/geany/pull/3838.patchhttps://github.com/geany/geany/pull/3838.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3838
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3838(a)github.com>
The Help command does not work on my Linux Mint 21 system, because BROWSER env variable is not set so `sensible-browser` does nothing. At minimum, the Help command should report an error when the return value is non-zero.
However, my system does have a preferred browser set to firefox - I'm not sure if this is part of a (freedesktop.org?) standard. Ideally Geany would use that as the default browser tool. Or is that moving to $BROWSER instead?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3468
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3468(a)github.com>
settings in filetypes.pascal:
```
[settings]
tag_parser=Pascal
lexer_filetype=Pascal
```
I try to improve pascal lexer with class and function name hightlighting (in LexCPP named "Global classes and typedefs"). For that geany tagger has to fill a wordlist with keys found by tagging function (see ctags/parsers/pascal.c)
In general parser seems to work sucessfully, because sidebar is updated correctly, which means function names can be seen there (`sidebar_update_tag_list works` o.k.).
On the other hand, if I attach debug code to `document.c:document_highlight_tags` function to see result of call of `symbols_find_typenames_as_string` always an empty string is returned.
Diving deeper in the code, I see whithin `symbols_find_typenames_as_string`, `typedefs->len`is always zero, which means `app->tm_workspace->global_typename_array` is not filled correctly.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3848
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3848(a)github.com>
Hi, this PR fixes this error spotted in Valgrind:
```
Invalid read of size 1
at 0x49211F3: utils_get_initials (utils.c:775)
by 0x48EBA56: load_dialog_prefs (keyfile.c:1025)
by 0x48EBA56: read_config_file (keyfile.c:1258)
by 0x48ED7C7: configuration_load (keyfile.c:1286)
by 0x48EFBB7: load_settings (libmain.c:917)
by 0x48EFBB7: main_lib (libmain.c:1154)
by 0x5FC7CCF: (below main) (libc_start_call_main.h:58)
Address 0xd21bfd1 is 0 bytes after a block of size 1 alloc'd
at 0x4843788: malloc (vg_replace_malloc.c:442)
by 0x5B26902: g_malloc (gmem.c:100)
by 0x5B1BC2A: g_key_file_parse_value_as_string (gkeyfile.c:4310)
by 0x5B1BD71: g_key_file_get_string (gkeyfile.c:1965)
by 0x49213FF: utils_get_setting_string (utils.c:900)
by 0x48EBA29: load_dialog_prefs (keyfile.c:1023)
by 0x48EBA29: read_config_file (keyfile.c:1258)
by 0x48ED7C7: configuration_load (keyfile.c:1286)
by 0x48EFBB7: load_settings (libmain.c:917)
by 0x48EFBB7: main_lib (libmain.c:1154)
by 0x5FC7CCF: (below main) (libc_start_call_main.h:58)
```
I slightly reshaped `utils_get_initials()` to make it kinda more intuitive. It also got improved a bit, in that it now produces correct results when `name` begins with a space (which AFAICT doesn't really occur, but why not...)
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3844
-- Commit Summary --
* Fix read past end of string in utils_get_initials()
-- File Changes --
M src/utils.c (12)
-- Patch Links --
https://github.com/geany/geany/pull/3844.patchhttps://github.com/geany/geany/pull/3844.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3844
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3844(a)github.com>
Fix utils_get_initials() reading past the end of the input string if that string was empty.
Also fix support for non-ASCII initials for which the UTF-8 character representation would have been truncated to the first byte only, leading to an invalid value.
The implementation here also tries to handle combining accents, although that part might not be really solid.
Fixes #3844.
---
This might get a bit over-the-top with the support for non-composable combining marks, but well, now it's there? :)
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3846
-- Commit Summary --
* Fix invalid memory access and Unicode support in utils_get_initials()
-- File Changes --
M src/utils.c (42)
M tests/test_utils.c (23)
-- Patch Links --
https://github.com/geany/geany/pull/3846.patchhttps://github.com/geany/geany/pull/3846.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3846
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3846(a)github.com>
On need to edit, modify the 'black scheme', tried to open the file but have no idea where the Windows' Geany's color scheme is saved
as in **Users/....geany** setting directory , `colorscheme` dir. is empty, while (almost) all file settings else are available
Please help out!
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-themes/issues/72
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-themes/issues/72(a)github.com>
Properly display the module node itself in the symbols tree so it can be the module content's parent instead of having each content node showing the module name as prefix.
Fixes #2650.
This is a revamp of the old patch I suggested ages ago in #2650 but failed to PR/commit.
@fbrau can you test this and see if all is good for you?
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3837
-- Commit Summary --
* Erlang: display module node in the symbols tree
-- File Changes --
M src/tagmanager/tm_parser.c (3)
M tests/ctags/maze.erl.tags (2)
M tests/ctags/test.erl.tags (2)
-- Patch Links --
https://github.com/geany/geany/pull/3837.patchhttps://github.com/geany/geany/pull/3837.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3837
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3837(a)github.com>
This happens with erlang files, just erlang files
Im on 1.37. If im not wrong, this didnt happened on 1.36...
It looks (erlang file):
It should look (python file):
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2650