On 05/07/09 23:49, Ken Bloom wrote: > 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.)
AFAICT, g<Up> and g<Down> are equivalent to gj and gk. I suppose it would be possible to define g<Left> and g<Right> via a future patch implementing true-bidi in gvim; anyone preferring other keys or key combos could of course remap them. > >> 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 > Quite possibly. The problem, I think, would be to program the true-bidi capability without introducing bugs in what we already have. I suppose quite a lot of testing would be necessary before those changes become part of mainline Vim -- but I hope they eventually will. Best regards, Tony. -- %DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
