Strange redraw problem on x86-64 Linux

[Ron Aaron]

I'm using Frugalware x86-64 as my Linux distro on my server machine.

For some reason, gvim (compiled with --enable-features=big) has a very
strange redraw problem, which is that it doesn't properly redraw the
screen if the vim window is obscured, and requires ^L to redraw.

The problem also seems to manifest itself when doing any colon command, in
that the first word on the command line shows up, but subsequent words are
not drawn visibly (though they are there).

A further problem is that the fonts are ragged rather than smooth.

The same vim (e.g. compiled from the same source) on my Frugalware x86
32-bit on my laptop works fine.

So I don't know if there is some strangeness about the distro or whether
there may be a 64bit linux problem.

Does anyone have ideas on how to narrow down the problem?

Re: Strange redraw problem on x86-64 Linux

[Ron Aaron]

 I'm using Frugalware x86-64 as my Linux distro on my server machine.

 For some reason, gvim (compiled with --enable-features=big) has a very
 strange redraw problem, which is that it doesn't properly redraw the
 screen if the vim window is obscured, and requires ^L to redraw.

I should add that the system was using xorg 7.1, which I downgraded to 7.0
based upon some comments on the Frugalware forum -- but that did not
change the problem.

I've got GTK2 GUI, X11.  The GTK version on the machine is 2.4

matchparen bug?

[Jared]

I think I found a bug in in the matchparen feature of Vim 7.  I'm using the
7.0 binary release for Windows XP.

When I'm in Insert mode and moving across lines, if the cursor passes over a
paren (defined here as any character in the matchpairs option), the cursor
will stay in the column position when moving to the next line.  See the
following code for an example:

let g:loaded_autoit_completion = 1
let s:cache_name = []
 This function is used for the 'omnifunc' option.

Now, if my cursor is on the '1' in the first line and I press down twice,
I'd expect the cursor to end up on the 'o' in 'omnifunc' in the third line.
 However, if I'm in Insert mode and matchparen is active, then my cursor
will instead end up on the 'e' in 'used'.

If I'm in Normal mode, this does not happen.  If I issue :NoMatchParen, this
does not happen.  However, if I reissue :DoMatchParen and enter Insert mode,
the problem reoccurs.

Can anyone else confirm this?  I do have a lot of customizations in my vimrc
files, so I'm not entirely sure it's not a problem that I'm causing myself,
but I've reviewed my vimrc pretty carefully and I can't find anything that
should cause this issue.  If anyone else would like to check, you can find
both vimrc files here:

http://www.legroom.net/~jbreland/transfer/Packages/Vim_7.0/support/_vimrc
http://www.legroom.net/~jbreland/transfer/Packages/Vim_7.0/support/_gvimrc

Please let me know if this is an actual Vim bug.  Thanks.

--
Jared

Re: Strange redraw problem on x86-64 Linux

[Ron Aaron]

 I'm using Frugalware x86-64 as my Linux distro on my server machine.

Aha!  When I change to a bitmap font the display problem seems to go away!
 TrueType and PS fonts look ugly.

Re: matchparen bug?

[Ilya]

Jared wrote:

[...]
When I'm in Insert mode and moving across lines, if the cursor passes over a
paren (defined here as any character in the matchpairs option), the cursor
will stay in the column position when moving to the next line.  See the
following code for an example:

let g:loaded_autoit_completion = 1
let s:cache_name = []
 This function is used for the 'omnifunc' option.

Now, if my cursor is on the '1' in the first line and I press down twice,
I'd expect the cursor to end up on the 'o' in 'omnifunc' in the third line.
 However, if I'm in Insert mode and matchparen is active, then my cursor
will instead end up on the 'e' in 'used'.

[...]

I do not have this bug.

I'm having

VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-17

that I've compiled myself from current CVS version.

Matchparen.vim is dated 2006 May 11.

Re: Netbeans Interface

[Sebastian Menge]

