date:20180523

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Jason Franklin

Good tips. Thank you!

I indeed use older versions of Vim without `getwininfo()` on disparate 
machines.  So, keeping this function is necessary at the moment.

-- 
-- 
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: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Nikolay Aleksandrovich Pavlov

2018-05-24 0:53 GMT+03:00 Jason Franklin :
> The first instance makes sense.   After all, no one would want to change the
> file name in the command line window.
>
> The second instance means that I can't run :file in the ftplugin for the "qf"
> file type.  I was previously doing this in my own "ftplugin/qf.vim" script to
> get the type of list I was dealing with (the :file command output can be
> redirected to extract this).
>
> Patch 8.0.0677 means I can't do this anymore... "curbuf_lock" is set before 
> the
> qf filetype is set, which stops me from running it in that ftplugin script.
>
> See the following link for when this was introduced:
>
> https://github.com/vim/vim/blame/6053f2d29a979ffed1fe01b0a2f28e23750530e9/src/quickfix.c#L4029
>
> Like I said in my follow-up post, I read further and decided this wasn't any
> kind of bug, just a decision.  The command:
>
>   execute "normal! \"
>
> works find for me.
>
> ZyX, to answer your question: I was using ":file" in my "ftplugin/qf.vim"
> script in the following manner:
>
> if !exists('*s:SetErrorListType')
> function s:SetErrorListType()
> redir => l:bufferInfo
> file
> redir END
>
> if l:bufferInfo =~ 'Quickfix List'
> let b:err_list_type = 'quickfix'
> else
> let b:err_list_type = 'location'
> endif
> endfunction
> endif
>
> silent call s:SetErrorListType()
>
> It gives me an indicator of what type of list this window holds.

Current Vim has this data in `getwininfo()` return value. Unless you
aim for older versions which did not have this kind of capability you
should be using it. (Also to make solution more universal it is good
idea to first set and restore language via `:lang` because “Quickfix
List” string is translated.)

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

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Jason Franklin

The first instance makes sense.   After all, no one would want to change the
file name in the command line window.

The second instance means that I can't run :file in the ftplugin for the "qf"
file type.  I was previously doing this in my own "ftplugin/qf.vim" script to
get the type of list I was dealing with (the :file command output can be
redirected to extract this).

Patch 8.0.0677 means I can't do this anymore... "curbuf_lock" is set before the
qf filetype is set, which stops me from running it in that ftplugin script.

See the following link for when this was introduced:

https://github.com/vim/vim/blame/6053f2d29a979ffed1fe01b0a2f28e23750530e9/src/quickfix.c#L4029

Like I said in my follow-up post, I read further and decided this wasn't any
kind of bug, just a decision.  The command:

  execute "normal! \"

works find for me. 

ZyX, to answer your question: I was using ":file" in my "ftplugin/qf.vim"
script in the following manner:

if !exists('*s:SetErrorListType')
function s:SetErrorListType()
redir => l:bufferInfo
file
redir END

if l:bufferInfo =~ 'Quickfix List'
let b:err_list_type = 'quickfix'
else
let b:err_list_type = 'location'
endif
endfunction
endif

silent call s:SetErrorListType()

It gives me an indicator of what type of list this window holds.

-- 
-- 
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: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Nikolay Aleksandrovich Pavlov

2018-05-24 0:33 GMT+03:00 Bram Moolenaar :
>
> Jason Franklin wrote:
>
>> To replicate with the cmdline window:
>>
>>   vim -u NONE
>>   q:
>>   :file
>
> Well, what do you expect to happen?

I would expect it to have same output as ``, though…

>
>> To replicate with the quickfix window:
>>
>>   vim -u NONE
>>   :autocmd FileType qf file
>>   :copen
>
> What's the use of :file here?

…I cannot really imagine what plugin could do with `:file` output
which is not best done using some other means. Also it is not like
using `:file` with arguments should be allowed in those buffers.

>
>> In both of these cases, ":file" fails.  This is more
>> what I was talking about.
>
> --
> Lower life forms have more fun!
>
>  /// 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.

