Re: Using "links -source" in netrw dumps raw gzipped stream into buffer

[Nikolay Aleksandrovich Pavlov]

2016-08-12 1:59 GMT+03:00 The Cheaterman :
> Are you serious? It took me forever to finally find this small topic hidden 
> in the bottom of Google... This needs to be addressed, please! It's a serious 
> issue, don't disregard it saying that most webservers don't serve gzipped 
> content because that's plain wrong!

Just change `links` to something more adequate (and report this issue
to its bug tracker, I do not see any reasons to first *explicitly
request* gzipped data and then return it as-is). `curl
http://www.ietf.org/rfc/rfc1918.txt` and `elinks -source
http://www.ietf.org/rfc/rfc1918.txt` both give nicely formatted file.
`links -dump http://www.ietf.org/rfc/rfc1918.txt` and `elinks -dump
http://www.ietf.org/rfc/rfc1918.txt` are inadequate, dumping the whole
file as a wall of text like below.

For this specific site this may be fixed by using `links
-http.extra-header 'Accept-Encoding: identity' -source
http://www.ietf.org/rfc/rfc1918.txt`. `tcpdump` shows that in this
case `links` sends only one `Accept-Encoding` header: the one which we
specified (links version 2.8-r1). @Charles Campbell, this may be the
fix: if choosing links to get the reply it should be additionally
passed `'-http.extra-header '.shellescape('Accept-Encoding:
identity')`. And links should be last thing to be choosen:

```Patch
--- netrw.vim 2016-08-05 05:57:26.267171457 +0300
+++ - 2016-08-12 05:50:08.307556080 +0300
@@ -215,18 +215,18 @@
  let g:netrw_ftp_options= "-i -n"
 endif
 if !exists("g:netrw_http_cmd")
- if executable("elinks")
-  let g:netrw_http_cmd = "elinks"
-  call s:NetrwInit("g:netrw_http_xcmd","-source >")
- elseif executable("links")
-  let g:netrw_http_cmd = "links"
-  call s:NetrwInit("g:netrw_http_xcmd","-source >")
- elseif executable("curl")
+ if executable("curl")
   let g:netrw_http_cmd = "curl"
   call s:NetrwInit("g:netrw_http_xcmd","-o")
  elseif executable("wget")
   let g:netrw_http_cmd = "wget"
   call s:NetrwInit("g:netrw_http_xcmd","-q -O")
+ elseif executable("elinks")
+  let g:netrw_http_cmd = "elinks"
+  call s:NetrwInit("g:netrw_http_xcmd","-source >")
+ elseif executable("links")
+  let g:netrw_http_cmd = "links"
+  call s:NetrwInit("g:netrw_http_xcmd","-http.extra-header
".shellescape("Accept-Encoding: identity", 1). "-source >")
  elseif executable("fetch")
   let g:netrw_http_cmd = "fetch"
   call s:NetrwInit("g:netrw_http_xcmd","-o")
```

 What links -dump returns for that page 


   Network Working Group Y. Rekhter Request for Comments: 1918 Cisco Systems
   Obsoletes: 1627, 1597 B. Moskowitz BCP: 5 Chrysler Corp. Category: Best
   Current Practice D. Karrenberg RIPE NCC G. J. de Groot RIPE NCC E. Lear
   Silicon Graphics, Inc. February 1996 Address Allocation for Private
   Internets Status of this Memo This document specifies an Internet Best
   Current Practices for the Internet Community, and requests discussion and
   suggestions for improvements. Distribution of this memo is unlimited. 1.
   Introduction For the purposes of this document, an enterprise
is an entity
   autonomously operating a network using TCP/IP and in particular
   determining the addressing plan and address assignments within that
   network. This document describes address allocation for private
internets.
   The allocation permits full network layer connectivity among all hosts
   inside an enterprise as well as among all public hosts of different
   enterprises. The cost of using private internet address space is the
   potentially costly effort to renumber hosts and networks between public
   and private. 2. Motivation With the proliferation of TCP/IP technology
   worldwide, including outside the Internet itself, an increasing number of
   non-connected enterprises use this technology and its addressing
   capabilities for sole intra-enterprise communications, without any
   intention to ever directly connect to other enterprises or the Internet
   itself. The Internet has grown beyond anyone's expectations. Sustained
   exponential growth continues to introduce new challenges. One
challenge is
   a concern within the community that globally unique address space will be
   exhausted. A separate and far more pressing concern is that the amount of
   routing overhead will grow beyond the Rekhter, et al Best
Current Practice
   [Page 1] RFC 1918 Address Allocation for Private Internets February 1996
   capabilities of Internet Service Providers. Efforts are in
progress within
   the community to find long term solutions to both of these problems.
   Meanwhile it is necessary to revisit address allocation procedures, and
   their impact on the Internet routing system. To contain growth of routing
   overhead, an Internet Provider obtains a block of address space from an
   address registry, and then assigns to its customers addresses from 

<M-"> broken by patch 7.4.1968

[Stephen Riehm]

Hi everyone,

after upgrading from MacVim 104 to MacVim 106 I noticed that  no longer 
works (not recognised for maps - just inserts a ¢ character). (The problem also 
exists in 105 - which I missed).

Workarounds such as  also had no effect.

After a bit of git bisecting I found the following commit:

1d90a5a... patch 7.4.1968 Problem:Invalid memory access with "\. 
Solution:   Do not recognize this as a special character. (Dominique Pelle)

misc2.c line 2762 (as of commit 5009946)

/* Anything accepted, like , except , because the "
 * ends the string. */
if (bp[l] != '"' && bp[l + 1] == '>')
bp += l;

This only checks for "> - thus not only catching  but also . (which 
always worked fine (for me at least :-)).
Strangely,  was not adversely affected.

After returning the check to its original

if (bp[l + 1] == '>')

 worked fine again.

Also, even without the extra check, I still could not reproduce any problems 
via  (except that it only produced a ' character - Mac OS 10.9.5, MacVim 
Snapshot 106).

Could we please revoke this patch, possibly replacing it with something else?

