Making :write transactional.

[Eric Lee]

Hi,

I have created a transactional library, and I am trying to make the vim :write 
command transactional. The idea here is that, instead of writing to the .swp 
file, vim directly applies updates to the relevant file. (I'm only guessing 
that this is how vim works when the noswpfile setting is enabled. Please 
correct me if I'm wrong.)

I've wrapped the do_write(eap) command in ex_write() (in src/ex_cmds.c) in a 
transaction. From my logs, it seems like some random file with a filename of 4 
random digits (4913 in my case) was created. And then the original file was 
renamed to itself with a "~" at the end. And then a file is created with the 
original file's name, and then that's removed.

In any case, it seems like the logs I record for filesystem operations do not 
reflect the final state of my folder. My question is, are there other commands 
executed outsides of do_write() when I enter :write into vim?

As a side note, my transactional library only covers basic glibc calls, like 
write(), open(), rename(), remove(), etc. If vim uses some other mechanism to 
persist data to storage, than it's possible those calls are bypassing my 
library.

Could someone give me a summary of how vim persists data when noswpfile is set?

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

[Bram Moolenaar]

Patch 8.0.1727
Problem:qf_get_properties() function is too long.
Solution:   Refactor the code. (Yegappan Lakshmanan, closes #2807)
Files:  src/quickfix.c


*** ../vim-8.0.1726/src/quickfix.c  2018-04-12 20:35:01.106692254 +0200
--- src/quickfix.c  2018-04-16 18:03:07.284370363 +0200
***
*** 1183,1189 
  fields.errmsglen = CMDBUFFSIZE + 1;
  fields.errmsg = alloc_id(fields.errmsglen, aid_qf_errmsg);
  fields.pattern = alloc_id(CMDBUFFSIZE + 1, aid_qf_pattern);
! if (fields.namebuf == NULL || fields.errmsg == NULL || fields.pattern == 
NULL)
goto qf_init_end;
  
  if (efile != NULL && (state.fd = mch_fopen((char *)efile, "r")) == NULL)
--- 1183,1190 
  fields.errmsglen = CMDBUFFSIZE + 1;
  fields.errmsg = alloc_id(fields.errmsglen, aid_qf_errmsg);
  fields.pattern = alloc_id(CMDBUFFSIZE + 1, aid_qf_pattern);
! if (fields.namebuf == NULL || fields.errmsg == NULL
!   || fields.pattern == NULL)
goto qf_init_end;
  
  if (efile != NULL && (state.fd = mch_fopen((char *)efile, "r")) == NULL)
***
*** 1817,1823 
  }
  }
  
- 
  /*
   * pop dirbuf from the directory stack and return previous directory or NULL 
if
   * stack is empty
--- 1818,1823 
***
*** 4948,4954 
  };
  
  /*
!  * Parse text from 'di' and return the quickfix list items
   */
  static int
  qf_get_list_from_lines(dict_T *what, dictitem_T *di, dict_T *retdict)
--- 4948,4955 
  };
  
  /*
!  * Parse text from 'di' and return the quickfix list items.
!  * Existing quickfix lists are not modified.
   */
  static int
  qf_get_list_from_lines(dict_T *what, dictitem_T *di, dict_T *retdict)
***
*** 5017,5041 
  }
  
  /*
!  * Return quickfix/location list details (title) as a
!  * dictionary. 'what' contains the details to return. If 'list_idx' is -1,
!  * then current list is used. Otherwise the specified list is used.
   */
! int
! qf_get_properties(win_T *wp, dict_T *what, dict_T *retdict)
  {
- qf_info_T *qi = _info;
- int   status = OK;
- int   qf_idx;
- dictitem_T*di;
  int   flags = QF_GETLIST_NONE;
  
- if ((di = dict_find(what, (char_u *)"lines", -1)) != NULL)
-   return qf_get_list_from_lines(what, di, retdict);
- 
- if (wp != NULL)
-   qi = GET_LOC_LIST(wp);
- 
  if (dict_find(what, (char_u *)"all", -1) != NULL)
flags |= QF_GETLIST_ALL;
  
--- 5018,5030 
  }
  
  /*
!  * Convert the keys in 'what' to quickfix list property flags.
   */