-- 
-- 
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: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Bram Moolenaar


Jason Franklin wrote:

> To replicate with the cmdline window:
> 
>   vim -u NONE
>   q:
>   :file

Well, what do you expect to happen?

> To replicate with the quickfix window:
> 
>   vim -u NONE
>   :autocmd FileType qf file
>   :copen

What's the use of :file here?

> In both of these cases, ":file" fails.  This is more 
> what I was talking about.

-- 
Lower life forms have more fun!

 /// 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: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Jason Franklin

To replicate with the cmdline window:

  vim -u NONE
  q:
  :file

To replicate with the quickfix window:

  vim -u NONE
  :autocmd FileType qf file
  :copen

In both of these cases, ":file" fails.  This is more 
what I was talking about.

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

2018-05-23 Fir de Conversatie Bram Moolenaar


Patch 8.1.0022
Problem:Repeating put from expression register fails.
Solution:   Re-evaluate the expression register. (Andy Massimino,
closes #2945)
Files:  src/getchar.c, src/testdir/test_put.vim


*** ../vim-8.1.0021/src/getchar.c   2018-05-22 20:35:13.554009274 +0200
--- src/getchar.c   2018-05-23 21:46:55.680567676 +0200
***
*** 844,849 
--- 844,857 
if (c >= '1' && c < '9')
++c;
add_char_buff(, c);
+ 
+   /* the expression register should be re-evaluated */
+   if (c == '=')
+   {
+   add_char_buff(, CAR);
+   cmd_silent = TRUE;
+   }
+ 
c = read_redo(FALSE, old_redo);
  }
  
*** ../vim-8.1.0021/src/testdir/test_put.vim2017-06-27 15:22:24.0 
+0200
--- src/testdir/test_put.vim2018-05-23 21:44:03.492595109 +0200
***
*** 45,47 
--- 45,60 
bw!
call setreg('a', a[0], a[1])
  endfunc
+ 
+ func Test_put_expr()
+   new
+   call setline(1, repeat(['A'], 6))
+   exec "1norm! \"=line('.')\p"
+   norm! j0.
+   norm! j0.
+   exec "4norm! \"=\P"
+   norm! j0.
+   norm! j0.
+   call assert_equal(['A1','A2','A3','4A','5A','6A'], getline(1,'$'))
+   bw!
+ endfunc
*** ../vim-8.1.0021/src/version.c   2018-05-23 20:30:52.738566360 +0200
--- src/version.c   2018-05-23 21:45:38.776580863 +0200
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 22,
  /**/

-- 
The word "leader" is derived from the word "lead", as in the material that
bullets are made out of.  The term "leader" was popularized at about the same
time as the invention of firearms.  It grew out of the observation that the
person in charge of every organization was the person whom everyone wanted to
fill with hot lead.
   I don't recomment this; it's just a point of historical interest.
(Scott Adams - The Dilbert principle)

 /// 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: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Bram Moolenaar


Jason Franklin wrote:

> Just a follow up on what I've learned here.
> 
> I don't think that the ":file" command makes much sense in the cmdline window.
> However, I don't think it should be disallowed when curbuf_lock is set.  Since
> these restrictions go together, not much can be done.
> 
> Still, this is more of a decision about when it is okay to call the ":file"
> command.  It's not a bug.  Since I was concerned with the output of ":file"
> only, I used the following...
> 
>   :execute "normal! \"
> 
> instead.  That worked for me!
> 
> Just a note for anyone who may have read my original post.

Not sure what you are actually discussing here.  I can use "file
newname" in the command line window just fine.

:new
q:
afile new_name


-- 
Never under any circumstances take a sleeping pill
and a laxative on the same night.

 /// 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: Trying to build with MinGW

2018-05-23 Fir de Conversatie Bram Moolenaar


Ken Takata wrote:

