[implementations-list] buggy behaviour with Transient Mark Mode disabled
Hello Vegard, OK, I see you fix bugs sooner than I decide whether I should whine about it or look in the source... :-P (speaking about gu/gU moving to bol unconditionally). Not this one though: Vimpulse exhibits strange behaviour with Transient Mark Mode disabled, and I seem to recall that wasn't the case before that last update (to rev 199, but I don't really remember from which revision) of mine. One typical manifestation, even without involving selection at all: With TMM off, first `dd' in a buffer deletes the whole portion of the buffer up to that line. After this failure, it works correctly again ...until you set the mark, obviously. In short, the command seems to act upon the region instead of line when TMM is disabled. Similarly with `yy'. Best regards, Štěpán P.S.: Is there any chance of convincing you to just use one big file? I'd really appreciate that, especially after switching to a usable VCS. Last time I proposed that you said multiple files were advantageous for debugging -- what did you mean? I can't think of any such advantage myself. Heck, you made it to 6k, but there's still allout.el with 7151! ;-)
Date: Mon, 12 Apr 2010 23:24:02 +0200 From: [email protected]
With TMM off, first `dd' in a buffer deletes the whole portion of the buffer up to that line. After this failure, it works correctly again ...until you set the mark, obviously. In short, the command seems to act upon the region instead of line when TMM is disabled.
Thank you for the bug report. This should be fixed in revision 203. Vimpulse /should/ work just fine with Transient Mark mode disabled. It may need to temporarily enable it now and then (e.g., Visual mode), but it should restore everything to their original settings afterwards. More details below.
Last time I proposed that you said multiple files were advantageous for debugging -- what did you mean? I can't think of any such advantage myself.
Let me give you an example. :) 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. Then, of course, Vimpulse comes along, enables Transient Mark mode, and boom! -- the region is immediately activated. Big mess. 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 ... 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, 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) My site-lisp directory contains Vimpulse as multiple files, of course. Maybe it would be easier if you did the same? Vegard _________________________________________________________________ Nye Windows 7: PCen som passer for deg. Finn ut mer. http://windows.microsoft.com/shop
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
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
On Tue, Apr 13, 2010 at 07:16:51PM +0000, Vegard Øye wrote:
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.
Actually, IIUC that depends on the value of `mark-even-if-inactive'. If it is nil, there is no distinction between active and inactive region in TMM -- either there is a region (active and highlighted) or not (IOW -- any use of `set-mark-command' activates TMM). But yeah, the behaviour is in some ways confusing to me, too.
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.
Hm. I assume you know about the possibility to set `transient-mark-mode' to `lambda' or `(only . OLDVAL)' and it does not help the problem?
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?
Yes. And unloading any feature would unload the whole file. In short, what I write above is basically nonsense (as is any scheme that doesn't go with one file == one feature correspondence). Sorry. Štěpán
I started the multiple-file thingy in vimpulse, mostly because i completely hate editing huge files, sometimes to find a function definition or call in a big file is a real pain in the ass. As a user it's really handy though, and as a user (I don't have the time to work on it and Vegard is probably doing a much better job than mine) I would like a one-big-file-only release... But I think the distribution format should reflect the needs and habits of the main developer/maintainer, the price (running make and copying the file) is very low to pay, while even a change in habits can be painful/frustrating for Vegard - I can understand not liking to work with ugly big files. Alessandro On 13 April 2010 22:06, Štěpán Němec <[email protected]> wrote:
On Tue, Apr 13, 2010 at 07:16:51PM +0000, Vegard Øye wrote:
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.
Actually, IIUC that depends on the value of `mark-even-if-inactive'. If it is nil, there is no distinction between active and inactive region in TMM -- either there is a region (active and highlighted) or not (IOW -- any use of `set-mark-command' activates TMM).
But yeah, the behaviour is in some ways confusing to me, too.
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.
Hm. I assume you know about the possibility to set `transient-mark-mode' to `lambda' or `(only . OLDVAL)' and it does not help the problem?
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?
Yes. And unloading any feature would unload the whole file. In short, what I write above is basically nonsense (as is any scheme that doesn't go with one file == one feature correspondence). Sorry.
Štěpán
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Date: Tue, 13 Apr 2010 23:06:32 +0200 From: [email protected]
It's this distinction which makes Transient Mark mode valuable, although it is a PITA to get the frequent enabling/disabling to work smoothly.
Hm. I assume you know about the possibility to set `transient-mark-mode' to `lambda' or `(only . OLDVAL)' and it does not help the problem?
No, because disabling Transient Mark mode must be handled by Vimpulse. Actually, the problem was pretty much solved already by Visual mode. Operator-Pending mode failed only because I'd forgotten to add an important nugget of code to the general function for enabling Transient Mark mode "safely". Now, `mark-active' is set to nil whenever Vimpulse enables Transient Mark mode, which leaves Vimpulse (or a selection command) free to activate the region subsequently. :) Vegard _________________________________________________________________ Windows 7: Se direkte-TV fra den bærbare PCen. Finn ut mer. http://windows.microsoft.com/windows-7
participants (3)
-
Alessandro Piras -
Vegard Øye -
Štěpán Němec