[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scratch/accurate-warning-pos: next steps.
From: |
Eli Zaretskii |
Subject: |
Re: scratch/accurate-warning-pos: next steps. |
Date: |
Mon, 10 Dec 2018 20:15:18 +0200 |
> Date: Mon, 10 Dec 2018 18:00:33 +0000
> From: Alan Mackenzie <address@hidden>
>
>
> Following an idea from Paul, I propose to build an alternative byte-code
> interpreter alongside the primary one. This second interpreter would
> regard symbols with position as being EQ to the corresponding bare
> symbols, just as the branch currently does when symbols-with-pos-enabled
> is bound to non-nil.
I don't think I understood when will this alternative interpreter be
used, and when will the "primary" one be used. Can you elaborate on
that?
Thanks.
- scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps.,
Eli Zaretskii <=
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Eli Zaretskii, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Eli Zaretskii, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Eli Zaretskii, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
Re: scratch/accurate-warning-pos: next steps., Paul Eggert, 2018/12/10