> 2018/5/21 Mon 1:30:53 UTC+9 Bram Moolenaar wrote:
> > I want to try debugging on MS-Windows with gdb.  I normally build with
> > MSVC, but I don't see a way to use that executable with gdb (perhaps
> > it's possible with some compiler flag?).
> > 
> > So I'll use MinGW for compiling. MinGW provides gcc and make, so I
> > expect this to work:
> > make -f Make_ming.mak GUI=no DEBUG=yes
> > 
> > This gives an error in diff.c:
> > storage size of 'st' isn't known.
> > 
> > Hmm.  I can work around it by changing the condition in vim.h:
> > 
> > /* Use 64-bit stat structure if available. */
> > #if (defined(_MSC_VER) && (_MSC_VER >= 1300)) || defined(__MINGW32__)
> > # define HAVE_STAT64
> > typedef struct _stat64 stat_T;
> > #else
> > typedef struct stat stat_T;
> > #endif
> > 
> > So use "struct stat".  I wonder why this change is needed.  perhaps the
> > #ifdef is wrong?
> > 
> > Then it compiles many files but fails when building iscygpty.c .
> > It complains that _WIN32_WINNT and WINVER differ.  That's because the
> > build file has:
> > 
> > $(OUTDIR)/iscygpty.o:   iscygpty.c $(CUI_INCL)
> > $(CC) -c $(CFLAGS) iscygpty.c -o $(OUTDIR)/iscygpty.o -U_WIN32_WINNT 
> > -D_WIN32_WINNT=0x0600 -DUSE_DYNFILEID -DENABLE_STUB_IMPL
> > 
> > Overruling _WIN32_WINNT for one file seems like a bad idea, why was this
> > added?  But building iscygpty.c with WINVER set to 0x0501 apparently
> > doesn't work.
> > 
> > So instead I specify WINVER to be 0x0600.  I wonder how it can ever work
> > without that.  Perhaps we should make it the default?
> 
> For iscygpty.c, how about adding `-UWINVER -DWINVER=0x0600`? (Not tested.)
> iscygpty requires new Win32 APIs which were added in Windows Vista.
 
Does it make sense to require WINVER 0x0600 here while 0x501 is the
default above?  Doesn't it mean the binary won't work properly on
Windows XP anyway?  Then we might as well make 0x0600 the default. And
add a comment to use 0x0501 for XP, and the need to disable using
iscygpty.

> For the other problem, I think your MinGW is too old. (The above problem
> should be caused by the same reason, though.)
> I highly recommend you to use MinGW-w64 instead of the original MinGW (which
> looks dead).

I ran the installer to update, but it appears nothing happened.

> There are some distributions which provide binary packages of MinGW-w64,
> and I think MSYS2 is the best. (https://www.msys2.org/)
> 
> If we still need to support the original MinGW, we might need some
> modifications to the codes and makefiles. However, I can't help it,
> because I have already uninstalled the original MinGW.

I think the main use of MinGW is to build without MSVC.  And since it's
freely available there shouldn't be much problem getting the latest
version.

So how about updating the instructions to add a step-by-step
explanation how to build Vim with MinGW?  Including hints how to get the
latest version (and possibly deleting the old one, if that is needed).

-- 
If you had to identify, in one word, the reason why the
human race has not achieved, and never will achieve, its
full potential, that word would be "meetings."

 /// 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] Resolve warning about undefined behavior (#2946)

2018-05-23 Fir de Conversatie Bram Moolenaar


Michael Jarvis wrote:

> Disclaimer: I'm sure there's a more elegant way to achieve the same
> result.  :-)

Using a variable will avoid duplicating the code.


-- 
I have read and understood the above. X

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

2018-05-23 Fir de Conversatie Bram Moolenaar


Patch 8.1.0021
Problem:Clang warns for undefined behavior.
Solution:   Move #ifdef outside of sprintf() call.(suggestion by Michael
Jarvis, closes #2956)
Files:  src/term.c


*** ../vim-8.1.0020/src/term.c  2018-05-10 14:39:42.0 +0200
--- src/term.c  2018-05-23 20:26:41.770633594 +0200
***
*** 2872,2885 
  #else
