This is the follow-up PR for #3488 and #3039 to seperate the code for generating the ctags format into a commonly used helper module and to use the ctags format also for the global PHP tags.
Works fine so far.
I noticed the return type (`typeref` in ctags speak) for symbols is not parsed correctly and so not displayed in the calltip.
This hasn't been a problem for Python as there is no return type information available. But for PHP it is.
Maybe this is related to #3049? @techee
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3512
-- Commit Summary --
* Add helper script for generating ctags files in Python
* Generate PHP global tags in ctags format
-- File Changes --
M data/tags/std.php.tags (18624)
M scripts/create_php_tags.py (39)
M scripts/create_py_tags.py (31)
A scripts/create_tags_helper.py (70)
-- Patch Links --
https://github.com/geany/geany/pull/3512.patchhttps://github.com/geany/geany/pull/3512.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3512
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3512(a)github.com>
Created by "scripts/update-nsis-functions.sh".
Changed keywords:
```diff
Changed functions:
+!assert
+!uninstfinalize
+getknownfolderpath
+getregview
+getshellvarcontext
+getwinver
+ifaltregview
+ifrtllanguage
+ifshellvarcontextall
+manifestappendcustomstring
+manifestlongpathaware
+readmemory
+sectioninsttype
Changed Variables:
+$commondesktop
+$commonlocalappdata
+$commonprogramdata
+$commonsmprograms
+$commonstartmenu
+$commontemplates
+$userappdata
+$userdesktop
+$userlocalappdata
+$usersmprograms
+$userstartmenu
+$usertemplates
```
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3487
-- Commit Summary --
* Update NSIS filetype keywords
-- File Changes --
M data/filedefs/filetypes.nsis (4)
-- Patch Links --
https://github.com/geany/geany/pull/3487.patchhttps://github.com/geany/geany/pull/3487.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3487
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3487(a)github.com>
`scripts/changelist.pl`: process ChangeLog which we do not use anymore
`scripts/cross-build-mingw.sh`: old cross build script, replaced by #3315
`scripts/rstrip-whitespace.py`: probably unused (as assumed in #2615)
There are more candidates:
`scripts/fix-alignment.pl`
`scripts/fix-cxx-comments.pl`
`scripts/warning-summary.pl`
I'm not sure if any of those are still used by anyone? @ntrel @b4n @elextr
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3486
-- Commit Summary --
* Remove obsolete helper scripts
-- File Changes --
D scripts/changelist.pl (135)
D scripts/cross-build-mingw.sh (98)
D scripts/rstrip-whitespace.py (23)
-- Patch Links --
https://github.com/geany/geany/pull/3486.patchhttps://github.com/geany/geany/pull/3486.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3486
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3486(a)github.com>
Given that Markdown has lots of undefined semantics, this may very well be a valid interpretation of certain broken Markdown documents. But I guess most would agree that the priority should be the other way around.
Example: (Save as `something.md` and open with Geany)
_This is "underlined"
```
should_be code
```
This sentence is considered code, because the
"matching" underscores had priority (?)
Note that the "stray underline" can also occur in HTML inline-comments, where they don't stand for underlining anyway.
<!-- Like this one. I know very well that this won't usually appear. -->
--
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/1439
![{464BD2C3-D2A8-4cd8-ADE3-925F52F8647D}](https://github.com/geany/geany-plugins/assets/139338389/90e72e2d-2132-46ba-bba5-5fc7340f4b2e)
How incomprehensible this is! Blue Chinese can be displayed normally, while red cannot!
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1262
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/issues/1262(a)github.com>
Geany version 1.33 (raspberry pi) not reloading the modified include file.
Scenario.
Project is composed of multiple project specific include and source cpp file.
One the supporting cpp file and corresponding include file is modified to add new method.
All the changes is saved.
recompile the project and it come back with an error unknown method. The unknown method is the newly added method.
Current solution.
The force the geany to reload the h file. I have to comment out the include section that refer to this modified h file.
Predictably the compiler produce an unknown method/variable.
Uncomment the include section where the h file is defined.
Recompile the project and the problem disappear.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3533
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3533(a)github.com>
Please include the Scintilla-Lexers for the Nim-language into Geany. As of now one uses the Python-Lexer and -Parser. There are two Lexers for Nim called "LexNim" and "LexNimrod". Both seem to be about 2-yrs old. "LexNimrod" was provided by the creator of Nim. I'd ask which of the two Lexers are more up-to-date.
thx Andreas
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3520
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3520(a)github.com>
When "load files from the last session" is enabled, regardless of whether a project is loaded, the previously active document is reactivated when Geany is closed and restarted with a document at the command line or from a file manager. The expected behavior is to activate the newly opened document for editing.
This occurs with the default config and no plugins loaded. Does not occur in an old build from 2021-12-30. Does occur in builds dated after 2022-05-01. I did not build Geany between those dates, so don't know when the new behavior was introduced. I do not see it in the manual, nor do I see any option to revert to the old behavior.
To reproduce:
1. Open Geany.
2. Open a several of documents.
3. Close Geany.
4. Open Geany with a file from a file manager or command line.
5. Geany will open and activate the last active document. Expected behavior is to activate the newly opened document for editing.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3210
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3210(a)github.com>
PR #3125 (commit 22aac443) broke that accidentally by moving the
"switch to last used tab" to a idle callback (g_idle_add()). This
runs after opening files from the command line.
Now, the same callback is moved to libmain.c and is only registered
when there are no files from the command line.
Additionally, projects gains a private copy of the current_page loaded
from the keyfile.
Fixes #3210
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3267
-- Commit Summary --
* Restore startup behavior to focus files from the command line after session files
-- File Changes --
M src/keyfile.c (40)
M src/keyfile.h (4)
M src/libmain.c (52)
M src/project.c (1)
M src/projectprivate.h (1)
-- Patch Links --
https://github.com/geany/geany/pull/3267.patchhttps://github.com/geany/geany/pull/3267.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3267
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3267(a)github.com>