[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possibly spurious bytecomp warning:
From: |
Michael Heerdegen |
Subject: |
Re: possibly spurious bytecomp warning: |
Date: |
Sat, 20 May 2023 02:26:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Robin Tarsiger <rtt@dasyatidae.com> writes:
> (cl-loop
> for c in
> '(?I ?o)
> do
> (when (assoc c eww-link-keymap)
> (delete (assoc c eww-link-keymap) eww-link-keymap))) ; <--
>
> Here, the list being modified is a keymap, so the first element
> is the keymap type symbol and assoc never returns it. And notably,
> delete's _docstring_ doesn't guarantee in-place modification for
> non-head deletions, but the Info node for delq/delete describes both
> functions as doing cdr splicing in that case, so assuming that's meant
> as normative, this will operate correctly.
I think this is correct.
Maybe using higher-level functions for keymaps (e.g. `lookup-key') would
be better.
> It probably wouldn't be reasonable for bytecomp to try to distinguish
> this, though...
I would not harm if it could, but how would it do that?
Michael.
- possibly spurious bytecomp warning:, T.V Raman, 2023/05/19
- Re: possibly spurious bytecomp warning:, Michael Heerdegen, 2023/05/19
- Re: possibly spurious bytecomp warning:, Robin Tarsiger, 2023/05/19
- Re: possibly spurious bytecomp warning:,
Michael Heerdegen <=
- Re: possibly spurious bytecomp warning:, T.V Raman, 2023/05/19
- Re: possibly spurious bytecomp warning:, Michael Heerdegen, 2023/05/19
- Re: possibly spurious bytecomp warning:, T.V Raman, 2023/05/20
- Re: possibly spurious bytecomp warning:, Michael Heerdegen, 2023/05/20
- Re: possibly spurious bytecomp warning:, T.V Raman, 2023/05/20