char *format = "%s%s%%dm";
  #endif
!   sprintf(buf, format,
!   i == 2 ?
  #if defined(FEAT_VTP) && defined(FEAT_TERMGUICOLORS)
!   s[1] == '|' ? IF_EB("\033|", ESC_STR "|") :
  #endif
!   IF_EB("\033[", ESC_STR "[") : "\233",
!   s[i] == '3' ? (n >= 16 ? "38;5;" : "9")
!   : (n >= 16 ? "48;5;" : "10"));
OUT_STR(tgoto(buf, 0, n >= 16 ? n : n - 8));
  }
  else
--- 2872,2886 
  #else
char *format = "%s%s%%dm";
  #endif
!   char *lead = i == 2 ? (
  #if defined(FEAT_VTP) && defined(FEAT_TERMGUICOLORS)
!   s[1] == '|' ? IF_EB("\033|", ESC_STR "|") :
  #endif
!   IF_EB("\033[", ESC_STR "[")) : "\233";
!   char *tail = s[i] == '3' ? (n >= 16 ? "38;5;" : "9")
!: (n >= 16 ? "48;5;" : "10");
! 
!   sprintf(buf, format, lead, tail);
OUT_STR(tgoto(buf, 0, n >= 16 ? n : n - 8));
  }
  else
*** ../vim-8.1.0020/src/version.c   2018-05-22 20:35:13.566009271 +0200
--- src/version.c   2018-05-23 20:30:12.982576453 +0200
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 21,
  /**/

-- 
BEDEVERE:And what do you burn, apart from witches?
FOURTH VILLAGER: ... Wood?
BEDEVERE:So why do witches burn?
SECOND VILLAGER: (pianissimo) ... Because they're made of wood...?
 "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: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Jason Franklin

Just a follow up on what I've learned here.

I don't think that the ":file" command makes much sense in the cmdline window.
However, I don't think it should be disallowed when curbuf_lock is set.  Since
these restrictions go together, not much can be done.

Still, this is more of a decision about when it is okay to call the ":file"
command.  It's not a bug.  Since I was concerned with the output of ":file"
only, I used the following...

  :execute "normal! \"

instead.  That worked for me!

Just a note for anyone who may have read my original post.

-- 
-- 
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: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-23 Fir de Conversatie Jason Franklin

Just a follow up on what I've learned here.

I don't think that the ":file" command makes much sense in the cmdline window.  
However, I don't think it should be disallowed when curbuf_lock is set.  Since 
these restrictions go together, not much can be done.

Still, this is more of a decision about when it is okay to call the ":file" 
command.  It's not a bug.  Since I was concerned with the output of ":file" 
only, I used the following...

  :execute "normal! \"

instead.  That worked for me!

Just a note for anyone who may have read my original post.



-- 
-- 
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] Add code and tests to fix the sentence text object

2018-05-23 Fir de Conversatie Jason Franklin

Hey Bram, and anyone else interested.

Just a friendly ping concerning this issue.  Like Andy, I feel pretty strongly
that this patch is worth merging.

I noted in my original post that the code for sentence text objects could use
a more general refactoring later down the line.  However, I think this patch is
good because it fixes the current functionality so that it is at least
consistent with the Vim documentation.

Has any more consideration gone into this request?

Thanks a ton!

-- 
-- 
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: Trying to build with MinGW

2018-05-23 Fir de Conversatie Ken Takata

Hi Bram,

