Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
It's awkward and could be more convenient. -- 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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19108373
Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
Why does it need fixing? Is it broken? -- 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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19108367
Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
For example `geany_plugin_register_full()` could register the module-bound data and we could add a `GData*` list to the `GeanyPlugin` for activation-bound arbitrary data (similar to document-data). -- 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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19108347
Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
That could probably fixed by having a different data scoped to the module and the activation. -- 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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19108329
Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
The data is destroyed depending on whether it was set at load (free at unload) or init (free at cleanup). See LOAD_DATA flag. This is also documented this way. -- 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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19108316
Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
Sorry for the spam, but a related idea (so I can find it later). We could have a macro like this: ```c #define GEANY_PLUGIN_REGISTER_OBJECT(plugin, min_api, gtype, ...) \ GEANY_PLUGIN_REGISTER_FULL (plugin, \ min_api, \ g_object_new (gtype, ##__VA_ARGS__), \ g_object_unref) ``` To provide syntax sugar to bind a GObject to the module's lifetime. -- 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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19107429
Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
I should mention for the specific case of Vala, I think you can write something
like this:
```vala
// some gobject in vala, to save typing
namespace Foo {
public class Plugin : Object {
[CCode(instance_pos=1.1)]
bool init(Geany.Plugin p) { return true; }
[CCode(instance_pos=1.1)]
void cleanup(Geany.Plugin p) {}
}
}
```
It might work directly in this case.
--
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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19107354
Re: [Github-comments] [geany/geany] plugins: separate geany_plugin_set_data() dual-use (437837d)
It just occurred to me while tinkering with this, if the `pdata` argument had
come first, then one could use member functions directly in the
`GeanyPluginFuncs` setup without the need for separate C wrapper boilerplate.
It would probably require typedefs for the function pointer types to facilitate
type casts. A basic wrapper plugin over a GObject could've looked like this:
```vala
// some gobject in vala, to save typing
namespace Foo {
public class Plugin {
bool init(Geany.Plugin p) { return true; }
void cleanup(Geany.Plugin p) {}
}
}
```
```c
// the actual plugin implementation
G_MODULE_EXPORT void
geany_load_module (GeanyPlugin *p)
{
p->info->name = "Foo";
...
p->funcs->init = (GeanyInitFunc) foo_plugin_init;
p->funcs->cleanup = (GeanyCleanupFunc) foo_plugin_cleanup;
...
GEANY_PLUGIN_REGISTER_FULL (p, 42, foo_plugin_new, g_object_unref);
}
```
I don't know if it can be changed now or some alternative funcs with swapped
arguments added, I just thought I'd mention it as I just coded 4 hook functions
to do nothing but reverse the arguments to call another C function.
--
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/commit/437837d3a54367393c41d6c1e1f4d1af4481627e#commitcomment-19107275
Re: [Github-comments] [geany/geany] Syntax Highlighting: Using > as comment_single not working (#1240)
The `comment_single`, `comment_open` and `comment_close` settings only control the `menu->edit->format->comment ...` commands. They do not affect the syntax lexing, its coded in the properties lexer in C++ to use `#`, `;`, `!`. The syntax lexing is part of the [Scintilla project](www.scintilla.org) which we simply use. You could ask on Scintilla that it be made a property of the properties lexer as well as being coded. -- 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/1240#issuecomment-248481488
Re: [Github-comments] [geany/geany] Geany 1.28 "Find in files" doesn't work in Windows 7 64bit OS (#1229)
> * I read in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16444 that *"in > which a patch was installed that tries to work around some of the MinGW > deficiency; unfortunately the patch broke a lot of things and was backed out. > I'm not optimistic about a fix this time either."* Does the patch proposed > here exhibit these breakage, whatever it is? Or does it misses some stuff? To be honest, I don't know. Also I don't know what exact breakage the quote refers to. I assume, but it's really just a guess, there were problems with the patch in combination with support of other platforms or so. On the other hand, while the inode handling part of the patch is easy enough, I'm not completely sure what impact making the directory enter/leave functions NO-OPs has. It seems to work fine after quick testing but it might also introduce bigger issues. > * what happens when actually encountering directory loops? It's probably > very rare, especially on Windows, but still, we probably better have some way > out. Can we stop Grep from inside Geany? (I'm afraid not currently) Sorry, I wasn't clear enough about the real issue: it's not only the warning which shows up, grep actually doesn't find any matches in sub directories if `--recurse` is used. I just updated the commit message in the PR to reflect this. And yes, we cannot stop grep in case it ran into a real directory loop. But this is independent from the patch, as directory loop detection based on inodes simply doesn't work on Windows, or at the very least not with Mingw. To say it clearly, if there is a directory loop, the patched version will most probably run into it and loop forever. I don't know if this is possible at all and how, but I guess there is a risk. Without the patch, `--recurse` is unusable. > * It's probably a question showing my ignorance in how we do Windows, but how > comes this is new? How comes it used to work? And if it did, can't we > simply do like we used to? (I don't know, compiling on native Windows, or > MSYS2, or whatever) Before we distributed an older version of grep (from UnxUtils, grep 2.5) which was either not affected by this issue because it didn't have the inode checks or was already patched/modified for Windows. We updated the distributed version of grep because of issues #789 and #560. -- 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/1229#issuecomment-248447824
[Github-comments] [geany/geany] Better translation. (#1242)
You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/1242 -- Commit Summary -- * Better translation. -- File Changes -- M po/es.po (2) -- Patch Links -- https://github.com/geany/geany/pull/1242.patch https://github.com/geany/geany/pull/1242.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/1242
Re: [Github-comments] [geany/geany] windows geany1.27 grep error (#1113)
Closing due to lack of information. @BrightRubik feel free to re-open with more details. -- 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/1113#issuecomment-248433759
Re: [Github-comments] [geany/geany] windows geany1.27 grep error (#1113)
Closed #1113. -- 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/1113#event-796335935
Re: [Github-comments] [geany/geany] Add patch for self-compiled grep to fix recursive searching (#1237)
eht16 commented on this pull request.
> tar xf ${grep_archive}
+ # patch grep sources to fix "recursive directory loop warnings" and
recusrive search, see #1229
Done
--
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/1237
Re: [Github-comments] [geany/geany] Error in "Document/Set Lineend/Set to xx and convert" (#1218)
Closed #1218. -- 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/1218#event-796313020
Re: [Github-comments] [geany/geany] Error in "Document/Set Lineend/Set to xx and convert" (#1218)
Thanks for testing. I created #1241 for the nightly build issue (and will work on this in a few weeks probably). So we can close this one. -- 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/1218#issuecomment-248429815
[Github-comments] [geany/geany] Modernize Windows nightly builds (#1241)
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
Re: [Github-comments] [geany/geany] Highlight C function names (patch available) (#1231)
Geany with this patches now available in this PPA https://launchpad.net/~linvinus/+archive/ubuntu/geany -- 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/1231#issuecomment-248369942
Re: [Github-comments] [geany/geany] Proxy Plugins Filename Pattern Matching (#1236)
> Seems overkill. In what way? 3 of the 4 files changed are documentation, and the one file with code changes (`plugins.c`) has the same lines added as removed if you don't count doc-comment lines. Further, some of those lines are to cleanup an existing leak of the `PluginProxy`s as well as 3 more lines that can be eliminated as noted in the inline comment. So in the end, it's actually less code to give enhanced features. > What's the use case? Read the comments in the linked #1233. Matching files with other extensions like `*.tar.bz2` or `*.geany++.plugin`. > Also why do you want to match all plugins? Read the comments in the linked #1233. A better question is why do you want to match file extensions at all? They aren't unique enough to decide whether a file is for a given proxy and you have to check them further in the `probe()` function anyway. -- 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/1236#issuecomment-248323062
Re: [Github-comments] [geany/geany] Highlight C function names (patch available) (#1231)
@elextr you are right! implemented as option for lexer. -- 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/1231#issuecomment-248302070
[Github-comments] [geany/geany] Syntax Highlighting: Using > as comment_single not working (#1240)
I wanted to build a minimal syntax highlighting for fasta files. Such files are used commonly in biology/bioinformatics and may look like this: ``` >Description of first element TAGCGACTACGACTACGATCAGCATCTACGAT >Description of second element TGAGCTACGACGTGAGCAGCGGCGCCTAG ``` I wanted to highlight the description lines and thought that marking it as "comment" should work. However, it looks like it is not possible to use `>` as character for a comment. /home/myuser/.config/geany/filedefs/filetypes.Fasta.conf: ``` [styling=Conf] [settings] lexer_filetype=Conf extension=fasta comment_single=> ``` The `filetype_extensions.conf` was adjusted accordingly and the *.fasta files are recognized as Fasta files according to the menu `Document` -> `Set filetype` This does not work as intended. Lines starting with `#` or `;` are highlighted as comments, but lines starting with `>` are not. Did I do anything wrong? Could you please help me with this (seemingly simple) issue? -- 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/1240
Re: [Github-comments] [geany/geany] Highlight C function names (patch available) (#1231)
Note that `LexCPP,cxx` styles for C, C++, Java and JS, but doesn't distinguish between them. Geany distinguishes between them, but Geany and Scintilla are different projects and there are a number of other users of Scintilla. So Scintilla can't depend on anything thats Geany specific. Also Geany (ab?)uses `LexCPP.cxx` for a number of other built in languages as well as the four above, Actionscript, Ferite, Go, and Haxe and there are several custom filetypes distributed with Geany that use C styling, CUDA, Genie, Graphviz, JSON and Scala. Finally there are many custom filetypes on the wiki and I bet a number of those use C styling. So it would be best to (as @b4n commented above) to have a property to specifically turn this on or off in the Scintilla lexer as the language sees fit, see `OptionSetCPP`. -- 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/1231#issuecomment-248298468
Re: [Github-comments] [geany/geany] Highlight C function names (patch available) (#1231)
parsing function parameters was bad idea, i have removed this part, but now if geany know class, then object initialization will not highlighted. there is C style (class is unknown), it looks like C prototype  and this is C++ style (class is known)  there is another idea, if file type GEANY_FILETYPES_CPP or GEANY_FILETYPES_C will be available on Scintilla lexer side , then lexer may change highlighting behavior, for example don't highlight C-style prototypes at all, because they are looks like object initialization, which is used in C++ very often. for example, don't highlight 'spaceText' part ```C++ std::string spaceText(virtualSpace, ' '); ``` what do you think? -- 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/1231#issuecomment-248289398
Re: [Github-comments] [geany/geany-plugins] [spellchecker] Apostrophes (`'`, ascii 39) at string boundary are spell-checked (#484)
Your second solution will generate some problems in languages like Italian, where `po'` is a word, but `po` isn't, but these are few corner cases that can be added to the dictionary when you meet them and a huge improvement wrt the current state. -- 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/484#issuecomment-248279084
Re: [Github-comments] [geany/geany] Proxy Plugins Filename Pattern Matching (#1236)
Seems overkill. What's the use case? Also why do you want to match all plugins? -- 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/1236#issuecomment-248235511
