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

[Miles Bader]

On Sun, Sep 22, 2002 at 06:48:20PM -0400, Stefan Monnier wrote:
> `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 ?

How about something like:

  (1) `mark-active' gets set to a (global) integer counter value instead of t.

  (2) In the current place where `deactivate-mark' is checked, it just
      handles the current buffer, but also increments the global counter.

  (3) `switch-to-buffer' checks to see if `mark-active' is less than the
      global counter value, and if so, checks the local value of
      `deactivate-mark' and perhaps sets mark-active to nil.

IOW, it lazily does the deactivation based on the local value of
deactivate-mark.

Is this too expensive a thing to take place in switch-to-buffer?

> 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".

Doesn't that require all the places where deactivate-mark is set to be
changed (in a non-trivial way)?  Sounds very annoying for programmers...
[and a maintainance headache]

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.