IMHO: If the invalid memory access problem still exists, it should be solved by 
"not accessing invalid memory" rather than simply turning off / breaking useful 
functionality.

Thanks in advance,

Steve

-- 
-- 
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: Using "links -source" in netrw dumps raw gzipped stream into buffer

[The Cheaterman]

Are you serious? It took me forever to finally find this small topic hidden in 
the bottom of Google... This needs to be addressed, please! It's a serious 
issue, don't disregard it saying that most webservers don't serve gzipped 
content because that's plain wrong!

-- 
-- 
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: gui cursor blinking issues (again)

[Ramel Eshed]

On Thursday, August 11, 2016 at 11:11:08 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > I guess that it depends on the job output characteristics, but I can
> > still see cursor blinking issues while using 'out_io': buffer in the
> > gui. I don't see it always, but there are cases in which it becomes
> > really disturbing. It was so bad that I've tried to disable cursor
> > blinking while there is an active job (adding blinkon0 to
> > 'guicursor'). It didn't help -the cursor is still unstable even though
> > it should not blink at all.
> > Please let me know if you need a test case for this and I'll try to
> > reproduce this behavior with a simpler job.
> 
> I'm not surpised this can still happen.  A reproducable test case would
> be good.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 2. You kiss your girlfriend's home page.
> 
>  /// 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///

Please try this:
Put the attached files in your home dir;

gvim -u NONE -N
sp job.vim
so %

-- 
-- 
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.
#!/bin/bash

for i in `seq 1 100`;
do
	echo "$i dflsk ksdjf shdaf sdasdlkfh"
	sleep 80 ms
	echo "kldj fdljkshf kjsdh sdlkfj $i"
	sleep 270 ms
done  


job.vim
Description: Binary data

Patch 7.4.2198

[Bram Moolenaar]

Patch 7.4.2198
Problem:Test alot sometimes fails under valgrind. (Dominique Pelle)
Solution:   Avoid passing a callback with the wrong number of arguments.
Files:  src/testdir/test_partial.vim


*** ../vim-7.4.2197/src/testdir/test_partial.vim2016-08-05 
19:31:37.640426182 +0200
--- src/testdir/test_partial.vim2016-08-11 22:46:37.495913590 +0200
***
*** 260,281 
unlet Pt
  endfunc
  
! func Ignored(job1, job2, status)
  endfunc
  
  func Test_cycle_partial_job()
if has('job')
  let job = job_start('echo')
! call job_setoptions(job, {'exit_cb': function('Ignored', [job])})
  unlet job
endif
  endfunc
  
  func Test_ref_job_partial_dict()
if has('job')
  let g:ref_job = job_start('echo')
  let d = {'a': 'b'}
! call job_setoptions(g:ref_job, {'exit_cb': function('string', [], d)})
endif
  endfunc
  
--- 260,284 
unlet Pt
  endfunc
  
! func Ignored3(job1, job2, status)
  endfunc
  
  func Test_cycle_partial_job()
if has('job')
  let job = job_start('echo')
! call job_setoptions(job, {'exit_cb': function('Ignored3', [job])})
  unlet job
endif
  endfunc
  
+ func Ignored2(job, status)
+ endfunc
+ 
  func Test_ref_job_partial_dict()
if has('job')
  let g:ref_job = job_start('echo')
  let d = {'a': 'b'}
! call job_setoptions(g:ref_job, {'exit_cb': function('Ignored2', [], d)})
endif
  endfunc
  
*** ../vim-7.4.2197/src/version.c   2016-08-11 22:51:01.641495491 +0200
--- src/version.c   2016-08-11 22:51:55.917000426 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2198,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
6. You refuse to go to a vacation spot with no electricity and no phone lines.

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

Patch 7.4.2197

[Bram Moolenaar]

Patch 7.4.2197
Problem:All functions are freed on exit, which may hide leaks.
Solution:   Only free named functions, not reference counted ones.
Files:  src/userfunc.c


*** ../vim-7.4.2196/src/userfunc.c  2016-08-01 22:49:18.065145186 +0200
--- src/userfunc.c  2016-08-11 22:15:52.452703436 +0200
***
*** 1099,1120 
  vim_free(fp);
  }
  
  #if defined(EXITFREE) || defined(PROTO)
  void
  free_all_functions(void)
  {
  hashitem_T*hi;
  
  /* Need to start all over every time, because func_free() may change the
   * hash table. */
! while (func_hashtab.ht_used > 0)
!   for (hi = func_hashtab.ht_array; ; ++hi)
if (!HASHITEM_EMPTY(hi))
{
!   func_free(HI2UF(hi), TRUE);
!   break;
}
! hash_clear(_hashtab);
  }
  #endif
  
--- 1099,1151 
  vim_free(fp);
  }
  
+ /*
+  * There are two kinds of function names:
+  * 1. ordinary names, function defined with :function
+  * 2. numbered functions and lambdas
+  * For the first we only count the name stored in func_hashtab as a reference,
+  * using function() does not count as a reference, because the function is
+  * looked up by name.
+  */
+ static int
+ func_name_refcount(char_u *name)
+ {
+ return isdigit(*name) || *name == '<';
+ }
+ 
  #if defined(EXITFREE) || defined(PROTO)
  void
  free_all_functions(void)
  {
  hashitem_T*hi;
+ ufunc_T   *fp;
+ long_uskipped = 0;
+ long_utodo;
  
  /* Need to start all over every time, because func_free() may change the
   * hash table. */
! while (func_hashtab.ht_used > skipped)
! {
!   todo = func_hashtab.ht_used;
!   for (hi = func_hashtab.ht_array; todo > 0; ++hi)
if (!HASHITEM_EMPTY(hi))
{
!   --todo;
!   /* Only free functions that are not refcounted, those are
!* supposed to be freed when no longer referenced. */
!   fp = HI2UF(hi);
!   if (func_name_refcount(fp->uf_name))
!   ++skipped;
!   else
!   {
!   func_free(fp, TRUE);
!   skipped = 0;
!   break;
!   }
}
! }
! if (skipped == 0)
!   hash_clear(_hashtab);
  }
  #endif
  
