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
-~--~~~~--~~--~--~---
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 -~--~~~~--~~--~--~---
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: 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
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: 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
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
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
