Re: [hackers] [dmenu] Revert "avoid redraw when there's no change" || Hiltjo Posthuma

From: NRK <nrk_AT_disroot.org>
Date: Sun, 27 Mar 2022 00:11:01 +0600

On Sat, Mar 26, 2022 at 06:00:03PM +0100, git_AT_suckless.org wrote:
> commit 31fa07b9849b0ffbf4b7efb55943f466b3ff160f
> Author: Hiltjo Posthuma <hiltjo_AT_codemadness.org>
> AuthorDate: Sat Mar 26 17:57:50 2022 +0100
> Commit: Hiltjo Posthuma <hiltjo_AT_codemadness.org>
> CommitDate: Sat Mar 26 17:57:50 2022 +0100
>
> Revert "avoid redraw when there's no change"
>
> This reverts commit 6818e07291f3b2913e687c8ec3d3fe4711724050.
>
> This broke keys such as ^W to delete-backward-word
>
> diff --git a/dmenu.c b/dmenu.c
> index 19f6385..085dc29 100644
> --- a/dmenu.c
> +++ b/dmenu.c
> _AT_@ -415,9 +415,8 @@ keypress(XKeyEvent *ev)
> switch(ksym) {
> default:
> insert:
> - if (iscntrl((unsigned char)*buf))
> - return;
> - insert(buf, len);
> + if (!iscntrl(*buf))
> + insert(buf, len);
> break;
> case XK_Delete:
> case XK_KP_Delete:
>

The patch was definitely short-sighted and I should've tested it more.

I saw that drawing had it's own goto label and some of the above keys
were doing `goto draw` instead of relying on the code going down.

But even if we change, for example the ctrl+w, from `break` to `goto draw`:

         case XK_w: /* delete word */
                 /* ... */
- break;
+ goto draw;

this still wouldn't have solved the problem because someone can press
ctrl+w on empty prompt, which effectively changes nothing, but still
would do a redraw.

Doing a redraw isn't THAT bad anymore with the recent patches, so maybe
this is a problem not worth solving. But even now, redrawing isn't
exactly "free".

One thing I can think of, is just to keep track of the previous cursor
position within drawmenu() and return early if there's no change.

I'll play around with this idea more thoroughly and see if there's any
edge cases where this doesn't work before sending the patch.

- NRK
Received on Sat Mar 26 2022 - 19:11:01 CET