With single reads, the input processing is limited to
(1/0.050 * DEFAULT_IO_LENGTH) KB/sec, which is pretty low.
Moved the check whether the maximum empty G_IO_IN-s are reached to a
macro, SPAWN_CHANNEL_GIO_WATCH(sc).
* Update obsolete references to GLib 2.27/28 in HACKING
Fixes#1476.
* Replace obsolete gcc -W option with -Wextra in HACKING
According to gcc --help=warnings, -W is a deprecated option
and -Wextra should be used instead.
Escaped newlines were properly handled inside preprocessor directives,
but not otherwise.
Seeing `continue` here suggests the code used to work a long time ago
but some loop refactoring broke it, as now it would not stay in the
loop unless in a preprocessor directive. Or maybe it only ever worked
for preprocessor directives, and the `continue` was superfluous?
Fixes#1370.
When plugin calls plugin_set_key_group() several times for the same
group (when creating keybindings dynamically and needs to reset them),
it crashes with the current code the second time it gets called.
The reason is that group->plugin_keys is an array into which entries of
group->key_items point and when calling
g_ptr_array_set_size(group->key_items, 0);
it calls free_key_binding() for every item - when these items are
deallocated by g_free(group->plugin_keys) previously, calls of
free_key_binding() reference an invalid memory.
Just first resizing group->key_items (and calling free_key_binding() for
its items) and freeing group->plugin_keys afterwards fixes the problem.
Some versions of GLib under Linux continuously generate G_IO_IN-s
without any data to read when using recusrive channel watch sources,
causing 100% CPU load. This patch detects such a situation, and
automatically switches the affected source from channel watch to
50ms timeout.
Add parfor to Matlab keyword list
Add `parfor` to the list of keywords to be highlighted in Matlab script sources. `parfor` is a Matlab keyword that can be used in place of `for` to achieve parallel processing.