Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
> Manager and allows other enabled proxy plugins to pick it up. > GeanyProxyFuncs::probe() returning > -@ref PROXY_IGNORED is an indication that the candidate is meant for another > proxy, or the user > +@ref GEANY_PROXY_IGNORE is an indication that the candidate is meant for > another proxy, or the user Nevermind, I was confused. -- 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/1213/files/094737533609dff5a2ff101f97e8c156bcca4979#r77767166
Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
> Manager and allows other enabled proxy plugins to pick it up. > GeanyProxyFuncs::probe() returning > -@ref PROXY_IGNORED is an indication that the candidate is meant for another > proxy, or the user > +@ref GEANY_PROXY_IGNORE is an indication that the candidate is meant for > another proxy, or the user What? It's [still in the enum](https://github.com/geany/geany/blob/master/src/plugindata.h#L356) and [documented there](https://github.com/geany/geany/blob/master/src/plugindata.h#L356) and in the [enum doc-comment](https://github.com/geany/geany/blob/master/src/plugindata.h#L344). I don't understand. -- 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/1213/files/094737533609dff5a2ff101f97e8c156bcca4979#r77766017
Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
> Can we find a better name than _RELATED? IMO it doesn't suggest that it wont > be loaded. Correct, it suggest that it _may_ be loaded (by the proxy) and is related to a "matched" one, but is not matched itself. It makes sense from the proxy plugin's point of view. If you look at it from Geany's point of view, then NOLOAD makes some kind of sense, but this is the proxy plugin API so it should be from that perspective, IMO. -- 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/1213#issuecomment-245186763
Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
Can we find a better name than _RELATED? IMO it doesn't suggest that it wont be loaded. -- 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/1213#issuecomment-245177881
Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
> Manager and allows other enabled proxy plugins to pick it up. > GeanyProxyFuncs::probe() returning > -@ref PROXY_IGNORED is an indication that the candidate is meant for another > proxy, or the user > +@ref GEANY_PROXY_IGNORE is an indication that the candidate is meant for > another proxy, or the user PROXY_IGNORE doesn't exist (was renamed to NOLOAD), can you please fix that also? -- 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/1213/files/094737533609dff5a2ff101f97e8c156bcca4979#r77760891
Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
> @@ -379,7 +392,7 @@ GeanyProxyProbeResults;
> struct GeanyProxyFuncs
> {
> /** Called to determine whether the proxy is truly responsible for the
> requested plugin.
> - * A NULL pointer assumes the probe() function would always return @ref
> PROXY_MATCHED */
> + * A NULL pointer assumes the probe() function would always return @ref
> GEANY_PROXY_MATCH */
> gint(*probe) (GeanyPlugin *proxy, const gchar
> *filename, gpointer pdata);
I find NOLOAD is the better name
--
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/1213/files/094737533609dff5a2ff101f97e8c156bcca4979#r77760630
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
Ok, when given a choice, take both :) ``` #idndef yes_I_really_really_really_really_know_what_I_am_doing #if a good language like C++ extern "C" declarations with noexcept #else if only C simple declarations #endif #endif ``` -- 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/1215#issuecomment-245169057
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
> Probably the best solution is @b4n's one No, it misses the point of the issue. It's not specific to `noexcept` and solving for that one specification only, among all current and future language specifications or compiler attributes and pragmas which could cause a similar problem doesn't really help in general. IMO, it would be better to go with the preprocessor guard and let plugins remove the forward declaration completely if they know what they're doing. This is more general and allows plugins to workaround not just `noexcept` but also any other specifications/attributes/pragmas which could cause similar problems. -- 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/1215#issuecomment-245158885
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
Probably the best solution is @b4n's one: ``` #if a good language like C++ extern "C" declarations with noexcept #else if only C simple declarations #end ``` That allows both languages to check the definition in the user plugin has the right type. -- 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/1215#issuecomment-245155295
Re: [Github-comments] [geany/geany] Inherit C lexer_properties in all filetypes inheriting C styles (#1217)
LGBI -- 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/1217#issuecomment-245154398
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
> That was the OP wasn't it? Yes, it was the specification I was trying to use when ran into this 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/1215#issuecomment-245153638
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
Ok, I read "that one place" to be in the HOWTO :) -- 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/1212#issuecomment-245153099
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
@codebrainz all declarations and the definition need to have the same exception specification in C++. To quote the surprisingly lucid standard clause "If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification." That was the OP wasn't it? @b4n the standard requires an `extern "c"` function to have a C compatible ABI, and it does not disallow `noexcept` so if the compiler allows `noexcept` then it must not change the ABI. (or the compiler has a bug) -- 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/1215#issuecomment-245152660
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
I meant "and" like "in addition to the reference docs". It's mentioned in the `@param` doc for the `extensions` argument. -- 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/1212#issuecomment-245151908
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
> (and in the Proxy Howto). Certainly if its a requirement its should be in the documentation, not the howto. If you don't want to fix that here can you make an issue pointing it out. -- 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/1212#issuecomment-245150619
Re: [Github-comments] [geany/geany] Enhancement Request - Multiselect Multipaste Option (#850)
@elextr I think I meant rather the first one. I've done a demo using Atom of the behaviour that I find nice to have :wink:  -- 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/850#issuecomment-245126748
Re: [Github-comments] [geany/geany] Haxe: Update keywords (#1216)
@programmador okay, thanks :) So, if there are other Haxe users around, show yourself! Otherwise I'll merge this and we'll see. -- 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/1216#issuecomment-245041759
Re: [Github-comments] [geany/geany] Haxe: Update keywords (#1216)
I use haxe quite rare so don't rely on me too much, but this fix looks fine as for me. -- 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/1216#issuecomment-245012129
Re: [Github-comments] [geany/geany] Inherit C lexer_properties in all filetypes inheriting C styles (#1217)
Seems OK to me then. -- 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/1217#issuecomment-244993118
Re: [Github-comments] [geany/geany] Inherit C lexer_properties in all filetypes inheriting C styles (#1217)
Unless I'm mistaken (and this commit would break many things then), we can override everything we want, the `=C` part imports the keys from the other file, and next ones are read normally, overriding any previous value. -- 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/1217#issuecomment-244992416
Re: [Github-comments] [geany/geany] Inherit C lexer_properties in all filetypes inheriting C styles (#1217)
If there is a new lexer property added that we only want to apply to a specific filetype, can we not just specify it in the `[lexer_properties=C]` group, or does it not read the group at all if it inherits from another filetype? -- 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/1217#issuecomment-244991655
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
> I'd prefer to error out (perhaps we need the dot in the future?) but I don't > feel strong. I personally don't feel strong about the specifics either, just that it should give some help. Mostly I made this PR out frustration after spending an hour or so scratching my head trying to understand why my proxy plugin hooks weren't being called, sprinkling `printf`s all over my code and deep inside the bowels of Geany to solve it (yeah, I know I should've used my debugger). I simply just missed the mention in the API reference that said it doesn't include the dots. To my mind the dot is part of the extension, so I didn't even suspect that could be the problem until I really started pinning down the program flow. -- 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/1212#issuecomment-244988396
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
> @@ -1963,6 +1963,18 @@ static void pm_show_dialog(GtkMenuItem *menuitem,
> gpointer user_data)
> }
>
>
> +static const gchar *fix_extension(const gchar *ext)
> +{
> + if (*ext == '.')
> + {
> + g_warning(_("Proxy plugin extension '%s' starts with a dot, "
> + "stripping. Please fix your proxy plugin."), ext);
indeed
--
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/1212/files/4d0acad41751552c7b271e6d06bd64a9f9682e29#r77656626
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
Unless `noexcept` is the only thing in C/C++ (and compiler extensions/attributes) which must be declared on the definition rather than/in addition to the declaration, discussing it (and C++ exceptions) is kind of off-topic. I was pretty sure there were others, particularly GCC `__attribute__`s where the definition and declaration must match (ex. whatever G_GNUC_INTERNAL expands to seems to be like this in C++ at least, last I checked), but I could be wrong. In any case, maybe we could simply offer a macro to guard out the forward declaration if the plugin opts to do so by defining the macro before including the header. Maybe something like `GEANY_DISABLE_PLUGIN_FORWARD_DECLS` or such. -- 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/1215#issuecomment-244985802
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
> The nice thing about the `noexcept` is it can catch exceptions from the
> `catch` clause too, so it would be good if it could be used.
Yeah, but my point is that it's not really a solution, as it'll abort Geany
altogether, not just the plugin. So a well-behaved plugin should manage it
anyway. Maybe do:
```C++
extern "C" G_MODULE_EXPORT void geany_load_module (GeanyPlugin *plugin)
{
try {
plugin->info->name = "great plugin";
plugin->info->description = "saves the world";
plugin->info->version = "42";
plugin->info->author = "Me";
plugin->funcs->init = great_plugin_init;
plugin->funcs->cleanup = great_plugin_cleanup;
GEANY_PLUGIN_REGISTER (plugin, 225);
} catch(...) {
// not much to be done, and mustn't throw exceptions
g_critical("My great plugin failed to register itself. Maybe it's not so
great after all...");
}
}
```
> I wouldn't think it would change the ABI […]
It *has* not to change the ABI of the C decl, as the C caller won't know about
it so won't do anything in either case. It still has to be able to call the
function just the same.
--
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/1215#issuecomment-244967214
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
> If really the author meant to add noexcept, she must then be aware of the
> problem and properly handle exceptions anyway, as IIUC all this is merely a
> runtime check that leads to program abortion.
Its sadly easy to allow exceptions, they are slippery little things:
```c++
int f() try {
the code;
} catch(...){
now I must not allow anything to throw here;
careful of IO, constructing objects, operators;
sheesh, not much you CAN do;
better just terminate, or return -1;
}
```
The nice thing about the `noexcept` is it can catch exceptions from the `catch`
clause too, so it would be good if it could be used.
> So authors of C++ plugins are forced to consider the issue. But that breaks
> C++ API.
Though I wouldn't expect too many C++ plugins for the new API, yet, now is the
best chance.
> Though, I still wonder how this can change the ABI, especially in C linkage
> where there can't be no name mangling anyway.
I wouldn't think it would change the ABI, I would have expected the stack frame
to have a flag saying this function is `noexcept` so the unwinder can see it
and terminate. So its internal to the function. But it is implementation
dependent, so who knows.
--
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/1215#issuecomment-244962916
Re: [Github-comments] [geany/geany] Hide Menu Bar (#633)
Looks like problem of unity-gtk*-module, which I installed just from curiousity. When I revmoved it, menu stopped disappearing. (I'm running Gnome on Opensuse). -- 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/633#issuecomment-244962418
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
> I was thinking a proxy written in C++ could cause Geany to call it on a > subplugin? (but I don't know the details of proxy and geany interaction). Probably not, because `geany_load_module()` is the builtin Geany API, a proxy plugin is likely to have it own, and even then, only one place should call that function inside plugins. > As best I can tell its UB. […] Yeah I'd imagine. Though, I'm wondering what's worse: not checking signature at all, or requiring authors of C++ plugins to carefully not throw any exception (from inside a function that is highly unlikely to contain much C++ code)? If really the author meant to add `noexcept`, she must then be aware of the problem and properly handle exceptions anyway, as IIUC all this is merely a runtime check that leads to program abortion. An alternative solution could be something like this: ```C++ #ifdef __cplusplus /* >= 2011 */ gboolean geany_load_module(GeanyPlugin *plugin) noexcept; #else gboolean geany_load_module(GeanyPlugin *plugin); #endif ``` So authors of C++ plugins are forced to consider the issue. But that breaks C++ API. -- 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/1215#issuecomment-244953219
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
> That's not the case here, as this is only directly called by Geany, right? I was thinking a proxy written in C++ could cause Geany to call it on a subplugin? (but I don't know the details of proxy and geany interaction). > BTW, can really C-linkage stuff throw exceptions? Sure it's somewhat > unrelated, but if it's meant to be called by C code it better not throw > indeed. As best I can tell its UB. The `extern "C"` is defined to control calling convention and name mangling, nothing else. I would doubt the C++ compiler will unilaterally apply `noexcept` to `extern "c"` functions since its still ok to call them from C++ as well. In fact a disaster may occur without even the need to go through C and back to C++. If the stack unwinding moves from C++ to C stack frames, will it see frames without handlers, or will it see some random part of the C frame as specifying an exception handler and do "interesting" things? UB. Its just very important to prevent all exceptions from exiting C++ into C, one of the rare places where swallowing exceptions is probably acceptable. -- 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/1215#issuecomment-244949764
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
> The REAL problem with exceptions is is when one passes through some C code > and back into C++ which catches it and continues to execute. That's not the case here, as this is only directly called by Geany, right? > If an exception tries to exit a noexcept function its an automatic terminate > which tells the programmer they screwed up. Not perfect, but indeed better than corrupting the call stack. BTW, can really C-linkage stuff throw exceptions? Sure it's somewhat unrelated, but if it's meant to be called by C code it better not throw indeed. -- 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/1215#issuecomment-244941743
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
Well, the intention of adding `noexcept` is to prevent exceptions escaping from C++ into C. The REAL problem with exceptions is is when one passes through some C code and back into C++ which catches it and continues to execute. Who knows what state the data being manipulated by the C code will be in since it will never complete its execution. If an exception tries to exit a noexcept function its an automatic terminate which tells the programmer they screwed up. -- 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/1215#issuecomment-244940716
Re: [Github-comments] [geany/geany] Inherit C lexer_properties in all filetypes inheriting C styles (#1217)
The only slight downside I see is that with this if we add a new C-specific lexer property in *filetypes.c*, it'll be inherited by everyone. However, it's kind of unlikely we do that, especially as *LexCPP* is *meant* for C and C++ highlighting, so the default feature set should target that, and extra properties will likely be there for *other* languages. -- 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/1217#issuecomment-244940403
[Github-comments] [geany/geany] Inherit C lexer_properties in all filetypes inheriting C styles (#1217)
`lexer.cpp.track.preprocessor` lexer properties affects which styles are used, and we don't set those, so no filetype inheriting C styles should set it to 1. Similarly, some properties like `styling.within.preprocessor` are mostly general settings rather than selecting syntax details, so they should probably match in all filetypes for consistency. So, inherit the C lexer_properties everywhere C styles are used, and only override specific properties in the inheriting filetype. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/1217 -- Commit Summary -- * Inherit C lexer_properties in all filetypes inheriting C styles -- File Changes -- M data/filedefs/filetypes.CUDA.conf (4) M data/filedefs/filetypes.Genie.conf (2) M data/filedefs/filetypes.Graphviz.conf (4) M data/filedefs/filetypes.JSON.conf (2) M data/filedefs/filetypes.Scala.conf (2) M data/filedefs/filetypes.actionscript (2) M data/filedefs/filetypes.cpp (4) M data/filedefs/filetypes.cs (4) M data/filedefs/filetypes.ferite (2) M data/filedefs/filetypes.glsl (4) M data/filedefs/filetypes.go (3) M data/filedefs/filetypes.haxe (2) M data/filedefs/filetypes.java (1) M data/filedefs/filetypes.javascript (2) M data/filedefs/filetypes.vala (4) -- Patch Links -- https://github.com/geany/geany/pull/1217.patch https://github.com/geany/geany/pull/1217.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/1217
Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
Makes sense. The only advantage of flags over enumeration is to be able to combine them, but here it doesn't seem to really make any sense, and I can't easily think of a future change reusing `NOLOAD` with something else than `MATCH`. And yeah, it's kind of unexpected to not be allowed to return `IGNORE | NOLOAD` yet them being flags. -- 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/1213#issuecomment-244937770
Re: [Github-comments] [geany/geany] Improve GeanyProxyProbeResults a litte (#1213)
> @@ -379,7 +392,7 @@ GeanyProxyProbeResults;
> struct GeanyProxyFuncs
> {
> /** Called to determine whether the proxy is truly responsible for the
> requested plugin.
> - * A NULL pointer assumes the probe() function would always return @ref
> PROXY_MATCHED */
> + * A NULL pointer assumes the probe() function would always return @ref
> GEANY_PROXY_MATCH */
> gint(*probe) (GeanyPlugin *proxy, const gchar
> *filename, gpointer pdata);
ideally the function would return `GeanyProxyProbeResults`, but well, it'd
technically be an ABI break -- even though we know everyone use 2's complement
so it wouldn't change nothing, but meh.
--
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/1213/files/094737533609dff5a2ff101f97e8c156bcca4979#r77625807
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
I'd prefer to error out (perhaps we need the dot in the future?) but I don't feel strong. -- 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/1212#issuecomment-244933640
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
Sounds reasonable -- 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/1212#issuecomment-244932042
Re: [Github-comments] [geany/geany] Gracefully handle proxies registering invalid extensions (#1212)
> @@ -1963,6 +1963,18 @@ static void pm_show_dialog(GtkMenuItem *menuitem,
> gpointer user_data)
> }
>
>
> +static const gchar *fix_extension(const gchar *ext)
> +{
> + if (*ext == '.')
> + {
> + g_warning(_("Proxy plugin extension '%s' starts with a dot, "
> + "stripping. Please fix your proxy plugin."), ext);
would be nice to include the plugin name somewhere
--
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/1212/files/4d0acad41751552c7b271e6d06bd64a9f9682e29#r77622584
Re: [Github-comments] [geany/geany] Plugins: Needless forward declaration of geany_load_module() (#1215)
Well, the reason we have this like we do for old-style `plugin_*()` is specifically to check for compatibility. It's not very nice if *really* compatible things are deemed not, but if the compiler thinks it's incompatible, is it really not? Also, could you propose another way to make sure the signature is correct, or at least try and warn if it isn't? As for C, are there really any pragmas or attributes, is there really some that would lead to incompatibility of the prototype here, while actually not changing how the function need be called? -- 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/1215#issuecomment-244931590
Re: [Github-comments] [geany/geany] Haxe: Update keywords (#1216)
@programmador As you seem to use Haxe and Geany, would you mind taking a quick look whether this is correct? 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/pull/1216#issuecomment-244905974
[Github-comments] [geany/geany] Haxe: Update keywords (#1216)
Update keywords with https://haxe.org/manual/expression.html#keywords. `trace` is kept although it's not a keyword, because it was already there and http://try.haxe.org/ highlights it identically to some other keywords. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/1216 -- Commit Summary -- * Haxe: Update keywords -- File Changes -- M data/filedefs/filetypes.haxe (4) -- Patch Links -- https://github.com/geany/geany/pull/1216.patch https://github.com/geany/geany/pull/1216.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/1216
Re: [Github-comments] [geany/geany] Haxe conditionals sometimes break syntax highlight (#936)
> So are you sure it's a scintilla bug? Actually it's not, it's "just" that we don't set the "inactive preprocessor" styles, and anyway Haxe's preprocessor directives are different from C, and we forget to disable preprocessor tracking for Haxe. Done 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/936#issuecomment-244900377
Re: [Github-comments] [geany/geany] Haxe conditionals sometimes break syntax highlight (#936)
Closed #936 via bbdf56fc2e2c978de6a61c3be56dfeb5bc6963ef. -- 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/936#event-779074310