Am Donnerstag, den 01.06.2006, 16:08 +0200 schrieb Sebastian Menge:
 Or does it mean that i have to compile my own vim with disabled
 gui-support and enabled netbeans?

I forgot to mention what I want to do ...

I want to communicate via the netbenas-protocol with a vim in a
terminal. That vim should not have any X or GUI features.

Is that possible?

If yes, how would I have to ./configure vim? I tried

./configure --enable-gui=no --enable-netbeans

But it doesnt seem to work.

On my ubuntu box 'vim --version' has +netbeans_intg and +X11, is linked
against gnome-libs. If I start my homebrewn netbeans-server, and then
'vim -nb', nothing happens. If I type :gui in the same vim-instance, it
immediatly connects to the server and executes the test command.

Thanks to anyone helping me with this.

regards, Sebastian.

PS: my test server:

start it first, then 'gvim -nb'

---
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;

public class VimNBApp {

  private static ServerSocket socket;
  private static Socket vimSocket;

  public static void main(String[] args) {
  try {
socket = new ServerSocket(3219);
System.out.print(Server waiting for connection ...);
vimSocket = socket.accept();
System.out.println( connected.);

PrintWriter out = 
new PrintWriter(vimSocket.getOutputStream(), true);
BufferedReader in = 
new BufferedReader(
new InputStreamReader(vimSocket.getInputStream()
));
  
//handshake
System.out.println(in.readLine());
System.out.println(in.readLine());
System.out.println(in.readLine());

String cmd = 1:editFile!123 \/tmp/test.txt\; 
out.println(cmd);
System.out.println(sent: +cmd);

  } catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
  }
}
  }
-

Re: Netbeans Interface

[Sebastian Menge]

Am Donnerstag, den 01.06.2006, 12:49 -0700 schrieb Xavier de Gaye:
 Netbeans can only be used with gvim compiled either with GTK, Motif, or
 with the Windows version of gvim. It cannot be used with plain vim
 running in a terminal.

No workaround? The communication itself does not need the gui. 

Im no c-programmer, but that sounds, as if one would have to change
little in netbeans.c .. !?

Seb.

Re: Netbeans Interface

[Xavier de Gaye]

--- Sebastian Menge [EMAIL PROTECTED] wrote:

 Under *netbeans-configure* it is said, that only gvim is supported.

 Does that mean i never can use the netbeans-interface in a terminal
 (since the dependency on gvim is hardcoded in netbeans.c)?

 Or does it mean that i have to compile my own vim with disabled
 gui-support and enabled netbeans?

Netbeans can only be used with gvim compiled either with GTK, Motif, or
with the Windows version of gvim. It cannot be used with plain vim
running in a terminal.

Xavier


--
http://clewn.sourceforge.net   gdb support in Vim

Re: Netbeans Interface

[Xavier de Gaye]

--- Sebastian Menge [EMAIL PROTECTED] wrote:
 Am Donnerstag, den 01.06.2006, 12:49 -0700 schrieb Xavier de Gaye:
  Netbeans can only be used with gvim compiled either with GTK, Motif, or
  with the Windows version of gvim. It cannot be used with plain vim
  running in a terminal.

 No workaround? The communication itself does not need the gui.

 Im no c-programmer, but that sounds, as if one would have to change
 little in netbeans.c .. !?

Vim, when run in a terminal is designed to work in a very poor
environment, and there is only one thread of execution.  On the other
hand, the netbeans interface has been designed with a GUI in mind (since
it was meant to be used by IDEs) and registers a call-back that is used
to process the received netbeans messages.  So, to port the netbeans
interface to Vim in terminal mode is not simple. One would have probably
to setup a hook in the main loop (RealWaitForChar() in os_unix.c), that
is, right in the deep heart of Vim.
Too bad.

Xavier


--
http://clewn.sourceforge.net   gdb support in Vim

Redraw bug on WinXP with non-GUI tab line.

