> On Mar 9, 2020, at 5:01 AM, martin rudalics <rudalics@gmx.at> wrote:
> 
> >> I'm sorry, I only skimmed through your patch, but shouldn't this use
> >> 'unwind-protect'? Otherwise the "temporarily" won't hold in case of
> >> abnormal exit from BODY, unless I'm missing something.
> >>
> >> —
> >> Štěpán
> >
> > Thanks for spotting that. I added the unwind-protext form.
> 
> If we want to be more strict about this macro then how about the
> following forms:
> 
> (with-selected-window-undedicated
> (set-window-dedicated-p nil t))
> 
> will leave the selected window dedicated which does not really violate
> the contract of the macro but is unexpected at least.
> 
> The following is more serious: Suppose a user has a >= 2 windows layout
> and does
> 
> (set-window-dedicated-p nil t)
> (with-selected-window-undedicated
> (other-window 1))
> 
> which will have the macro make some other window dedicated and the
> initially selected window undedicated.  A similar thing happens with
> 
> (set-window-dedicated-p nil t)
> (with-selected-window-undedicated
> (delete-window))
> 
> The macro should be named 'with-window-undedicated', take a WINDOW (nil
> for the selected one) as first argument and BODY as second.  It should
> restore the dedicated status of WINDOW to what it was before running
> BODY and leave the dedicated status of all other windows alone.  IMHO.
> 
> Martin
> 

I updated the patch accordingly. Could you have a look at the docsting? I had a hard time writing it.

Yuan