***
*** 1669,1688 
  }
  
  /*
-  * There are two kinds of function names:
-  * 1. ordinary names, function defined with :function
-  * 2. numbered functions and lambdas
-  * For the first we only count the name stored in func_hashtab as a reference,
-  * using function() does not count as a reference, because the function is
-  * looked up by name.
-  */
- static int
- func_name_refcount(char_u *name)
- {
- return isdigit(*name) || *name == '<';
- }
- 
- /*
   * ":function"
   */
  void
--- 1700,1705 
*** ../vim-7.4.2196/src/version.c   2016-08-10 23:02:42.499155800 +0200
--- src/version.c   2016-08-11 22:20:49.922041422 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2197,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
5. You find yourself brainstorming for new subjects to search.

 /// 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: Test_with_partial_callback fails when run with valgrind

[Bram Moolenaar]

Dominique Pellé wrote:

> I have a machine where running vim tests with valgrind
> always gives the following error using latest vim-7.4.2196
> (but I've seen this with earlier versions too):
> 
> ===
> $ cd src/testdir
> $ make
> 
> Executed 144 tests
> 1 FAILED:
> Found errors in Test_with_partial_callback():
> Caught exception in Test_with_partial_callback(): Vim(sleep):E118: Too
> many arguments for function: string @ function
> RunTheTest[9]..Test_with_partial_callback[8]..WaitFor, line 10
> 
> 
> From test_alot.vim:
> Found errors in Test_with_partial_callback():
> Caught exception in Test_with_partial_callback(): Vim(sleep):E118: Too
> many arguments for function: string @ function
> RunTheTest[9]..Test_with_partial_callback[8]..WaitFor, line 10
> 
> Test results:
> 
> 
> From test_alot.vim:
> Found errors in Test_with_partial_callback():
> Caught exception in Test_with_partial_callback(): Vim(sleep):E118: Too
> many arguments for function: string @ function
> RunTheTest[9]..Test_with_partial_callback[8]..WaitFor, line 10
> TEST FAILURE
> Makefile:41: recipe for target 'report' failed
> make[2]: *** [report] Error 1
> make[2]: Leaving directory '/home/dope/sb/vim/src/testdir'
> Makefile:1981: recipe for target 'scripttests' failed
> make[1]: *** [scripttests] Error 2
> make[1]: Leaving directory '/home/dope/sb/vim/src'
> Makefile:36: recipe for target 'test' failed
> make: *** [test] Error 2
> ===
> 
> Function Test_with_partial_callback() lin src/testdir/test_timers.vim is:
> 
>  41 func Test_with_partial_callback()
>  42   let g:val = 0
>  43   let s:meow = {}
>  44   function s:meow.bite(...)
>  45 let g:val += 1
>  46   endfunction
>  47
>  48   call timer_start(50, s:meow.bite)
>  49   let slept = WaitFor('g:val == 1')
>  50   call assert_equal(1, g:val)
>  51   call assert_inrange(30, 100, slept)
>  52 endfunc
> 
> Function WaitFor() in src/testdir/shared.vim is:
> 
> 111 " Wait for up to a second for "expr" to become true.
> 112 " Return time slept in milliseconds.
> 113 func WaitFor(expr)
> 114   let slept = 0
> 115   for i in range(100)
> 116 try
> 117   if eval(a:expr)
> 118 return slept
> 119   endif
> 120 catch
> 121 endtry
> 122 let slept += 10
> 123 sleep 10m
> 124   endfor
> 125 endfunc
> 
> Valgrind does not give errors.
> All test pass when run without valgrind.
> They also pass with the address sanitizer.
> 
> Any idea why the test fails when run with valgrind?

Valgrind makes Vim a lot slower.  Since the error happens in "sleep" it
suggests that a callback is called much later.  Probably from a function
that's called before Test_with_partial_callback().  Since the functions
are sorted this one comes near the end:

[...]
Executing Test_window_cmd_wincmd_gf()
Executing Test_with_directories()
Executing Test_with_partial_callback()
Executing Test_with_tilde()
Executing Test_wrong_arguments()

Hmm, don't spot anything suspicious.  It could very well be any callback
that, when run without valgrind, is not invoked because Vim has already
exited.

The error suggests it comes from a function('string', ...) callback.
I would suspect a call in test_partial.vim
I can't reproduce it, thus I can't try out possible fixes.

You could try changing Test_ref_job_partial_dict() to call another
function than string().  Actually, that is always wrong, since string()
only accepts one argument.

-- 
hundred-and-one symptoms of being an internet addict:
4. Your eyeglasses have a web site burned in on them.

 /// 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 in complete() function?

[Tumbler Terrall]

> It mentions version 7.4.0, that's very old.  Many completion bugs have
> already been fixed.
> 
> It would be nicer if you can copy the essential information here, so
> that not everybody has to navigate to some website to see the contents.

Thanks for the reply.

I tried it on 7.4.2196 and it seemed to be fixed. Sorry for submitting old 
data. Although to be fair, 7.4.0 is the latest version supplied on 
www.vim.org/download.php. :)

As far as putting everything here, I will make sure to do that in the future. I 
kept it on Stack Exchange because I posted some code and I like the markdown 
they supply for code snippets.

-- 
-- 
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 in complete() function?

[Bram Moolenaar]

Tumbler Terrall wrote:

