Re: [patch] Make the new MKDIR_P friendlier to 'make shadow'

[Kazunobu Kuriyama]

2017-04-23 4:21 GMT+09:00 Bram Moolenaar :

>
> Kazunobu Kuriyama wrote:
>
> > As of 8.0.0570, 'make shadow' cannot run properly for a fresh source tree
> > or after 'make distclean' is done.
> >
> > This is because MKDIR_P has been set only through auto/config.mk since
> > 8.0.0570.  As a result, for a fresh source tree or after 'make disclean'
> is
> > done, MKDIR_P remains undefined.
> >
> > The proposed patch restores the default 'MKDIR = mkdir -p', but places it
> > before 'include auto/config.mk'.   That way the patch fixes the issue as
> > well as allowing the script-detected thread-safe mkdir to overwrite the
> > default.
>
> I believe this is obsolete, now that MKDIR_P is defined in Makefile.
> Let me know if there is a remaining problem.
>

Yes, that's already obsolete, and I confirm that Patch 8.0.0576 fixes the
issue of this thread as well as that of the Patch 8.0.0.570 thread.

I don't have any further issue with it.

Hmm, it looks that my previous email arrived at you with some delay.  I
sent it to you hours after I sent another patch to the Patch 5.0.0570
thread but hours before you sent out Patch 8.0.0576.  I thought you
skillfully addressed the two issues all at once with a single patch of that
breath-taking neat solution and implicitly closed this issue as a matter of
course :)

Kazunobu

>
> --
> The early bird gets the worm. If you want something else for
> breakfast, get up later.
>
>  /// 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 8.0.0582

[Bram Moolenaar]

Patch 8.0.0582
Problem:Illegal memory access with z= command. (Dominique Pelle)
Solution:   Avoid case folded text to be longer than the original text.  Use
MB_PTR2LEN() instead of MB_BYTE2LEN().
Files:  src/spell.c, src/testdir/test_spell.vim


