On Wednesday, May 26, 2004 at 10:27:56, Milan Zamazal wrote: [...] > Oh no. I don't use xtla as a replacement for the command line > interface.
That explains a lot. Basically I try to do all from xtla. > I invoke most tla commands from command line, I only use > xtla when it is more convenient for me. It may be nice if xtla can > handle all tla commands, but that doesn't mean everybody wants to > operate with tla this way. > > RW> Or make it optional to unbind them. We should honor the > RW> majority of users. > > ATTENTION, MS WINDOWS APPROACH HERE! This approach is wrong. Well, this is just your opinion. > For example, most users probably want to have font-lock > mode enabled, but Emacs still doesn't enable it by > default. Why? Because it would hurt the minority of > users, who work with monochrome screens or strange > terminals. The first rule is don't hurt anyone, the > second is be consistent and only then convenience of > majority can come. Your approach is, the majority should do more work and save the few others from doing it ... outch THIS APPROACH IS WRONG. Binding can be set an unset, it it no one-way street. Also your example is lame, if done right it will detect the monochrome display and will not enable font-lock. This would be like making -nw an default option for Emacs, hey but Emacs is clever. [...] > If you don't know *Completions* and dired and don't know about C-n > and C-p, you're an Emacs newbie and should learn Emacs first. ;-) > Your picky argument is not picky enough. ;-) I use completions all the time, just not dired. My point was: How do you select only a part of a item in the *Completion* buffer by using the cursor keys? Maybe I just want to add a prefix/suffix/part of an item to the kill ring. It is not possible, since evil people have broken the standard ... > >> and standard things like dired or the completion buffer > >> work in a similar way. > > RW> In calendar-mode it is not that way! And also not in > RW> completion buffers, rather than moving for a single char the > RW> selection moves to the next logical item! > > I meant up/down. I have nothing against left/right being rebound > too, as long as their bindings are reasonable and don't change my > window configuration, That is a good point. My window config is not changing as I have (setq tla-switch-to-buffer-mode 'single-window) > buffer contents, etc. In all the examples > (completions, dired, calendar) the arrow keys hold the movement-only > requirement. Calendar mode will change the buffer content, try it, go to the last currently visible date and move further on. Probably you are an calendar newbie or missed this. Also in the *tla-archives* buffer up/down will move two lines, is this not strange for you? Selecting the archive name is king of hard as you are forced to use other movement keys. This also holds for other tla buffers. > RW> My mood on xtla is, that it should make everyday life with > RW> tla easier, i.e. the fewer keys I need for doing daily work > RW> and the more intuitive bindings are the better it will be. > > Right! But *you* and *I* are personal preferences and this is what > `define-key' is for in your and my ~/.emacs (yes, I bind some xtla > commands to my own keys). _Fewer keys_ and _more intuitive_ is very > individual, so we must try to abandon our personal preferences and > stick to standard conventions. Everyone can bind the arrow keys to > whatever he wants, but getting rid of them is worse. Well my point is, what standard? In editing modes the cursor keys all do the same thing, but NOT in other modes. Rather than doing dumb cursor movement there they do LOGICAL moves. When I added those bindings I had this logical move in mind. > [Not that I think the whole issue of two arrow keys is so important > to spend long discussions about it. What I talk here about now is > how to design Emacs interfaces properly.] As I already said earlier, I have not problem making them optional or removing them at all, in fact its on my todo list. I just wanted to point out my view: 1) there is nothing like THE consistent behavior or an Emacs interface design guide. 2) reducing the overall work of an community it better than trying not to offend a few. 3) we could find more arguments for both of our positions and there is no right one. Well, sure personally we both think the other one is wrong ;c) So, let's focus on more important things now. Robert