> If the complete() function is used and the user backspaces, vim goes into 
> "Whole line completion" mode. I'm curious if this is intended or if it is a 
> bug.
> 
> It kind of seems like a bug to me since if you press CTRL-e the whole line 
> gets replaced by the current word in certain circumstances. (Full details 
> here: 
> http://vi.stackexchange.com/questions/9125/strange-behavior-from-the-complete-function)
> 
> Can anyone here comment on this?

It mentions version 7.4.0, that's very old.  Many completion bugs have
already been fixed.

It would be nicer if you can copy the essential information here, so
that not everybody has to navigate to some website to see the contents.

-- 
hundred-and-one symptoms of being an internet addict:
1. You actually wore a blue ribbon to protest the Communications Decency Act.

 /// 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: gui cursor blinking issues (again)

[Bram Moolenaar]

Ramel Eshed wrote:

> I guess that it depends on the job output characteristics, but I can
> still see cursor blinking issues while using 'out_io': buffer in the
> gui. I don't see it always, but there are cases in which it becomes
> really disturbing. It was so bad that I've tried to disable cursor
> blinking while there is an active job (adding blinkon0 to
> 'guicursor'). It didn't help -the cursor is still unstable even though
> it should not blink at all.
> Please let me know if you need a test case for this and I'll try to
> reproduce this behavior with a simpler job.

I'm not surpised this can still happen.  A reproducable test case would
be good.

-- 
hundred-and-one symptoms of being an internet addict:
2. You kiss your girlfriend's home page.

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

Test_with_partial_callback fails when run with valgrind

[Dominique Pellé]

Hi

I have a machine where running vim tests with valgrind
always gives the following error using latest vim-7.4.2196
(but I've seen this with earlier versions too):

===
$ cd src/testdir
$ make

Executed 144 tests
1 FAILED:
Found errors in Test_with_partial_callback():
Caught exception in Test_with_partial_callback(): Vim(sleep):E118: Too
many arguments for function: string @ function
RunTheTest[9]..Test_with_partial_callback[8]..WaitFor, line 10


>From test_alot.vim:
Found errors in Test_with_partial_callback():
Caught exception in Test_with_partial_callback(): Vim(sleep):E118: Too
many arguments for function: string @ function
RunTheTest[9]..Test_with_partial_callback[8]..WaitFor, line 10

Test results:


>From test_alot.vim:
Found errors in Test_with_partial_callback():
Caught exception in Test_with_partial_callback(): Vim(sleep):E118: Too
many arguments for function: string @ function
RunTheTest[9]..Test_with_partial_callback[8]..WaitFor, line 10
TEST FAILURE
Makefile:41: recipe for target 'report' failed
make[2]: *** [report] Error 1
make[2]: Leaving directory '/home/dope/sb/vim/src/testdir'
Makefile:1981: recipe for target 'scripttests' failed
make[1]: *** [scripttests] Error 2
make[1]: Leaving directory '/home/dope/sb/vim/src'
Makefile:36: recipe for target 'test' failed
make: *** [test] Error 2
===

Function Test_with_partial_callback() lin src/testdir/test_timers.vim is:

 41 func Test_with_partial_callback()
 42   let g:val = 0
 43   let s:meow = {}
 44   function s:meow.bite(...)
 45 let g:val += 1
 46   endfunction
 47
 48   call timer_start(50, s:meow.bite)
 49   let slept = WaitFor('g:val == 1')
 50   call assert_equal(1, g:val)
 51   call assert_inrange(30, 100, slept)
 52 endfunc

Function WaitFor() in src/testdir/shared.vim is:

111 " Wait for up to a second for "expr" to become true.
112 " Return time slept in milliseconds.
113 func WaitFor(expr)
114   let slept = 0
115   for i in range(100)
116 try
117   if eval(a:expr)
118 return slept
119   endif
120 catch
121 endtry
122 let slept += 10
123 sleep 10m
124   endfor
125 endfunc

Valgrind does not give errors.
All test pass when run without valgrind.
They also pass with the address sanitizer.

Any idea why the test fails when run with valgrind?

Regards
Dominique

-- 
-- 
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: gvim and ASCII glyphs

[Stefan Schwarzer]

On 2016-08-11 17:40, Kazunobu Kuriyama wrote:
> 2016-08-11 23:44 GMT+09:00 Ken Takata :
>> Screenshot attached.  (I haven't try PragmataPro.)
> 
> I don't either for an obvious reason..Isn't there a free version? :)

As far as I know there's no free version. The cheapest is the
"PragmataPro Essential" version for 19 Euro plus tax [1]. :-/

Maybe it would make sense to ask [2] the author for a reduced
subset to try things out. If I remember correctly, someone in
the forum section (at [1]) suggested having such a "test version"
and the font author seemed open to the idea. If you want, I can
contact the author and ask.

[1] http://www.fsd.it/shop/fonts/pragmatapro/
(There's no dedicated page for the Essential version, but it's
selectable from the "Weights" list.)

[2] http://www.fsd.it/contact-me/

Best regards,
Stefan

-- 
-- 
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] sh syntax script highlights multiline arrays inside an if statement incorrectly (#962)

[Charles E Campbell]

keremc wrote:
>
> Inside an if statement the opening parenthesis of a multiline array
> will not be highlighted at all, while the closing parenthesis will be
> highlighted as an error.
>
>
Hello:

Please try the attached syntax/sh.vim.

Regards,
Chip Campbell

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


sh.vim
Description: application/octetstream

gui cursor blinking issues (again)

[Ramel Eshed]

Hi Bram,

I guess that it depends on the job output characteristics, but I can still see 
cursor blinking issues while using 'out_io': buffer in the gui. I don't see it 
always, but there are cases in which it becomes really disturbing. It was so 
bad that I've tried to disable cursor blinking while there is an active job 
(adding blinkon0 to 'guicursor'). It didn't help -the cursor is still unstable 
even though it should not blink at all.
Please let me know if you need a test case for this and I'll try to reproduce 
this behavior with a simpler job.

Thanks,
Ramel

-- 
-- 
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: gvim and ASCII glyphs

[Kazunobu Kuriyama]

Hi Ken,

Thank you for the headsup!  Great.  Bram must feel relief now :)

2016-08-11 23:44 GMT+09:00 Ken Takata :

> Hi,
>
> 2016/8/11 Thu 14:36:57 UTC+9 Kazunobu Kuriyama wrote:
> > Hi Tony,
> >
> > 2016-08-11 10:05 GMT+09:00 Tony Mechelynck :
> > > Hm. gui_gtk_x11.c is of course only for gvim with GTK GUI running on
> > > Linux-X11. GTK2, and now even GTK3 ("new in 8.0"), are of course the
> > > preferred GUIs for Vim on Linux these days, and for X11 in general
> > > (though a few older ones are still supported IIUC); however, what
> > > about other flavors of gvim? Such as gvim for Windows, and, maybe
> > > worse, MacVim (gvim for Mac-Cocoa IIUC), of which I think, but am not
> > > sure, that all its sources are included in the current "official" Vim
> > > sources. Do Windows and/or Mac have similar fonts? Won't they feel
> > > left out? The mechanisms to implement the corresponding Poor Man's
> > > Ligatures will of necessity be different because we're at too low a
> > > level for cross-platform programming to be possible all the way. Maybe
> > > you don't have the necessary OSes to build and test the corresponding
> > > gvim versions (neither do I) so it might perhaps be useful if some
> > > Windows Vim developer(s) and some Mac Vim developer(s) joined you on
> > > this project.
> > >
> > > I'm cross-posting on the vim_mac group because Mac people might (or
> > > might not) be interested; but this thread was started on vim_dev. Mac
> > > developers: please refer to vim_dev for the discussion's history.
> >
> > As for Mac-Cocoa, I haven't succeeded in building it with recent OSXs
> last 6 years. That build is automatically disabled at configure.
> >
> > As for MacVim, they've already merged a patch which enables ligatures
> into their repo. It was almost a year ago ( Aug 24, 2015).
> >
> > So...it's us who was left out.
> >
> > In my understanding, they made ligatures possible by tweaking an
> attribute of a class of character strings called NSAttributedString [2]
> (Actually, they are doing that through the Core API, not Cocoa).
> >
> > FYI, the latest nightly build of iTerm2, which is one of the popular
> terminals on Mac and seen a lot of Vimmer on console using the editor on
> it, starts supporting ligatures by a similar way.
> >
> > Rendering ligatures is done by using some information from font files.
> Therefore, as can been seen in two instances above, people usually rely on
> an rendering engine in use for that chore.
> >
> > In other words, since creating a new shaping module for the purpose of
> cross-platform is very tough, there's no feasible solution other than
> relying on GUI's rendering engines.
> >
> > As for Windows stuff...anyone?
>
> I just tried Hasklig on Windows.  It seems that ligatures partly works on
> Windows.
>

