The 'Github Flavored Markdown' specification says that headers must be
followed by a space character, update the changelog to respect that
requirement.
Because "&" is not the last character to be unescaped, it is possible that
the lines for "<" and ">" expand some things they shouldn't.
For example, "&lt;" should become "<", but instead it becomes ">".
While this is unlikely to appear naturally in a notification, it is wrong.
This turns a hard-to-understand nested if{} chain into a simple switch
statement, and pulls some code out in to utility functions.
This is strictly a code-organization change, and should contain no
functional changes.
It makes more sense to handle escapes in configuration strings when we
parse them, rather than after-the-fact when we handle notifications that
use the relevant config options.
Do this in the proper backslash handler; rather than a naive string
replace which doesn't allow the backslash to be escaped (`\\n` => 0x5C0x0A
rather than 0x5C0x6E).
it to the proper backslash handler
Treating unrecognized sequences as invalid means that the backslash itself
is never propagated; so we can hoist the handling of it outside of the
switch; simplifying the code a bit.
The current behavior is
- If the value contains a double-quote:
- 1. Verify that it must contains at least two quotes.
- 2. If one of the quotes is the first character, trim it.
- 3. If one of the quotes is the last character, trim it.
- Else:
- 1. Trim a trailing comment from the value.
This has the effect that
`key = "value" # comment` => `value" #comment`
This is surprising and almost certainly not what the user wants.
However, it allows simple nested quotes like:
`key = "A string "with quotes""` => `A string "with quotes"`
Fix the brokenness of the first example at the expense of breaking the
second. A user seeking that value will now have to type:
key = "A string \"with quotes\""
Do this by treating double-quote as a toggle that simply changes whether
`;` and `#` start comments (not too different than Bash using it to toggle
field separation).
In order to have strings that contain a literal double-quote, add
rudimentary support for backslash-escaping. For now, only recognize
double-quote and backslash-itself; anything else is undefined; and the
program is free to do whatever it likes with them; for now, silently treat
the backslash as an ordinary character.
Note that this formulation of quoting implies that backslash-escaping works
identically both inside and outside of quotes.
If dmenu didn't return anything we returned out of the function without
calling `waitpid` to collect the childs exit code, leaving to the child
process to be left as a zombie indefinitely. This commit makes `waitpid`
be called before the return checks are done.
When generating the list of urls to pass to dmenu, string_append with a
newline as a separator was called unconditionally. This caused a newline
character to be added for each notification even if it didn't contain
any urls, leading to empty items in dmenu.
Fixes#300
A lot of error reporting used a simple `printf` call which by default
prints to stdout. This was changed so that all error reporting is done
by an `fprintf(stderr, ...)` call.
It doesn't make much sense to print usage into to stderr. What's more is
that it prevents users from easily piping the output to other
programs(i.e. grep)
According to the glib memory allocation documentation, if any memory
allocation calls fail the application will be terminated so there is no
need to check if the call succeeded.
multi-user.target isn't a valid user target and it doesn't make sense to run
dunst as a system service.
Eventually, this unit should probably be converted to use
graphical-session.target but it's a bit unclear how that's supposed to work
right now.
Show what is happening during build etc, the way most other make-based
projects do.
There is thus no need for the options target. Additionally, this target
caused unnecessary rebuilds of ./dunst each and every time, even on
`make install`.
'True' and 'False' are defined in Xlib.h
Since we use stdbool boolean 'true' and 'false' definitions in several
places, it's best not to mix boolean macros. So in the sake of
consistency switch to using the stdbool macros project-wide.
To load each line of the configuration file we were previously using a
simple buffer of length BUFSIZ. BUFSIZ is a macro provided by glibc as
the 'recommended length for a buffer'. But since one of our users
encountered a situation where really long config lines were necessary
it's time to change that behaviour.
This commit changes the line reading from using fgets with a character
limit of BUFSIZ to simply using getline.
We initialize the buffer pointer to NULL since getline will
automatically allocate a big enough buffer for us if it's passed a NULL
pointer. After that we pass the same buffer pointer again since,
according to the getline manpage, getline will also call realloc on the
buffer if necessary. Which means the only thing we have to do is call
free() at the end of the parsing process.
Fixes#294
