Two consecutive "go to matching brace" commands have to return us to the original position. After we moved to the matching brace, we still should see the same brace pair highlighted. All Scintilla-based editors have the problem. Scintilla doesn't necessarily return us to the initial position after the subsequent matching brace jumps. After the first jump Scintilla often highlights nearby brace pair. It is so because Scintilla attempts to place the cursor following to outside or inside braces logic. However, when the cursor is between two braces, Scintilla highlights only the first, left brace.
I will provide with two examples. (bold+italic parenthesis indicate the highlighted braces. The exclamation sign indicates the cursor position. )
First example: ( )( )
Place the cursor after the last brace:
( )_**( )!**_
do twice "go to matching brace" and we see the cursor before the fist brace.
**_!( )_**( )
Second example: (((( f1+1 )^f2)+( f3+1 ))^f4)
Place the cursor after the second brace.
(**_(!_**(( f1+1 )^f2)+( f3+1 )**_)_**^f4)
do twice "go to matching brace" and we see where the cursor is .
(((( f1+1 )^f2)+**_!(_** f3+1 **_)_**)^f4)
People who are used to work with other editors are confused. As a workaround, I made a LUA script that goes to matching brace and always keeps the same braces highlighted. (https://github.com/dyura/LUA-scripts-for-text-editors/blob/master/Geany/GoT…)
At the same time, I think that this problem should be solved at the project level.
--
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/1998
This should fix #808.
The approach here is to try and have the Python callback return value be used as the C one is. I'm not totally sure how compatible that is, but IIUC if a Python function doesn't explicitly return it returns None, which should (I guess) fail the `PyObject_IsTrue()` check.
I did *not* test this *at all*: I didn't even try to build it (thanks to a crappy Internet connection tonight, I didn't wait long enough to fetch the dependencies). This PR should be reviewed as what it is: an attempt at a fix by a guy that doesn't know neither the API nor the plugin :)
However, this should also fix a leak as the return value should likely be `DECREF`'d in any case.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/809
-- Commit Summary --
* geanypy: Use Python callback return value for keybindings return value
-- File Changes --
M geanypy/src/geanypy-keybindings.c (8)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/809.patchhttps://github.com/geany/geany-plugins/pull/809.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-plugins/pull/809
Had to create the new pull request quickly - not having a huge ctags-related pull request in Geany brings bad luck!
This pull request brings the changes from upstream ctags made in the last 2 years so that parsers are compatible with uctags parsers. This isn't a complete sync to avoid too big pull request, just the minimal changes required so syncing parsers isn't blocked. In addition, to verify that subparser support works, this pull request uses html, javascript and css parsers from upstream and enables subparser support for HTML.
In general most of the patches are fortunately boring, the "interesting" ones are:
8822e4e - using kindIndex instead of kindDefinition. This one took a bit of work and I hope I didn't introduce any problems on the way. In some functions which aren't relevant to Geany I left just function stubs to avoid extra syncing with upstream. This patch also disables regex parsing - the parsing is only disabled inside ctags, I kept the regex parsers there for now until we decide what we want to do about them.
72d4b5d - using upstream javascript parser. I haven't verified completely if the generated tags are correct (seems OK to someone who doesn't really know javascript) but better to check by somebody else.
5de9b3e - Support subparsers in Geany. The biggest part of the patch is additional mapping of subparser tag types to the tag type used by Geany. This is necessary because we don't want subparser tag types to clash with main parser tag types.
I tried to copy all the parsers from upstream to Geany to see if it compiles (I have only tried the compilation part, not if the parsers actually work correctly) and the only ones that didn't compile because of upstream changes were:
1. asm - would need upstream preprocessor.c/h implementation. But it probably wouldn't be hard to convert it to our lcpp.c/h
2. make and tcl parsers - need subparser.c/h and it would require more syncs with upstream
3. c.c and cxx parsers - I haven't actually tried these beasts
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2018
-- Commit Summary --
* Use latest version of htable
* Use latest version of mio
* Use latest version of objpool
* Use latest version of ptrarray
* Use latest version of vstring
* Rename fieldSpec to fieldDefinition
* Rename kindOption to kindDefinition
* Rename kinds field in parserDefinition to kindTable
* Rename structure fields about field in parserDefinition
* Use kindIndex instead of kindDefinition
* Rename roleDesc to roleDefinition
* Add XTAG_ANONYMOUS used by jscript
* Include stdint.h in entry.h
* Don't use hash value as an Anonymous field identifier
* Call anonReset in main part
* Use upstream javascript parser
* Use upstream css parser
* Create correctly sized MIO for 0 size
* Always enable promise API and subparsers for Geany
* Support subparsers in Geany and add HTML parser demonstrating this feature
* Rename truncateLine field of tagEntryInfo
* Add dummy mbcs.h and trace.h
* Introduce an accessor to `locate' field of `Option'
* Add numarray.c/h
* Add getLanguageForFilename() and getLanguageForCommand()
-- File Changes --
M ctags/Makefile.am (7)
M ctags/main/ctags-api.c (10)
M ctags/main/ctags-api.h (1)
M ctags/main/dependency.c (12)
M ctags/main/entry.c (86)
M ctags/main/entry.h (25)
M ctags/main/field.c (63)
M ctags/main/field.h (6)
M ctags/main/htable.c (71)
M ctags/main/htable.h (24)
A ctags/main/inline.h (26)
M ctags/main/kind.c (27)
M ctags/main/kind.h (27)
M ctags/main/lcpp.c (16)
M ctags/main/lcpp.h (2)
M ctags/main/lregex.c (34)
M ctags/main/lxcmd.c (36)
M ctags/main/lxpath.c (15)
A ctags/main/mbcs.h (1)
M ctags/main/mio.c (32)
M ctags/main/mio.h (2)
A ctags/main/numarray.c (175)
A ctags/main/numarray.h (48)
M ctags/main/objpool.c (7)
M ctags/main/objpool.h (5)
M ctags/main/options.c (11)
M ctags/main/options.h (5)
M ctags/main/parse.c (210)
M ctags/main/parse.h (26)
M ctags/main/promise.c (4)
M ctags/main/ptrarray.c (28)
M ctags/main/ptrarray.h (6)
M ctags/main/read.c (12)
M ctags/main/read.h (6)
A ctags/main/trace.h (1)
A ctags/main/trashbox.c (246)
A ctags/main/trashbox.h (41)
M ctags/main/types.h (8)
M ctags/main/vstring.c (59)
M ctags/main/vstring.h (31)
M ctags/main/xtag.c (2)
M ctags/main/xtag.h (1)
M ctags/parsers/abaqus.c (6)
M ctags/parsers/abc.c (6)
M ctags/parsers/asciidoc.c (8)
M ctags/parsers/asm.c (12)
M ctags/parsers/basic.c (12)
M ctags/parsers/c.c (50)
M ctags/parsers/conf.c (10)
M ctags/parsers/css.c (47)
M ctags/parsers/diff.c (6)
M ctags/parsers/docbook.c (6)
M ctags/parsers/erlang.c (12)
M ctags/parsers/fortran.c (14)
M ctags/parsers/go.c (8)
M ctags/parsers/haskell.c (8)
M ctags/parsers/haxe.c (16)
M ctags/parsers/html.c (540)
M ctags/parsers/jscript.c (1209)
M ctags/parsers/json.c (8)
M ctags/parsers/latex.c (10)
M ctags/parsers/lua.c (6)
M ctags/parsers/make.c (8)
M ctags/parsers/markdown.c (6)
M ctags/parsers/matlab.c (8)
M ctags/parsers/nsis.c (10)
M ctags/parsers/objc.c (8)
M ctags/parsers/pascal.c (10)
M ctags/parsers/perl.c (12)
M ctags/parsers/php.c (12)
M ctags/parsers/powershell.c (8)
M ctags/parsers/python.c (28)
M ctags/parsers/r.c (6)
M ctags/parsers/rest.c (8)
M ctags/parsers/ruby.c (14)
M ctags/parsers/rust.c (8)
M ctags/parsers/sh.c (6)
M ctags/parsers/sql.c (8)
M ctags/parsers/tcl.c (6)
M ctags/parsers/txt2tags.c (7)
M ctags/parsers/verilog.c (8)
M ctags/parsers/vhdl.c (10)
M src/tagmanager/tm_parser.c (85)
M src/tagmanager/tm_parser.h (2)
M src/tagmanager/tm_source_file.c (10)
M tests/ctags/Makefile.am (8)
M tests/ctags/complex-return.js.tags (2)
M tests/ctags/js-class-related-unterminated.js.tags (3)
M tests/ctags/js-let.js.tags (2)
M tests/ctags/js-string-continuation.js.tags (2)
M tests/ctags/jsFunc_tutorial.js.tags (10)
M tests/ctags/simple.html.tags (4)
M tests/ctags/simple.js.tags (3)
-- Patch Links --
https://github.com/geany/geany/pull/2018.patchhttps://github.com/geany/geany/pull/2018.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/2018
This got broken by 907a79263d907fa354d3b4c6570f33047801dd84 back in 2011 as encoding names started to be compared more permissively, leading to "none" matching the "None" encoding.
This shouldn't be too much of a problem as trying the None encoding first should not cause any issue, but fix loading of the option anyway.
This however won't restore settings from existing configuration files that used the previous code, as there is no way to tell whether the user selected the None encoding voluntarily or not.
---
To reproduce the issue, go to the file preferences, and deactivate the *Use fixed encoding when opening non-Unicode files*. Save the setting, and restart Geany: you'll see the setting is activated again.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1326
-- Commit Summary --
* Fix loading the default open encoding option
-- File Changes --
M src/keyfile.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/1326.patchhttps://github.com/geany/geany/pull/1326.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/1326
Hi, i am a newly geany user.
when i open a plain/txt file that is gbk encoding from file-manager, always show measy characters due to geany default using utf-8.
if i change encoding by the menu 'doc - encodeing - lang ...', geany do not auto-reload the file with the changed encoding. kate editor can do that way.
i know geany how to correctly open non-utf8 txt file, but auto reload when change encoding makes user much simpler. i hope geany have the function.
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/1529