[Ilya]

Hello.

I've found bug in vim version

VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-17

In case incremental search is on, tab line some times is not visible.

Steps to reproduce:

gvim -u NONE -U NONE
:e 1.txt
:set is
:tab sp
/s

after hitting 's' text is scrolled to a line containing 'six1' and 
tabline is empty - cleared with background color.
1
2
3
4
5
6
7
8
9
one1
10
11
12
13
14
15
16
17
18
19
two1
20
21
22
23
24
25
26
27
28
29
three1
30
31
32
33
34
35
36
37
38
39
four1
40
41
42
43
44
45
46
47
48
49
five1
50
51
52
53
54
55
56
57
58
59
six1
60
61
62
63
64
65
66
67
68
69
seven1
70
71
72
73
74
75
76
77
78
79
eight1
80
81
82
83
84
85
86
87
88
89
nine1
90
91
92
93
94
95
96
97
98
99
ten1
1
2
3
4
5
6
7
8
9
one2
10
11
12
13
14
15
16
17
18
19
two2
20
21
22
23
24
25
26
27
28
29
three2
30
31
32
33
34
35
36
37
38
39
four2
40
41
42
43
44
45
46
47
48
49
five2
50
51
52
53
54
55
56
57
58
59
six2
60
61
62
63
64
65
66
67
68
69
seven2
70
71
72
73
74
75
76
77
78
79
eight2
80
81
82
83
84
85
86
87
88
89
nine2
90
91
92
93
94
95
96
97
98
99
ten2

Re: Redraw bug on WinXP with non-GUI tab line.

[Eric Arnold]

It appears that the first key of any incremental search to a point far
enough down in the file (i.e. a page below the displayed area) will
cause it.  Typing any additional key brings the tabline back.

I fiddled around with TabLineSet.vim, but it appears that the bug is
in the code that decides whether to display either the default or
custom tabline.

On 6/1/06, Ilya [EMAIL PROTECTED] wrote:

Hello.

I've found bug in vim version

VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-17

In case incremental search is on, tab line some times is not visible.

Steps to reproduce:

gvim -u NONE -U NONE
:e 1.txt
:set is
:tab sp
/s

after hitting 's' text is scrolled to a line containing 'six1' and
tabline is empty - cleared with background color.


1
2
3
4
5
6
7
8
9
one1
10
11
12
13
14
15
16
17
18
19
two1
20
21
22
23
24
25
26
27
28
29
three1
30
31
32
33
34
35
36
37
38
39
four1
40
41
42
43
44
45
46
47
48
49
five1
50
51
52
53
54
55
56
57
58
59
six1
60
61
62
63
64
65
66
67
68
69
seven1
70
71
72
73
74
75
76
77
78
79
eight1
80
81
82
83
84
85
86
87
88
89
nine1
90
91
92
93
94
95
96
97
98
99
ten1
1
2
3
4
5
6
7
8
9
one2
10
11
12
13
14
15
16
17
18
19
two2
20
21
22
23
24
25
26
27
28
29
three2
30
31
32
33
34
35
36
37
38
39
four2
40
41
42
43
44
45
46
47
48
49
five2
50
51
52
53
54
55
56
57
58
59
six2
60
61
62
63
64
65
66
67
68
69
seven2
70
71
72
73
74
75
76
77
78
79
eight2
80
81
82
83
84
85
86
87
88
89
nine2
90
91
92
93
94
95
96
97
98
99
ten2

commandline window

[mzyzik]

All,

Is there an elegant way of checking if the current window is a command
line window other than seeing if the buffer name is command-line ?

--Matt

Re: commandline window

[Yegappan Lakshmanan]

Hi,

On 6/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

All,

Is there an elegant way of checking if the current window is a command
line window other than seeing if the buffer name is command-line ?



You can use the CmdwinEnter and CmdwinLeave autocmds and set
buffer-local variables.

- Yegappan