*** ../vim-8.0.0581/src/spell.c 2017-03-29 17:30:23.168136866 +0200
--- src/spell.c 2017-04-22 23:44:08.384237267 +0200
***
*** 3123,3129 
  
  if (has_mbyte)
  {
!   l = MB_BYTE2LEN(*p);
s = p;
if (l == 1)
{
--- 3123,3129 
  
  if (has_mbyte)
  {
!   l = MB_PTR2LEN(p);
s = p;
if (l == 1)
{
***
*** 3808,3813 
--- 3808,3817 
  vim_strncpy(su->su_badword, su->su_badptr, su->su_badlen);
  (void)spell_casefold(su->su_badptr, su->su_badlen,
su->su_fbadword, MAXWLEN);
+ /* TODO: make this work if the case-folded text is longer than the 
original
+  * text. Currently an illegal byte causes wrong pointer computations. */
+ su->su_fbadword[su->su_badlen] = NUL;
+ 
  /* get caps flags for bad word */
  su->su_badflags = badword_captype(su->su_badptr,
   su->su_badptr + su->su_badlen);
***
*** 4937,4948 
{
int l;
  
! #ifdef FEAT_MBYTE
!   if (has_mbyte)
!   l = MB_BYTE2LEN(fword[sp->ts_fidx]);
!   else
! #endif
!   l = 1;
if (fword_ends)
{
/* Copy the skipped character to preword. */
--- 4941,4947 
{
int l;
  
!   l = MB_PTR2LEN(fword + sp->ts_fidx);
if (fword_ends)
{
/* Copy the skipped character to preword. */
***
*** 5109,5117 
/* Correct ts_fidx for the byte length of the
 * character (we didn't check that before). */
sp->ts_fidx = sp->ts_fcharstart
!   + MB_BYTE2LEN(
!   fword[sp->ts_fcharstart]);
! 
/* For changing a composing character adjust
 * the score from SCORE_SUBST to
 * SCORE_SUBCOMP. */
--- 5108,5115 
/* Correct ts_fidx for the byte length of the
 * character (we didn't check that before). */
sp->ts_fidx = sp->ts_fcharstart
!   + MB_PTR2LEN(
!   fword + sp->ts_fcharstart);
/* For changing a composing character adjust
 * the score from SCORE_SUBST to
 * SCORE_SUBCOMP. */
***
*** 5232,5238 
if (has_mbyte)
{
c = mb_ptr2char(fword + sp->ts_fidx);
!   stack[depth].ts_fidx += MB_BYTE2LEN(fword[sp->ts_fidx]);
if (enc_utf8 && utf_iscomposing(c))
stack[depth].ts_score -= SCORE_DEL - SCORE_DELCOMP;
else if (c == mb_ptr2char(fword + stack[depth].ts_fidx))
--- 5230,5236 
if (has_mbyte)
{
c = mb_ptr2char(fword + sp->ts_fidx);
!   stack[depth].ts_fidx += MB_PTR2LEN(fword + sp->ts_fidx);
if (enc_utf8 && utf_iscomposing(c))
stack[depth].ts_score -= SCORE_DEL - SCORE_DELCOMP;
else if (c == mb_ptr2char(fword + stack[depth].ts_fidx))
***
*** 5456,5464 
  #ifdef FEAT_MBYTE
if (has_mbyte)
{
!   n = MB_BYTE2LEN(*p);
c = mb_ptr2char(p + n);
!   mch_memmove(p + MB_BYTE2LEN(p[n]), p, n);
mb_char2bytes(c, p);
}
else
--- 5454,5462 
  #ifdef FEAT_MBYTE
if (has_mbyte)
{
!   n = MB_PTR2LEN(p);
c = mb_ptr2char(p + n);
!   mch_memmove(p + MB_PTR2LEN(p + n), p, n);
mb_char2bytes(c, p);
}
else
***
*** 5550,5560 
  #ifdef FEAT_MBYTE
if (has_mbyte)
{
!   n = MB_BYTE2LEN(*p);
c2 = mb_ptr2char(p + n);
!   fl = MB_BYTE2LEN(p[n]);
c = mb_ptr2char(p + n + fl);
!   tl = MB_BYTE2LEN(p[n + fl]);
mch_memmove(p + fl + tl, p, n);
   

Patch 8.0.0581

[Bram Moolenaar]

Patch 8.0.0581
Problem:Moving folded text is sometimes not correct.
Solution:   Bail out when "move_end" is zero. (Matthew Malcomson)
Files:  src/fold.c, src/testdir/test_fold.vim


*** ../vim-8.0.0580/src/fold.c  2017-03-23 21:53:31.045117492 +0100
--- src/fold.c  2017-04-22 22:35:05.594898754 +0200
***
*** 3133,3142 
  dest_index = fold_index(fp, gap);
  
  /*
!  * All folds are now correct, but they are not necessarily in the correct
!  * order. We have to swap folds in the range [move_end, dest_index) with
!  * those in the range [move_start, move_end).
   */
  foldReverseOrder(gap, (linenr_T)move_start, (linenr_T)dest_index - 1);
  foldReverseOrder(gap, (linenr_T)move_start,
   (linenr_T)(move_start + dest_index - move_end - 1));
--- 3133,3146 
  dest_index = fold_index(fp, gap);
  
  /*
!  * All folds are now correct, but not necessarily in the correct order.  
We
!  * must swap folds in the range [move_end, dest_index) with those in the
!  * range [move_start, move_end).
   */
+ if (move_end == 0)
+   /* There are no folds after those moved, hence no folds have been moved
+* out of order. */
+   return;
  foldReverseOrder(gap, (linenr_T)move_start, (linenr_T)dest_index - 1);
  foldReverseOrder(gap, (linenr_T)move_start,
   (linenr_T)(move_start + dest_index - move_end - 1));
*** ../vim-8.0.0580/src/testdir/test_fold.vim   2017-03-21 11:48:33.630472643 
+0100
--- src/testdir/test_fold.vim   2017-04-22 22:34:45.135028119 +0200
***
*** 1,10 
  " Test for folding
  
! func! PrepIndent(arg)
return [a:arg] + repeat(["\t".a:arg], 5)
  endfu
  
! func! Test_address_fold()
new
call setline(1, ['int FuncName() {/*{{{*/', 1, 2, 3, 4, 5, '}/*}}}*/',
  \ 'after fold 1', 'after fold 2', 'after fold 3'])
--- 1,10 
  " Test for folding
  
! func PrepIndent(arg)
return [a:arg] + repeat(["\t".a:arg], 5)
  endfu
  
! func Test_address_fold()
new
call setline(1, ['int FuncName() {/*{{{*/', 1, 2, 3, 4, 5, '}/*}}}*/',
  \ 'after fold 1', 'after fold 2', 'after fold 3'])
***
*** 68,84 
quit!
  endfunc
  
! func! Test_indent_fold()
! new
! call setline(1, ['', 'a', 'b', 'c'])
! setl fen fdm=indent
! 2
! norm! >>
! let a=map(range(1,4), 'foldclosed(v:val)')
! call assert_equal([-1,-1,-1,-1], a)
! endfunc
! 
! func! Test_indent_fold()
  new
  call setline(1, ['', 'a', 'b', 'c'])
  setl fen fdm=indent
--- 68,74 
quit!
  endfunc
  
! func Test_indent_fold()
  new
  call setline(1, ['', 'a', 'b', 'c'])
  setl fen fdm=indent
***
*** 89,95 
  bw!
  endfunc
  
! func! Test_indent_fold2()
  new
  call setline(1, ['', '{{{', '}}}', '{{{', '}}}'])
  setl fen fdm=marker
--- 79,85 
  bw!
  endfunc
  
! func Test_indent_fold2()
  new
  call setline(1, ['', '{{{', '}}}', '{{{', '}}}'])
  setl fen fdm=marker
***
*** 122,128 
endfor
  endfunc
  
! func! Test_indent_fold_with_read()
new
set foldmethod=indent
call setline(1, repeat(["\a"], 4))
--- 112,118 
endfor
  endfunc
  
! func Test_indent_fold_with_read()
new
set foldmethod=indent
call setline(1, repeat(["\a"], 4))
***
*** 224,230 
set foldmethod& foldexpr&
  endfunc
  
! func! Test_move_folds_around_manual()
new
let input = PrepIndent("a") + PrepIndent("b") + PrepIndent("c")
call setline(1, PrepIndent("a") + PrepIndent("b") + PrepIndent("c"))
--- 214,224 
set foldmethod& foldexpr&
  endfunc
  
! func Check_foldlevels(expected)
!   call assert_equal(a:expected, map(range(1, line('$')), 'foldlevel(v:val)'))
! endfunc
! 
! func Test_move_folds_around_manual()
new
let input = PrepIndent("a") + PrepIndent("b") + PrepIndent("c")
call setline(1, PrepIndent("a") + PrepIndent("b") + PrepIndent("c"))
***
*** 293,303 
6m$
" The first fold has been truncated to the 5'th line.
" Second fold has been moved up because the moved line is now below it.
!   call assert_equal([0, 1, 1, 1, 1, 0, 0, 0, 1, 0], map(range(1, line('$')), 
'foldlevel(v:val)'))
bw!
  endfunc
  
! func! Test_move_folds_around_indent()
new
let input = PrepIndent("a") + PrepIndent("b") + PrepIndent("c")
call setline(1, PrepIndent("a") + PrepIndent("b") + PrepIndent("c"))
--- 287,336 
6m$
" The first fold has been truncated to the 5'th line.
" Second fold has been moved up because the moved line is now below it.
!   call Check_foldlevels([0, 1, 1, 1, 1, 0, 0, 0, 1, 0])
! 
!   %delete
!   set fdm=indent foldlevel=0
!   call setline(1, [
!   \ "a",
!   \ "\ta",
!   \ "\t\ta",
!   \ "\t\ta",
!   \ "\t\ta",
!   \ "a",
!   \ "a"])
!   set fdm=manual
!   %foldopen!
!   

Re: Patch 8.0.0574

[Yegappan Lakshmanan]

Hi Bram,

On Sat, Apr 22, 2017 at 6:43 AM, Bram Moolenaar  wrote:
>
> Yegappan Lakshmanan wrote:
>
>> On Thu, Apr 20, 2017 at 1:45 PM, Bram Moolenaar  wrote:
>> >
>> > Patch 8.0.0574
>> > Problem:Get only one quickfix list after :caddbuf.
>> > Solution:   Reset qf_multiline. (Yegappan Lakshmanan)
>> > Files:  src/quickfix.c, src/testdir/test_quickfix.vim
>>
>> This new function is not needed and is a duplicate. I have already
>> added these commands above with asserts.
>
> OK, I'll remove this function then.
>
> I'm still trying to figure out a memory leak in Test_qf_free().
> Didn't get further than pinpointing it to this function.
> Not sure when I'll have time to dig deeper.
>

I have located the memory leak when freeing a location list from the
location list window and the fix for it is attached.

- Yegappan

-- 
-- 
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/quickfix.c b/src/quickfix.c
index b28a321..b7b6129 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -4930,6 +4930,9 @@ qf_free_stack(win_T *wp, qf_info_T *qi)
 * location list */
qf_info_T *new_ll = ll_new_list();
 
+   /* first free the list reference in location list window */
+   ll_free_all(_wp->w_llist_ref);
+
orig_wp->w_llist_ref = new_ll;
if (llwin != NULL)
{

Re: [patch] Clean up Mac code

[Bram Moolenaar]

I wrote:

> Kazunobu Kuriyama wrote:
> 
> > > > [TL;DR]  I wish you rethink about this.  It seems there's
> > > misunderstanding
> > > > about the proposed patch.  Since I thought it was not the one on my
> > > pert, I
> > > > didn't address it to the feedback from Marvin.  But you still rase
> > > similar
> > > > concerns.  Now I'm going to try to address them at full length.   Since
> > > > it's pretty long, please read it at your convenient time.
> > >
> > > Sorry, this is too much to read.  Let's summarize.
> > >
> > > First of all, we need to keep all the existing values for has().
> > > Otherwise plugins break.  So keep has('gui_mac').
> > 
> > 
> > I'll keep intact the description of gui_mac in eval.txt.  Then, what should
> > we do with evalfunc.c:5670 where "gui_mac" is set as a member of has_list[]
> > when FEAT_GUI_MAC is defined?  My proposal was to remove it together with
> > the ifdef block.  Will we keep it there as-is or keep it there yet
> > replacing FEAT_GUI_MAC with 0 or a newly designated preprocessor symbol,
> > say SUPPORT_DISCONTINUED?
> 
> Wait, are you saying that FEAT_GUI_MAC would never be defined?  I
> thought that was still working if Carbon is available.  I suppose that's
> only on older systems.
> 
> Unfortunately os_mac.txt is totally unhelpful.  It points to macvim.org
> without mentioning anything about what version one gets there and for
> which system.  Also, the code names are not explained.  E.g., what is
> Darwin?  I believe it's the same as OS X.
> 
> Why don't we start with listing versions of Mac OS and what versions of
> Vim one can build on it.  I guess we only support OS X.  Mac OS 9 was
> released in 1999, OS X in 2001.  Even my very old Powerbook G4 has OS X.
> I managed to make it startup again.  It has the GUI with Vim 7.2. When I
> have time I'll try later versions.

Unfortunately, it looks like the harddisk died just now.  So I won't be
able to try out things on OS X 10.4.  I hope someone else has an older
OS X version to verify the Carbon code still works.

-- 
If your life is a hard drive,
Christ can be your backup.

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

[Bram Moolenaar]

Patch 8.0.0580
Problem:Cannot set the valid flag with setqflist().
Solution:   Add the "valid" argument. (Yegappan Lakshmanan, closes #1642)
Files:  runtime/doc/eval.txt, src/quickfix.c,
src/testdir/test_quickfix.vim


*** ../vim-8.0.0579/runtime/doc/eval.txt2017-04-03 22:02:51.778787637 
+0200
--- runtime/doc/eval.txt2017-04-22 21:15:38.693001351 +0200
***
*** 6905,6910 
--- 6945,6951 
nr  error number
textdescription of the error
typesingle-character error type, 'E', 'W', etc.
+   valid   recognized error message
  
The "col", "vcol", "nr", "type" and "text" entries are
optional.  Either "lnum" or "pattern" entry can be used to
***
*** 6914,6919 
--- 6955,6962 
item will not be handled as an error line.
If both "pattern" and "lnum" are present then "pattern" will
be used.
+   If the "valid" entry is not supplied, then the valid flag is
+   set when "bufnr" is a valid buffer or "filename" exists.
If you supply an empty {list}, the quickfix list will be
cleared.
Note that the list is not exactly the same as what
*** ../vim-8.0.0579/src/quickfix.c  2017-04-20 22:44:42.600262225 +0200
--- src/quickfix.c  2017-04-22 21:16:46.232576623 +0200
***
*** 4779,4784 
--- 4779,4788 
bufnum = 0;
}
  
+   /* If the 'valid' field is present it overrules the detected value. */
+   if ((dict_find(d, (char_u *)"valid", -1)) != NULL)
+   valid = (int)get_dict_number(d, (char_u *)"valid");
+ 
status =  qf_add_entry(qi,
   NULL,/* dir */
   filename,
*** ../vim-8.0.0579/src/testdir/test_quickfix.vim   2017-04-22 
15:42:48.969317185 +0200
--- src/testdir/test_quickfix.vim   2017-04-22 21:13:07.257953882 +0200
***
*** 1201,1206 
--- 1201,1225 
let l = g:Xgetlist()
call assert_equal(0, len(l))
  
+   " Tests for setting the 'valid' flag
+   call g:Xsetlist([{'bufnr':a:bnum, 'lnum':4, 'valid':0}])
+   Xwindow
+   call assert_equal(1, winnr('$'))
+   let l = g:Xgetlist()
+   call g:Xsetlist(l)
+   call assert_equal(0, g:Xgetlist()[0].valid)
+   call g:Xsetlist([{'text':'Text1', 'valid':1}])
+   Xwindow
+   call assert_equal(2, winnr('$'))
+   Xclose
+   let save_efm = 
+   set efm=%m
+   Xgetexpr 'TestMessage'
+   let l = g:Xgetlist()
+   call g:Xsetlist(l)
+   call assert_equal(1, g:Xgetlist()[0].valid)
+   let  = save_efm
+ 
" Error cases:
" Refer to a non-existing buffer and pass a non-dictionary type
call assert_fails("call g:Xsetlist([{'bufnr':998, 'lnum':4}," .
*** ../vim-8.0.0579/src/version.c   2017-04-22 15:42:48.969317185 +0200
--- src/version.c   2017-04-22 21:14:33.493411421 +0200
***
*** 766,767 
--- 766,769 
  {   /* Add new patch number below this line */
+ /**/
+ 580,
  /**/

-- 
FATHER: We are here today to witness the union of two young people in the
joyful bond of the holy wedlock.  Unfortunately, one of them, my son
Herbert, has just fallen to his death.
   [Murmurs from CROWD;  the BRIDE smiles with relief, coughs.]
 "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: [patch] Make the new MKDIR_P friendlier to 'make shadow'

[Bram Moolenaar]

Kazunobu Kuriyama wrote:

> As of 8.0.0570, 'make shadow' cannot run properly for a fresh source tree
> or after 'make distclean' is done.
> 
> This is because MKDIR_P has been set only through auto/config.mk since
> 8.0.0570.  As a result, for a fresh source tree or after 'make disclean' is
> done, MKDIR_P remains undefined.
> 
> The proposed patch restores the default 'MKDIR = mkdir -p', but places it
> before 'include auto/config.mk'.   That way the patch fixes the issue as
> well as allowing the script-detected thread-safe mkdir to overwrite the
> default.

I believe this is obsolete, now that MKDIR_P is defined in Makefile.
Let me know if there is a remaining problem.

-- 
The early bird gets the worm. If you want something else for
breakfast, get up later.

 /// 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] quickfix entry with ='%m' from cgetexpr is valid, but invalid with setqflist (#1642)

[Bram Moolenaar]

Yegappan wrote:

> On Thu, Apr 20, 2017 at 7:29 PM, Yegappan Lakshmanan
>  wrote:
> > Hi,
> >
> > On Wed, Apr 19, 2017 at 4:23 PM, Daniel Hahler
> >  wrote:
> >> It might also be possible to allow for setting valid?!
> >>
> >> Are you referring to changing the setqflist() function to accept the valid
> >> flag field and not checking for a valid file name and a line number?
> >>
> >> Yes.
> >> This way you could set this flag yourself in general, but it would fix the
> >> issue at hand (since valid is contained already, and would be used as-is
> >> when passing it to setqflist()).
> >>
> >
> > The attached patch implements the support for setting the 'valid' flag
> > using the setqflist() function and tests for this functionality.
> >
> 
> Attaching an updated patch with the documentation update.

Thanks!

-- 
GUEST:He's killed the best man!
SECOND GUEST: (holding a limp WOMAN) He's killed my auntie.
FATHER:   No, please!  This is supposed to be a happy occasion!  Let's
  not bicker and argue about who killed who ...
 "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: [patch] Clean up Mac code

[Christian Brabandt]

On So, 23 Apr 2017, Kazunobu Kuriyama wrote:

> I do wish someone on Linux comes up and works for the GUIs, taking
> over the role I'm now playing for Vim.  Till then, I want to continue
> working with Mac.  For that purpose, I want to make my work more
> efficient and productive.  That's my primary reason why I'm now trying
> to improve the code of Vim for Mac, though I have little complaint
> about the performance and functionality of the current Vim.

And that is really appreciated! I am glad that you are there and can 
look into gui specific features and bugs as I don't feel competent 
enough to do so, so I am happy that you do. So let me thanks for all the 
effort you are putting into maintaining the GUI stuff.

> TBH, I rather feel like working for them and myself than people
> invisible from me, though I don't deny the existence of them at all.

Understandable.

Mit freundlichen Grüßen
Christian
-- 
Ein schwacher Verstand ist wie ein Mikroskop, das Kleinigkeiten
vergrößert und große Dinge nicht erfaßt.
-- Lord Chesterfield

-- 
-- 
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: Patch 8.0.0275

[Christian Brabandt]

On Sa, 22 Apr 2017, Bram Moolenaar wrote:

> We do need to append a NUL to key_name!

Thanks for fixing this for me. I somehow thought it would be initialized 
with NUL.

Best,
Christian
-- 
Das beste vom Sonntag ist der Samstagabend.

-- 
-- 
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: [patch] Clean up Mac code

[Manuel Ortega]

On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2017-04-23 0:02 GMT+09:00 Manuel Ortega :
>
>> On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar :
>>>


 The terms "with darwin" and "without darwin" are very confusing.  There
 is no help for "darwin". Cleaning that up sounds like a good idea.

>>>
>>> OK, I'll add some explanation on the darwin feature to os_mac.txt, and
>>> make links between that and the terms.
>>>
>>
>> I seem to remember, from a while back, that "disabling darwin" has a
>> bigger effect than just disconnecting Vim from the macOS clipboard.
>> Something about it messed up (believe it or not) the precomposition (or
>> lack thereof) of unicode, particularly when one did something like ":r
>> !some-cmd".  I think there was a report about this on the vim_mac list a
>> long time ago.
>>
>
> Wasn't that issue fixed later?  I don't see any glitch with
> --disable-darwin build for these 6 years...
>

No, it was not.  I'm not sure if it's a bug, but Vim behaves differently
regarding Unicode precomposition depending on whether --disable-darwin is
passed.

If I `touch` some nonACII filenames like "föo" and "bár" (in a terminal
operating in utf-8), and then fire up vim in that directory where the
touches happened, and then do:
   :let @a = glob("*") | put a

Then doing a `ga` (or `g8`) over the multibyte characters will display
something different depending on whether --disable-darwin was passed or not.

If --disable-darwin is passed during build, then:
  * `ga` over the "ö" in "föo" shows:
111,  Hex 6f,  Octal 157 < ̈> 776, Hex 0308, Octal 1410
  * `g8` over that same character shows: 6f + cc 88

If --disable-darwin is NOT passed during build, then the same operations
show:
  * `ga`: <ö> 246, Hex 00f6, Octal 366
  * `g8`: c3 b6

Again, I don't know whether this is an actual *bug* (or *why* it's
happening), but it just isn't true that the only difference between
--disable-darwin or --enable-darwin is the clipboard.  There is more at
work, and it should be documented to the extent anyone can figure out
what's going on.

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

Re: [patch] Clean up Mac code

[Manuel Ortega]

On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2017-04-23 0:02 GMT+09:00 Manuel Ortega :
>
>> On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar :
>>>


 The terms "with darwin" and "without darwin" are very confusing.  There
 is no help for "darwin". Cleaning that up sounds like a good idea.

>>>
>>> OK, I'll add some explanation on the darwin feature to os_mac.txt, and
>>> make links between that and the terms.
>>>
>>
>> I seem to remember, from a while back, that "disabling darwin" has a
>> bigger effect than just disconnecting Vim from the macOS clipboard.
>> Something about it messed up (believe it or not) the precomposition (or
>> lack thereof) of unicode, particularly when one did something like ":r
>> !some-cmd".  I think there was a report about this on the vim_mac list a
>> long time ago.
>>
>
> Wasn't that issue fixed later?  I don't see any glitch with
> --disable-darwin build for these 6 years...
>
>
>>
>> Still, prior to making the suggested list, I think we should first remove
>>> the code relevant to Mac OS 9 and the Carbon GUI.  Please allow me to
>>> reiterate them:
>>>
>>> version7.txt:108 (2005-12-06, 241a8aaa48):
>>> "The support for Mac OS 9 has been removed."
>>>
>>>
>>> src/configure.ac:2231  (2010-07-14, 164fca39bd):
>>> "AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"
>>>
>>> They are backlogs overdue.
>>>
>>>
 How about Carbon?  On my Mac air it appears not to work, Quickdraw.h is
 missing.

>>>
>>> They say that Carbon wasn't updated to support 64-bit.  So current
>>> Carbon Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in
>>> a 64-bit environment for one reason or another.  I'm definitely the last
>>> person of this kind.
>>>
>>> And, as you noticed, our build system hasn't maintained in a way to
>>> support it.
>>>
>>
>> I think Carbon Vim was destroyed in three phases:  First, the Carbon code
>>> was alienated from the codebase when the darwin feature is merged there on
>>> 2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
>>> Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
>>> AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
>>> effort for the Carbon code at any rate.
>>>
>>> IIRC, we haven't received any report, patch or request on the breakage
>>> relevant to the Carbon code so far.
>>>
>>> in conclusion, unless someone is willing to work for that, we are no
>>> longer able to maintain it.  Personally, I think it's nearly impossible to
>>> restore it.
>>>
>>
>> I think you are underestimating the Carbon build.  The Carbon GUI is only
>> broken for recent versions of macOS, where there is independently no reason
>> to ask for it because there is MacVim which is infinitely superior.  There
>> is no "work needed to restore it", because there is no need to restore it,
>> because it builds fine on 10.8 and under (and will even run on macOS
>> Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I
>> know it works just fine even on macOS 10.4 and 10.5.
>>
>
> Alas, the reason why I mentioned the exact versions and dates was to avoid
> this sort of misunderstanding...
>

What misunderstanding is that?  You listed versions and dates and then,
despite the fact that the Carbon GUI is usable for older Macs, declared
that we should get rid of it---on the grounds that (1) it doesn't work
anymore and would be nearly impossible to "restore", and (2) that the
Carbon GUI is only for people with 64 bit Macs who nevertheless want a
32bit Vim GUI (and that (3) you are *definitely* the only such person
anyway).

(2) and (3) are false, and (1) doesn't apply in the slightest to older Macs
(10.4-10.6 at *least*, maybe even up to 10.8), which are not ancient or
obscure compared to the sort of stuff that Vim generally bends over
backwards to support.

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

Re: [patch] Clean up Mac code

[Kazunobu Kuriyama]

2017-04-23 0:02 GMT+09:00 Manuel Ortega :

> On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
> kazunobu.kuriy...@gmail.com> wrote:
>
>> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar :
>>
>>>
>>>
>>> The terms "with darwin" and "without darwin" are very confusing.  There
>>> is no help for "darwin". Cleaning that up sounds like a good idea.
>>>
>>
>> OK, I'll add some explanation on the darwin feature to os_mac.txt, and
>> make links between that and the terms.
>>
>
> I seem to remember, from a while back, that "disabling darwin" has a
> bigger effect than just disconnecting Vim from the macOS clipboard.
> Something about it messed up (believe it or not) the precomposition (or
> lack thereof) of unicode, particularly when one did something like ":r
> !some-cmd".  I think there was a report about this on the vim_mac list a
> long time ago.
>

Wasn't that issue fixed later?  I don't see any glitch with
--disable-darwin build for these 6 years...


>
> Still, prior to making the suggested list, I think we should first remove
>> the code relevant to Mac OS 9 and the Carbon GUI.  Please allow me to
>> reiterate them:
>>
>> version7.txt:108 (2005-12-06, 241a8aaa48):
>> "The support for Mac OS 9 has been removed."
>>
>>
>> src/configure.ac:2231  (2010-07-14, 164fca39bd):
>> "AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"
>>
>> They are backlogs overdue.
>>
>>
>>> How about Carbon?  On my Mac air it appears not to work, Quickdraw.h is
>>> missing.
>>>
>>
>> They say that Carbon wasn't updated to support 64-bit.  So current Carbon
>> Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in a
>> 64-bit environment for one reason or another.  I'm definitely the last
>> person of this kind.
>>
>> And, as you noticed, our build system hasn't maintained in a way to
>> support it.
>>
>
> I think Carbon Vim was destroyed in three phases:  First, the Carbon code
>> was alienated from the codebase when the darwin feature is merged there on
>> 2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
>> Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
>> AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
>> effort for the Carbon code at any rate.
>>
>> IIRC, we haven't received any report, patch or request on the breakage
>> relevant to the Carbon code so far.
>>
>> in conclusion, unless someone is willing to work for that, we are no
>> longer able to maintain it.  Personally, I think it's nearly impossible to
>> restore it.
>>
>
> I think you are underestimating the Carbon build.  The Carbon GUI is only
> broken for recent versions of macOS, where there is independently no reason
> to ask for it because there is MacVim which is infinitely superior.  There
> is no "work needed to restore it", because there is no need to restore it,
> because it builds fine on 10.8 and under (and will even run on macOS
> Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I
> know it works just fine even on macOS 10.4 and 10.5.
>

Alas, the reason why I mentioned the exact versions and dates was to avoid
this sort of misunderstanding...


> Maybe the reason there haven't been bug reports is because the people that
> have a reason to use it are using it on a machine for which it still
> works.  Why would anyone be using a machine that's 32 bit and with an older
> macOS?  Because the machines still work fine for doing work in a text
> editor, even though they're not good for internet videos or photoshop.
>
> On top of this, people on 10.7 and less have been ruthlessly dumped by
> MacVim.  (You can bet it won't be long before the trigger-happy MacVim devs
> dump 10.8 and 10.9).  This means those people would have no Vim GUI
> whatsoever if you dump the Carbon GUI.  (The X11 GUI on the Mac is worse
> than nothing, which is not Vim's fault, but is because of the X11
> emulators.)
>

Believe or not, the GTK+ 3 GUI was fully developed on XQuartz running on OS
X.  Actually, almost all of recent implementation changes in the X11-based
GUIs (Athena, Motif, GTK+ 2 and 3) were all developed and tested, and the
resulting patches were sent to vim_dev.  XQuartz is not an emulator, but a
full-fledge implementation of X11 for OS X.

I do wish someone on Linux comes up and works for the GUIs, taking over the
role I'm now playing for Vim.  Till then, I want to continue working with
Mac.  For that purpose, I want to make my work more efficient and
productive.  That's my primary reason why I'm now trying to improve the
code of Vim for Mac, though I have little complaint about the performance
and functionality of the current Vim.

Recently, I often com across a lot of pictures of Vim running on Mac and
Mac-related Vim questions at user forums on the Internet.  Though I don't
have any of statistics, it seems that vimmers on Mac have been rapidly
increasing in number.  Maybe, code and documents that are well 

Re: [patch] Clean up Mac code

[Bram Moolenaar]

Kazunobu Kuriyama wrote:

> > > [TL;DR]  I wish you rethink about this.  It seems there's
> > misunderstanding
> > > about the proposed patch.  Since I thought it was not the one on my
> > pert, I
> > > didn't address it to the feedback from Marvin.  But you still rase
> > similar
> > > concerns.  Now I'm going to try to address them at full length.   Since
> > > it's pretty long, please read it at your convenient time.
> >
> > Sorry, this is too much to read.  Let's summarize.
> >
> > First of all, we need to keep all the existing values for has().
> > Otherwise plugins break.  So keep has('gui_mac').
> 
> 
> I'll keep intact the description of gui_mac in eval.txt.  Then, what should
> we do with evalfunc.c:5670 where "gui_mac" is set as a member of has_list[]
> when FEAT_GUI_MAC is defined?  My proposal was to remove it together with
> the ifdef block.  Will we keep it there as-is or keep it there yet
> replacing FEAT_GUI_MAC with 0 or a newly designated preprocessor symbol,
> say SUPPORT_DISCONTINUED?

Wait, are you saying that FEAT_GUI_MAC would never be defined?  I
thought that was still working if Carbon is available.  I suppose that's
only on older systems.

Unfortunately os_mac.txt is totally unhelpful.  It points to macvim.org
without mentioning anything about what version one gets there and for
which system.  Also, the code names are not explained.  E.g., what is
Darwin?  I believe it's the same as OS X.

Why don't we start with listing versions of Mac OS and what versions of
Vim one can build on it.  I guess we only support OS X.  Mac OS 9 was
released in 1999, OS X in 2001.  Even my very old Powerbook G4 has OS X.
I managed to make it startup again.  It has the GUI with Vim 7.2. When I
have time I'll try later versions.

For MacVim there is only one version, right?  We should figure out what
macros are relevant for it.

> > I can't remember why we had has('mac') return false on any Mac OS.
> > Also having it return true for OS/X is most likely OK.
> 
> Let's make has('mac') work just the way people expect.  As I proposed
> previously, the meaning of has('macunix') won't change.
> 
> > The terms "with darwin" and "without darwin" are very confusing.  There
> > is no help for "darwin". Cleaning that up sounds like a good idea.
> 
> OK, I'll add some explanation on the darwin feature to os_mac.txt, and make
> links between that and the terms.

Thanks.

> > For the preprocessor symbols: Let's first list all the possible ways Vim
> > can be compiled for the Mac.  For as far as that matters (I suppose the
> > ppc vs intel choice only matters for compiler flags).  The
> > --disable-darwin configure argument changes a few things.
> 
> Still, prior to making the suggested list, I think we should first remove
> the code relevant to Mac OS 9 and the Carbon GUI.  Please allow me to
> reiterate them:
> 
> version7.txt:108 (2005-12-06, 241a8aaa48):
> "The support for Mac OS 9 has been removed."
> 
> 
> src/configure.ac:2231  (2010-07-14, 164fca39bd):
> "AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"
> 
> They are backlogs overdue.

Mac OS 9 probably is irrelevant.  But Carbon might still work.  My old
Powerbook has OS X 10.4 (Tiger).  I believe it was supported up to OX X
10.8, so that's a wide range of systems.

> > How about Carbon?  On my Mac air it appears not to work, Quickdraw.h is
> > missing.
> 
> They say that Carbon wasn't updated to support 64-bit.  So current Carbon
> Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in a
> 64-bit environment for one reason or another.  I'm definitely the last
> person of this kind.
> 
> And, as you noticed, our build system hasn't maintained in a way to support
> it.
> 
> I think Carbon Vim was destroyed in three phases:  First, the Carbon code
> was alienated from the codebase when the darwin feature is merged there on
> 2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
> Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
> AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
> effort for the Carbon code at any rate.

Hmm, so the Carbon code might already be broken?  I haven't heard
complaints, so perhaps it's not worth fixing.

> IIRC, we haven't received any report, patch or request on the breakage
> relevant to the Carbon code so far.
> 
> in conclusion, unless someone is willing to work for that, we are no longer
> able to maintain it.  Personally, I think it's nearly impossible to restore
> it.

How about Cocoa support?  Is that only in MacVim?

> > Anyway, I think this change should be split into smaller pieces to make
> > it easier to see what changes.
> 
> So my current plain consists of four phases:
> 
> (1) Removal of MACOS_CLASSIC related code and adjustments of the build
> system.

That makes sense.

> (2) Removal of FEAT_GUI_MAC related code and adjustments of the build
> system.

This is Carbon support, right?  I wonder if we can make this 

Re: [patch] Clean up Mac code

[Manuel Ortega]

On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar :
>
>>
>>
>> The terms "with darwin" and "without darwin" are very confusing.  There
>> is no help for "darwin". Cleaning that up sounds like a good idea.
>>
>
> OK, I'll add some explanation on the darwin feature to os_mac.txt, and
> make links between that and the terms.
>

I seem to remember, from a while back, that "disabling darwin" has a bigger
effect than just disconnecting Vim from the macOS clipboard.  Something
about it messed up (believe it or not) the precomposition (or lack thereof)
of unicode, particularly when one did something like ":r !some-cmd".  I
think there was a report about this on the vim_mac list a long time ago.

Still, prior to making the suggested list, I think we should first remove
> the code relevant to Mac OS 9 and the Carbon GUI.  Please allow me to
> reiterate them:
>
> version7.txt:108 (2005-12-06, 241a8aaa48):
> "The support for Mac OS 9 has been removed."
>
>
> src/configure.ac:2231  (2010-07-14, 164fca39bd):
> "AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"
>
> They are backlogs overdue.
>
>
>> How about Carbon?  On my Mac air it appears not to work, Quickdraw.h is
>> missing.
>>
>
> They say that Carbon wasn't updated to support 64-bit.  So current Carbon
> Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in a
> 64-bit environment for one reason or another.  I'm definitely the last
> person of this kind.
>
> And, as you noticed, our build system hasn't maintained in a way to
> support it.
>

I think Carbon Vim was destroyed in three phases:  First, the Carbon code
> was alienated from the codebase when the darwin feature is merged there on
> 2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
> Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
> AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
> effort for the Carbon code at any rate.
>
> IIRC, we haven't received any report, patch or request on the breakage
> relevant to the Carbon code so far.
>
> in conclusion, unless someone is willing to work for that, we are no
> longer able to maintain it.  Personally, I think it's nearly impossible to
> restore it.
>

I think you are underestimating the Carbon build.  The Carbon GUI is only
broken for recent versions of macOS, where there is independently no reason
to ask for it because there is MacVim which is infinitely superior.  There
is no "work needed to restore it", because there is no need to restore it,
because it builds fine on 10.8 and under (and will even run on macOS
Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I
know it works just fine even on macOS 10.4 and 10.5.

Maybe the reason there haven't been bug reports is because the people that
have a reason to use it are using it on a machine for which it still
works.  Why would anyone be using a machine that's 32 bit and with an older
macOS?  Because the machines still work fine for doing work in a text
editor, even though they're not good for internet videos or photoshop.

On top of this, people on 10.7 and less have been ruthlessly dumped by
MacVim.  (You can bet it won't be long before the trigger-happy MacVim devs
dump 10.8 and 10.9).  This means those people would have no Vim GUI
whatsoever if you dump the Carbon GUI.  (The X11 GUI on the Mac is worse
than nothing, which is not Vim's fault, but is because of the X11
emulators.)

It may be that when all is said and done Carbon should still be dumped
anyway, but it is not true that (a) nobody uses it, or (b) that nobody
*could* use it, or (c) that keeping it would require a lot of work.

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

Re: Patch 8.0.0574

[Bram Moolenaar]

Yegappan Lakshmanan wrote:

> On Thu, Apr 20, 2017 at 1:45 PM, Bram Moolenaar  wrote:
> >
> > Patch 8.0.0574
> > Problem:Get only one quickfix list after :caddbuf.
> > Solution:   Reset qf_multiline. (Yegappan Lakshmanan)
> > Files:  src/quickfix.c, src/testdir/test_quickfix.vim
> >
> >
> > *** ../vim-8.0.0573/src/testdir/test_quickfix.vim   2017-04-02 
> > 15:15:44.825083189 +0200
> > --- src/testdir/test_quickfix.vim   2017-04-20 22:37:45.246969386 +0200
> > ***
> > *** 1057,1062 
> > --- 1085,1109 
> > call assert_equal(1, l[4].valid)
> > call assert_equal('unittests/dbfacadeTest.py', bufname(l[4].bufnr))
> >
> > +   " The following sequence of commands used to crash Vim
> > +   set efm=%W%m
> > +   cgetexpr ['msg1']
> > +   let l = getqflist()
> > +   call assert_equal(1, len(l), string(l))
> > +   call assert_equal('msg1', l[0].text)
> > +   set efm=%C%m
> > +   lexpr 'msg2'
> > +   let l = getloclist(0)
> > +   call assert_equal(1, len(l), string(l))
> > +   call assert_equal('msg2', l[0].text)
> > +   lopen
> > +   call setqflist([], 'r')
> > +   caddbuf
> > +   let l = getqflist()
> > +   call assert_equal(1, len(l), string(l))
> > +   call assert_equal('|| msg2', l[0].text)
> > +
> > +   new | only
> > let  = save_efm
> >   endfunc
> >
> > ***
> > *** 1975,1977 
> > --- 2022,2036 
> > call XfreeTests('c')
> > call XfreeTests('l')
> >   endfunc
> > +
> > + func Test_no_reuse_mem()
> >
> 
> This new function is not needed and is a duplicate. I have already
> added these commands above with asserts.

OK, I'll remove this function then.

I'm still trying to figure out a memory leak in Test_qf_free().
Didn't get further than pinpointing it to this function.
Not sure when I'll have time to dig deeper.


-- 
-rwxr-xr-x  1 root  24 Oct 29  1929 /bin/ed
-rwxr-xr-t  4 root  131720 Jan  1  1970 /usr/ucb/vi
-rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

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

[Bram Moolenaar]

Patch 8.0.0579
Problem:Duplicate test case for quickfix.
Solution:   Remove the function. (Yegappan Lakshmanan)
Files:  src/testdir/test_quickfix.vim


*** ../vim-8.0.0578/src/testdir/test_quickfix.vim   2017-04-20 
22:44:42.600262225 +0200
--- src/testdir/test_quickfix.vim   2017-04-22 15:39:55.290403923 +0200
***
*** 2022,2036 
call XfreeTests('c')
call XfreeTests('l')
  endfunc
- 
- func Test_no_reuse_mem()
-   set efm=E,%W%m,
-   cgetexpr ['C']
-   set efm=%C%m
-   lexpr '0'
-   lopen
-   call setqflist([], 'r')
-   caddbuf
- 
-   set efm&
- endfunc
--- 2022,2024 
*** ../vim-8.0.0578/src/version.c   2017-04-22 15:17:36.122798042 +0200
--- src/version.c   2017-04-22 15:40:41.130117058 +0200
***
*** 766,767 
--- 766,769 
  {   /* Add new patch number below this line */
+ /**/
+ 579,
  /**/

-- 
5 out of 4 people have trouble with fractions.

 /// 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: Patch 8.0.0275

[Bram Moolenaar]

Christian Brabandt wrote:

> On Do, 20 Apr 2017, Bram Moolenaar wrote:
> 
> > How about using K_IGNORE instead?  In the input buffer that's K_SPECIAL
> > KS_EXTRA KE_IGNORE (three bytes).
> 
> Thanks that helps. How about this patch then:
> 
> diff --git a/src/gui_w32.c b/src/gui_w32.c
> index fc566abee..4d9eaab92 100644
> --- a/src/gui_w32.c
> +++ b/src/gui_w32.c
> @@ -2627,7 +2627,9 @@ gui_mch_set_curtab(int nr)
>  void
>  ex_simalt(exarg_T *eap)
>  {
> -char_u *keys = eap->arg;
> +char_u *keys = eap->arg;
> +intfill_typebuf = FALSE;
> +char_u key_name[3];
> 
>  PostMessage(s_hwnd, WM_SYSCOMMAND, (WPARAM)SC_KEYMENU, (LPARAM)0);
>  while (*keys)
> @@ -2636,6 +2638,15 @@ ex_simalt(exarg_T *eap)
> *keys = ' ';/* for showing system menu */
> PostMessage(s_hwnd, WM_CHAR, (WPARAM)*keys, (LPARAM)0);
> keys++;
> +   fill_typebuf = TRUE;
> +}
> +if (fill_typebuf)
> +{
> +   key_name[0] = K_SPECIAL;
> +   key_name[1] = KS_EXTRA;
> +   key_name[2] = KE_IGNORE;
> +   typebuf_was_filled = TRUE;
> +   (void)ins_typebuf(key_name, REMAP_NONE, 0, TRUE, FALSE);
>  }
>  }
> 
> 
> In fact, even simply setting typebuf_was_filled seems to be enough. 
> However, as I don't know what the input typebuf will then look like, I 
> added the K_IGNORE as suggested.

Not sure if that makes a difference, would depend on from where
ex_simalt() was called.

We do need to append a NUL to key_name!

-- 
MARTHA'S WAY: Don't throw out all that leftover wine. Freeze into ice cubes
  for future use in casseroles and sauces.
MY WAY:   What leftover wine?

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

[Bram Moolenaar]

Patch 8.0.0578
Problem::simalt on MS-Windows does not work properly.
Solution:   Put something in the typeahead buffer. (Christian Brabandt)
Files:  src/gui_w32.c


*** ../vim-8.0.0577/src/gui_w32.c   2017-03-12 20:09:59.476468319 +0100
--- src/gui_w32.c   2017-04-22 15:13:30.164337859 +0200
***
*** 2627,2633 
  void
  ex_simalt(exarg_T *eap)
  {
! char_u *keys = eap->arg;
  
  PostMessage(s_hwnd, WM_SYSCOMMAND, (WPARAM)SC_KEYMENU, (LPARAM)0);
  while (*keys)
--- 2627,2635 
  void
  ex_simalt(exarg_T *eap)
  {
! char_u*keys = eap->arg;
! int   fill_typebuf = FALSE;
! char_ukey_name[4];
  
  PostMessage(s_hwnd, WM_SYSCOMMAND, (WPARAM)SC_KEYMENU, (LPARAM)0);
  while (*keys)
***
*** 2636,2641 
--- 2638,2655 
*keys = ' ';/* for showing system menu */
PostMessage(s_hwnd, WM_CHAR, (WPARAM)*keys, (LPARAM)0);
keys++;
+   fill_typebuf = TRUE;
+ }
+ if (fill_typebuf)
+ {
+   /* Put something in the typeahead buffer so that the message will get
+* processed. */
+   key_name[0] = K_SPECIAL;
+   key_name[1] = KS_EXTRA;
+   key_name[2] = KE_IGNORE;
+   key_name[3] = NUL;
+   typebuf_was_filled = TRUE;
+   (void)ins_typebuf(key_name, REMAP_NONE, 0, TRUE, FALSE);
  }
  }
  
*** ../vim-8.0.0577/src/version.c   2017-04-21 23:18:22.246279788 +0200
--- src/version.c   2017-04-22 15:16:50.279085920 +0200
***
*** 766,767 
--- 766,769 
  {   /* Add new patch number below this line */
+ /**/
+ 578,
  /**/

-- 
BLACK KNIGHT:  Come on you pansy!
[hah] [parry thrust]
[ARTHUR chops the BLACK KNIGHT's right arm off]
ARTHUR:Victory is mine!  [kneeling]
   We thank thee Lord, that in thy merc-
[Black Knight kicks Arthur in the head while he is praying]
  The Quest for the Holy Grail (Monty Python)

 /// 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: [patch] Clean up Mac code

[Kazunobu Kuriyama]

2017-04-21 1:48 GMT+09:00 Bram Moolenaar :

>
> Kazunobu Kuriyama wrote:
>
> > [TL;DR]  I wish you rethink about this.  It seems there's
> misunderstanding
> > about the proposed patch.  Since I thought it was not the one on my
> pert, I
> > didn't address it to the feedback from Marvin.  But you still rase
> similar
> > concerns.  Now I'm going to try to address them at full length.   Since
> > it's pretty long, please read it at your convenient time.
>
> Sorry, this is too much to read.  Let's summarize.
>
> First of all, we need to keep all the existing values for has().
> Otherwise plugins break.  So keep has('gui_mac').


I'll keep intact the description of gui_mac in eval.txt.  Then, what should
we do with evalfunc.c:5670 where "gui_mac" is set as a member of has_list[]
when FEAT_GUI_MAC is defined?  My proposal was to remove it together with
the ifdef block.  Will we keep it there as-is or keep it there yet
replacing FEAT_GUI_MAC with 0 or a newly designated preprocessor symbol,
say SUPPORT_DISCONTINUED?


> I can't remember why we had has('mac') return false on any Mac OS.
> Also having it return true for OS/X is most likely OK.
>

Let's make has('mac') work just the way people expect.  As I proposed
previously, the meaning of has('macunix') won't change.


> The terms "with darwin" and "without darwin" are very confusing.  There
> is no help for "darwin". Cleaning that up sounds like a good idea.
>

OK, I'll add some explanation on the darwin feature to os_mac.txt, and make
links between that and the terms.


> For the preprocessor symbols: Let's first list all the possible ways Vim
> can be compiled for the Mac.  For as far as that matters (I suppose the
> ppc vs intel choice only matters for compiler flags).  The
> --disable-darwin configure argument changes a few things.
>

Still, prior to making the suggested list, I think we should first remove
the code relevant to Mac OS 9 and the Carbon GUI.  Please allow me to
reiterate them:

version7.txt:108 (2005-12-06, 241a8aaa48):
"The support for Mac OS 9 has been removed."


src/configure.ac:2231  (2010-07-14, 164fca39bd):
"AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"

They are backlogs overdue.


> How about Carbon?  On my Mac air it appears not to work, Quickdraw.h is
> missing.
>

They say that Carbon wasn't updated to support 64-bit.  So current Carbon
Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in a
64-bit environment for one reason or another.  I'm definitely the last
person of this kind.

And, as you noticed, our build system hasn't maintained in a way to support
it.

I think Carbon Vim was destroyed in three phases:  First, the Carbon code
was alienated from the codebase when the darwin feature is merged there on
2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
effort for the Carbon code at any rate.

IIRC, we haven't received any report, patch or request on the breakage
relevant to the Carbon code so far.

in conclusion, unless someone is willing to work for that, we are no longer
able to maintain it.  Personally, I think it's nearly impossible to restore
it.


> Anyway, I think this change should be split into smaller pieces to make
> it easier to see what changes.
>

So my current plain consists of four phases:

(1) Removal of MACOS_CLASSIC related code and adjustments of the build
system.
(2) Removal of FEAT_GUI_MAC related code and adjustments of the build
system.
(3) Making a list of all the possible ways Vim can be build for Mac.  Based
on that, optimize the build system for Mac if possible.
(4) Correct the meaning of the feature list item 'mac'.

Each phase has its own patch and will be accompanied with document update.

Kazunobu

>
>
> --
> The question is:  What do you do with your life?
> The wrong answer is: Become the richest guy in the graveyard.
> (billionaire and Oracle founder Larry
> Ellison)
>
>  /// 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.