Re: Bug report: display bug with accented characters and completion menu
Gombault Damien wrote: I noticed a display bug with the completion menu. If accented characters appears in the completion menu, some others characters from the edited file appears too in the menu ! It's quite difficult to explain so I've made some screenshots. You can also notice these bad characters appears only if a filename is displayed next to the word. Screenshots taken from Ubuntu Feisty (VIM 7.0-164) : - GVIM (GTK+) with custom config : http://img139.imageshack.us/img139/21/vim1et2.png - GVIM (GTK+) with custom config (another colorscheme) : http://img115.imageshack.us/img115/6541/vim2jb9.png - GVIM (GTK+) with default config : http://img163.imageshack.us/img163/2661/vim3fp1.png - VIM (gnome-terminal) with default config : http://img53.imageshack.us/img53/6716/vim4xk5.png I noticed this bug with : - GVIM (GTK+) 7.0-164 (Ubuntu Feisty) - VIM (gnome-terminal) 7.0-164 (Ubuntu Feisty) - GVIM (GTK+) 7.0-201 (Gentoo) - GVIM (x11) 7.0-201 (Gentoo) (I have not tested x11 on other builds) - VIM (konsole) 7.0-201 (Gentoo) - GVIM (GTK+) 7.0-219 (custom build on Gentoo) - VIM (konsole) 7.0-219 (custom build on Gentoo) I have NOT noticed this bug with : - GVIM (win32) 7.0-219 (Cream build without Cream config) A few questions: - What is 'encoding' set to? - What is the actual text in the entries with problems? Give this byte-for-byte. You may need to insert an entry to find out. - Can you reproduce it by setting 'omnifunc' to a simple function that returns a fixed list of text entries? If so, please give us the script with this. Otherwise, give us a text file to reproduce the problem. - The entries in the menu appear not to be sorted. How did this happen? - What did you type to get to these screenshots? -- When I die, I want a tombstone that says GAME OVER - Ton Richters /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Bug report: display bug with accented characters and completion menu
A few questions: - What is 'encoding' set to? - What is the actual text in the entries with problems? Give this byte-for-byte. You may need to insert an entry to find out. - Can you reproduce it by setting 'omnifunc' to a simple function that returns a fixed list of text entries? If so, please give us the script with this. Otherwise, give us a text file to reproduce the problem. - The entries in the menu appear not to be sorted. How did this happen? - What did you type to get to these screenshots? My system is UTF-8, so 'encoding' is also set to 'utf-8'. On the screenshot, the file was wrotten in 'latin1' charset. After some tests, I noticed this bugs seems only appears when 'encoding' and 'fileencoding' are not the same. Finally, I could get this bug on win32 : I set 'encoding' to 'utf-8' then open some 'latin-1' files. I wrote two very simple C++ file to help you to reproduce the bug. These two files are written in 'latin1' charset. Their content is simple C++ comments containing French text with accented characters like é, è, à, etc. Put the two files in the same directory. Then open gvim and set your 'encoding' to 'utf-8'. Edit the '2.cpp' file. Verify that 'fileencoding' is set to 'latin1'. Insert a new line between #include and the begin of the /* comment. (o key) Then type CTRL+x CTRL+i and the include completion menu appears like this : http://img131.imageshack.us/img131/4117/vim5ls3.png Another test : 'encoding' = latin1 and utf-8 texts, you get this : http://img78.imageshack.us/img78/483/vim6nt2.png Accents are not correctly displayed. The completion menu uses 'encoding' to display its text. When you edit a file, the buffer is converted to the current encoding (the [converted] message). When you use the completion menu with current buffer words, accented characters will be correctly displayed. But if you use completion menu with words in other files (like with include completion) with a different fileencoding than your current buffer encoding, accented characters will not be displayed correctly because they are not converted to the current encoding. So words from other files should be converted to the current buffer 'encoding' before display them in the completion menu. That will certainly fix this problem. Regards. -- Gombault Damien | Powered by Gentoo Linux AMD64 texts.tar.gz Description: application/tgz
Re: Bug report: display bug with accented characters and completion menu
Another test with 3 files : 1.cpp : UTF-8 file with French accented characters. 2.cpp : the same file but with Latin-1 charset. 3.cpp : a file to test 'include' completion. Yes, it's a bit strange because it's not a great idea to work with different encodings. But it shows the problem. :) Put the 3 files in the same directory. Run Gvim, set your 'encoding' to 'latin1'. Edit 3.cpp file. Type, before the comment, CTRL-x CTRL-i for 'include' completion. Words from 1.cpp are not displayed in the completion menu because words are not converted to the current encoding. Run Gvim, set your 'encoding' to 'utf-8'. Edit 3.cpp file. Type, before the comment, CTRL-x CTRL-i for 'include' completion. Words from 2.cpp are displayed but you have a display bug with the completion menu because words are not converted to the current encoding. Regards. -- Gombault Damien | Powered by Gentoo Linux AMD64 another_test.tar.gz Description: application/tgz
Re: Bug report: display bug with accented characters and completion menu
Gombault Damien wrote:
A few questions:
- What is 'encoding' set to?
- What is the actual text in the entries with problems? Give this
byte-for-byte. You may need to insert an entry to find out.
- Can you reproduce it by setting 'omnifunc' to a simple function that
returns a fixed list of text entries? If so, please give us the
script with this. Otherwise, give us a text file to reproduce the
problem.
- The entries in the menu appear not to be sorted. How did this happen?
- What did you type to get to these screenshots?
My system is UTF-8, so 'encoding' is also set to 'utf-8'. On the screenshot,
the file was wrotten in 'latin1' charset.
After some tests, I noticed this bugs seems only appears when 'encoding'
and 'fileencoding' are not the same. Finally, I could get this bug on win32 :
I set 'encoding' to 'utf-8' then open some 'latin-1' files.
I wrote two very simple C++ file to help you to reproduce the bug. These two
files are written in 'latin1' charset. Their content is simple C++ comments
containing French text with accented characters like é, è, à, etc.
Put the two files in the same directory.
Then open gvim and set your 'encoding' to 'utf-8'.
Edit the '2.cpp' file.
Verify that 'fileencoding' is set to 'latin1'.
Insert a new line between #include and the begin of the /* comment. (o key)
Then type CTRL+x CTRL+i and the include completion menu appears like this :
http://img131.imageshack.us/img131/4117/vim5ls3.png
Another test :
'encoding' = latin1 and utf-8 texts, you get this :
http://img78.imageshack.us/img78/483/vim6nt2.png
Accents are not correctly displayed.
The completion menu uses 'encoding' to display its text.
When you edit a file, the buffer is converted to the current encoding (the
[converted] message). When you use the completion menu with current buffer
words, accented characters will be correctly displayed.
But if you use completion menu with words in other files (like with include
completion) with a different fileencoding than your current buffer encoding,
accented characters will not be displayed correctly because they are not
converted to the current encoding.
So words from other files should be converted to the current buffer
'encoding' before display them in the completion menu. That will
certainly fix this problem.
Thanks for the clear example. I'm now able to reproduce the problem.
There are actually two problems. One is that text with non-printable
characters causes trouble in the popup menu. I'll fix that now (see
patch below).
The other is that completions obtained from a file in another encoding
result in text with the wrong encoding. That's difficult to fix. It
would require loading the file as if editing it, so that the encoding is
detected. I'll put this in the todo list, but don't expect it to be
fixed soon.
*** ../vim-7.0.219/src/charset.cTue Apr 18 00:04:40 2006
--- src/charset.c Sat Mar 24 21:10:37 2007
***
*** 317,323
}
}
! #if defined(FEAT_EVAL) || defined(FEAT_TITLE) || defined(PROTO)
/*
* Translate a string into allocated memory, replacing special chars with
* printable chars. Returns NULL when out of memory.
--- 317,324
}
}
! #if defined(FEAT_EVAL) || defined(FEAT_TITLE) || defined(FEAT_INS_EXPAND) \
! || defined(PROTO)
/*
* Translate a string into allocated memory, replacing special chars with
* printable chars. Returns NULL when out of memory.
*** ../vim-7.0.219/src/popupmnu.c Tue Aug 22 21:51:18 2006
--- src/popupmnu.c Sat Mar 24 21:07:39 2007
***
*** 280,287
w = ptr2cells(p);
if (*p == NUL || *p == TAB || totwidth + w pum_width)
{
! /* Display the text that fits or comes before a Tab. */
! screen_puts_len(s, (int)(p - s), row, col, attr);
col += width;
if (*p != TAB)
--- 280,299
w = ptr2cells(p);
if (*p == NUL || *p == TAB || totwidth + w pum_width)
{
! /* Display the text that fits or comes before a Tab.
!* First convert it to printable characters. */
! char_u *st;
! int saved = *p;
!
! *p = NUL;
! st = transstr(s);
! *p = saved;
! if (st != NULL)
! {
! screen_puts_len(st, (int)STRLEN(st), row, col,
! attr);
! vim_free(st);
! }
col += width;
if (*p != TAB)
--
Dreams are free, but there's a small charge for alterations.
/// Bram
Re: Suggestion: numbers for completion menu?
On 1/23/07, Marc Weber [EMAIL PROTECTED] wrote:
It would be convinient to get an item from the completion menu faster
than downdown .. or typing more characters.
What do you think of prepending each item with a number and add a
key-mapping
c-iidx to get the idxth item?
so c-i4 would select the 4th.
Would it be convinient to add another mapping space for completions?
mnoremap 2 c-i2 ?
m = omni completion _m_enu ?
Or is there another easy way to achieve this ?
I've already mentioned this here:
http://thread.gmane.org/gmane.editors.vim.devel/15344/focus=15344
Here's the mappings:
for digit in [1, 2, 3, 4, 5, 6, 8, 9]
execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
\ repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
endfor
However, what I also mention there is that the completion menu
flickers like mad if you use this. It shouldn't be redrawn quite as
often as it currently is, and not as much of it either.
nikolai
Suggestion: numbers for completion menu?
It would be convinient to get an item from the completion menu faster than downdown .. or typing more characters. What do you think of prepending each item with a number and add a key-mapping c-iidx to get the idxth item? so c-i4 would select the 4th. Would it be convinient to add another mapping space for completions? mnoremap 2 c-i2 ? m = omni completion _m_enu ? Or is there another easy way to achieve this ? Marc
should space exit completion menu?
All, Recently I was appreciating the beauty of using pumvisible() to setup all kinds of mappings for the completion menu (ex. enter to do c-y). I noticed when messing around with all of that, that space actually exits the menu. Is this the desired behavior? Sometimes I am doing line completion (c-x,c-l) and I type part of the line to narrow the matches; however, space just exits the completion. If someone wants space to behave this way, couldn't he/she just make the mapping? --Matt P.S. Another example is c-xc-f; and some of the filenames have spaces in them. The menu exits before you can make your selection.
Flickering of completion menu
Hi!
As you've probably all noticed the completion menu flickers when you
move through the items rapidly. Why is this? Is it really necessary
to redraw the whole completion menu when it really only should require
redrawing the item previously selected and the item selected now [1]?
Anyway, would this be possible to implement?
Also, here's a set of mappings that make the digits move their value
number of items down the completion list (if displayed):
for digit in [1, 2, 3, 4, 5, 6, 8, 9]
execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
endfor
(I guess this could be extended to include -n, for 1 = n = 9, which
would move n number of items upward. Any takers?)
It flickers like mad, but at least it goes a lot faster than holding
down CTRL-N or CTRL-P.
nikolai
[1] Excepting the case where one begins to scroll in the menu, when
all items need to be redrawn, as they move up or down one step - which
leads to a second question, wouldn't it be a lot more economical to
scroll like half a menu or something, so that scrolling wouldn't
require so many redraws? Or at least utilize the terminal codes that
enable scrolling in a buffer to be done with only redrawing the first
or last line when scrolling by a single line in a buffer?
Re: Flickering of completion menu
I would also love a flicker-less popup menu. I use the completion
excessively, since I've found it makes coding faster and less error
prone. I noticed the menu only flickers in some cases.
--Matt
On Wed, Nov 08, 2006 at 10:10:09AM +1100, Peter Hodge wrote:
Hello,
I agree, it would be great if the popup-menu could be optimized. One of the
best features of Vim is that is fast enough to keep up with my keystrokes
(many
editors will begin to 'lag' when given commands too rapidly, and I have to
stop
and wait for them). I often have to slacken my pace when it comes to Vim's
popup-menu, because it takes at least .2 seconds to redraw each time I press
CTRL-N.
regards,
Peter
--- Nikolai Weibull [EMAIL PROTECTED] wrote:
Hi!
As you've probably all noticed the completion menu flickers when you
move through the items rapidly. Why is this? Is it really necessary
to redraw the whole completion menu when it really only should require
redrawing the item previously selected and the item selected now [1]?
Anyway, would this be possible to implement?
Also, here's a set of mappings that make the digits move their value
number of items down the completion list (if displayed):
for digit in [1, 2, 3, 4, 5, 6, 8, 9]
execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
endfor
(I guess this could be extended to include -n, for 1 = n = 9, which
would move n number of items upward. Any takers?)
It flickers like mad, but at least it goes a lot faster than holding
down CTRL-N or CTRL-P.
nikolai
[1] Excepting the case where one begins to scroll in the menu, when
all items need to be redrawn, as they move up or down one step - which
leads to a second question, wouldn't it be a lot more economical to
scroll like half a menu or something, so that scrolling wouldn't
require so many redraws? Or at least utilize the terminal codes that
enable scrolling in a buffer to be done with only redrawing the first
or last line when scrolling by a single line in a buffer?
Send instant messages to your online friends http://au.messenger.yahoo.com
Re: Flashing completion menu
Robert Webb wrote: When I use Ctrl+P to complete a word in insert mode, then hit space or Esc because I'm happy with the match, not waiting for the menu to pop up with every possible match (ie while it's still searching through header files etc), the menu then still flashes up briefly, even though the search has now been cancelled. It's visually distracting and unnecessary. Can it be avoided? I'll see if that can be avoided with a simple and predictably harmless change. -- Hacker: Someone skilled in computer programming (good guy). Cracker: A hacker that uses his skills to crack software (bad guy). /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Flashing completion menu
Robert Webb wrote: When I use Ctrl+P to complete a word in insert mode, then hit space or Esc because I'm happy with the match, not waiting for the menu to pop up with every possible match (ie while it's still searching through header files etc), the menu then still flashes up briefly, even though the search has now been cancelled. It's visually distracting and unnecessary. Can it be avoided? Thanks, Rob. -- Robert Webb [EMAIL PROTECTED], MineSweeper3D - Take Minesweeper to a whole new dimension! http://www.software3d.com/Mines3D Sure. Add the following line to your .vimrc to turn it off: set completeopt-=menu For detail, see: :h completeopt HTH -- Guopeng
RE: Flashing completion menu
When I use Ctrl+P to complete a word in insert mode, then hit space or Esc because I'm happy with the match, not waiting for the menu to pop up with every possible match (ie while it's still searching through header files etc), the menu then still flashes up briefly, even though the search has now been cancelled. It's visually distracting and unnecessary. Can it be avoided? Sure. Add the following line to your .vimrc to turn it off: set completeopt-=menu I didn't want to get rid of the menu altogether though, just for it not to appear briefly when further typing had already cancelled the search. Rob. -- Robert Webb [EMAIL PROTECTED], Want to make polyhedra? http://www.software3d.com/Stella.html
Re: completion menu
Bram Moolenaar wrote: Georg Dahn wrote: Ok, let's assume there are several completions, such that you get a menu with C-N. Then if you move the selection with the cursor keys and press Enter, the selected item is being chosen. If you do the same with C-N (instead of using cursor keys), Enter inserts a new line. I think, this is confusing. Is this behavior intentional or is it a bug? This is intentional, it was discussed recently. This is a compromise between different expectations from different users. People who used CTRL-N/CTRL-P in Vim 6.4 expect the Enter to be inserted, since that is what happened in older versions. People who are using cursor keys to select an item in the popup menu mostly expect Enter to accept the selected match. That's why the behavior of Enter depends on what you did earlier. Hi, I also think here is a little confusing. Since the user are selecting menu items with C-N/C-P, and at this time, Enter is normally assumed as a confirm of the selection. And I think it is very common a user interface convention. I think it is worth breaking the compatibility between vim6.x and vim7 since there is no completion menu in vim6.x. Best regards, Vincent
Re: completion menu
Georg Dahn wrote: Ok, let's assume there are several completions, such that you get a menu with C-N. Then if you move the selection with the cursor keys and press Enter, the selected item is being chosen. If you do the same with C-N (instead of using cursor keys), Enter inserts a new line. I think, this is confusing. Is this behavior intentional or is it a bug? This is intentional, it was discussed recently. This is a compromise between different expectations from different users. People who used CTRL-N/CTRL-P in Vim 6.4 expect the Enter to be inserted, since that is what happened in older versions. People who are using cursor keys to select an item in the popup menu mostly expect Enter to accept the selected match. That's why the behavior of Enter depends on what you did earlier. -- From know your smileys: |-(Contact lenses, but has lost them /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://www.ICCF.nl ///
