Re: Fixed issue with langmap
Any comments on the patch? -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Fixed issue with langmap
It seems the Windows gVim build (7.2.267) is not affected of this issue. All the examples above works well with this langmap: Yes, I think the issue is in gtk+ behavior. (I even think it's not bug but a feature since, in general, it allows using sequences like ^russian letter). I've looked through geany sources and have found nothing concerning keymaps. Geany works because its keybindings are set via gtk accelerators and the layouts are processed inside gtk. But in gtk the task is somewhat different from what we need. In gtk the bindings are known and when a key is pressed we just have to compare the new key with all registered accelerators to find the actual one. In gvim we have to translate the pressed key without knowing whether the key is registered in gvim (and gvim knows how to process it) or not, so we have to go another way. The patch below fixes the issue for me. In the patch we use gdk_keymap_translate_keyboard_state() just to know the current level, and then use gdk_keymap_get_entries_for_keycode() to get the list of keys and keyvals with the same keycode as the pressed key. Then we just use the first key with the same level as the pressed one, from range 0x20 to 0x7f. Can it be commited to vim repository? -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php diff -Napur vim72.orig/src/gui_gtk_x11.c vim72/src/gui_gtk_x11.c --- vim72.orig/src/gui_gtk_x11.c 2010-06-18 00:22:25.0 +0400 +++ vim72/src/gui_gtk_x11.c 2010-06-18 00:21:34.0 +0400 @@ -993,8 +993,36 @@ key_press_event(GtkWidget *widget UNUSED guint state; char_u *s, *d; +#ifdef HAVE_GTK2 +gint n_entries; +GdkModifierType consumed; +guint *keyvals; +gint level; +GdkKeymapKey *keys; +#endif + key_sym = event-keyval; state = event-state; + +#ifdef HAVE_GTK2 +if (event-state (GDK_CONTROL_MASK | GDK_MOD1_MASK | GDK_MOD4_MASK) + gdk_keymap_translate_keyboard_state (NULL, event-hardware_keycode, +event-state, event-group, +NULL, NULL, level, consumed) + gdk_keymap_get_entries_for_keycode (NULL, event-hardware_keycode, + keys, keyvals, n_entries)) +{ +for (i = 0; i n_entries; i++) +if (level == keys[i].level + keyvals[i] = 0x20 keyvals[i] 0x80) +{ +key_sym = keyvals[i]; +state = event-state ~consumed; +break; +} +} +#endif + #ifndef HAVE_GTK2 /* deprecated */ len = event-length; g_assert(len = sizeof(string));
Re: Fixed issue with langmap
I don't think this is the right solution. Any key typed with CTRL would be affected. That's exactly as it supposed to work in the patch. I think you need to find a way to produce Esc in your russian layout. Yes, but not only Esc. All the keybindings with Ctrl key don't work, such as completion (^n, ^p, ...), editing (^w, ^u). But now I think the right solution is not to use langmap for such translation, but just (somehow) ignore the current layout just like it's done in the console version (vim). I tried geany (and kate), and there Ctrl with russian letter acts exactly like if Ctrl is pressed with the corresponding english letter (for example, ^т acts as ^n). I'll try to investigate how geany does that. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Fixed issue with langmap
Hi! I use vim-7.2.441 and I use vim's great langmap feature when writing russian texts. But when I try pressing ^[ to exit insert mode (or ^O to exit it temporarily) in russian xkb layout I got `х' (the russian character placed at the same key as `[') inserted instead of exiting. The following patch fixes the issue (besides Control it also processes Alt and Win keys in similar way). Can it be commited to vim repository? diff -Napur vim72.orig/src/gui_gtk_x11.c vim72/src/gui_gtk_x11.c --- vim72.orig/src/gui_gtk_x11.c2010-06-01 13:43:45.0 +0400 +++ vim72/src/gui_gtk_x11.c 2010-06-01 13:45:59.0 +0400 @@ -878,6 +878,9 @@ keyval_to_string(unsigned int keyval, un uc = gdk_keyval_to_unicode(keyval); if (uc != 0) { +if (state (GDK_CONTROL_MASK | GDK_MOD1_MASK | GDK_MOD4_MASK)) +LANGMAP_ADJUST(uc, TRUE); + /* Check for CTRL-foo */ if ((state GDK_CONTROL_MASK) uc = 0x20 uc 0x80) { -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.2.315 bug (with a fix) - Unable to close a fold when foldmethod=syntax
Hmm... I've just found a case on which my patch fails (as well as unpatched vim). I attach the updated test case but it has (now) incorrect title and isn't finished yet. It seems that in the vim-7.2-fold_o.patch patch while (!got_int fline.lnum 0 (!fline.start || fline.lvl != lvl)) whould be at least replaced by while (!got_int fline.lnum 0 (!fline.start || fline.lvl != 1)) to work properly since changing a line may change all the parents' fold levels. But I guess that will be much slower. It would probably be faster to use foldFind() for the similar purpose but the solution will still be slower than the current (fline.lvl != lvl) situation. I hope someone can find a better fix. -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php test70.in Description: Binary data test70.ok Description: Binary data
Vim 7.2.315 bug (with a fix) - Unable to close a fold when foldmethod=syntax
Hello! I think (well, I'm sure) I found a bug in vim when using foldmethod=syntax (both FEAT_SYN_HL and FEAT_FOLD are enabled). BRIEF: I attached two unified patches that should be applied after applying all the upstream patches from 7.2.001 to 7.2.315 to fix the issue (the bug exists in plain vim-7.2 without patches 1-315 as well though). vim-7.2-fold_o-test.patch - tests whether the bug exists vim-7.2-fold_o.patch - fixes the issue. I was unable to create an empty file in the patch (I probably should read diff's man page) so after applying fold_o-test patch you should create the empty file vim72/src/testdir/test70.ok for the new test to pass successfully. I set fml=3 in the test patch to break the solutions that will fix the issue without a loop. Will the fix get into vim upstream patches? :) DETAILS: I have a syntax region with ending match ^$ (empty line), and foldminlines is set to 1 (the default). If I enter the line matching the starting match and then press Enter without leaving insert mode then a second line appears which is empty. Since both lines were modified by pressing enter vim checks whether they (both) should have non-zero foldlevel. Vim thinks that the second line (being empty) closes the region so both lines get foldlevel=0 (since only the first one should belong to a fold and 1-line folds are disabled with fml=1). Then I (still without leaving insert mode) enter a character (for example, a space) making the second line non-empty. Now it doesn't match the ending region match anymore and the region is not closed by the second line and vim checks whether the _modified_ line should have non-zero fold, discovers that yes, it should, and marks the second line as _starting_ the fold with foldlevel=1. If vim look at the first line now it would see it has non-zero foldlevel as well (since the block contains more than 1 line now) and understand that it's the first line that should be marked as starting the fold. But it doesn't look above (it just checks if the modified (the second) line belongs to a fold by calling findFold but the fold has just been created and therefore doesn't appear in the array findFold acts on). The similar issue appears for more than two lines if foldminlines greater than 1. The issue doesn't appear if one enters a non-zero first line and then (having left insert mode) breaks it in the middle with ienter because in this case vim will check both modified lines and the second line isn't empty, so vim understands the fold should be started at the first line. -- Vladimir -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.phpdiff -Naur vim72.orig/src/fold.c vim72/src/fold.c --- vim72.orig/src/fold.c 2009-12-07 23:38:53.0 +0300 +++ vim72/src/fold.c 2009-12-07 23:40:29.0 +0300 @@ -2254,6 +2254,17 @@ if (fline.lvl = 0) break; } + + if (foldlevelSyntax == getlevel) + { + int lvl = fline.lvl; + while (!got_int fline.lnum 0 (!fline.start || fline.lvl != lvl)) + { + lvl = fline.lvl; + fline.lnum--; + getlevel(fline); + } + } } /* diff -Naur vim72.orig/src/testdir/Makefile vim72/src/testdir/Makefile --- vim72.orig/src/testdir/Makefile 2009-12-08 19:02:45.0 +0300 +++ vim72/src/testdir/Makefile 2009-12-08 18:16:56.0 +0300 @@ -23,7 +23,7 @@ test54.out test55.out test56.out test57.out test58.out \ test59.out test60.out test61.out test62.out test63.out \ test64.out test65.out test66.out test67.out test68.out \ - test69.out + test69.out test70.out SCRIPTS_GUI = test16.out diff -Naur vim72.orig/src/testdir/test70.in vim72/src/testdir/test70.in --- vim72.orig/src/testdir/test70.in 1970-01-01 03:00:00.0 +0300 +++ vim72/src/testdir/test70.in 2009-12-08 18:55:11.0 +0300 @@ -0,0 +1,13 @@ +Test for a syntax fold being created correctly when an ending region match becomes not ending + +STARTTEST +:%d +:sy region r start=^s end=^$ fold +:se fdm=syntax +:se fml=3 +ishould be deleted + should be deleted + should be deleted + should and will be deletedzcGdd:wq test.out +ENDTEST +
Re: New feature: cursor at the beginning of tab character in normal mode
On Sat, 4 Oct 2008 at 02:37 Richard Hartmann wrote: I would suggest adapting the helpfiles to reflect the above, though. I found the section called VIEWING TABS in the chapter 05.7 of the standard vim manual. It contains the following: :set listchars=tab:-,trail:- with the explanation what the setting does. However there is no word concerning cursor position there. That chapter seems to be the best place to write how to emulate the standard cursor behaviour in vim. But: 1. it would be difficult for a novice who came from another editor to find that place and he/she won't probably find the solution of the problem. Are there better places? 2. is the solution in question correct on all platforms/terminals so that we are allowed to add such a comment to the help file? It works on x86 and x86_64 in xterm and linux terminals but what about others? Vladimir, I suspect Bram would accept a patch against the help. Bram, would you? -- Vladimir --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
New feature: cursor at the beginning of tab character in normal mode
Hello! A few days ago I wrote the following to [EMAIL PROTECTED]: I'd like to switch to vim but there is an annoying issue with it that I couldn't solve. When the cursor is at a tab character most editors display the cursor at the beginning of the interval the tab character occupies as follows (_ is the cursor): _ if (a c) ... Vim does the same in insert or replace mode. But in normal mode the cursor is displayed at the end of the tab character: _if (a c) ... Is there a way to make vim show the cursor at the beginning of a tab character in normal mode as it does in insert mode? I tried searching in Google but found nothing unfortunatelly :( Then I got a reply that said it's impossible without vim code modification so I decided to find out how to fix that. I seem to find the solution (the patch is at the end of this email) but it is so simple that I can't understand why it hasn't been done yet (since I know several people that are irritated by this feature of vim). I guess this mailing list is the best place to ask whether I miss anything. Here are my questions: 1. Are there any obvious problems/bugs with the patch itself? In other words, does it breaks anything very basic so that it definitely breaks some basic functionality or some plugins? 2. If there are no problems with it, do you have any wishes to apply it to the trunk? (And what the reasons for not doing so?) If so, I would add an option called, say, cursorattabstart that will trigger the new behaviour and resend the patch here for anyone of you to commit. -- Vladimir The patch follows (should be applied to just unpacked vim-7.2.tar.bz2): diff -Naur vim72.orig/src/charset.c vim72/src/charset.c --- vim72.orig/src/charset.c2008-07-24 18:59:44.0 +0400 +++ vim72/src/charset.c 2008-10-02 21:44:18.0 +0400 @@ -1333,7 +1333,7 @@ if (start != NULL) *start = vcol + head; if (end != NULL) - *end = vcol + incr - 1; + *end = vcol; if (cursor != NULL) { if (*ptr == TAB @@ -1345,7 +1345,7 @@ (*p_sel == 'e' || ltoreq(*pos, VIsual))) #endif ) - *cursor = vcol + incr - 1; /* cursor at end */ + *cursor = vcol; /* cursor at end */ else *cursor = vcol + head; /* cursor at start */ } --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---