Re: [patch] fixed typo in runtime/doc/eval.txt

2016-10-13 Fir de Conversatie Bram Moolenaar

Dominique wrote:

> Attached patch fixes a typo in runtime/doc/eval.txt.

Thanks.

-- 
Dreams are free, but there's a small charge for alterations.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [bug][patch] Doing ":redraw" during external command causes strange screen state

2016-10-13 Fir de Conversatie Bram Moolenaar

Ozaki Kiichi wrote:

> Doing ":redraw" during external command causes strange screen state and 
> cursor position.
> 
> [repro steps]
> 
> test.vim
> 
> 
> " for clarity of screen state
> colorscheme morning
> syntax on
> 
> function! Callback(timer) abort
> redraw
> "quit
> endfunction
> 
> call timer_start(1000, 'Callback')
> :!ls
> 
> 
> vim -Nu NONE -S test.vim
> 
> starting, after ":!ls" and ":redraw" in timer callback:
> cursor is positioned on the right of "help version7"
> 
> https://cloud.githubusercontent.com/assets/18260849/17743470/cadaca1e-64de-11e6-9c95-cd3a0f5111a3.png
> 
> entering insert mode:
> "~" of empty line prefix isn't drawn.
> 
> https://cloud.githubusercontent.com/assets/18260849/17743478/cfacf242-64de-11e6-922d-0411f7a59c5e.png
> 
> quiting:
> intro remains.
> 
> https://cloud.githubusercontent.com/assets/18260849/17743483/d48c6e1e-64de-11e6-9d77-a96709b15c4c.png
> 
> [cause/detail]
> 
> Terminal goes into inconsistent state.
> 
> normal sequence of executing external command:
> 
> do_shell
>   stoptermcap // switch to normal screen buffer (T_TE [DECRST 1049]), 
> termcap_active=FALSE
>   call_shell
> mch_call_shell
>   settmode(TMODE_COOK)
>   [:!ls]
>   settmode(TMODE_RAW)
>   wait_return
>   starttermcap // switch to alt-screen buffer (T_TI [DECSET 1049]), 
> termcap_active=TRUE
> 
> 
> case-1: this problem
> 
> do_shell
>   stoptermcap // switch to normal screen buffer
>   call_shell
>   (snip)
>   wait_return
> (firing timer)
>ex_redraw // draw intro on normal (NOT alt-) screen buffer
> (waiting key-input)
>   starttermcap // switch to alt-screen buffer
>   (snip)
>   // on exiting, restore to normal screen buffer (== intro)
> 
> 
> case-2: uncommenting ":quit" in callback
> 
> do_shell
>   stoptermcap // switch to normal screen buffer
>   call_shell
>   (snip)
>   wait_return
> (timer発火)
>   ex_redraw // draw intro on normal (NOT alt-) screen buffer
>   ex_quit
> getout
>   (exit) // :quit
> 
> 
> [patch]
> 
> - check "termcap_active" in screen_valid(), except GUI.
> (on GUI, this prevents executing external command)
> 
> https://gist.github.com/ichizok/4fe3853dbc7cc2e67c4a994e59fc5ee8

Isn't this a bit too drastic?  When termcap_active it should still be
possible to output text (e.g. from another timer command).

Also check msg_use_printf().  Looks like your change overrules its own
check for termcap_active.

-- 
   [Another hideous roar.]
BEDEVERE: That's it!
ARTHUR:   What?
BEDEVERE: It's The Legendary Black Beast of Arrggghhh!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [vim/vim] make line commands use visual lines in softwrap (enhancement) (#1164)

2016-10-13 Fir de Conversatie Manuel Ortega
On Thu, Oct 13, 2016 at 4:00 PM, yashamon  wrote:

> What about D, V command, etc? these behave terribly with wrapped text.
>
For the D command, just do dg$.  If you don't like typing three characters,
make up a mapping.

-Manny

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[bug][patch] matchaddpos() may not draw overldapped pos.

2016-10-13 Fir de Conversatie Ozaki Kiichi
Hi.

This is matchaddpos() problem.

[repro steps]

vim -Nu NONE

i1234567890
:call matchaddpos('ErrorMsg', [[1, 1, 5], [1, 3, 5]])

expected: colored 1~7 ("12345" and "34567"; pos [1, 1, 5] and [1, 3, 5], 
overlapped "345")

actual: colored 1~5 ("12345"; only first pos [1, 1, 5])

This problem occurs when overlapping more than 1 char.
e.g. [[1, 1, 5], [1, 5, 5]] is no problem.

[cause]

https://github.com/vim/vim/blob/fd89d7e/src/screen.c#L7770-L7771

On processing second pos [1, 3, 5], mincol is 5 (end of first pos col).
Thus, col (== 3) is less then mincol, and second pos is skipped.

I think that the case of "col < mincol < col + len -1" should be also processed.

[patch]

https://gist.github.com/ichizok/f34c9018f5e9e452d3bc78cc9026a720

Thank you.
- Ozaki Kiichi

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[bug][patch] Doing ":redraw" during external command causes strange screen state