2018/5/21 Mon 1:30:53 UTC+9 Bram Moolenaar wrote:
> I want to try debugging on MS-Windows with gdb.  I normally build with
> MSVC, but I don't see a way to use that executable with gdb (perhaps
> it's possible with some compiler flag?).
> 
> So I'll use MinGW for compiling. MinGW provides gcc and make, so I
> expect this to work:
>   make -f Make_ming.mak GUI=no DEBUG=yes
> 
> This gives an error in diff.c:
>   storage size of 'st' isn't known.
> 
> Hmm.  I can work around it by changing the condition in vim.h:
> 
> /* Use 64-bit stat structure if available. */
> #if (defined(_MSC_VER) && (_MSC_VER >= 1300)) || defined(__MINGW32__)
> # define HAVE_STAT64
> typedef struct _stat64 stat_T;
> #else
> typedef struct stat stat_T;
> #endif
> 
> So use "struct stat".  I wonder why this change is needed.  perhaps the
> #ifdef is wrong?
> 
> Then it compiles many files but fails when building iscygpty.c .
> It complains that _WIN32_WINNT and WINVER differ.  That's because the
> build file has:
> 
> $(OUTDIR)/iscygpty.o: iscygpty.c $(CUI_INCL)
>   $(CC) -c $(CFLAGS) iscygpty.c -o $(OUTDIR)/iscygpty.o -U_WIN32_WINNT 
> -D_WIN32_WINNT=0x0600 -DUSE_DYNFILEID -DENABLE_STUB_IMPL
> 
> Overruling _WIN32_WINNT for one file seems like a bad idea, why was this
> added?  But building iscygpty.c with WINVER set to 0x0501 apparently
> doesn't work.
> 
> So instead I specify WINVER to be 0x0600.  I wonder how it can ever work
> without that.  Perhaps we should make it the default?

For iscygpty.c, how about adding `-UWINVER -DWINVER=0x0600`? (Not tested.)
iscygpty requires new Win32 APIs which were added in Windows Vista.

