Re: Very slow scrolling with gtk3

2016-09-30 9:51 GMT+09:00 Taylor Venable : > Thanks, but it seems I have been unclear. > > My problem is that, all other things being equal, scrolling through a > buffer in gvim is very sluggish using GTK+ 3, compared to using GTK+ 2. > This is not a problem that affects other

Re: [vim/vim] Fix systemlist() (#1135)

Hi thinca, 2016-9-30(Fri) 12:01:55 UTC+9 thinca: > @h-east Thank you for your advice! > > I updated the patch. You need select one of the two patches. I think the first one is good. > diff -ru vim.orig/src/testdir/Make_all.mak vim/src/testdir/Make_all.mak > ---

Re: [vim/vim] Fix systemlist() (#1135)

Hi thinca, 2016-9-30(Fri) 1:39:34 UTC+9 thinca: > :help systemlist() says: > > > > Output is the same as readfile() will output with {binary} argument > > set to "b". > > > > And :help readfile() says: > > > > When {binary} contains "b" binary mode is used: > > > When the last line

Re: Very slow scrolling with gtk3

Thanks, but it seems I have been unclear. My problem is that, all other things being equal, scrolling through a buffer in gvim is very sluggish using GTK+ 3, compared to using GTK+ 2. This is not a problem that affects other GTK+ 3 applications. My example using the output of seq was only to

Re: Very slow scrolling with gtk3

2016-09-30 5:01 GMT+09:00 Taylor Venable : > On Thursday, September 29, 2016 at 3:49:55 PM UTC-4, Taylor Venable wrote: > > I use some other GTK3 apps like Emacs with performance issues. > > I'm sorry, this should have said "WITHOUT performance issues." :-) > Really? I think

Re: Very slow scrolling with gtk3

On Thursday, September 29, 2016 at 3:49:55 PM UTC-4, Taylor Venable wrote: > I use some other GTK3 apps like Emacs with performance issues. I'm sorry, this should have said "WITHOUT performance issues." :-) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your

Re: Very slow scrolling with gtk3

On Thursday, September 29, 2016 at 2:17:45 PM UTC-4, Kazunobu Kuriyama wrote: > 2016-09-30 1:06 GMT+09:00 Taylor Venable : > Hi, my distribution (Arch Linux) just switched to using the GTK3 build of > gvim by default. But it behaves very poorly on my computer, the scroll speed

Patch 8.0.0019

Patch 8.0.0019 Problem:Test_command_count is old style. Solution: Turn it into a new style test. (Naruhiko Nishino) Use more assert functions. Files: src/Makefile, src/testdir/Make_all.mak, src/testdir/test_alot.vim, src/testdir/test_autocmd.vim,

Re: update to todo.txt

Hi Ben! On Do, 29 Sep 2016, Ben Fritz wrote: > On Tuesday, September 27, 2016 at 2:09:10 PM UTC-5, Christian Brabandt > wrote: > > -Using ":make" blocks Vim. Allow running one make in the background > > (if the -shell supports it), catch errors in a file and update the > > error list on the

Re: Very slow scrolling with gtk3

2016-09-30 1:06 GMT+09:00 Taylor Venable : > Hi, my distribution (Arch Linux) just switched to using the GTK3 build of > gvim by default. But it behaves very poorly on my computer, the scroll > speed is so slow that it's very difficult to use. With GTK2, everything is > fine.

Re: update to todo.txt

On Tuesday, September 27, 2016 at 2:09:10 PM UTC-5, Christian Brabandt wrote: > -Using ":make" blocks Vim. Allow running one make in the background (if the > -shell supports it), catch errors in a file and update the error list on the > -fly. A bit like "!make > file&" and repeating ":cf file".

Re: Possible problem when running a job immediately followed by a sleep

Santiago Alejandro Aguero wrote: > While I was trying to write some vim code for testing a (async) > functionality for Neomake plugin, I've noticed the following scenario: > > > - Having the following shell script (with errors): > > #!/bin/sh > > a='$var' > > foo( > > > - And the next vim

Patch 8.0.0018

Patch 8.0.0018 Problem:When using ":sleep" channel input is not handled. Solution: When there is a channel check for input also when not in raw mode. Check every 100 msec. Files: src/channel.c, src/proto/channel.pro, src/ui.c, src/proto/ui.pro, src/ex_docmd.c,

Re: Possible problem when running a job immediately followed by a sleep

Daniel Hahler wrote: > > Thanks, this is useful. Now we need to find out why we see an error or > > nothing to read, while reading the pipe/socket should give us the > > output. Adding some ch_logs() calls in channel_wait() could help > > pinpoint it. > > Sorry, I have not patched/debugged

Re: Add ttymouse=xterm support when TERM=tmux

On Sep 29, 2016 7:12 AM, "Christian Brabandt" wrote: > I thought, tmux proposed to use the screen terminal entry? Staying in 2.1 tmux can be used to differentiate functionality. https://github.com/tmux/tmux/blob/20598dff258da1e96a060adba95e8e05bfdd8b3b/FAQ#L355-L378 Cheers,

Re: Add ttymouse=xterm support when TERM=tmux

On Do, 29 Sep 2016, Michael Henry wrote: > All, > > Vim has compiled-in knowledge of a few terminals whose mouse > support is like that of xterm. One such terminal is GNU screen. > Missing from this list is tmux, a terminal multiplexer similar > to GNU screen: > https://tmux.github.io/ > >

Add ttymouse=xterm support when TERM=tmux

All, Vim has compiled-in knowledge of a few terminals whose mouse support is like that of xterm. One such terminal is GNU screen. Missing from this list is tmux, a terminal multiplexer similar to GNU screen: https://tmux.github.io/ When ``$TERM`` is ``screen``, Vim automatically performs the