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