For the other problem, I think your MinGW is too old. (The above problem
should be caused by the same reason, though.)
I highly recommend you to use MinGW-w64 instead of the original MinGW (which
looks dead).
There are some distributions which provide binary packages of MinGW-w64,
and I think MSYS2 is the best. (https://www.msys2.org/)

If we still need to support the original MinGW, we might need some modifications
to the codes and makefiles. However, I can't help it, because I have already
uninstalled the original MinGW.

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: feature to differentiate 32 from 64 bits build version

2018-05-23 Fir de Conversatie Ni Va

Le mercredi 23 mai 2018 15:14:51 UTC+2, Ken Takata a écrit :
> Hi,
> 
> 2018/5/23 Wed 21:29:43 UTC+9 Ni Va wrote:
> > I build both 32 and 64 bits version of gvim but always 1 is returned when 
> > from 32bits or 64bits I do :
> > 
> > echo has('num64')
> > echo has('win32')
> > echo has('win64')
> > 
> > What the feature to differentiate the two built 32/64bits
> 
> You must have made a mistake.  has('win64') returns 0 on 32-bit Vim.
> 
> And yes, has('win32') returns 1 on 64-bit Vim also.  This is explicitly
> documented.  See `:help feature-list`.
> 
> Regards,
> Ken Takata

I claim this mistake! has('win64') is sufficient.

Thank you!

-- 
-- 
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: feature to differentiate 32 from 64 bits build version

2018-05-23 Fir de Conversatie Tony Mechelynck

On Wed, May 23, 2018 at 3:14 PM, Ken Takata  wrote:
> Hi,
>
> 2018/5/23 Wed 21:29:43 UTC+9 Ni Va wrote:
>> I build both 32 and 64 bits version of gvim but always 1 is returned when 
>> from 32bits or 64bits I do :
>>
>> echo has('num64')
>> echo has('win32')
>> echo has('win64')
>>
>> What the feature to differentiate the two built 32/64bits
>
> You must have made a mistake.  has('win64') returns 0 on 32-bit Vim.
>
> And yes, has('win32') returns 1 on 64-bit Vim also.  This is explicitly
> documented.  See `:help feature-list`.
>
> Regards,
> Ken Takata

Of course, both has('win32') and has('win64') return 0 on Unix-like
Vim; so I suppose that there, either the :version redirect as above,
or testing the value returned by system('file ' . v:progpath) for the
text "64-bit" would still be necessary.

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: feature to differentiate 32 from 64 bits build version

2018-05-23 Fir de Conversatie Ken Takata

Hi,

2018/5/23 Wed 21:29:43 UTC+9 Ni Va wrote:
> I build both 32 and 64 bits version of gvim but always 1 is returned when 
> from 32bits or 64bits I do :
> 
> echo has('num64')
> echo has('win32')
> echo has('win64')
> 
> What the feature to differentiate the two built 32/64bits

You must have made a mistake.  has('win64') returns 0 on 32-bit Vim.

And yes, has('win32') returns 1 on 64-bit Vim also.  This is explicitly
documented.  See `:help feature-list`.

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

2018-05-23 Fir de Conversatie Bram Moolenaar


Hirohito Higashi wrote:

> 2018-5-23(Wed) 16:41:25 UTC+9 Christ van Willegen:
> > Hi,
> > 
> > On Tue, May 22, 2018 at 8:35 PM, Bram Moolenaar  wrote:
> > >
> > > Patch 8.1.0020
> > > Problem:Cannot tell whether a register is being used for executing or
> > > recording.
> > > Solution:   Add reg_executing() and reg_recording(). (Hirohito Higashi,
> > > closes #2745)  Rename the global variables for consistency.  
> > > Store
> > > the register name in reg_executing.
> > > Files:  runtime/doc/eval.txt, runtime/doc/usr_41.txt, src/evalfunc.c,
> > > src/testdir/test_functions.vim, src/getchar.c, src/normal.c,
> > > src/ops.c, src/globals.h, src/edit.c, src/fileio.c, 
> > > src/message.c,
> > > src/screen.c
> > >
> > >
> > > *** ../vim-8.1.0019/runtime/doc/eval.txt2018-05-17 
> > > 15:06:48.0 +0200
> > > --- runtime/doc/eval.txt2018-05-22 20:25:41.869831935 +0200
> > > ***
> > > *** 2302,2307 
> > > --- 2302,2309 
> > > Listitems from {expr} to {max}
> > >   readfile({fname} [, {binary} [, {max}]])
> > > Listget list of lines from file 
> > > {fname}
> > > + reg_executing()   Number  get the executing 
> > > register name
> > > + reg_recording()   String  get the recording 
> > > register name
> > >   reltime([{start} [, {end}]])  Listget time value
> > >   reltimefloat({time})  Float   turn the time value into a Float
> > >   reltimestr({time})String  turn time value into a String
> > 
> > Shouldn't both these functions have "String" as their return type?
> 
> Oh, It's my mistake.

I claim this mistake!  It's mine!  :-)

I change the return value from true/false to the register name, since I
was changing the name everywhere anyway and made it more consistent.

> Attached patch fixes this.
> 
> Thanks for reporting!

-- 
FIRST VILLAGER: We have found a witch.  May we burn her?
 "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: feature to differentiate 32 from 64 bits build version

2018-05-23 Fir de Conversatie Ni Va

Le mercredi 23 mai 2018 14:29:43 UTC+2, Ni Va a écrit :
> Hi,
> 
> 
> I build both 32 and 64 bits version of gvim but always 1 is returned when 
> from 32bits or 64bits I do :
> 
> echo has('num64')
> echo has('win32')
> echo has('win64')
> 
> What the feature to differentiate the two built 32/64bits
> 
> Thank
> you
> NiVa

Pass by redirecting :ver command to check running 32-bit or 64-bit


if has('win32')

  " determine gvim 32 or 64-bit built running version
  silent redir @v
  silent exe 'ver'
  silent redir END

  if matchstr(@v,'32-bit')=='32-bit'
" lua
set luadll=lua54.dll
" ruby
set rubydll=msvcrt-ruby250.dll
let $path.=';'.dllPath.'/ruby/x86'
  endif

  if matchstr(@v,'64-bit')=='64-bit'
set rubydll=x64-msvcrt-ruby250.dll
let $path.=';'.dllPath.'/ruby/x64'
  endif

endif

-- 
-- 
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: feature to differentiate 32 from 64 bits build version

2018-05-23 Fir de Conversatie Tony Mechelynck

On Wed, May 23, 2018 at 2:29 PM, Ni Va  wrote:
> Hi,
>
>
> I build both 32 and 64 bits version of gvim but always 1 is returned when 
> from 32bits or 64bits I do :
>
> echo has('num64')
> echo has('win32')
> echo has('win64')
>
> What the feature to differentiate the two built 32/64bits
>
> Thank
> you
> NiVa

AFAIK, nothing that has() could test. On Linux, doing

file `which vim`

(in the shell) returns

/usr/local/bin/vim: ELF 64-bit LSB executable, x86-64, (etc.)

but I don't know if there is a Windows utility with similar functionality.


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.

feature to differentiate 32 from 64 bits build version

2018-05-23 Fir de Conversatie Ni Va

Hi,


I build both 32 and 64 bits version of gvim but always 1 is returned when from 
32bits or 64bits I do :

echo has('num64')
echo has('win32')
echo has('win64')

What the feature to differentiate the two built 32/64bits

Thank
you
NiVa

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

2018-05-23 Fir de Conversatie Christ van Willegen

Hi Hirohito Higashi,

On Wed, May 23, 2018 at 12:05 PM, h_east  wrote:
> Hi Christ,
>
> Oh, It's my mistake.
> Attached patch fixes this.
>
> Thanks for reporting!

You're welcome!

Christ van Willegen

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

Lua 5.4 32bits support

2018-05-23 Fir de Conversatie Ni Va

Hi,

On Windows 10,

1. After download and build lua 5.4 current work I got a the lua.5.4.0.dll 32 
bits and rename it to lua54.dll

guidelines : 
https://blog.spreendigital.de/2015/01/16/how-to-compile-lua-5-3-0-for-windows/


2. From gvim 32 bits 8.1.020 
  lua print('hell') says E448: Could not load library function lua_newuserdata
Lua library cannot be loaded.


in _vimrc I have put these lines :
let dllPath  = fnamemodify($vimruntime.'/extDlls',':p:h:gs?/?\\?')
" Lua
let $path.=';'.dllPath.'/lua'
if has('win32')
  set luadll=lua54.dll
endif



Here is detailed on vim build


VIM - Vi IMproved 8.1 (2018 May 17, compiled May 23 2018 09:59:48)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-20
Compiled by niva
Huge version with GUI.  Features included (+) or not (-):
+acl   +byte_offset   +comments  +digraphs  
+farsi +iconv/dyn +linebreak +mouse 
+packages  +python3/dyn   +startuptime   -termguicolors 
+user_commands +wildignore
+arabic+channel   +conceal   +directx   
+file_in_path  +insert_expand +lispindent+mouseshape
+path_extra+quickfix  +statusline+terminal  
+vertsplit +wildmenu
+autocmd   +cindent   +cryptv-dnd   
+find_in_path  +job   +listcmds  +multi_byte
-perl  +reltime   -sun_workshop  -tgetent   
+virtualedit   +windows
+autoservername+clientserver  -cscope-ebcdic
+float +jumplist  +localmap  +multi_lang
+persistent_undo   +rightleft +syntax-termresponse  
+visual+writebackup
+balloon_eval  +clipboard +cursorbind+emacs_tags
+folding   +keymap+lua/dyn   -mzscheme  
-postscript+ruby/dyn  +tag_binary+textobjects   
+visualextra   -xfontset
-balloon_eval_term +cmdline_compl +cursorshape   +eval  
-footer+lambda+menu  -netbeans_intg 
+printer   +scrollbind+tag_old_static+timers
+viminfo   -xim
+browse+cmdline_hist  +dialog_con_gui+ex_extra  
+gettext/dyn   +langmap   +mksession +num64 
+profile   +signs -tag_any_white +title 
+vreplace  -xpm_w32
++builtin_terms+cmdline_info  +diff  +extra_search  
-hangul_input  +libcall   +modify_fname  +ole   
+python/dyn+smartindent   -tcl   +toolbar   
-vtp   -xterm_save
   system vimrc file: "$VIM\vimrc"
 user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$HOME\vimfiles\vimrc"
 3rd user vimrc file: "$VIM\_vimrc"
  user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
  system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$HOME\vimfiles\gvimrc"
3rd user gvimrc file: "$VIM\_gvimrc"
   defaults file: "$VIMRUNTIME\defaults.vim"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32   
-DFEAT_TERMINAL  -DFEAT_JOB_CHANNEL  -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 
/MP -DHAVE_STDINT_H /O2 /GL -DNDEBUG /arch:IA32 /Zl /MT -DFEAT_OLE -DFEAT_MBYTE 
-DFEAT_GUI_W32 -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI 
-DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_LUA -DDYNAMIC_LUA  
-DDYNAMIC_LUA_DLL=\"lua54.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON 
-DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 
-DDYNAMIC_PYTHON3_DLL=\"python36.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY 
-DDYNAMIC_RUBY_VER=25 -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby250.dll\" -DFEAT_HUGE 
/Fd.\ObjGXOUYHRi386/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /opt:ref /LTCG:STATUS 
oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib  comdlg32.lib 
ole32.lib uuid.lib /machine:i386 gdi32.lib version.lib   winspool.lib 
comctl32.lib advapi32.lib shell32.lib  /machine:i386  libcmt.lib oleaut32.lib 
user32.lib  /nodefaultlib:lua54.lib   /nodefaultlib:python27.lib 
/nodefaultlib:python36.libWSock32.lib  /PDB:gvim.pdb -debug

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

2018-05-23 Fir de Conversatie Christ van Willegen

Hi,

On Tue, May 22, 2018 at 8:35 PM, Bram Moolenaar  wrote:
>
> Patch 8.1.0020
> Problem:Cannot tell whether a register is being used for executing or
> recording.
> Solution:   Add reg_executing() and reg_recording(). (Hirohito Higashi,
> closes #2745)  Rename the global variables for consistency.  Store
> the register name in reg_executing.
> Files:  runtime/doc/eval.txt, runtime/doc/usr_41.txt, src/evalfunc.c,
> src/testdir/test_functions.vim, src/getchar.c, src/normal.c,
> src/ops.c, src/globals.h, src/edit.c, src/fileio.c, src/message.c,
> src/screen.c
>
>
> *** ../vim-8.1.0019/runtime/doc/eval.txt2018-05-17 15:06:48.0 
> +0200
> --- runtime/doc/eval.txt2018-05-22 20:25:41.869831935 +0200
> ***
> *** 2302,2307 
> --- 2302,2309 
> Listitems from {expr} to {max}
>   readfile({fname} [, {binary} [, {max}]])
> Listget list of lines from file {fname}
> + reg_executing()   Number  get the executing register 
> name
> + reg_recording()   String  get the recording register 
> name
>   reltime([{start} [, {end}]])  Listget time value
>   reltimefloat({time})  Float   turn the time value into a Float
>   reltimestr({time})String  turn time value into a String

Shouldn't both these functions have "String" as their return type?

Christ van Willegen

-- 
-- 
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: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Patch 8.1.0022

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: Trying to build with MinGW

Re: [vim/vim] Resolve warning about undefined behavior (#2946)

Patch 8.1.0021

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Re: [PATCH] Add code and tests to fix the sentence text object

Re: Trying to build with MinGW

Re: feature to differentiate 32 from 64 bits build version

Re: feature to differentiate 32 from 64 bits build version

Re: feature to differentiate 32 from 64 bits build version

Re: Patch 8.1.0020

Re: feature to differentiate 32 from 64 bits build version

Re: feature to differentiate 32 from 64 bits build version

feature to differentiate 32 from 64 bits build version

Re: Patch 8.1.0020

Lua 5.4 32bits support

Re: Patch 8.1.0020

25 matches

Site Navigation

Mail list logo

Footer information