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/437837d3a54367393c41d6c1e1f4d1af44816…
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/437837d3a54367393c41d6c1e1f4d1af44816…
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/437837d3a54367393c41d6c1e1f4d1af44816…
change the grep.exe than can search other dir files.
---
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
Geany 1.29 "Jowar" compiled 2016-07-16 / Windows 7-64 Bit
and also
Geany 1.29 "Jowar" compiled 2016-09-08 / Windows 7-64 Bit
If you select -> Lineend will be
Set to CR -> 0x0d
Set to LF -> 0x0d 0x0a
Set to CR/LF -> 0x0d 0x0d 0x0a
Except with "Set to CR" there is an additional 0x0d.
SciTE 3.6.7 / Windows 7-64 Bit does it right.
Geany Release 1.28 / Windows 7-64 Bit does it right.
The problem seems to be connected with the recognition of the lineend when opening a file.
With Geany 1.28 when I open a file with CR/LF as lineend then "Document/Set Lineend/Set to CR/LF and convert" is preselected.
When I open this file with Geany 1.29 then "Document/Set Lineend/Set to LF and convert" is preselected.
I attached three small test files with lineend CR, CR/LF and LF for convenience.
[test_cr.txt](https://github.com/geany/geany/files/464234/test_cr.txt)
[test_crlf.txt](https://github.com/geany/geany/files/464235/test_crlf.txt)
[test_lf.txt](https://github.com/geany/geany/files/464236/test_lf.txt)
--
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
Microsoft office/ MS Word (all versions) saves its custom dictionary spelling word lists in a text encoding that Microsoft Windows calls UTF16 or UTF-16, but which is more specifically described as UTF-16LE or "little endian", as distinct from UTF-16BE or "big endian".
Geany 1.28 for Windows "(built on or after Jul 10 2016)", running on Windows 10, fails to open this file type (right click menu, or start Geany, and "Open").
I've tried choosing both File Encoding "UTF-16LE" and "UTF-16BE", as well as "auto detect", and tried "Set file type" to "detect from file" and "none".
In all cases I've tried, Geany fails. With UTF-16LE, the failure manifests in the error:
12:40:12: The file "C:\tmp\CUSTOM.dic" is not valid UTF-16LE.
and in the case of choosing UTF-16BE, the failure manifests as improper display/loading of the file - instead of a word per line, there is an endless series of long thin square rectangles on a single line.
So I go back to using Notepad++ or Akelpad... at least for the time being.
I suspect that the problem is Microsoft inserting BOM or "Unicode byte order mark" character into the file, and even though I manually specify file encoding and file type, Geany does some sort of auto detection thing, which it should NOT do when I manually choose the settings - even a bad rendering of a file (with my "bad" encoding choices") would be better than Geany completely FAILING to open the file at all!
Geany should have an option to "preserve BOM character" (in fact, should do this automatically), and should also have an option to "load file with my chosen encoding and filetype, even if Geany detects something not quite right"!!
Don't treat all users as stupid idiots! It makes your software look like a self conceited prig.
--
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/1238
Please provide some way to increase/decrease the font size in tree browser plugin in sidebar.
Vishal Chaudhary
---
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/424
There are good reason for running geany via sudo, as opposed to gksudo.
I'm aware of bug #294, and why this happens with sudo and not gksudo. (In short, because gksudo sets $HOME to /root, while sudo leaves $HOME to same as user - and if user is already running geany in their user session, an attempt to open the same config file will be made, and fail).
Please allow me to explain why this shouldn't be dismissed as "not a bug", just because there is a workaround. The problem is not _just_ that sudo works differently than gksudo. The problem is that, _and_ Geany's flawed implementation of config file (or "domain socket" or whatever is going on with that file).
Like many Linux administrators / power users, I use GUI tools with sudo very often, for three related reasons: 1) I prefer working in a terminal; 2) I prefer GUI terminals for ease-of-use [e.g. highlight/copy/paste, color, resize]; and 3) I prefer using sudo in a GUI terminal instead of gksudo, so that I don't have to input my password every single time I open a system configuration file for editing - which is often.
I use many GUI tools this way, and none of them have the problems Geany has. I love Geany - both for system configuration file editing as well as personal file editing, but have had to quit using it because this bug prevents productivity way too often.
It is a bug because a very simple and common use case is prohibited for no good reason, shouldn't be prohibted, and no other similar tools have the same prohibition.
A fix should be simple, in theory. Either:
1. Don't use temporary config files [or whatever is being referenced by "domain socket error"], or
2. Detect if $USER == "root" but $HOME points to somewhere in /home. If so, use /root if it exists, or %TMP% as a fallback (in a unique and secure way that has been exhaustively documented elsewhere on the nets).
Sure, the second one - without additional smarts - might not catch all distributions and/or custom installs, but would cover 99%+ of the user base. And for that tiny percentage that it might not cover, their situation wouldn't be any worse that it is now.
---
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/1150
I think it's can be a useful info; showing size of file in bytes to the right of **scope: main**
--
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/1196