Building and Compiling works, but running doesn't. When I press F5, a terminal window appears with nothing in it, the program doesn't get executed, ctrl+c and ctrl+x do nothing, closing it with ctrl+shift+w works.
I tried it with default geany configuration and it still didn't work.
This may have begun since l updated to lubuntu 17.04.
l hope l didn't submit a duplicate 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/1515
:smile: No problem. Maybe we should open a new ticket as a discussion of this point. The goal for me would be to find a common way that every one can agree to and probably could become part of the coding guidelines.
--
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/commit/109b8d079a59ba35e8aba5da960fc…
@codebrainz @b4n, its probably best we take this argument somewhere else, not hijack __another__ pull request :grin:
Apologies to @LarsGit223
--
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/commit/109b8d079a59ba35e8aba5da960fc…
> Because they know things will crash if they do
They will crash or do whatever undefined behaviour either way.
>Thats a specious argument. Since most programmers fix crashing errors that occur every time the program runs, the errors MUST depend on user input otherwise they would be fixed if they occurred all the time. So unless you apply analysis or exhaustive testing user input can always expose programming errors, so if the program can politely decline to perform the user operation and keep running its better than crashing.
No, these assertions are meant only for programming error, using them for release-build control flow is not advised. See from the docs below:
> The g_return family of macros (g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), g_return_val_if_reached()) should only be used for programming errors, a typical use case is checking for invalid parameters at the beginning of a public function. They should not be used if you just mean "if (error) return", they should only be used if you mean "if (bug in program) return". The program behavior is generally considered undefined after one of these checks fails. They are not intended for normal control flow, only to give a perhaps-helpful warning before giving 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-plugins/commit/109b8d079a59ba35e8aba5da960fc…
@b4n
> (although in practice most builders don't disable them anyway)
Because they know things will crash if they do :frowning:
> as these checks are for programming errors, and should not depend on user behavior.
Thats a specious argument. Since most programmers fix crashing errors that occur every time the program runs, the errors MUST depend on user input otherwise they would be fixed if they occurred all the time. So unless you apply analysis or exhaustive testing user input can always expose programming errors, so if the program can politely decline to perform the user operation and keep running its better than crashing.
--
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/commit/109b8d079a59ba35e8aba5da960fc…
@elextr I find it pertinent to use these macros when they are meant to detect programming errors. Yes, you can be forcefully defensive and always check no matter the debugging status, but the point these macros can be disabled (although in practice most builders don't disable them anyway) is for one to be able to trade safety for more speed.
So IMO if a builder do want to disable those checks, fine, but they gotta know it's less defensive. Which could make sense, as these checks are for programming errors, and should not depend on user behavior.
In all cases, I think using a GError for programming error is worse than emitting a warning somewhere, because it's harder to handle the error and it could be ignored and left unnoticed more easily.
>Your documentation for the function doesn't disallow NULL
It odes, unless you accept `NULL` to be valid for *The project*, and as the function is supposed to save it to a file, I wouldn't expect `NULL` to be a valid one unless explicitly stated otherwise.
--
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/commit/109b8d079a59ba35e8aba5da960fc…
The patch adds a new keybinding action for undoing hunks. When cursor is
placed at a line with a diff and the keybinding is invoked, the
corresponding hunk is undone.
To get the previous contents at the given position, a temporary Scintilla
instance is used into which the previous state of the document is loaded
and the corresponding text from the previous state of the document is
extracted. This temporary Scintilla object is then destroyed.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/531
-- Commit Summary --
* git-changebar: Add the possibility to undo hunk at cursor position
-- File Changes --
M git-changebar/src/gcb-plugin.c (135)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/531.patchhttps://github.com/geany/geany-plugins/pull/531.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/531
Hmmm...yes I have also seen some calls like mine in other plugins. Let's say it this way: if never ever a programming error occurs than it is useless to check for ```NULL``` in this case. But whom am I to think that there never will be errors in the future? So I would always check pointers on the "boundaries" functions and just maybe not on internal static functions. In the case of an error it still prevents the user from a crash.
But for now I will keep the code like that. What about writing some own Geany debugging macros which use glib macros if compiled in and if not still guarantee an defined action and consistent error output among geany and geany 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-plugins/commit/109b8d079a59ba35e8aba5da960fc…