I'm also playing around Hasklig on MacVim today.  It appears the ligature
support is not completed yet.

But this is my Day 1 of ligature experience, my setting may be wrong.  I'd
like to hear the voices from MacVim guys about that.


> After Vim 7.4.393, gvim.exe can use two types of rendering engine, the
> traditional GDI engine and newer DirectWrite engine.  GDI doesn't seem to
> support ligatures at all, but DirectWrite supports ligature.  However, when
> you put the cursor on a ligature, it is shown as separate characters.  If
> you
> want to show the ligature again, you need to type .
>

Hmm, it looks leaving everything to rendering engines is not a good
solution to rendering programming ligatures...  Perhaps, Vim itself needs
to know byte sequences which constitute those ligatures and instruct the
rendering engine about them explicitly...


> Screenshot attached.  (I haven't try PragmataPro.)
>

I don't either for an obvious reason..Isn't there a free version? :)

>
> Regards,
> Ken Takata
>

Best regards,
Kazunobu

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

-- 
-- 
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 in complete() function?

[Tumbler Terrall]

If the complete() function is used and the user backspaces, vim goes into 
"Whole line completion" mode. I'm curious if this is intended or if it is a bug.

It kind of seems like a bug to me since if you press CTRL-e the whole line gets 
replaced by the current word in certain circumstances. (Full details here: 
http://vi.stackexchange.com/questions/9125/strange-behavior-from-the-complete-function)

Can anyone here comment on this?

-- 
-- 
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] Mark "double quote" does not saved in file ".viminfo" since patch 7.4.320. (#974)

[h_east]

Hi,

2016-8-11(Thu) 18:50:11 UTC+9 h_east:
> Hi guraga and list,
> 
> 2016-8-11(Thu) 16:54:13 UTC+9 guraga:
> > Mark saved, if run
> > 
> > 
> > ./vim-7.4.230 test_file.txt
> > 
> > 
> > move cursor and press "ZQ".
> > 
> > 
> > Also mark saved, if run
> > 
> > 
> > ./vim-7.4.230
> > 
> > 
> > execute ":edit test_file.txt", move cursor, press "ZQ".
> > 
> > 
> > Why it is not saved, if executed ":tabnew" command? It's seems as a bug.
> 
> I investegasted and grasped.
> This problem occurs with a combination of tabpage closed and buffer closed.
> 
> I'm writing a patch now.
> Please wait a few hours.

I attached a patch.
I am glad if you could confirm.

Investigation result:
When `close_buffer()` has been called from `win_close_othertab()`, `curtab` 
does not contained `win`.
So `win_valid()` result is FALSE, then doesn't save the last cursor position of 
file.

I add the `tabpage_T *tp` to the argument of `close_buffer()`, it has been 
changed to window validation check using it.
In order to realize this, I add the function `win_valid_in_tabpage()`.

Please confirm this.
--
Best regards,
Hirohito Higashi (a.k.a. h_east) 

-- 
-- 
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.
diff --git a/src/buffer.c b/src/buffer.c
index 2a09a63..3d479c7 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -163,7 +163,7 @@ open_buffer(
 	 * There MUST be a memfile, otherwise we can't do anything
 	 * If we can't create one for the current buffer, take another buffer
 	 */
-	close_buffer(NULL, curbuf, 0, FALSE);
+	close_buffer(NULL, NULL, curbuf, 0, FALSE);
 	FOR_ALL_BUFFERS(curbuf)
 	if (curbuf->b_ml.ml_mfp != NULL)
 		break;
@@ -438,6 +438,7 @@ buf_hashtab_remove(buf_T *buf)
  */
 void
 close_buffer(
+tabpage_T	*tp,		/* if NULL, same as curtab */
 win_T	*win,		/* if not NULL, set b_last_cursor */
 buf_T	*buf,
 int		action,
@@ -473,11 +474,14 @@ close_buffer(
 	unload_buf = TRUE;
 #endif
 
-if (win != NULL
+if (
 #ifdef FEAT_WINDOWS
-	&& win_valid(win)	/* in case autocommands closed the window */
+	/* in case autocommands closed the window */
+	win_valid_in_tabpage(tp, win)
+#else
+	win != NULL
 #endif
-	)
+	)
 {
 	/* Set b_last_cursor when closing the last window for the buffer.
 	 * Remember the last cursor position and window options of the buffer.
@@ -581,7 +585,7 @@ aucmd_abort:
 
 if (
 #ifdef FEAT_WINDOWS
-	win_valid(win) &&
+	win_valid_in_tabpage(tp, win) &&
 #else
 	win != NULL &&
 #endif
@@ -948,7 +952,7 @@ handle_swap_exists(bufref_T *old_curbuf)
 	 * open a new, empty buffer. */
 	swap_exists_action = SEA_NONE;	/* don't want it again */
 	swap_exists_did_quit = TRUE;
-	close_buffer(curwin, curbuf, DOBUF_UNLOAD, FALSE);
+	close_buffer(NULL, curwin, curbuf, DOBUF_UNLOAD, FALSE);
 	if (old_curbuf == NULL || !bufref_valid(old_curbuf)
 	  || old_curbuf->br_buf == curbuf)
 	buf = buflist_new(NULL, NULL, 1L, BLN_CURBUF | BLN_LISTED);
@@ -1166,7 +1170,7 @@ empty_curbuf(
  * if the buffer still exists.
  */
 if (buf != curbuf && bufref_valid() && buf->b_nwindows == 0)
-	close_buffer(NULL, buf, action, FALSE);
+	close_buffer(NULL, NULL, buf, action, FALSE);
 if (!close_others)
 	need_fileinfo = FALSE;
 return retval;
@@ -1365,7 +1369,7 @@ do_buffer(
 	if (buf != curbuf && bufref_valid())
 #endif
 		if (buf->b_nwindows <= 0)
-		close_buffer(NULL, buf, action, FALSE);
+		close_buffer(NULL, NULL, buf, action, FALSE);
 	return OK;
 	}
 
@@ -1610,8 +1614,8 @@ set_curbuf(buf_T *buf, int action)
 #endif
 	if (prevbuf == curbuf)
 		u_sync(FALSE);
-	close_buffer(prevbuf == curwin->w_buffer ? curwin : NULL, prevbuf,
-		unload ? action : (action == DOBUF_GOTO
+	close_buffer(NULL, prevbuf == curwin->w_buffer ? curwin : NULL,
+		prevbuf, unload ? action : (action == DOBUF_GOTO
 			&& !P_HID(prevbuf)
 			&& !bufIsChanged(prevbuf)) ? DOBUF_UNLOAD : 0, FALSE);
 #ifdef FEAT_WINDOWS
@@ -3048,7 +3052,7 @@ setfname(
 		return FAIL;
 	}
 	/* delete from the list */
-	close_buffer(NULL, obuf, DOBUF_WIPE, FALSE);
+	close_buffer(NULL, NULL, obuf, DOBUF_WIPE, FALSE);
 	}
 	sfname = vim_strsave(sfname);
 	if (ffname == NULL || sfname == NULL)
@@ -6055,7 +6059,7 @@ wipe_buffer(
 if (!aucmd)		/* Don't trigger BufDelete autocommands here. */
 	block_autocmds();
 #endif
-close_buffer(NULL, buf, DOBUF_WIPE, FALSE);
+close_buffer(NULL, NULL, buf, DOBUF_WIPE, FALSE);
 #ifdef FEAT_AUTOCMD
 if (!aucmd)
 	unblock_autocmds();
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
index 30b0d5c..d5c9a44 100644
--- 

Re: gvim and ASCII glyphs

[Ken Takata]

Hi,

2016/8/11 Thu 14:36:57 UTC+9 Kazunobu Kuriyama wrote:
> Hi Tony,
> 
> 2016-08-11 10:05 GMT+09:00 Tony Mechelynck :
> > Hm. gui_gtk_x11.c is of course only for gvim with GTK GUI running on
> > Linux-X11. GTK2, and now even GTK3 ("new in 8.0"), are of course the
> > preferred GUIs for Vim on Linux these days, and for X11 in general
> > (though a few older ones are still supported IIUC); however, what
> > about other flavors of gvim? Such as gvim for Windows, and, maybe
> > worse, MacVim (gvim for Mac-Cocoa IIUC), of which I think, but am not
> > sure, that all its sources are included in the current "official" Vim
> > sources. Do Windows and/or Mac have similar fonts? Won't they feel
> > left out? The mechanisms to implement the corresponding Poor Man's
> > Ligatures will of necessity be different because we're at too low a
> > level for cross-platform programming to be possible all the way. Maybe
> > you don't have the necessary OSes to build and test the corresponding
> > gvim versions (neither do I) so it might perhaps be useful if some
> > Windows Vim developer(s) and some Mac Vim developer(s) joined you on
> > this project.
> > 
> > I'm cross-posting on the vim_mac group because Mac people might (or
> > might not) be interested; but this thread was started on vim_dev. Mac
> > developers: please refer to vim_dev for the discussion's history.
> 
> As for Mac-Cocoa, I haven't succeeded in building it with recent OSXs last 6 
> years. That build is automatically disabled at configure.
> 
> As for MacVim, they've already merged a patch which enables ligatures into 
> their repo. It was almost a year ago ( Aug 24, 2015).
> 
> So...it's us who was left out.
> 
> In my understanding, they made ligatures possible by tweaking an attribute of 
> a class of character strings called NSAttributedString [2] (Actually, they 
> are doing that through the Core API, not Cocoa).
> 
> FYI, the latest nightly build of iTerm2, which is one of the popular 
> terminals on Mac and seen a lot of Vimmer on console using the editor on it, 
> starts supporting ligatures by a similar way.
> 
> Rendering ligatures is done by using some information from font files.  
> Therefore, as can been seen in two instances above, people usually rely on an 
> rendering engine in use for that chore.
> 
> In other words, since creating a new shaping module for the purpose of 
> cross-platform is very tough, there's no feasible solution other than relying 
> on GUI's rendering engines.
> 
> As for Windows stuff...anyone?

I just tried Hasklig on Windows.  It seems that ligatures partly works on
Windows.

After Vim 7.4.393, gvim.exe can use two types of rendering engine, the
traditional GDI engine and newer DirectWrite engine.  GDI doesn't seem to
support ligatures at all, but DirectWrite supports ligature.  However, when
you put the cursor on a ligature, it is shown as separate characters.  If you
want to show the ligature again, you need to type .

Screenshot attached.  (I haven't try PragmataPro.)

Regards,
Ken Takata

-- 
-- 
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: gvim and ASCII glyphs

[Tony Mechelynck]

On Thu, Aug 11, 2016 at 7:36 AM, Kazunobu Kuriyama
 wrote:
> Hi Tony,
>
> 2016-08-11 10:05 GMT+09:00 Tony Mechelynck :
>>
>> On Thu, Aug 11, 2016 at 1:39 AM, manuelschiller.pimail via vim_dev
>>  wrote:
>> > On Wednesday, 10 August 2016 02:35:04 UTC+2, Tony Mechelynck  wrote:
>> >> Manuel:
>> >>
>> >> In the past there have been "unofficial" features published as patches
>> >> which remained outside of the "official" Vim repositories but publicly
>> >> available, sometimes for years, before Bram finally decided to take
>> >> them in. The +conceal and +float features, now part of mainstream Vim,
>> >> are two examples of such which I've seen remain "unofficial
>> >> third-party patches" while several successive minor versions of Vim
>> >> came and went.
>> >>
>> >> Maybe you could publish your patch (as a patch that could be applied
>> >> by running "patch -p1 ligatures.diff", or something like that, at the
>> >> top level of a Vim repository clone), upload it somewhere on github or
>> >> vim.org or wherever, and let anyone use it who wants. Then after
>> >> letting it bake there for some time, we'll know better how popular it
>> >> is. Assuming that the new version currently being made ready will be
>> >> called Vim 8.0 and be released before the end of 2016, we might then
>> >> have a poll about your patch when getting ready for 8.1 or 8.2, and
>> >> let's hope that that will arrive long before 8.0 is at patchlevel
>> >> 8.0.2200 — Vim 7.4, whose original release was almost exactly three
>> >> years ago, seems to have been quite successful in its own way.
>> >>
>> >> If you choose to go this way, please set it up so that it could be
>> >> disabled at compile-time (I mean, place the changes  behind #ifdef
>> >> FEAT_LIGATURES or something equally distinctive), it will help it
>> >> being accepted into the main code, since anyone not wanting it would
>> >> be able to disable it at compile-time — and similarly, an option (to
>> >> enable or disable it at runtime if present at compile-time, let's say
>> >> in the vimrc or gvimrc before starting the GUI) would IMHO be equally
>> >> welcome.
>> >>
>> >>
>> >> Best regards,
>> >> Tony.
>> >
>> > Hi Tony,
>> >
>> > you (and others) are making very good points here, and I appreciate the
>> > feedback.
>> >
>> > Following your suggestion, I have created a vim fork with a branch for
>> > this kind of development:
>> >
>> > https://github.com/manuelschiller/vim/tree/glyphs
>> >
>> > Currently, it contains two patches:
>> >
>> > - gui_gtk_x11: force shaping one character at a time for ASCII glyph
>> > cache
>> >
>> >   This one does what it says. It'll get fonts like PragmataPro or
>> > Hasklig
>> >   working in gvim without ligatures, and without the drawing caveats we
>> >   discussed earlier. I imagine that this patch might make inclusion in
>> > vim
>> >   quite a bit earlier (I'd hope soonish, but that may be wishful
>> > thinking)
>> >   than the next item, because I do not think it does anything
>> > controversial.
>> >   If you'd like to see style improvements etc., please let me know, I'm
>> >   happy to accomodate you. :)
>> >
>> > - gui_gtk_x11: enable poor man's ligatures
>> >
>> >   This one is the bit that enables ligatures, and will require a couple
>> > of
>> >   iterations on my side before it's ready to be considered for
>> > inclusion.
>> >   (For example, I'd like to make the set of characters that disable the
>> >   ASCII glyph cache user-configurable, and I have to find out how C code
>> >   gets access to variables inside vimscript...) For the curious, this is
>> >   something they might want to try out, and give feedback...
>> >
>> > I would again like to thank you all for the friendly and constructive
>> > atmosphere. And let me know if you have suggestions, please!
>> >
>> > Manuel
>>
>> Hm. gui_gtk_x11.c is of course only for gvim with GTK GUI running on
>> Linux-X11. GTK2, and now even GTK3 ("new in 8.0"), are of course the
>> preferred GUIs for Vim on Linux these days, and for X11 in general
>> (though a few older ones are still supported IIUC); however, what
>> about other flavors of gvim? Such as gvim for Windows, and, maybe
>> worse, MacVim (gvim for Mac-Cocoa IIUC), of which I think, but am not
>> sure, that all its sources are included in the current "official" Vim
>> sources. Do Windows and/or Mac have similar fonts? Won't they feel
>> left out? The mechanisms to implement the corresponding Poor Man's
>> Ligatures will of necessity be different because we're at too low a
>> level for cross-platform programming to be possible all the way. Maybe
>> you don't have the necessary OSes to build and test the corresponding
>> gvim versions (neither do I) so it might perhaps be useful if some
>> Windows Vim developer(s) and some Mac Vim developer(s) joined you on
>> this project.
>>
>> I'm cross-posting on the vim_mac group because Mac people might (or
>> 

Re: Scant GTK3 documentation

[Tony Mechelynck]

On Thu, Aug 11, 2016 at 10:01 AM, Kazunobu Kuriyama
 wrote:
> Hi Tony,
>
> Thank you for all those checks!

Thank _you_ for the explanations, they're a great help to my
understanding of the new GUI.
>
> 2016-08-11 12:23 GMT+09:00 Tony Mechelynck :
>>
>> - GTK3 is supported, it is said, but there aren't a lot of details about
>> it
>> - It is only barely mentioned under ":help GTK3" in doc/gui_x11.txt
>> - It is mentioned here and there in version8.txt, once at lines 137
>> and 139, long below ":help new-8" and shortly before ":help
>> new-vim-script-8", then here and there starting at patch 7.4.1402
>> - It is nowhere mentioned in the possible configuration settings in
>> the src/Makefile
>
>
> All those, I'll see to it later.
>
>>
>> - Contrary to what "configure -h" seems to imply, AFAICT the only way
>> to build with GTK3 is to require it explicitly by --enable-gui=gtk3
>
>
> That's because, when the GTK3 patch was included, there was an agreement (or
> no objection, more precisely) that, when both gtk2 and gtk3 are available,
> the GTK2 GUI shall be selected as default.

Ah, OK
>
> Since I didn't think the current output of 'configure -h' caused a
> confusion, I have little idea as to what caused that.  Do you have an
> suggestion how we could improve that?

I have no _coding_ suggestions. As a _documentation_ suggestion, maybe
mention in more detail the priority of GUIs (when more than one are
available for building) in the Makefile comments about CONF_OPT_GUI
and in the "configure -h" text
>
>>
>> - When both GTK2 and GTK3 are present in the system,
>> disable-gtk2-check --enable-gtk3-check builds a Vim with no GUI
>
>
> Oh, I didn't try those combination.  I'd rather like to know why those
> --(enable|disable)-*-check options were introduced.  It looks --enable-gui=
> is enough...  For the sake of completeness of the autodetection mechanism,
> maybe?
>
>>
>> - In the same configuration, just «export
>> CONF_OPT_GUI='enable-gnome-check'» (without the French quotes) gives a
>> GTK2 GUI; GTK3 is not looked for.
>> - When --enable-gui=gtk3 is present, then AFAICT --enable-gnome-check
>> has no effect. (Maybe I don't have the right packages installed.)
>
>
> Please note that the GTK3 GUI is completely independent of the Gnome 2
> stuff.  This is because that stuff has been deprecated since the very early
> version of Gnome 3 was released and was once said it would soon go away, I
> intentionally wrote the patch in such a way that the GUI doesn't rely on
> that.
>
> Accordingly, the both cases look fine to me: If --enable-gnome-check is
> selected, it's natural for us to conclude that the user wants the GTK2 GUI,
> and if --enable-gui=3 is selected, the user don't want the Gnome stuff.
>
> Still, if you find there's room for improvement, please let me know.

Here too, I would suggest "documentation improvements": let's say,
mention that the Gnome interface to Vim is removed starting with GTK3,
in the "build documentation" in src/Makefile and configure -h as
above, and maybe also somewhere under "help GNOME" in the ordinary Vim
help.


Best regards,
Tony

-- 
-- 
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] Mark "double quote" does not saved in file ".viminfo" since patch 7.4.320. (#974)

[h_east]

Hi guraga and list,

2016-8-11(Thu) 16:54:13 UTC+9 guraga:
> Mark saved, if run
> 
> 
> ./vim-7.4.230 test_file.txt
> 
> 
> move cursor and press "ZQ".
> 
> 
> Also mark saved, if run
> 
> 
> ./vim-7.4.230
> 
> 
> execute ":edit test_file.txt", move cursor, press "ZQ".
> 
> 
> Why it is not saved, if executed ":tabnew" command? It's seems as a bug.

I investegasted and grasped.
This problem occurs with a combination of tabpage closed and buffer closed.

I'm writing a patch now.
Please wait a few hours.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)

-- 
-- 
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: Scant GTK3 documentation

[Kazunobu Kuriyama]

Hi Tony,

Thank you for all those checks!

2016-08-11 12:23 GMT+09:00 Tony Mechelynck :

> - GTK3 is supported, it is said, but there aren't a lot of details about it
> - It is only barely mentioned under ":help GTK3" in doc/gui_x11.txt
> - It is mentioned here and there in version8.txt, once at lines 137
> and 139, long below ":help new-8" and shortly before ":help
> new-vim-script-8", then here and there starting at patch 7.4.1402
> - It is nowhere mentioned in the possible configuration settings in
> the src/Makefile
>

All those, I'll see to it later.


> - Contrary to what "configure -h" seems to imply, AFAICT the only way
> to build with GTK3 is to require it explicitly by --enable-gui=gtk3
>

That's because, when the GTK3 patch was included, there was an agreement
(or no objection, more precisely) that, when both gtk2 and gtk3 are
available, the GTK2 GUI shall be selected as default.

Since I didn't think the current output of 'configure -h' caused a
confusion, I have little idea as to what caused that.  Do you have an
suggestion how we could improve that?


> - When both GTK2 and GTK3 are present in the system,
> disable-gtk2-check --enable-gtk3-check builds a Vim with no GUI
>

Oh, I didn't try those combination.  I'd rather like to know why those
--(enable|disable)-*-check options were introduced.  It looks --enable-gui=
is enough...  For the sake of completeness of the autodetection mechanism,
maybe?


> - In the same configuration, just «export
> CONF_OPT_GUI='enable-gnome-check'» (without the French quotes) gives a
> GTK2 GUI; GTK3 is not looked for.
> - When --enable-gui=gtk3 is present, then AFAICT --enable-gnome-check
> has no effect. (Maybe I don't have the right packages installed.)
>

Please note that the GTK3 GUI is completely independent of the Gnome 2
stuff.  This is because that stuff has been deprecated since the very early
version of Gnome 3 was released and was once said it would soon go away, I
intentionally wrote the patch in such a way that the GUI doesn't rely on
that.

Accordingly, the both cases look fine to me: If --enable-gnome-check is
selected, it's natural for us to conclude that the user wants the GTK2 GUI,
and if --enable-gui=3 is selected, the user don't want the Gnome stuff.

Still, if you find there's room for improvement, please let me know.

Best regards,
Kazunobu


> For the record, I'm on openSUSE 42.1 x86_64 and this is my first (but
> successful) attempt at building with GTK3: before, I used GTK2 with
> Gnome.
>
>
> Best regards,
> Tony.
>
> --
> --
> 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.
>

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