[implementations-list] buggy behaviour with Transient Mark Mode disabled

Štěpán Němec stepnem at gmail.com
Tue Apr 13 17:04:08 CEST 2010


On Tue, Apr 13, 2010 at 01:13:44PM +0000, Vegard Øye wrote:
> Thank you for the bug report. This should be fixed in revision 203.

Yeah, seems to work fine now, thanks!

> Transient Mark mode has a global variable, `mark-active', which
> governs whether the region is "active" or not. When it is t, Transient
> Mark mode highlights the region. When Transient Mark mode is disabled,
> the value is ignored. You can set the variable directly, but the
> common way to activate the region is with
> 
>     (push-mark nil nil t) ; ACTIVATE argument is t
> 
> which sets mark at point and, provided Transient Mark mode is enabled,
> activates it. If you do
> 
>     (push-mark) ; ACTIVATE argument is nil
> 
> then mark is set at point, but /not/ activated (i.e., `mark-active'
> is unchanged).
> 
> Now, let's disable Transient Mark mode and call `push-mark' again:
> 
>     (push-mark) ; ACTIVATE argument is nil
> 
> What happens to `mark-active' now? Well, its value is ignored, so why
> should it change? But that's precisely what happens: when Transient
> Mark mode is disabled, `push-mark' will set `mark-active' to t
> /even if the ACTIVATE argument is nil/. That is, `push-mark' will set
> `mark-active' to t if the ACTIVATE argument is t /or/ if Transient
> Mark mode is disabled, even though it's ignored in the latter case.
> 
> Makes sense? Well, not to me either, but there it is.

Well, looking at the `push-mark' and `set-mark' code, this behaviour
certainly does not seem to be a mistake.

I'm not familiar with the detailed history, but one guess would be that
things got a bit complicated with recent decisions like making TMM
enabled by default.

> Then, of course, Vimpulse comes along, enables Transient Mark mode,
> and boom! -- the region is immediately activated. Big mess.

Yeah, well that's a kind of problem -- TMM mode is supposed to highlight
the current region, i.e. the portion between point and mark. And you can
have mark (and region) without TMM, of course -- it's just not
highlighted (or perhaps "active" in TMM-speak), but gets highlighted as
soon as you enable TMM. Which is perfectly correct behaviour.
 
> How does one discover these things? Multiple files to the rescue!
> Unload them one by one until the problem disappears; that narrows it
> down. Then search the remaining code for mark-related code, and the
> strange, unintuitive behavior of `push-mark' becomes apparent. Not the
> way I usually go about these things, but when you have to deal with
> certain global variables ...

Hm... I'd say that's a rather crude way of debugging; I wouldn't
consider that a persuasive argument for multiple files (also see below).

> Now, Vimpulse is always released as one big file at EmacsWiki, and you
> can run `make all' to produce that file yourself. Unfortunately, this
> will lose you all revision history. I'm sorry about this
> inconvenience.

[FWIW, just `make' is enough.]
 
> FWIW, this is how I load Vimpulse in my .emacs:
> 
>     (require 'vimpulse-dependencies)
>     (require 'vimpulse-viper-function-redefinitions)
>     (require 'vimpulse-utils)
>     (require 'vimpulse-misc-keybindings)
>     (require 'vimpulse-modal)
>     (require 'vimpulse-ex)
>     (require 'vimpulse-paren-matching)
>     (require 'vimpulse-operator)
>     (require 'vimpulse-text-object-system)
>     (require 'vimpulse-visual-mode)
>     (require 'vimpulse-compatibility)

You don't really need this, unless you're going to evaluate the
`require' forms manually one by one. Just `(require vimpulse)' is enough
(vimpulse.el contains all the forms above), no matter if you use the
single file or multiple files.

For the same reason, you don't even need multiple files for your
debugging method. You can unload the features one by one anyway (the
only difference being `vimpulse' depending on all the others, so you
would need to unload it first or use the FORCE argument to
`unload-feature').

...but you would have to use narrowing or some similar functionality
for exluding the unloaded parts from searching.
 
> My site-lisp directory contains Vimpulse as multiple files, of course.
> Maybe it would be easier if you did the same?

Yeah... not easier, it would be a PITA for both searching and editing,
so I wanted to avoid that.


  Štěpán



More information about the implementations-list mailing list