Kyle Jones <kyle_jones(a)wonderworks.com&gt; writes: First, your opinion has much value and you know this. Second, making things *look* unlogical at a first glance is not the way to encourage users to become like you. It's encouraging them to use something else. When something appears to work not logically (I didn't say "not obviously"), the most common reaction is not to investigate the manual, but to think that there's a bug. The documentation and the doc-strings are here to let people know that they can do complex things. But the point I try to raise is precisely that "obvious" and "logical" are different things. I have nothing against non-obvious behavior as long as this behavior doesn't fuck up the obvious one, which is the case right now. Let me make this clear: let's consider an XEmacs feature, the ability to move around and mark a place in the buffer. This feature has obvious aspects and non obvious ones. The obvious one (the most intuitive) is that after you set the mark somewhere, the region is hilighted, and when you move around, the region extents between the place you marked and the current point. Well. You can experiment this with the basic motion commands, `next-line' and the like. Now suddendly, you try to use M-> and M-<, and you discover that the beginning of the region you had marked before has changed. _THIS IS NOT LOGICAL IN ANY WAY_. What happens here is that in order to achieve a more complex behavior (a *non-obvious* one), you fuck up the logic of the simple behavior. This is the ONLY thing against which I'm fighting. Now, second step. You learn about the non-obvious behavior and you find it interesting. You decide to use it. In order to use this behavior, you need a special feature, namely, you need to allow some functions to push the mark (Stephen, for instance, does even want to push the mark even if it's already set). This is something non-obvious at all, and consequently *you* should have to position some non-obvious variable in order to get it. Not the other way around. Am I clearer ? To summarize: in any kind of software, each feature has different levels of complexity. This is good because experimented users do want to be able to achieve complex things. However, for each feature, the immediate level of complexity should *always* be the simplest one in order to let people learn progressively how to use the software. Finally, if you want to use the feature in a more complex manner, *you* should have to say so in some manner. And most important: if, in order to make things work in the non-obvious way, you have break the logic of the obvious way, then the feature is completely bogus. As far as our particular matter is concerned, I have absolutely nothing against beginning-of-buffer pushing the mark, and doing so even if the region is already active, but this is a damned *non-obvious* thing and consequently shouldn't be the default because by default, *it's not logic*. On the contrary, if you want to enable this non-obvious feature, you should have to say it explicitely, like (setq long-moves-override-mark t), and then - you get the behavior you want - you don't impose a non-obvious behavior onto the other, especially the newcomers - you don't break the logic of the feature, because now, the mark is indeed pushed, but this is logic since you requested it. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19