I have a large Java file (4.8MB). If I insert a new <b><big>{</big></b> near the start of this file, the run time for the parser becomes very long (5 minutes or so) - while the parser is running the editor is unusable. Is there some way to prevent this from happening? By parser I mean the code that determines the coloration of the keywords, strings, etc. <b>Thanks!</b>
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/791
So I tried to just get the regex parser compile and run but it turned out that it requires so many changes in ctags itself that it's just impossible to perform without the complete ctags sync. So the first patch is a huge blob which gets all the upstream changes (no way to get this more granular) on top of which I applied the Geany-related changes. Regex parsers using GNU regex work, at least on linux (not sure about Windows - someone has to get it compile there if it doesn't work).
This was hell a lot of work and something I don't want to do in the future in this form. So in the subsequent patches I tried to minimize Geany-related diffs to the absolute minimum, even if it meant adding and compiling more uctags code (which we'll never actually use). I'd say the result is quite nice, the diffs are really minimalistic and easy to locate in the code. The upstream commit against which this is made is
7dd02539554a81aa39b49ce8df9d4511f92d9f4f
which is already several months old but this is the one against which we have the parsers synced (in fact, it's against https://github.com/techee/ctags/commit/915d69794cd90af9a2e577dd57dd888341ee… to have this fix applied). The best way to review this pull request is to make a diff in meld against this commit in uctags - the diff is really small - and also having a look at the patches excluding the first one which is just unreviewable.
I'd really like if this could get merged soon because I don't want to get again to the state where I have to merge multi-year diffs from uctags. My proposal is that I'd prepare a patch at the beginning of every Geany release cycle which syncs it with uctags (by just taking the current uctags code and applying Geany diffs on top of it) so it gets tested during the development cycle. If we make releases 3 times a year, the diffs shouldn't be so huge and much more easily manageable.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2132
-- Commit Summary --
* Sync with upstream ctags
* Enable Cobol test
* Rename Geany ctags diff markers
* Store varType inside typeRef[1]
* Add all ctags writers to eliminate some geany diffs
* Move bufferOpen() to parse.c to eliminate diff in read.c/h
* Reduce diff size in fileNameMatched()
* Reduce number of diffs in main.c
* Use upstream mbcs.h
* Reduce number of diffs in parse.c/h
* Move diffs together in entry.c/h
* Move isIgnoreToken() to lcpp.c/h which we don't sync with uctags
* Eliminate diff in options.c by adding interactive_p.h
* Reuse createTagsWithFallback1() for Geany
* Eliminate bufferOpen()
* Make sure all functions/global vars added to ctags have the "geany" prefix
* Eliminate diff in runParserInNarrowedInputStream()
* Eliminate diff in promise.c by manually enabling Xtag during initialization
* Add some comments
* Make sure all kinds are enabled in ctags for all languages
* Use the builtin ctags writer functionality to pass tags to Geany
* Remove some diffs from parse.c
* Reuse the functionality of createTagsWithFallback()
* Simplify various ctags-api.c implementations using existing ctags functions
* Fix ctags warning because of cobol parser f/file kind which is reserved
* Add simple ActionScript test
-- File Changes --
M configure.ac (2)
M ctags/Makefile.am (34)
M ctags/main/args.c (6)
R ctags/main/args_p.h (6)
A ctags/main/colprint.c (295)
A ctags/main/colprint_p.h (37)
M ctags/main/ctags-api.c (134)
M ctags/main/ctags-api.h (4)
M ctags/main/ctags.h (8)
M ctags/main/debug.c (102)
M ctags/main/debug.h (28)
M ctags/main/dependency.c (349)
M ctags/main/dependency.h (42)
M ctags/main/e_msoft.h (10)
M ctags/main/entry.c (682)
M ctags/main/entry.h (85)
A ctags/main/entry_p.h (68)
A ctags/main/entry_private.c (37)
M ctags/main/error.c (41)
M ctags/main/field.c (952)
M ctags/main/field.h (47)
M ctags/main/flags.c (107)
R ctags/main/flags_p.h (16)
M ctags/main/fmt.c (57)
R ctags/main/fmt_p.h (0)
M ctags/main/general.h (13)
A ctags/main/gvars.h (29)
A ctags/main/interactive_p.h (29)
M ctags/main/keyword.c (18)
M ctags/main/keyword.h (9)
A ctags/main/keyword_p.h (26)
M ctags/main/kind.c (536)
M ctags/main/kind.h (78)
M ctags/main/lcpp.c (72)
M ctags/main/lcpp.h (4)
M ctags/main/lregex.c (2230)
A ctags/main/lregex.h (47)
A ctags/main/lregex_p.h (76)
D ctags/main/lxcmd.c (1227)
M ctags/main/lxpath.c (12)
A ctags/main/lxpath.h (81)
M ctags/main/main.c (194)
M ctags/main/mbcs.h (23)
M ctags/main/nestlevel.c (1)
M ctags/main/nestlevel.h (1)
M ctags/main/options.c (1985)
M ctags/main/options.h (167)
A ctags/main/options_p.h (183)
D ctags/main/output-ctags.c (59)
D ctags/main/output.h (50)
A ctags/main/param.c (57)
A ctags/main/param.h (38)
M ctags/main/parse.c (2988)
M ctags/main/parse.h (246)
A ctags/main/parse_p.h (154)
M ctags/main/parsers.h (3)
M ctags/main/promise.c (223)
M ctags/main/promise.h (12)
A ctags/main/promise_p.h (24)
M ctags/main/ptag.c (84)
R ctags/main/ptag_p.h (9)
M ctags/main/read.c (622)
M ctags/main/read.h (42)
M ctags/main/repoinfo.h (2)
M ctags/main/routines.c (129)
M ctags/main/routines.h (75)
A ctags/main/routines_p.h (107)
M ctags/main/selectors.c (190)
M ctags/main/selectors.h (14)
M ctags/main/sort.c (94)
M ctags/main/strlist.c (106)
M ctags/main/strlist.h (2)
A ctags/main/subparser.h (81)
M ctags/main/trace.h (101)
M ctags/main/types.h (30)
A ctags/main/writer-ctags.c (292)
A ctags/main/writer-etags.c (133)
A ctags/main/writer-json.c (248)
A ctags/main/writer-xref.c (72)
A ctags/main/writer.c (112)
A ctags/main/writer_p.h (81)
M ctags/main/xtag.c (350)
M ctags/main/xtag.h (43)
M ctags/parsers/c.c (4)
M ctags/parsers/cobol.c (2)
M ctags/parsers/erlang.c (1)
M ctags/parsers/go.c (3)
M ctags/parsers/make.c (1)
M ctags/parsers/objc.c (3)
M ctags/parsers/pascal.c (2)
M ctags/parsers/perl.c (1)
M ctags/parsers/python.c (1)
M ctags/parsers/r.c (1)
M ctags/parsers/ruby.c (2)
M ctags/parsers/rust.c (4)
M ctags/parsers/sql.c (2)
M src/tagmanager/tm_parser.c (2)
M tests/ctags/Makefile.am (5)
M tests/ctags/Package.pm.tags (3)
M tests/ctags/bug1938565.sql.tags (2)
M tests/ctags/random.sql.tags (7)
M tests/ctags/refcurs.sql.tags (2)
A tests/ctags/simple.as (44)
A tests/ctags/simple.as.tags (20)
-- Patch Links --
https://github.com/geany/geany/pull/2132.patchhttps://github.com/geany/geany/pull/2132.diff
--
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/pull/2132
I just started to use Geany, coming from Bluefish... it's really a great tool and I wish to tank everyone contributing!
I only noticed a problem when I try commit to a Subversion repository which needs the user to be authenticated. No problem wen I commit to a repository which does not require authentication.
Here is the screenshot of a packet capture between client and SVN server which shows the issue:
![commit_unauthorized](https://user-images.githubusercontent.com/26433166/45874868-4549ab00-bd96-11e8-9729-e4dff590ad28.jpg)
I think to be unable to fix without help from someone. Thanks!
--
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-plugins/issues/777
This means that you can't do any work in Geany until you close the external diff viewer. This seriously reduces the usefulness of the otherwise great feature of being able to use an external diff viewer.
The external diff viewer is spawned here:
https://github.com/geany/geany-plugins/blob/master/geanyvc/src/externdiff.c…
Looks like the problem might simply be solved by calling `g_spawn_async` instead of `g_spawn_sync`.
--
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-plugins/issues/539
- In editor menu elements are disabled, if the current file is not in the repository, but all menu items under Control Version -> File are enabled in any situation.
- In editor menu element "Add to Version Control" is always disabled.
--
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-plugins/issues/741
Please tell me if there is some way I can make the line marker (the cross) on line number 1, shown below,
![smallcross](https://user-images.githubusercontent.com/7548378/34533758-859ab0ce-f0b3-11e7-8b06-f04f7bd0e48e.png)
larger as it is very difficult to find visually.
--
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/1733
This adds a combo-box to the find-in-files dialog which lets the user choose which kind of regular expressions shall be used: extended, basic or perl.
The pre-selected value is 'extended' so users which do not want to change the reg-exp mode used, do not need to change anything. If a user only toggles the checkbox to enable/disable regular expressions then anything works as it used to.
Also see #443.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1809
-- Commit Summary --
* find-in-files: choose reg-exp mode (extended/basic/perl)
-- File Changes --
M src/search.c (44)
-- Patch Links --
https://github.com/geany/geany/pull/1809.patchhttps://github.com/geany/geany/pull/1809.diff
--
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/pull/1809
As pointed out in #1218, currently the Windows nightly builds are not really compabitle with the release installers (line end character detection, strange warnings about image loading, maybe more).
Currently, the nightly builds are created with a very old toolchain (gcc 3.x) and probably outdated GTK stack.
Ideally, we use https://github.com/geany/geany/blob/master/scripts/cross-build-mingw.sh also for the nightly builds with newer Mingw toolchain and maybe even use NSIS to create full installers.
--
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/1241