2016-10-13 Fir de Conversatie Ozaki Kiichi
Hi.

Doing ":redraw" during external command causes strange screen state and cursor 
position.

[repro steps]

test.vim


" for clarity of screen state
colorscheme morning
syntax on

function! Callback(timer) abort
redraw
"quit
endfunction

call timer_start(1000, 'Callback')
:!ls


vim -Nu NONE -S test.vim

starting, after ":!ls" and ":redraw" in timer callback:
cursor is positioned on the right of "help version7"

https://cloud.githubusercontent.com/assets/18260849/17743470/cadaca1e-64de-11e6-9c95-cd3a0f5111a3.png

entering insert mode:
"~" of empty line prefix isn't drawn.

https://cloud.githubusercontent.com/assets/18260849/17743478/cfacf242-64de-11e6-922d-0411f7a59c5e.png

quiting:
intro remains.

https://cloud.githubusercontent.com/assets/18260849/17743483/d48c6e1e-64de-11e6-9d77-a96709b15c4c.png

[cause/detail]

Terminal goes into inconsistent state.

normal sequence of executing external command:

do_shell
  stoptermcap // switch to normal screen buffer (T_TE [DECRST 1049]), 
termcap_active=FALSE
  call_shell
mch_call_shell
  settmode(TMODE_COOK)
  [:!ls]
  settmode(TMODE_RAW)
  wait_return
  starttermcap // switch to alt-screen buffer (T_TI [DECSET 1049]), 
termcap_active=TRUE


case-1: this problem

do_shell
  stoptermcap // switch to normal screen buffer
  call_shell
  (snip)
  wait_return
(firing timer)
   ex_redraw // draw intro on normal (NOT alt-) screen buffer
(waiting key-input)
  starttermcap // switch to alt-screen buffer
  (snip)
  // on exiting, restore to normal screen buffer (== intro)


case-2: uncommenting ":quit" in callback

do_shell
  stoptermcap // switch to normal screen buffer
  call_shell
  (snip)
  wait_return
(timer発火)
  ex_redraw // draw intro on normal (NOT alt-) screen buffer
  ex_quit
getout
  (exit) // :quit


[patch]

- check "termcap_active" in screen_valid(), except GUI.
(on GUI, this prevents executing external command)

https://gist.github.com/ichizok/4fe3853dbc7cc2e67c4a994e59fc5ee8

Thank you.
- Ozaki Kiichi

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RFC: Can we have a bang (!) modifier after ":caddexpr" and ":cexpr" ?

2016-10-13 Fir de Conversatie skywind3000
Thanks to the new apis in vim 8. I have just released a plugin "asyncrun" to 
run a shell command in background and display the output to the quickfix window 
in realtime:

https://github.com/skywind3000/asyncrun.vim

This is a better alternative to old "vim-dispatch" plugin by using the 
advantage of vim 8. 

My friends and I has been using and improving it for months. Usually we start 
exploring the error output in quickfix window immediately while the command is 
still running. We added a condition on whether invoke ":cbottom" after append a 
new line in quickfix window by ":caddexpr":

1. if current cursor in qf window is on the last line before ":caddexpr", 
invoke ":cbottom" after ":caddexpr", and scroll the qf window. 

2. if current cursor in qf window isn't on the last line, skip ":cbottom" and 
call ":caddexpr" to populate qf directly.

The code is like these:

" quickfix window cursor check
function! s:AsyncRun_Job_Cursor()
if  == 'quickfix'
if line('.') != line('$')
let s:qf_cursor_on_last_line = 0
endif
endif
endfunc

" check if quickfix window can scroll now
function! s:AsyncRun_Job_CheckScroll()
let s:qf_cursor_on_last_line = 1
let l:winnr = winnr()
windo call s:AsyncRun_Job_Cursor()
silent exec ''.l:winnr.'wincmd w'
return s:qf_cursor_on_last_line
endfunc

-
":cbottom" is only invoked if AsyncRun_Job_CheckScroll returns non-zero.

So, if someone need read the output while executing, they just need to go to 
the qf window, and move cursor to the line above, auto scroll will stop, if 
they want to continue read the newest output, they just need press 'G' in qf 
window, ":cbottom" will continue be invoked and qf window will start scrolling 
again.

It works fine and have a very good user experience.

but one downside is lack of performance, especially display some crazy STL 
error output to quickfix window, vim alyways get unresponsed while cpu usage 
exceeds 100%.

another little downside is calling ":windo" before each ":caddexp" will make 
the cursor blink in a strange frequency. (maybe a little bug in vim).

due to this we have to disable these "last line checking" feature by default.

So, can we have a "!" after ":caddexpr" and ":cexpr" ? 

If there is a "!" after ":caddexpr" or ":cexpr", they can detect cursor 
position of the qf window in current tab-page, and make scroll after append 
text if cursor in qf window is on the last line ?

Quickfix is a fundamental module which becomes more useful after introducing 
async job system in vim.

It could be much helpful not only for my asyncrun, but a lot of other plugins 
who use quickfix window and async jobs together.

require for comments.


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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.