I don't recall specifically enabling the XML Snippets plugin, but it appears to conflict with the internal XML tag closing mechanism in some way. I recently ran into an issue editing an XSL stylesheet where typing the closing bracket (`>`) would crash Geany. I disabled the XML Snippets plugin, and Geany didn't crash when typing the closing bracket, while allowing Geany to create the closing tag using the built-in function.
What does XML Snippets do that the `XML/HTML tag auto-closing` built-in feature doesn't? Should XML Snippets be removed?
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/318
New feature with new icon on toolbar & in the menu.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1471
-- Commit Summary --
* Add related icons to project
* Add to ui 'Reload all' feature
* Add shortcat key for 'Reload all' feature
* Modify reload algorithm according to new feature
* Insert some rows to doc file about new feature
-- File Changes --
M data/geany.glade (17)
M doc/geany.txt (3)
M icons/16x16/Makefile.am (3)
A icons/16x16/geany-reload-all.png (0)
M icons/24x24/Makefile.am (3)
A icons/24x24/geany-reload-all.png (0)
M icons/32x32/Makefile.am (3)
A icons/32x32/geany-reload-all.png (0)
M icons/48x48/Makefile.am (3)
A icons/48x48/geany-reload-all.png (0)
M icons/scalable/Makefile.am (3)
A icons/scalable/geany-reload-all.svg (682)
M icons/tango/16x16/Makefile.am (3)
A icons/tango/16x16/geany-reload-all.png (0)
M icons/tango/24x24/Makefile.am (3)
A icons/tango/24x24/geany-reload-all.png (0)
M icons/tango/32x32/Makefile.am (3)
A icons/tango/32x32/geany-reload-all.png (0)
M icons/tango/48x48/Makefile.am (3)
A icons/tango/48x48/geany-reload-all.png (0)
M icons/tango/scalable/Makefile.am (3)
A icons/tango/scalable/geany-reload-all.svg (682)
M src/callbacks.c (20)
M src/callbacks.h (2)
M src/keybindings.c (16)
M src/keybindings.h (3)
M src/toolbar.c (2)
M src/ui_utils.c (7)
M src/ui_utils.h (1)
-- Patch Links --
https://github.com/geany/geany/pull/1471.patchhttps://github.com/geany/geany/pull/1471.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/1471
When I select one character, the <b>sel</b>ection count and the <b>col</b>umn number are correct, but when I extend the selection by one character, the <b>sel</b>ection increases by 4 not 1, although the <b>col</b>umn number only increases by the expected value of 1.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/745
Alright, hopefully my last Colomban-killer patchset. I tried to sync as much as possible from ctags/main here (no big parser changes at this point, only those caused by some change in main).
I'm not sure how much it's worth reviewing patch by patch (maybe except those patches that touch some Geany code or parsers) - it's much easier to diff this against universal-ctags and see the differences - there just a few of them. I made some minor changes to uctags as well so better to diff against https://github.com/techee/ctags/tree/geany_sync2 which contains those changes.
I tried to librarify ctags a bit by adding CTAGS_LIB macro by which I protect the library-specific stuff. There are however still some things which are either missing in uctags or which we should change in Geany:
* varType missing in uctags
* GRegex vs GNU regex - I kept GRegex in lregex.c (but synced all the rest) but we should think whether not to convert back to GNU regex
* isIgnoreToken() works differently than in uctags. If it simply just dropped certain tags, we could move the logic into TM but right now, it helps the C parser with parsing by suggesting whether the contents of braces should be dropped too. I'm not sure if we need to preserve this functionality (never used the ignored.tags file myself) but if we move to the new cxx parser we'd have to keep this diff unless there's some interest for this in uctags.
* lcpp contains lots of changes as it's tightly related to c.c. However, as it's used by c.c only and quite independent of the rest, if we move to the cxx parser we could keep a separate copy of lcpp for the obsolete c.c parser.
Except 829ea7d I tried to do all the work piece by piece so nothing should be lost. There wasn't much work on parsers except the mentioned patch where parsers using nestlevel had to be updated to its new API and using cork (which works so every uctags parser could be now ported to Geany).
I think it's too late for Geany 1.29 but it would be good to have it ready for early 1.30 so it can be tested during the whole release cycle.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1263
-- Commit Summary --
* Grab the complete uctags vString implementation
* Add generic pointer array
* Eliminate uses of g_stat()
* Drop some more unused functions from routines.c/h
* Remove most uses of glib calls
* Remove unused functions from options.c/h
* Grab uctags implementation of strlist
* Grab uctags keyword.c/h and add types.h with type declarations
* Make tempFile() return MIO
* Make combinePathAndFile() return char * instead of vString
* Use parse separator utilities in routines.c
* Make sure that file extension is taken from file (not preceding directory)
* Use uctags implementation of strstr()
* Don't initialize ExecutableProgram and ExecutableName
* Sync the rest of routines.c/h
* Grab uctags ctags.h and add repoinfo.c/h
* Grab args.c/h uctags implementation
* Define gcc attributes inside gcc-attr.h
* Move debug related code to debug.c/h
* Remove all unused code from main.c
* Grab all MIO changes from uctags
* Implement iFileGetLine() using gets()
* Grab ctags version of general.h and make related changes
* Grab ctags implementation of sort.c/h
* Create geany.c/h and put isIgnoreToken()
* Sync options.c/h (and introduce a lot of new garbage)
* Grab uctags kind.c/h
* Some sync of lcpp.c/h
* Move eTagFile from entry.h to entry.c
* Sync the beginning of entry.c/h
* entry: Take over uctags tag writing code
* entry: Some more or less formal changes
* entry: make makeTakEntry() implementation closer to uctags
* entry: Sync initTagEntry() code
* entry: Add the remaining code from uctags
* read: change macros into functions and move them into c
* c.c, lcpp.c: Avoid using File.mio
* read: move sInputFileInfo, sInputFile and File to read.c
* read: Add some extra data structures
* read: use makeFileTag()
* read: Some function renaming
* read: implement openBuffer() using openInputFile()
* read: Add function to initialize common parts of input/source files and use it
* read: introduce langStack for source files
* read: add lineFposMap
* read: add the remaining stuff from uctags
* parse: remove things unused by Geany for simpler merge
* parse: some simple syncs and include syncs
* parse: other small syncs
* lregex: sync includes
* lregex: replace regexBroken with regexAvailable
* lregex: some simple syncs
* lregex: remove unused functions
* lregex: Initialize lregex structures the universal-ctags way
* lregex: Add missing fields to regexPattern
* lregex: sync some function prototypes
* lregex: introduce findRegexTagsMainloop()
* lregex: some harmless syncs
* lregex: add new flag processing
* lregex: sync the remaining parts of the existing code
* lregex: Add the remaining missing functions from uctags
* Grab uctags version of parse.c/h and nestlevel.c/h plus additional fallout
* grab uctags debug.c/h
* Add typeRef to sTagEntryInfo
* read: backport patch from uctags
* Some minor syncs
* Sync error.c completely and create a custom error printer
* tmp
* Some initial work on ctags as a library
* Move ctags "API" from Geany to ctags
* Make LanguageTable variable private in parse.c
* Add the remaining missing files from uctags
* Annotate geany-specific diffs
-- File Changes --
M configure.ac (9)
M ctags/Makefile.am (42)
M ctags/main/args.c (50)
M ctags/main/args.h (6)
A ctags/main/ctags-api.c (141)
A ctags/main/ctags-api.h (56)
M ctags/main/ctags.h (21)
A ctags/main/debug.c (128)
M ctags/main/debug.h (82)
A ctags/main/dependency.c (102)
A ctags/main/dependency.h (45)
A ctags/main/e_msoft.h (71)
M ctags/main/entry.c (1233)
M ctags/main/entry.h (175)
A ctags/main/error.c (59)
A ctags/main/error.h (26)
A ctags/main/field.c (921)
A ctags/main/field.h (111)
A ctags/main/flags.c (107)
A ctags/main/flags.h (29)
A ctags/main/fmt.c (354)
A ctags/main/fmt.h (25)
A ctags/main/gcc-attr.h (30)
M ctags/main/general.h (112)
A ctags/main/htable.c (271)
A ctags/main/htable.h (47)
M ctags/main/keyword.c (22)
M ctags/main/keyword.h (4)
A ctags/main/kind.c (158)
M ctags/main/kind.h (73)
M ctags/main/lcpp.c (254)
M ctags/main/lcpp.h (42)
M ctags/main/lregex.c (806)
A ctags/main/lxcmd.c (1227)
A ctags/main/lxpath.c (217)
M ctags/main/main.c (464)
A ctags/main/mbcs.c (112)
A ctags/main/mbcs.h (22)
M ctags/main/mio.c (382)
M ctags/main/mio.h (40)
M ctags/main/nestlevel.c (61)
M ctags/main/nestlevel.h (19)
A ctags/main/objpool.c (79)
A ctags/main/objpool.h (39)
M ctags/main/options.c (3474)
M ctags/main/options.h (172)
A ctags/main/output-ctags.c (224)
A ctags/main/output-etags.c (107)
A ctags/main/output-json.c (189)
A ctags/main/output-xref.c (60)
A ctags/main/output.h (50)
M ctags/main/parse.c (2846)
M ctags/main/parse.h (262)
A ctags/main/pcoproc.c (296)
A ctags/main/pcoproc.h (29)
A ctags/main/promise.c (102)
A ctags/main/promise.h (27)
A ctags/main/ptag.c (234)
A ctags/main/ptag.h (63)
A ctags/main/ptrarray.c (152)
A ctags/main/ptrarray.h (46)
M ctags/main/read.c (962)
M ctags/main/read.h (121)
A ctags/main/repoinfo.c (12)
A ctags/main/repoinfo.h (1)
M ctags/main/routines.c (585)
M ctags/main/routines.h (71)
A ctags/main/selectors.c (382)
A ctags/main/selectors.h (35)
M ctags/main/sort.c (120)
M ctags/main/sort.h (15)
M ctags/main/strlist.c (167)
M ctags/main/strlist.h (20)
A ctags/main/types.h (29)
M ctags/main/vstring.c (214)
M ctags/main/vstring.h (29)
M ctags/parsers/abc.c (1)
M ctags/parsers/asciidoc.c (23)
M ctags/parsers/c.c (39)
M ctags/parsers/conf.c (1)
M ctags/parsers/fortran.c (14)
M ctags/parsers/lua.c (8)
M ctags/parsers/markdown.c (1)
M ctags/parsers/php.c (4)
M ctags/parsers/powershell.c (1)
M ctags/parsers/python.c (107)
M ctags/parsers/rest.c (21)
M ctags/parsers/ruby.c (38)
M ctags/parsers/txt2tags.c (59)
M src/symbols.c (2)
M src/tagmanager/Makefile.am (4)
D src/tagmanager/tm_ctags_wrappers.c (171)
D src/tagmanager/tm_ctags_wrappers.h (65)
M src/tagmanager/tm_parser.c (18)
M src/tagmanager/tm_source_file.c (74)
M src/tagmanager/tm_tag.c (2)
M src/tagmanager/tm_workspace.c (4)
M tests/ctags/bug1585745.cpp.tags (6)
M tests/ctags/bug507864.c.tags (7)
M tests/ctags/cpp_destructor.cpp.tags (2)
M tests/ctags/simple.d.tags (2)
-- Patch Links --
https://github.com/geany/geany/pull/1263.patchhttps://github.com/geany/geany/pull/1263.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/1263
Hi,
Scintilla uses LexLisp.cxx for Lisp and Scheme, but Geany uses Lisp only. I use GIMP and Script-Fu and I would like to see the syntax :)
If it possible, [geany-master-scheme.zip](http://www118.zippyshare.com/v/VoUXDqTp/file.html) (new/modif. files):
```
data/filedefs/filetypes.scheme
data/filetype_extensions.conf
data/Makefile.am
src/filetypes.c
src/filetypes.h
src/highlighting.c
src/highlightingmappings.h
```
Regards,
---
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/982
Fixes #1069 by implementing the suggestions there.
See commit messages for details. tl;dr: the goto-symbols popup will show more of the paths, but as little as possible. The common prefix is stripped and the longest common sub-path is ellipsized.
Example: Assume the popup would show utils.h twice (/home/kugel/geany.git/src/utils.h and /home/kugel/geany.git/build/dest/include/geany/utils.h.
The popup would show:
src/utils.h
build/dest/include/geany/utils.h
Additionally, as per @elextr suggestion and for a frequent use-case of mine, the ellipsis is introduced for long common substrings, which I often have due to having the same code base checked out multiple times (my workflow at work requires this).
So, /home/kugel/checkout_a/path/to/project/src/main.c and /home/kugel/checkout_b/path/to/project/src/main.c shows as:
checkout_a/.../main.c
checkout_b/.../main.c
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1445
-- Commit Summary --
* utils: add functions to process file name list
* symbols: provide a bit more path information in the goto-symbol popup.
* gtkdoc: add support for array annotions
* api: export new utils_strv_shorten_file_list() function
-- File Changes --
M doc/Doxyfile.in (2)
M scripts/gen-api-gtkdoc.py (7)
M src/plugindata.h (2)
M src/symbols.c (13)
M src/utils.c (193)
M src/utils.h (2)
-- Patch Links --
https://github.com/geany/geany/pull/1445.patchhttps://github.com/geany/geany/pull/1445.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/1445
At the moment if symbols of the same name are defined in identically named files, it's hard to distinguish which file is which because there's no path in the popup.
The popup should show part of the path until a directory where the paths differ so it's possible to distinguish the different files. At the same time there should probably be some top limit for the length of the paths as they can make the popup too wide.
---
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/1069
Hi,
is it possible to start creating a new file in an existing instance from shell? I'd like to use a keyboard shortcut to start a new file, but `geany` with no arguments opens a new instance (not useful).
If it can't be done, how likely are you to implement it? Ideally, this would be a commandline parameter (something like the opposite of `-i`).
--
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/1512