emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cvs] bug when using pc-selection-mode/transient-mark-mode


From: Stefan Monnier
Subject: Re: [cvs] bug when using pc-selection-mode/transient-mark-mode
Date: Sun, 22 Sep 2002 18:48:20 -0400

> HOWEVER, this is an ugly hack and I've noticed a lot of similar "save
> deactivate_mark; do crap; restore deactivate_mark" code in Emacs. It just
> smells of bad design when global variables have to be pushed and popped
> all the time and someone calling a function needs to know which variables
> to push/pop, especially when this is not documented.  Some ideas for a
> more elegant (i.e. a lot more troublesome to implement)  solution:
> 
>   - per-buffer `deactivate-mark' variable.
>   - maybe prepare_to_modify_buffer doesn't need to set deactivate-mark
>     (probably does need to).
>   - a "temporary buffer" status for buffers that are such. Could be either
>     passed to get-buffer-create or set as a buffer-local variable.
>   - notice whether the buffer being modified by in prepare_to_MB is the
>     "active" one (current buffer? or any visible buffer) that the user has
>     a selection in (and if not assume it's a temporary buffer)
> 
> In the meantime there should be a documented warning to emacs developers
> that whenever they create and manipulate temporary buffers that they have
> to save the deactivate-mark variable.

`mark-active' is buffer-local and I think `deactivate-mark' should
be buffer-local as well.  But that begs the question "when do we check
whether deactivate-mark was set and reset mark-active accordingly" ?
Are we going to loop through all buffers, looking for ones with
a non-nil deactivate-mark ?
So maybe we should not make it buffer-local but instead make it hold
a list of buffers whose mark should be deactivated.
Currently we only use t or nil where t means "current-buffer".


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]