Tony Mechelynck <[email protected]> wrote: > > On 04/07/09 14:31, J.A.J. Pater wrote: >> Tony Mechelynck wrote: >> Sure one could get used to it! >> But d(elete) p(aste) y(ank) are sort of intuitive. >> But it is counter intuitive to use a key which is placed (more to the) >> right on the keyboard (lll) to go left >> and a key which is (more to the) left on the keyboard to go right (hhh). >> Which is even more so if you are used to the opposite behaviour! >> Like p doing yank (instead of paste) and y doing paste (instead of yank). >> >> [SNIP discussion about what is/isnt' intutive about h and l >> movement in a bidi terminal.] >> >> That would be nice! But I think there should be an option to make h and >> l movement unequivocal >> (like it is with gedit+ViGedit). >> And AFAIUI, it is because of these kind of discussions that Bram doesn't >> like the idea of a real-bidi gvim.
I think a bidi vim should have key strokes for both (a set of motion keystrokes that operate in logical order, and a set of keystrokes that operate in display order). If we consider gj and gk as the keystrokes for operating over display lines versus j and k for operating over logical lines, then the keystrokes for this purpose are actually pretty obvious. (gl is free for use for display order navigation, but unfortunately, gh seems to be taken already.) > I don't kow gedit, but IMHO it is already unequivocal, if we remember > that in Vim the cursor is always "on" a character, never "between" > characters, even in Insert mode where, in gvim, its "25% left-side > vertical bar" shape can make us believe that it is "between" the current > character cell and the one (if any) to its left, or "before" the whole > line if it's on the first character of a line. That actually helps a lot in figuring out where the cursor will go next in logical order. When I have an isolated hebrew word in an English sentence, I always have a hard time in editors where the cursor is between letters knowing whether the cursor is logically after or before the Hebrew word, when it is displayed immediately after the Hebrew word. > As long as true-bidi consoles are a rarity, there is no urgency for a > true-bidi gvim, but I suppose that some years from now, all console > terminals will behave like mlterm, and by then there could be some > demand for a true-bidi gvim. I expect that true-bidi gvim and true-bidi > Console vim will behave the same way, but I suppose that that is still > several years in the future. Actually, if we were to explore the possiblities for a true-bidi (g)vim that didn't depend on a bidi terminal, I think we could come up with a much better and much more intuitive bidi editor than the existing editors. (For examples of why I think so, see above.) --Ken -- Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory. Department of Computer Science. Illinois Institute of Technology. http://www.iit.edu/~kbloom1/ --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
