Date: Tue, 13 Apr 2010 17:04:08 +0200 From: [email protected]
Thank you for the bug report. This should be fixed in revision 203.
Yeah, seems to work fine now, thanks!
Great!
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.
Transient Mark mode doesn't necessarily hightlight the region; it creates a distinction between "active regions" and "inactive regions". By default, the region is inactive; it has to be /made/ active to be highlighted. When Transient Mark mode is disabled, on the other hand, there is no distinction; the region is just the region. Vimpulse wants the distinction between "active" and "inactive", because it allows it to reliably identify selection commands like `mark-sexp' and `mark-paragraph', which activate the region in Transient Mark mode. So, when you press "d M-h", the region is activated, and that region is deleted. When you press "d w", the region is not activated, so a motion range is constructed instead, and that range is deleted. It's this distinction which makes Transient Mark mode valuable, although it is a PITA to get the frequent enabling/disabling to work smoothly.
How does one discover these things? Multiple files to the rescue!
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).
Crude? Hell yeah. But that's the problem with poorly documented global variables: you have no idea /what/ might be influencing them. It would never occur to me that `push-mark' changes `mark-active' when Transient Mark mode is /disabled/ -- and, furthermore, that C-SPC (`set-mark-command') overrides this behavior by calling `deactivate-mark'! Of course, I rarely debug in this way. Most of the bugs are of my own making, they can be /seen/ with edebug, and usually I have some idea about where they may be.
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').
Hm. Wouldn't requiring any single feature load the whole file?
Yeah... not easier, it would be a PITA for both searching and editing, so I wanted to avoid that.
M-x lgrep :) Vegard _________________________________________________________________ Få nye Windows Live™ Messenger. http://download.live.com/messenger