! static int
! qf_getprop_keys2flags(dict_T *what)
  {
  int   flags = QF_GETLIST_NONE;
  
  if (dict_find(what, (char_u *)"all", -1) != NULL)
flags |= QF_GETLIST_ALL;
  
***
*** 5066,5205 
  if (dict_find(what, (char_u *)"changedtick", -1) != NULL)
flags |= QF_GETLIST_TICK;
  
! if (qi != NULL && qi->qf_listcount != 0)
  {
!   qf_idx = qi->qf_curlist;/* default is the current list */
!   if ((di = dict_find(what, (char_u *)"nr", -1)) != NULL)
{
!   /* Use the specified quickfix/location list */
!   if (di->di_tv.v_type == VAR_NUMBER)
{
!   /* for zero use the current list */
!   if (di->di_tv.vval.v_number != 0)
!   {
!   qf_idx = di->di_tv.vval.v_number - 1;
!   if (qf_idx < 0 || qf_idx >= qi->qf_listcount)
!   qf_idx = -1;
!   }
}
-   else if (di->di_tv.v_type == VAR_STRING
-   && di->di_tv.vval.v_string != NULL
-   && STRCMP(di->di_tv.vval.v_string, "$") == 0)
-   /* Get the last quickfix list number */
-   qf_idx = qi->qf_listcount - 1;
-   else
-   qf_idx = -1;
-   flags |= QF_GETLIST_NR;
}
  
!   if ((di = dict_find(what, (char_u *)"id", -1)) != NULL)
{
!   /* Look for a list with the specified id */
!   if (di->di_tv.v_type == VAR_NUMBER)
!   {
!   /*
!* For zero, use the current list or the list specifed by 'nr'
!*/
!   if (di->di_tv.vval.v_number != 0)
!   qf_idx = qf_id2nr(qi, di->di_tv.vval.v_number);
!   flags |= QF_GETLIST_ID;
!   }
!   else
!   qf_idx = -1;
}
  }
  
! /* List is not present or is empty */
! if (qi == NULL || qi->qf_listcount == 0 || qf_idx == -1)
! {
!   if (flags & QF_GETLIST_TITLE)
!   status = dict_add_nr_str(retdict, "title", 0L, (char_u *)"");
!   if ((status == OK) && (flags & QF_GETLIST_ITEMS))
!   {
!   list_T  *l = list_alloc();
!   if (l != NULL)
!   status = dict_add_list(retdict, "items", l);
!   else
!   status = FAIL;

Patch 8.0.1726

[Bram Moolenaar]

Patch 8.0.1726 (after 8.0.1724)
Problem:Older MSVC doesn't support declarations halfway a block.
Solution:   Move the declaration back to the start of the block.
Files:  src/main.c


*** ../vim-8.0.1725/src/main.c  2018-04-16 15:40:46.800498011 +0200
--- src/main.c  2018-04-16 17:05:53.903560867 +0200
***
*** 1056,1061 
--- 1056,1062 
  int   cmdwin, /* TRUE when working in the command-line 
window */
  int   noexmode)   /* TRUE when return on entering Ex mode */
  {
+ oparg_T   oa; /* operator arguments */
  volatile int previous_got_int = FALSE;/* "got_int" was TRUE */
  #ifdef FEAT_CONCEAL
  /* these are static to avoid a compiler warning */
***
*** 1095,1101 
  }
  #endif
  
- oparg_T   oa; /* operator arguments */
  clear_oparg();
  while (!cmdwin
  #ifdef FEAT_CMDWIN
--- 1096,1101 
***
*** 1383,1393 
  void
  getout(int exitval)
  {
- tabpage_T *tp;
- tabpage_T *next_tp;
- buf_T *buf;
- win_T *wp;
- 
  exiting = TRUE;
  #if defined(FEAT_JOB_CHANNEL)
  ch_log(NULL, "Exiting...");
--- 1383,1388 
***
*** 1416,1421 
--- 1411,1421 
  
  if (v_dying <= 1)
  {
+   tabpage_T   *tp;
+   tabpage_T   *next_tp;
+   buf_T   *buf;
+   win_T   *wp;
+ 
/* Trigger BufWinLeave for all windows, but only once per buffer. */
for (tp = first_tabpage; tp != NULL; tp = next_tp)
{
*** ../vim-8.0.1725/src/version.c   2018-04-16 16:21:43.962795866 +0200
--- src/version.c   2018-04-16 17:05:36.615685537 +0200
***
*** 764,765 
--- 764,767 
  {   /* Add new patch number below this line */
+ /**/
+ 1726,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
201. When somebody asks you where you are, you tell them in which chat room.

 /// 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: Is ANSI C support still needed?

[Bram Moolenaar]

Mike Williams wrote:

> On 16/04/2018 14:16, Bram Moolenaar wrote:
> > 
> > Mike Williams wrote:
> > 
> >> On 16/04/2018 01:34, James McCoy wrote:
> >>> On Sun, Apr 15, 2018 at 02:32:14PM +0200, Dominique Pellé wrote:
>  Bram Moolenaar  wrote:
> 
> > Hello Vimmers,
> >
> > For a long time Vim code was made to be compiled with ANSI C (also known
> > as C89 and ISO C90).  This means it can also be compiled on very old
> > systems.  And since it wasn't too much work to support it, that was the
> > choice.
> >
> > Now that we are adding checks for C89 compliance, it turns out that we
> > already are using some C99 features, such as the "long long" type.
> > Also, many libraries produce warnings when enforcing C89.  That means
> > using C89 is starting to become a hassle.  So, the question comes up: is
> > it still worth it?
> >
> > If you CANNOT build Vim with a C99 compiler, please speak up!
> > If I don't hear about such cases, I think we are better off using C99 as
> > the standard.
> >
> > Note that if we go with C99, we still need to decide what features we
> > will actually use, since C99 compliance was lacking for quite a while
> > (esp. in MS-Visual C).  That's not going to make this easier.
> 
>  I would welcome C99.
> 
>  gcc-4.5 has full support of C99, but many C99 features
>  were supported much earlier than that, see [1].
> 
>  It's less clear to me when C99 features were introduced
>  in Visual studio. C99 support was lagging in Visual Studio.
> >>>
> >>> Visual Studio doesn't fully support C99.  It supports the subset of C99
> >>> that overlaps with C++, as well as changes that could be implemented in
> >>> the standard library (i.e., didn't require compiler changes).
> >>> https://stackoverflow.com/q/9610747/198244 is a useful reference.
> >>>
> >>> That will probably be enough for what Vim (and its dependencies) need.
> >>
> >> My experience with a transition period moving to Visual Studio 2015 from
> >> earlier versions is that the biggest issue is allowing variable
> >> declarations to be declared anywhere within a block - it is very easy to
> >> do.  If anyone is still using older versions this could become a regular
> >> bump in the development road like not casting the result of STRLEN() to
> >> an int where needed.
> > 
> > Are you saying that VS 2008 (the oldest that could still be used) did not
> > support a declaration after a statement?  If that is so we should not
> > allow it (at least for a while).  I don't think this is an important
> > restriction, putting declarations at the start of the block is always
> > possible.  Only including libvterm was a bit of a problem because of
> > this.
> 
> That is correct.  Picking some code at random I added a declaration 
> after a statement ...
> 
> diff --git a/src/beval.c b/src/beval.c
> --- a/src/beval.c
> +++ b/src/beval.c
> @@ -47,6 +47,8 @@ get_beval_info(
>   {
>  row = Y_2_ROW(beval->y);
>  col = X_2_COL(beval->x);
> +int j;
> +j=0;
>   }
>   #endif
>   wp = mouse_find_win(, );
> 
> ... and built with VS2012, resulting in the following compiler errors 
> being reported:
> 
> beval.c(50) : error C2143: syntax error : missing ';' before 'type'
> beval.c(51) : error C2065: 'j' : undeclared identifier
> 
> VS2015 compiled it without complaint.  I don't have VS2008 to check 
> that.  Perhaps support of C++ style language features moved in and out 
> of VC over various releases, I don't know.
> 
> Trying to identify a workable subset across language standards is a 
> painful process, hence my suggestion of setting a cut off date for older 
> versions of VC as being an easier solution.
> 
> > I just tried using VS 2008, and it seemed not to have a problem with
> > moving a declaration to halfway a block.  MSVC may not support C99 very
> > well, but this is probably a C++ feature, which they do support.
> 
> I don't know if you meant your change to main.c in path 1724.  This 
> patch will only test some unix builds as the statements before it is 
> only present when using X11 with a clipboard.

Ah, good point.  And yes, when I try out another place I get an error
with MSVC 2008.  And so MSVC 2012 also still doesn't support it.
Bummer.

-- 
hundred-and-one symptoms of being an internet addict:
200. You really believe in the concept of a "paperless" office.

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

Re: [patch] some fixes for termdebug

[Christian Brabandt]

On Mo, 16 Apr 2018, Bram Moolenaar wrote:

> Thanks.  I had to fix a few problems, but I like the idea of using ! to
> execute.

Thanks for including. I have usually been using the old way to debug 
using gdb --args ./vim --clean -c  to start and debug right away. Now I 
can move on to using the termdebug plugin actually.

Best,
Christian

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

[Mike Williams]

Hi

On 16/04/2018 14:16, Bram Moolenaar wrote:


I wrote:


Patch 8.0.1723
Problem:Using one item array size declaration is misleading.
Solution:   Instead of using "[1]" and actually using a larger array, use
 "[]".  This is to verify that this C99 feature works for all
 compilers.
Files:  src/structs.h, src/getchar.c


If you notice a prolem because of this patch, please speak up!
Also if it's just a compiler warning.  We want to know if this C99
feature works for everybody.


The use of unsized arrays as the last member of a structure is supported 
as an extension in MSVC, at least as far back as VS2008.  There are 
other extensions but finding a list is not trivial.  There is the /Za 
compiler option to disable the extensions, but this throws up a whole 
new bunch of compiler messages to due extensive use of the extensions in 
the system include files making spotting issues in vim code a needle in 
the haystack problem.


TTFN

Mike
--
A diplomat is a man who always remembers a woman's birthday but never 
remembers her age.


--
--
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] some fixes for termdebug

[Bram Moolenaar]

Christian wrote:

> > > Still when the current session is finished and a new session is run 
> > > using `:Termdebug vim` it errors out with E174, because the commands are 
> > > already defined.
> > 
> > I don't see that.  There was an error for one command, it was missing in
> > the list of the cleanup function.
> 
> Strange I had it yesterday all day long but now cannot reproduce it.
> 
> > > How about to delete the commands when the first window 
> > > (the one in which you enter the gdb commands) is closed?
> > > Alternatively, please use the `!` argument to the `:command` definition.
> > 
> > I avoid using !, because it would cover up overwriting an existing
> > command (that might do something completely different).  It's a bit of
> > a risk already, using simple names such as "Finish" and "Step".
> > 
> > > My use case is usually I want to run with a clean state. How about using 
> > > the special separator '--' to separate gdb arguments from process 
> > > specific arguments. This way I can actually run
> > > `:Termdebug vim -- --clean -c ":call setline('..')"` and start debugging 
> > > from a good initial state.
> > > 
> > > The attached patch does those two things.
> > 
> > Hmm, it's different from how gdb is normally used.  And it's also not
> > how you would start Vim.  Thus introducing a whole new syntax.
> > 
> > When using a core file or running process the command arguments would
> > not be used.  Thus we would need some way to specify "this is the
> > command I want to run".
> > 
> > Perhaps we can use two commands, one to start with gdb arguments, one
> > with the command to run.
> > :Termdebug vim core
> > :TermdebugCommand vim --clean
> > 
> > Something like that?  We could also use a command to make gdb execute
> > "run" right away.  Sometimes it's a hassle that one needs to navigate to
> > the gdb window to type "run" and then navigate to the program window to
> > type something:
> > :TermdebugRun vim --clean test.txt
> > This would start the debugger on Vim and do "run --clean test.txt" in
> > the gdb window and put the cursor in the command window.
> 
> Here is a patch. I did not add the TermdebugRun command, but rather use 
> the optional '!' to indicate to run the command.

Thanks.  I had to fix a few problems, but I like the idea of using ! to
execute.

-- 
hundred-and-one symptoms of being an internet addict:
196. Your computer costs more than your car.

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

[Bram Moolenaar]

Patch 8.0.1725
Problem:Terminal debugger doesn't handle command arguments.
Solution:   Add the :TermdebugCommand command.  Use a ! to execute right away.
(Christian Brabandt)
Files:  runtime/pack/dist/opt/termdebug/plugin/termdebug.vim,
runtime/doc/terminal.txt


*** ../vim-8.0.1724/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
2018-04-14 18:59:45.928174961 +0200
--- runtime/pack/dist/opt/termdebug/plugin/termdebug.vim2018-04-16 
16:16:51.848971612 +0200
***
*** 25,31 
  
  " The command that starts debugging, e.g. ":Termdebug vim".
  " To end type "quit" in the gdb window.
! command -nargs=* -complete=file Termdebug call s:StartDebug()
  
  " Name of the gdb command, defaults to "gdb".
  if !exists('termdebugger')
--- 25,32 
  
  " The command that starts debugging, e.g. ":Termdebug vim".
  " To end type "quit" in the gdb window.
! command -nargs=* -complete=file -bang Termdebug call s:StartDebug(0, 
)
! command -nargs=+ -complete=file -bang TermdebugCommand call 
s:StartDebugCommand(0, )
  
  " Name of the gdb command, defaults to "gdb".
  if !exists('termdebugger')
***
*** 43,49 
  endif
  hi default debugBreakpoint term=reverse ctermbg=red guibg=red
  
! func s:StartDebug(...)
if exists('s:gdbwin')
  echoerr 'Terminal debugger already running'
  return
--- 44,60 
  endif
  hi default debugBreakpoint term=reverse ctermbg=red guibg=red
  
! func s:StartDebug(bang, ...)
!   " First argument is the command to debug, second core file or process ID.
!   call s:StartDebug_internal({'gdb_args': a:000, 'bang': a:bang})
! endfunc
! 
! func s:StartDebugCommand(bang, ...)
!   " First argument is the command to debug, rest are run arguments.
!   call s:StartDebug_internal({'gdb_args': [a:1], 'proc_args': a:000[1:], 
'bang': a:bang})
! endfunc
! 
! func s:StartDebug_internal(dict)
if exists('s:gdbwin')
  echoerr 'Terminal debugger already running'
  return
***
*** 95,101 
  
" Open a terminal window to run the debugger.
" Add -quiet to avoid the intro message causing a hit-enter prompt.
!   let cmd = [g:termdebugger, '-quiet', '-tty', pty] + a:000
echomsg 'executing "' . join(cmd) . '"'
let s:gdbbuf = term_start(cmd, {
\ 'exit_cb': function('s:EndDebug'),
--- 106,115 
  
" Open a terminal window to run the debugger.
" Add -quiet to avoid the intro message causing a hit-enter prompt.
!   let gdb_args = get(a:dict, 'gdb_args', [])
!   let proc_args = get(a:dict, 'proc_args', [])
! 
!   let cmd = [g:termdebugger, '-quiet', '-tty', pty] + gdb_args
echomsg 'executing "' . join(cmd) . '"'
let s:gdbbuf = term_start(cmd, {
\ 'exit_cb': function('s:EndDebug'),
***
*** 109,114 
--- 123,133 
endif
let s:gdbwin = win_getid(winnr())
  
+   " Set arguments to be run
+   if len(proc_args)
+ call term_sendkeys(s:gdbbuf, 'set args ' . join(proc_args) . "\r")
+   endif
+ 
" Connect gdb to the communication pty, using the GDB/MI interface
call term_sendkeys(s:gdbbuf, 'new-ui mi ' . commpty . "\r")
  
***
*** 182,187 
--- 201,214 
  au BufRead * call s:BufRead()
  au BufUnload * call s:BufUnloaded()
augroup END
+ 
+   " Run the command if the bang attribute was given
+   " and got to the window
+   if get(a:dict, 'bang', 0)
+ call s:SendCommand('-exec-run')
+ call win_gotoid(s:ptywin)
+   endif
+ 
  endfunc
  
  func s:EndDebug(job, status)
*** ../vim-8.0.1724/runtime/doc/terminal.txt2018-04-14 18:59:45.932174933 
+0200
--- runtime/doc/terminal.txt2018-04-16 16:08:23.384925575 +0200
***
*** 623,629 
  Load the plugin with this command: >
packadd termdebug
  < *:Termdebug*
! To start debugging use `:Termdebug` followed by the command name, for 
example: >
:Termdebug vim
  
  This opens two windows:
--- 623,630 
  Load the plugin with this command: >
packadd termdebug
  < *:Termdebug*
! To start debugging use `:Termdebug` or `:TermdebugCommand`` followed by the
! command name, for example: >
:Termdebug vim
  
  This opens two windows:
***
*** 641,647 
  highlight the current position, using highlight group debugPC. 
  
  If the buffer in the current window is modified, another window will be opened
! to display the current gdb position.
  
  Focus the terminal of the executed program to interact with it.  This works
  the same as any command running in a terminal window.
--- 642,649 
  highlight the current position, using highlight group debugPC. 
  
  If the buffer in the current window is modified, another window will be opened
! to display the current gdb position.  You can use `:Winbar` to add a window
! toolbar there.
  
  Focus the terminal of the executed program to 

Re: Is ANSI C support still needed?

[Mike Williams]

Hi

On 16/04/2018 14:16, Bram Moolenaar wrote:


Mike Williams wrote:


On 16/04/2018 01:34, James McCoy wrote:

On Sun, Apr 15, 2018 at 02:32:14PM +0200, Dominique Pellé wrote:

Bram Moolenaar  wrote:


Hello Vimmers,

For a long time Vim code was made to be compiled with ANSI C (also known
as C89 and ISO C90).  This means it can also be compiled on very old
systems.  And since it wasn't too much work to support it, that was the
choice.

Now that we are adding checks for C89 compliance, it turns out that we
already are using some C99 features, such as the "long long" type.
Also, many libraries produce warnings when enforcing C89.  That means
using C89 is starting to become a hassle.  So, the question comes up: is
it still worth it?

If you CANNOT build Vim with a C99 compiler, please speak up!
If I don't hear about such cases, I think we are better off using C99 as
the standard.

Note that if we go with C99, we still need to decide what features we
will actually use, since C99 compliance was lacking for quite a while
(esp. in MS-Visual C).  That's not going to make this easier.


I would welcome C99.

gcc-4.5 has full support of C99, but many C99 features
were supported much earlier than that, see [1].

It's less clear to me when C99 features were introduced
in Visual studio. C99 support was lagging in Visual Studio.


Visual Studio doesn't fully support C99.  It supports the subset of C99
that overlaps with C++, as well as changes that could be implemented in
the standard library (i.e., didn't require compiler changes).
https://stackoverflow.com/q/9610747/198244 is a useful reference.

That will probably be enough for what Vim (and its dependencies) need.


My experience with a transition period moving to Visual Studio 2015 from
earlier versions is that the biggest issue is allowing variable
declarations to be declared anywhere within a block - it is very easy to
do.  If anyone is still using older versions this could become a regular
bump in the development road like not casting the result of STRLEN() to
an int where needed.


Are you saying that VS 2008 (the oldest that could still be used) did not
support a declaration after a statement?  If that is so we should not
allow it (at least for a while).  I don't think this is an important
restriction, putting declarations at the start of the block is always
possible.  Only including libvterm was a bit of a problem because of
this.


That is correct.  Picking some code at random I added a declaration 
after a statement ...


diff --git a/src/beval.c b/src/beval.c
--- a/src/beval.c
+++ b/src/beval.c
@@ -47,6 +47,8 @@ get_beval_info(
 {
row = Y_2_ROW(beval->y);
col = X_2_COL(beval->x);
+int j;
+j=0;
 }
 #endif
 wp = mouse_find_win(, );

... and built with VS2012, resulting in the following compiler errors 
being reported:


beval.c(50) : error C2143: syntax error : missing ';' before 'type'
beval.c(51) : error C2065: 'j' : undeclared identifier

VS2015 compiled it without complaint.  I don't have VS2008 to check 
that.  Perhaps support of C++ style language features moved in and out 
of VC over various releases, I don't know.


Trying to identify a workable subset across language standards is a 
painful process, hence my suggestion of setting a cut off date for older 
versions of VC as being an easier solution.



I just tried using VS 2008, and it seemed not to have a problem with
moving a declaration to halfway a block.  MSVC may not support C99 very
well, but this is probably a C++ feature, which they do support.


I don't know if you meant your change to main.c in path 1724.  This 
patch will only test some unix builds as the statements before it is 
only present when using X11 with a clipboard.



Designated initializers and very large arrays are concious changes in
developer habits so will be less likely if they are to be precluded for
backward MSVC support.

Perhaps the release of 8.2/9.0 could be a red flag event to only support
VS2015 and later.

My 2ps worth to the debate.


HTH - TTFN

Mike
--
If you're not part of the solution, be part of the problem!

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

[Tony Mechelynck]

FWIW I don't see any compiler messages (neither in Huge nor in Tiny)
but I'm on Linux and it's MSVC support which is problematic. Let's see
if we get errors or warnings on Windows.

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.

Patch 8.0.1724

[Bram Moolenaar]

Patch 8.0.1724
Problem:Declarations cannot be halfway a block.
Solution:   Move one declaration to check if this works for all compilers.
Files:  src/main.c


*** ../vim-8.0.1723/src/main.c  2018-04-10 18:47:16.093527046 +0200
--- src/main.c  2018-04-16 15:38:30.429374793 +0200
***
*** 1056,1062 
  int   cmdwin, /* TRUE when working in the command-line 
window */
  int   noexmode)   /* TRUE when return on entering Ex mode */
  {
- oparg_T   oa; /* operator arguments */
  volatile int previous_got_int = FALSE;/* "got_int" was TRUE */
  #ifdef FEAT_CONCEAL
  /* these are static to avoid a compiler warning */
--- 1056,1061 
***
*** 1096,1101 
--- 1095,1101 
  }
  #endif
  
+ oparg_T   oa; /* operator arguments */
  clear_oparg();
  while (!cmdwin
  #ifdef FEAT_CMDWIN
*** ../vim-8.0.1723/src/version.c   2018-04-16 14:45:41.020162889 +0200
--- src/version.c   2018-04-16 15:38:08.481514153 +0200
***
*** 764,765 
--- 764,767 
  {   /* Add new patch number below this line */
+ /**/
+ 1724,
  /**/

-- 
Some of the well known MS-Windows errors:
EMULTI  Multitasking attempted, system confused
EKEYBOARD   Keyboard locked, try getting out of this one!
EXPLAIN Unexplained error, please tell us what happened
EFUTURE Reserved for our future mistakes

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

[Bram Moolenaar]

I wrote:

> Patch 8.0.1723
> Problem:Using one item array size declaration is misleading.
> Solution:   Instead of using "[1]" and actually using a larger array, use
> "[]".  This is to verify that this C99 feature works for all
> compilers.
> Files:  src/structs.h, src/getchar.c

If you notice a prolem because of this patch, please speak up!
Also if it's just a compiler warning.  We want to know if this C99
feature works for everybody.

-- 
Press any key to continue, press any other key to quit.

 /// 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: Is ANSI C support still needed?

[Bram Moolenaar]

Mike Williams wrote:

> On 16/04/2018 01:34, James McCoy wrote:
> > On Sun, Apr 15, 2018 at 02:32:14PM +0200, Dominique Pellé wrote:
> >> Bram Moolenaar  wrote:
> >>
> >>> Hello Vimmers,
> >>>
> >>> For a long time Vim code was made to be compiled with ANSI C (also known
> >>> as C89 and ISO C90).  This means it can also be compiled on very old
> >>> systems.  And since it wasn't too much work to support it, that was the
> >>> choice.
> >>>
> >>> Now that we are adding checks for C89 compliance, it turns out that we
> >>> already are using some C99 features, such as the "long long" type.
> >>> Also, many libraries produce warnings when enforcing C89.  That means
> >>> using C89 is starting to become a hassle.  So, the question comes up: is
> >>> it still worth it?
> >>>
> >>> If you CANNOT build Vim with a C99 compiler, please speak up!
> >>> If I don't hear about such cases, I think we are better off using C99 as
> >>> the standard.
> >>>
> >>> Note that if we go with C99, we still need to decide what features we
> >>> will actually use, since C99 compliance was lacking for quite a while
> >>> (esp. in MS-Visual C).  That's not going to make this easier.
> >>
> >> I would welcome C99.
> >>
> >> gcc-4.5 has full support of C99, but many C99 features
> >> were supported much earlier than that, see [1].
> >>
> >> It's less clear to me when C99 features were introduced
> >> in Visual studio. C99 support was lagging in Visual Studio.
> > 
> > Visual Studio doesn't fully support C99.  It supports the subset of C99
> > that overlaps with C++, as well as changes that could be implemented in
> > the standard library (i.e., didn't require compiler changes).
> > https://stackoverflow.com/q/9610747/198244 is a useful reference.
> > 
> > That will probably be enough for what Vim (and its dependencies) need.
> 
> My experience with a transition period moving to Visual Studio 2015 from 
> earlier versions is that the biggest issue is allowing variable 
> declarations to be declared anywhere within a block - it is very easy to 
> do.  If anyone is still using older versions this could become a regular 
> bump in the development road like not casting the result of STRLEN() to 
> an int where needed.

Are you saying that VS 2008 (the oldest that could still be used) did not
support a declaration after a statement?  If that is so we should not
allow it (at least for a while).  I don't think this is an important
restriction, putting declarations at the start of the block is always
possible.  Only including libvterm was a bit of a problem because of
this.

I just tried using VS 2008, and it seemed not to have a problem with
moving a declaration to halfway a block.  MSVC may not support C99 very
well, but this is probably a C++ feature, which they do support.

> Designated initializers and very large arrays are concious changes in 
> developer habits so will be less likely if they are to be precluded for 
> backward MSVC support.
> 
> Perhaps the release of 8.2/9.0 could be a red flag event to only support 
> VS2015 and later.
> 
> My 2ps worth to the debate.

-- 
Some of the well known MS-Windows errors:
EHUHUnexpected error
EUSER   User error, not our fault!
EGODHorrible problem, god knows what has happened
EERRErrornous error: nothing wrong

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

[Bram Moolenaar]

Patch 8.0.1723
Problem:Using one item array size declaration is misleading.
Solution:   Instead of using "[1]" and actually using a larger array, use
"[]".  This is to verify that this C99 feature works for all
compilers.
Files:  src/structs.h, src/getchar.c


*** ../vim-8.0.1722/src/structs.h   2018-04-10 15:59:04.295392601 +0200
--- src/structs.h   2018-04-16 14:45:10.504367039 +0200
***
*** 511,517 
  struct buffblock
  {
  buffblock_T   *b_next;/* pointer to next buffblock */
! char_ub_str[1];   /* contents (actually longer) */
  };
  
  /*
--- 511,517 
  struct buffblock
  {
  buffblock_T   *b_next;/* pointer to next buffblock */
! char_ub_str[];/* contents (flexible array) */
  };
  
  /*
***
*** 519,525 
   */
  struct buffheader
  {
! buffblock_T   bh_first;   /* first (dummy) block of list */
  buffblock_T   *bh_curr;   /* buffblock for appending */
  int   bh_index;   /* index for reading */
  int   bh_space;   /* space in bh_curr for appending */
--- 519,525 
   */
  struct buffheader
  {
! buffblock_T   *bh_first;  /* first block of the list */
  buffblock_T   *bh_curr;   /* buffblock for appending */
  int   bh_index;   /* index for reading */
  int   bh_space;   /* space in bh_curr for appending */
*** ../vim-8.0.1722/src/getchar.c   2018-03-04 18:07:04.256592423 +0100
--- src/getchar.c   2018-04-16 14:38:22.299064897 +0200
***
*** 40,48 
  
  #define MINIMAL_SIZE 20   /* minimal size for b_str */
  
! static buffheader_T redobuff = {{NULL, {NUL}}, NULL, 0, 0};
! static buffheader_T old_redobuff = {{NULL, {NUL}}, NULL, 0, 0};
! static buffheader_T recordbuff = {{NULL, {NUL}}, NULL, 0, 0};
  
  static int typeahead_char = 0;/* typeahead char that's not 
flushed */
  
--- 40,48 
  
  #define MINIMAL_SIZE 20   /* minimal size for b_str */
  
! static buffheader_T redobuff = {NULL, NULL, 0, 0};
! static buffheader_T old_redobuff = {NULL, NULL, 0, 0};
! static buffheader_T recordbuff = {NULL, NULL, 0, 0};
  
  static int typeahead_char = 0;/* typeahead char that's not 
flushed */
  
***
*** 138,149 
  {
  buffblock_T   *p, *np;
  
! for (p = buf->bh_first.b_next; p != NULL; p = np)
  {
np = p->b_next;
vim_free(p);
  }
! buf->bh_first.b_next = NULL;
  }
  
  /*
--- 138,150 
  {
  buffblock_T   *p, *np;
  
! for (p = buf->bh_first; p != NULL; p = np)
  {
np = p->b_next;
vim_free(p);
  }
! buf->bh_first = NULL;
! buf->bh_curr = NULL;
  }
  
  /*
***
*** 159,174 
  char_u*p = NULL;
  char_u*p2;
  char_u*str;
! buffblock_T *bp;
  
  /* compute the total length of the string */
! for (bp = buffer->bh_first.b_next; bp != NULL; bp = bp->b_next)
count += (long_u)STRLEN(bp->b_str);
  
  if ((count || dozero) && (p = lalloc(count + 1, TRUE)) != NULL)
  {
p2 = p;
!   for (bp = buffer->bh_first.b_next; bp != NULL; bp = bp->b_next)
for (str = bp->b_str; *str; )
*p2++ = *str++;
*p2 = NUL;
--- 160,175 
  char_u*p = NULL;
  char_u*p2;
  char_u*str;
! buffblock_T   *bp;
  
  /* compute the total length of the string */
! for (bp = buffer->bh_first; bp != NULL; bp = bp->b_next)
count += (long_u)STRLEN(bp->b_str);
  
  if ((count || dozero) && (p = lalloc(count + 1, TRUE)) != NULL)
  {
p2 = p;
!   for (bp = buffer->bh_first; bp != NULL; bp = bp->b_next)
for (str = bp->b_str; *str; )
*p2++ = *str++;
*p2 = NUL;
***
*** 232,248 
  long  slen)   /* length of "s" or -1 */
  {
  buffblock_T *p;
! long_ulen;
  
  if (slen < 0)
slen = (long)STRLEN(s);
  if (slen == 0)/* don't add empty strings */
return;
  
! if (buf->bh_first.b_next == NULL) /* first add to list */
  {
buf->bh_space = 0;
!   buf->bh_curr = &(buf->bh_first);
  }
  else if (buf->bh_curr == NULL)/* buffer has already been read */
  {
--- 233,249 
  long  slen)   /* length of "s" or -1 */
  {
  buffblock_T *p;
! long_ulen;
  
  if (slen < 0)
slen = (long)STRLEN(s);
  if (slen == 0)/* don't add empty strings */
return;
  
! if (buf->bh_first == NULL)/* first add to list */
  {
buf->bh_space = 0;
!   buf->bh_curr = NULL;
  }
  else if (buf->bh_curr == NULL)/* buffer has already been read */
  

Re: Is ANSI C support still needed?

[Christian Brabandt]

On Mo, 16 Apr 2018, Mike Williams wrote:

> My experience with a transition period moving to Visual Studio 2015 from
> earlier versions is that the biggest issue is allowing variable declarations
> to be declared anywhere within a block - it is very easy to do.  If anyone
> is still using older versions this could become a regular bump in the
> development road like not casting the result of STRLEN() to an int where
> needed.
> 
> Designated initializers and very large arrays are concious changes in
> developer habits so will be less likely if they are to be precluded for
> backward MSVC support.
> 
> Perhaps the release of 8.2/9.0 could be a red flag event to only support
> VS2015 and later.
> 
> My 2ps worth to the debate.

Perhaps we should include a certain test within the current code base to 
see if someone complains. I know the git developers included such a test 
balloon some time ago:
https://public-inbox.org/git/20170710070342.txmlwwq6gvjkw...@sigill.intra.peff.net/

We could use something similar to get an indication, what can be used 
without hassle.

Best,
Christian
-- 
Lieber zweifelhaft als pinselhaft.

-- 
-- 
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: Is ANSI C support still needed?

[Mike Williams]

Hiya

On 16/04/2018 01:34, James McCoy wrote:

On Sun, Apr 15, 2018 at 02:32:14PM +0200, Dominique Pellé wrote:

Bram Moolenaar  wrote:


Hello Vimmers,

For a long time Vim code was made to be compiled with ANSI C (also known
as C89 and ISO C90).  This means it can also be compiled on very old
systems.  And since it wasn't too much work to support it, that was the
choice.

Now that we are adding checks for C89 compliance, it turns out that we
already are using some C99 features, such as the "long long" type.
Also, many libraries produce warnings when enforcing C89.  That means
using C89 is starting to become a hassle.  So, the question comes up: is
it still worth it?

If you CANNOT build Vim with a C99 compiler, please speak up!
If I don't hear about such cases, I think we are better off using C99 as
the standard.

Note that if we go with C99, we still need to decide what features we
will actually use, since C99 compliance was lacking for quite a while
(esp. in MS-Visual C).  That's not going to make this easier.


I would welcome C99.

gcc-4.5 has full support of C99, but many C99 features
were supported much earlier than that, see [1].

It's less clear to me when C99 features were introduced
in Visual studio. C99 support was lagging in Visual Studio.


Visual Studio doesn't fully support C99.  It supports the subset of C99
that overlaps with C++, as well as changes that could be implemented in
the standard library (i.e., didn't require compiler changes).
https://stackoverflow.com/q/9610747/198244 is a useful reference.

That will probably be enough for what Vim (and its dependencies) need.


My experience with a transition period moving to Visual Studio 2015 from 
earlier versions is that the biggest issue is allowing variable 
declarations to be declared anywhere within a block - it is very easy to 
do.  If anyone is still using older versions this could become a regular 
bump in the development road like not casting the result of STRLEN() to 
an int where needed.


Designated initializers and very large arrays are concious changes in 
developer habits so will be less likely if they are to be precluded for 
backward MSVC support.


Perhaps the release of 8.2/9.0 could be a red flag event to only support 
VS2015 and later.


My 2ps worth to the debate.


I just thought about C99 a few days ago, when I saw a colleague
having a crash with vim, because he did not compile it with
-D_FORTIFY_SOURCE=1. The ugly compilation option won't
be needed with C99,


That would certainly be welcome.

Cheers,


TTFN

Mike
--
Reality's the only obstacle to happiness.

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

[Bram Moolenaar]

Christian Robinson wrote:

> Just for your information, the version number is not updating on the 
> www.vim.org main page.

Yep, something is failing on SourceForge.  It works on vim8.org (OSDN).
So maybe we should switch over...

-- 
hundred-and-one symptoms of being an internet addict:
191. You rate eating establishments not by the quality of the food,
 but by the availability of electrical outlets for your PowerBook.

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