On Thu Nov 19, 2020 at 6:06 AM CET, Jan Beich wrote:
> Regressed by https://git.sr.ht/~leon_plickat/wlclock/commit/74a155389c20
> Found while packaging/testing meson_options.txt with non-default values.
>

Fixed, thanks for the report.

Do you need a point-release for packaging?


Friendly greetings,
Leon Plickat

Hi again.

I got an answer to the mini survey explaining a good use case for the
mode "full". To make it short: This mode is apparently useful for
phones, to replicate the android-typical "app drawer" thing at the
bottom of the screen.

As such, I decided to keep the "full" mode. However some changes will
still be made: "default" mode will be renamed to "aggressive" mode and
"simple" mode will be the new default.

Friendly greetings,
Leon Plickat

Hi.
This is a mini-survey asking any users of LavaLauncher whether they
use the `mode` and/or `align` options.

I have some things planned for LavaLauncher, however before I can
comfortably work on those things, I need to clean up the code base.
There being multiple different modes massively hurts code quality, so
I would like to remove these features.

LavaLauncher will then behave like it does if `mode` is set to
`simple`. This is the way I always imagined LavaLauncher to work, the
different modes were just a workaround for a bug in Sways layer shell
implementation. I have since fixed that bug in Sway and I believe
other compositors implementations of the layer shell have also been

Thanks!


Friendly greetings,
Leon Plickat

The return value of set_url() was not checked, meaning that when it
failed, gmnlm continued anyway, causing an assertion to fail and
subsequentially resulting in a segfault.
---
 src/gmnlm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gmnlm.c b/src/gmnlm.c
index 41284df..5997edd 100644
--- a/src/gmnlm.c
+++ b/src/gmnlm.c
@@ -780,7 +780,9 @@ main(int argc, char *argv[])
 	}
 
[message trimmed]

Thanks, applied.

Friendly greetings,
Leon Plickat

On Sat Aug 29, 2020 at 8:30 PM CEST, Drew DeVault wrote:
> I would really prefer if you added an automated test for this.

I get it. Would you prefer a test for the next line simply starting
with '\t' or doing a "full" indentation check with parse_indent()?


Friendly greetings,
Leon Plickat

This fixes a bug causing incorrect indentation when the first char in
the next line after an indented line ended with "++" is '\t'.
---
As suggested, I tested this patch with multiple different cases, like
linebreak on indented line and the next line having a (vastly)
different indentation. I also tried generating sway(5) and searching
through that for any unexpected formatting. All cases I tested have
the same result as if generated without this patch, just with correct
indentation after linebreaks. Therefore I still do not think the test
is necessary, so I did not include it in the patch.

 src/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[message trimmed]

I just released version 2.0.0 of LavaLauncher.

This is most radical update of LavaLauncher to date. This new version
not only introduces a lot of new features, but also completely
overhauls the configuration as well as basically all internal data
structures and operations. If all patches since the last version are
considered, this is almost a complete rewrite, hence the major version
bump.

CHANGELOG:
- LavaLauncher is now configured via a configuration file instead of
  command flags. This not only provides a considerably more pleasant
  user experience, but also makes more complex configuration options
  possible, allowing LavaLauncher to gain a lot more useful features.

On Wed Aug 26, 2020 at 3:50 PM CEST, Drew DeVault wrote:
> This patch might be a good solution but it would be better with a
> test attached.

I am not sure I understand what test you mean. Test whether the line
is indented before returning and otherwise using the old behaviour?

I may be missing something, but on an unindented line, whether we
directly return after a linebreak or let parse_text() explicitly
handle the newline makes little difference. The resulting output is
the same.

Unrelated, but should the queue be flushed to output before returning?