Re: Off-by-one error in varsofttabstop description?

[François Ingelrest]

BTW, I'm sorry if this has been asked before as I didn't have time to
catch all my emails recently, but if the vartab feature is to be used
for column editing (and it's great at that), wouldn't it be more
logical to provide the columns where to stop at rather than the length
of tabs?

For instance, I have a configuration file where columns starts at 4,
13, 23, 31, 60, which means I had to go through the computation of the
vsts option to end up with vsts=3,9,10,8,29. It's not that complicated
and it has to be done only once, but providing the actual tab stops
would be easier. Also, adding a tab stop means recomputing the whole
sequence, while with the actual list of tab stops this would require
adding a single value to the list.

Anyway, this feature is already really useful to me for editing column
based files. Thanks for it!

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

Off-by-one error in varsofttabstop description?

[François Ingelrest]

Hello,

:h varsofttabstop reads :

For example, when editing assembly language files where statements
start in the 8th column and comments in the 40th, it may be useful
to use the following:
:set varsofttabstop=8,32,8

To me, this will move the cursor to the 9th (inserting 8 spaces) and
41th columns (inserting 8 + 32 spaces) since the cursor starts at
column 1.

Shouldn't it rather be " :set varsofttabstop=7,32,8 " ?

-- 
-- 
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: Visual Studio 2017 fails to compile one of six Vims...

[Tony Mechelynck]

On Thu, Jun 28, 2018 at 11:34 PM, tux.  wrote:
> As some of you might know, I provide my own Windows Vim builds. My
> latest hardware upgrade brought a new infrastructure though.
>
> I usually compile six Vims in a row:
>
> - x86 GVim without OLE
> - x86 GVim with OLE
> - x86 CLI Vim
> - the same for amd64
>
> Now I get these errors _exclusively_ with x86 GVim with OLE:
>
>>Bibliothek "gvim.lib" und Objekt "gvim.exp" werden erstellt.
>> msvcrt.lib(initializers.obj) : warning LNK4098: Standardbibliothek 
>> "libcmt.lib" steht in Konflikt mit anderen Bibliotheken; 
>> /NODEFAULTLIB:Bibliothek verwenden.
>> misc1.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
>> "_default_vim_dir".
>> misc1.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
>> "_default_vimruntime_dir".
>> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
>> "_compiled_user".
>> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
>> "_compiled_sys".
>> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_all_lflags".
>> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_all_cflags".
>> gvim.exe : fatal error LNK1120: 6 nicht aufgelöste Externe
>
> Why? - Or, more precisely, why does _only_ this build fail, the other
> five don't?
>
> My compilation script:
> https://tuxproject.de/projects/vim/_compile.bat.php
>
> (It is the second x86 compilation...)
>
> What am I missing?
>
> TIA!

Hm, it's been a long time since I last used Windows, and a lot may
have changed. However, IIUC you say you get those errors only when
compiling 32-bit gvim with OLE, and not on any of your other builds,
not even 64-bit gvim with OLE. So the question arises: do you have the
correct software installed (including headers) to compile and link
with 32-bit OLE? Is 32-bit OLE even supported by your newly upgraded
system? Or does it maybe require an optional package, SDK, or
something, which isn't yet installed?

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.

Visual Studio 2017 fails to compile one of six Vims...

[tux.]

As some of you might know, I provide my own Windows Vim builds. My
latest hardware upgrade brought a new infrastructure though.

I usually compile six Vims in a row:

- x86 GVim without OLE
- x86 GVim with OLE
- x86 CLI Vim
- the same for amd64

Now I get these errors _exclusively_ with x86 GVim with OLE:

>Bibliothek "gvim.lib" und Objekt "gvim.exp" werden erstellt.
> msvcrt.lib(initializers.obj) : warning LNK4098: Standardbibliothek 
> "libcmt.lib" steht in Konflikt mit anderen Bibliotheken; 
> /NODEFAULTLIB:Bibliothek verwenden.
> misc1.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
> "_default_vim_dir".
> misc1.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
> "_default_vimruntime_dir".
> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
> "_compiled_user".
> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
> "_compiled_sys".
> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_all_lflags".
> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_all_cflags".
> gvim.exe : fatal error LNK1120: 6 nicht aufgelöste Externe

Why? - Or, more precisely, why does _only_ this build fail, the other
five don't?

My compilation script:
https://tuxproject.de/projects/vim/_compile.bat.php

(It is the second x86 compilation...)

What am I missing?

TIA!

-- 
-- 
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: Three diffent systems used for translating messages, menu, doc

[Antonio Giovanni Colombo]

Well, very few people are still using 8.3 systems.
So, that is no longer a problem, but it explains the choice
to go with three letter suffixes. Even today, most of the
Vim documentation (e.g. doc/options.txt) uses 8.3 names.
And yes, newer documentation is not limited to 8.3 character
names (e.g. pi_getscript.txt).

On Thu, Jun 28, 2018 at 10:08 PM scootergrisen 
wrote:

> Den 28-06-2018 kl. 21:39 skrev Antonio Giovanni Colombo:
> > I think the reason was to use two letters to identifiy the language, and
> > keep the third one fixed ("x") because in the old day of MS-DOS 8.3
> > names, the suffixes were usually of three letters. I have no problem at
> > all with this. All boils down to "easy to manage".
>
> Ok so it comes from 8.3 but would anything bad happen if it was updated
> now to allow longer file names?
>
> The lang/menu* files uses longer file names so do they not work on a
> system that use 8.3?
>

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

[Bram Moolenaar]

Patch 8.1.0126
Problem:Various problems with 'vartabstop'.
Solution:   Fix memory leak.  Fix crash. Add a few more tests. (Christian
Brabandt, closes #3076)
Files:  src/ex_cmds.c, src/option.c, src/screen.c,
src/testdir/test_vartabs.vim


*** ../vim-8.1.0125/src/ex_cmds.c   2018-06-28 11:28:04.79340 +0200
--- src/ex_cmds.c   2018-06-28 20:37:11.354721386 +0200
***
*** 866,872 
{
set_string_option_direct((char_u *)"vts", -1, new_ts_str,
OPT_FREE|OPT_LOCAL, 0);
-   vim_free(new_ts_str);
curbuf->b_p_vts_array = new_vts_array;
vim_free(old_vts_ary);
}
--- 866,871 
***
*** 877,882 
--- 876,882 
curbuf->b_p_ts = tabstop_first(new_vts_array);
vim_free(new_vts_array);
}
+   vim_free(new_ts_str);
  }
  #else
  curbuf->b_p_ts = new_ts;
*** ../vim-8.1.0125/src/option.c2018-06-28 15:29:48.081656098 +0200
--- src/option.c2018-06-28 20:40:51.173370370 +0200
***
*** 12870,12876 
  tabstop_fromto(
colnr_T start_col,
colnr_T end_col,
!   int ts,
int *vts,
int *ntabs,
int *nspcs)
--- 12870,12876 
  tabstop_fromto(
colnr_T start_col,
colnr_T end_col,
!   int ts_arg,
int *vts,
int *ntabs,
int *nspcs)
***
*** 12880,12891 
  int   padding = 0;
  int   tabcount;
  int   t;
  
  if (vts == NULL || vts[0] == 0)
  {
int tabs = 0;
!   int initspc = ts - (start_col % ts);
  
if (spaces >= initspc)
{
spaces -= initspc;
--- 12880,12893 
  int   padding = 0;
  int   tabcount;
  int   t;
+ int   ts = ts_arg == 0 ? curbuf->b_p_ts : ts_arg;
  
  if (vts == NULL || vts[0] == 0)
  {
int tabs = 0;
!   int initspc = 0;
  
+   initspc = ts - (start_col % ts);
if (spaces >= initspc)
{
spaces -= initspc;
*** ../vim-8.1.0125/src/screen.c2018-06-25 21:24:47.284934379 +0200
--- src/screen.c2018-06-28 20:38:50.538108113 +0200
***
*** 4753,4765 
n_extra = win_lbr_chartabsize(wp, line, p, (colnr_T)vcol,
NULL) - 1;
if (c == TAB && n_extra + col > wp->w_width)
! #ifdef FEAT_VARTABS
n_extra = tabstop_padding(vcol, wp->w_buffer->b_p_ts,
!   wp->w_buffer->b_p_vts_array) - 1;
! #else
n_extra = (int)wp->w_buffer->b_p_ts
   - vcol % (int)wp->w_buffer->b_p_ts - 1;
!  #endif
  
  # ifdef FEAT_MBYTE
c_extra = mb_off > 0 ? MB_FILLER_CHAR : ' ';
--- 4753,4765 
n_extra = win_lbr_chartabsize(wp, line, p, (colnr_T)vcol,
NULL) - 1;
if (c == TAB && n_extra + col > wp->w_width)
! # ifdef FEAT_VARTABS
n_extra = tabstop_padding(vcol, wp->w_buffer->b_p_ts,
! wp->w_buffer->b_p_vts_array) - 1;
! # else
n_extra = (int)wp->w_buffer->b_p_ts
   - vcol % (int)wp->w_buffer->b_p_ts - 1;
! # endif
  
  # ifdef FEAT_MBYTE
c_extra = mb_off > 0 ? MB_FILLER_CHAR : ' ';
***
*** 4902,4907 
--- 4902,4912 
p_extra_free = p;
for (i = 0; i < tab_len; i++)
{
+   if (*p == NUL)
+   {
+   tab_len = i;
+   break;
+   }
  #ifdef FEAT_MBYTE
mb_char2bytes(lcs_tab2, p);
p += mb_char2len(lcs_tab2);
*** ../vim-8.1.0125/src/testdir/test_vartabs.vim2018-06-25 
21:24:47.284934379 +0200
--- src/testdir/test_vartabs.vim2018-06-28 20:42:19.772833210 +0200
***
*** 262,282 
  endfunc
  
  func! Test_vartabs_linebreak()
!   if winwidth(0) < 80
  return
endif
new
!   70vnew
%d
!   setl linebreak vartabstop=10,15,20,40
call setline(1, "\tx\tx\tx\tx")
  
!   let lines = ScreenLines([1, 2], winwidth(0))
!   let expect = ['  x  x   x   
 ',
! \   '   x 
 ']
call s:compare_lines(expect, lines)
  
" cleanup
bw!
bw!
  endfunc
--- 262,298 
  endfunc
  
  func! Test_vartabs_linebreak()
!   if 

Re: Three diffent systems used for translating messages, menu, doc

[scootergrisen]

Den 28-06-2018 kl. 21:39 skrev Antonio Giovanni Colombo:
I think the reason was to use two letters to identifiy the language, and 
keep the third one fixed ("x") because in the old day of MS-DOS 8.3 
names, the suffixes were usually of three letters. I have no problem at 
all with this. All boils down to "easy to manage".


Ok so it comes from 8.3 but would anything bad happen if it was updated 
now to allow longer file names?


The lang/menu* files uses longer file names so do they not work on a 
system that use 8.3?


--
--
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: Three diffent systems used for translating messages, menu, doc

[Antonio Giovanni Colombo]

I think the reason was to use two letters to identifiy the language, and
keep the third one fixed ("x") because in the old day of MS-DOS 8.3 names,
the suffixes were usually of three letters. I have no problem at all with
this. All boils down to "easy to manage".

On Thu, Jun 28, 2018 at 8:45 PM scootergrisen 
wrote:

> Den 28-06-2018 kl. 20:14 skrev Antonio Giovanni Colombo:
> > Hi,
> >
> > the reason for the suffix in the file names is that "that way" all the
> > files (and the tags tags-ll files) are in the same directory. That makes
> > a lot of sense to me (I don't have to define a directory to get the
> > Italian docs, and the English docs are always available asking e.g.
> > intro@en).
>
> But why change a common file exenstion like .txt to unknown file
> extension like .dax .itx .cnx .rux?
>
> --
> --
> 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.
>


-- 
   /||\| Antonio Colombo
  / || \   |  azc...@gmail.com
 /  ()  \  | anto...@geekcorp.com
(___||___) |   az...@yahoo.com

-- 
-- 
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: Three diffent systems used for translating messages, menu, doc

[scootergrisen]

Den 28-06-2018 kl. 20:14 skrev Antonio Giovanni Colombo:

Hi,

the reason for the suffix in the file names is that "that way" all the 
files (and the tags tags-ll files) are in the same directory. That makes 
a lot of sense to me (I don't have to define a directory to get the 
Italian docs, and the English docs are always available asking e.g. 
intro@en).


But why change a common file exenstion like .txt to unknown file 
extension like .dax .itx .cnx .rux?


--
--
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: Three diffent systems used for translating messages, menu, doc

[Antonio Giovanni Colombo]

Hi,

the reason for the suffix in the file names is that "that way" all the
files (and the tags tags-ll files) are in the same directory. That makes a
lot of sense to me (I don't have to define a directory to get the Italian
docs, and the English docs are always available asking e.g. intro@en).

The "message" thing depends on how it is done "generally": all programs do
it that way.

As for the menus, they are all in a single place, which also makes sense to
me.

By the way, of course, there have been times in which Vim was
"English-only". The internationalization came bit by bit, and was placed in
the "easier" places.

Hope it helps, Antonio



On Thu, Jun 28, 2018 at 6:26 PM scootergrisen 
wrote:

> It seems the translation files are using three different "systems".
>
> If i translate to "da" its:
> lang/da/LC_MESSAGES/vim.mo (da is folder)
> lang/menu_da.utf-8.vim (da is part of filename)
> doc/intro.dax (da is part of filename extension)
>
> The last one seems strange to change the extension.
>
> I would think it better to have something like:
> doc/da/intro.txt
> lang/da/intro.txt
> lang/da/doc/intro.txt
> lang/doc/intro.txt
> lang/doc/da/intro.txt
> Or:
> doc/intro.da.txt
> doc/intro_da.txt
>
> As a translation i would prefer having all translations the same place
> so in the lang folder.
>
>

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

[Bram Moolenaar]

Patch 8.1.0125
Problem:Virtual edit replace with multi-byte fails at end of line. (Lukas
Werling)
Solution:   use ins_char() to add the character. (Christian Brabandt,
closes #3114)  Rename PCHAR() to PBYTE() to avoid mistakes like
this.
Files:  src/ops.c, src/testdir/test_virtualedit.vim, src/macros.h


*** ../vim-8.1.0124/src/ops.c   2018-06-27 20:49:40.567862384 +0200
--- src/ops.c   2018-06-28 19:20:39.671555865 +0200
***
*** 2146,2151 
--- 2146,2170 
  #endif
  
  #if defined(FEAT_VISUALEXTRA) || defined(PROTO)
+ 
+ # ifdef FEAT_MBYTE
+ /*
+  * Replace the character under the cursor with "c".
+  * This takes care of multi-byte characters.
+  */
+ static void
+ replace_character(int c)
+ {
+ int n = State;
+ 
+ State = REPLACE;
+ ins_char(c);
+ State = n;
+ /* Backup to the replaced character. */
+ dec_cursor();
+ }
+ 
+ # endif
  /*
   * Replace a whole area with one character.
   */
***
*** 2331,2342 
 * with a multi-byte and the other way around. */
if (curwin->w_cursor.lnum == oap->end.lnum)
oap->end.col += (*mb_char2len)(c) - (*mb_char2len)(n);
!   n = State;
!   State = REPLACE;
!   ins_char(c);
!   State = n;
!   /* Backup to the replaced character. */
!   dec_cursor();
}
else
  #endif
--- 2350,2356 
 * with a multi-byte and the other way around. */
if (curwin->w_cursor.lnum == oap->end.lnum)
oap->end.col += (*mb_char2len)(c) - (*mb_char2len)(n);
!   replace_character(c);
}
else
  #endif
***
*** 2358,2364 
getvpos(>end, end_vcol);
}
  #endif
!   PCHAR(curwin->w_cursor, c);
}
}
  #ifdef FEAT_VIRTUALEDIT
--- 2372,2378 
getvpos(>end, end_vcol);
}
  #endif
!   PBYTE(curwin->w_cursor, c);
}
}
  #ifdef FEAT_VIRTUALEDIT
***
*** 2377,2385 
curwin->w_cursor.col -= (virtcols + 1);
for (; virtcols >= 0; virtcols--)
{
!   PCHAR(curwin->w_cursor, c);
!   if (inc(>w_cursor) == -1)
!   break;
}
}
  #endif
--- 2391,2404 
curwin->w_cursor.col -= (virtcols + 1);
for (; virtcols >= 0; virtcols--)
{
! #ifdef FEAT_MBYTE
!if ((*mb_char2len)(c) > 1)
!  replace_character(c);
!else
!  #endif
!   PBYTE(curwin->w_cursor, c);
!  if (inc(>w_cursor) == -1)
!  break;
}
}
  #endif
***
*** 2619,2625 
}
else
  #endif
!   PCHAR(*pos, nc);
return TRUE;
  }
  return FALSE;
--- 2638,2644 
}
else
  #endif
!   PBYTE(*pos, nc);
return TRUE;
  }
  return FALSE;
*** ../vim-8.1.0124/src/testdir/test_virtualedit.vim2018-04-25 
21:58:46.0 +0200
--- src/testdir/test_virtualedit.vim2018-06-28 19:12:57.486074037 +0200
***
*** 42,47 
--- 42,63 
set virtualedit=
  endfunc
  
+ func Test_replace_end_of_line()
+   new
+   set virtualedit=all
+   call setline(1, range(20))
+   exe "normal! gg2jv10lr-"
+   call assert_equal(["1", "---", "3"], getline(2,4))
+   if has('multi_byte')
+ call setline(1, range(20))
+ exe "normal! gg2jv10lr\hh"
+ call assert_equal(["1", "───", "3"], getline(2,4))
+   endif
+ 
+   bwipe!
+   set virtualedit=
+ endfunc
+ 
  func Test_edit_CTRL_G()
new
set virtualedit=insert
*** ../vim-8.1.0124/src/macros.h2018-04-10 18:37:19.0 +0200
--- src/macros.h2018-06-28 19:15:50.801135759 +0200
***
*** 14,22 
   */
  
  /*
!  * PCHAR(lp, c) - put character 'c' at position 'lp'
   */
! #define PCHAR(lp, c) (*(ml_get_buf(curbuf, (lp).lnum, TRUE) + (lp).col) = (c))
  
  /*
   * Position comparisons
--- 14,22 
   */
  
  /*
!  * PBYTE(lp, c) - put byte 'c' at position 'lp'
   */
! #define PBYTE(lp, c) (*(ml_get_buf(curbuf, (lp).lnum, TRUE) + (lp).col) = (c))
  
  /*
   * Position comparisons
*** ../vim-8.1.0124/src/version.c   2018-06-28 15:50:23.178568297 +0200
--- src/version.c   2018-06-28 19:11:53.922415636 +0200
***
*** 791,792 
--- 791,794 
  {   /* Add new patch number below this line */
+ /**/
+ 125,
  /**/

-- 
The coffee just wasn't strong enough to defend itself -- Tom Waits

 /// Bram Moolenaar -- b...@moolenaar.net -- 

Three diffent systems used for translating messages, menu, doc

[scootergrisen]

It seems the translation files are using three different "systems".

If i translate to "da" its:
lang/da/LC_MESSAGES/vim.mo (da is folder)
lang/menu_da.utf-8.vim (da is part of filename)
doc/intro.dax (da is part of filename extension)

The last one seems strange to change the extension.

I would think it better to have something like:
doc/da/intro.txt
lang/da/intro.txt
lang/da/doc/intro.txt
lang/doc/intro.txt
lang/doc/da/intro.txt
Or:
doc/intro.da.txt
doc/intro_da.txt

As a translation i would prefer having all translations the same place 
so in the lang folder.


--
--
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: The translated help files

[scootergrisen]

We can assume users will only get one of the packages and know where to
find it.  Putting them in a central place doesn't really help for that.


It would have helped the users looking for french, persian or polish 
translations because the links on https://www.vim.org/translations.php 
dont work.


So having a copy/mirror/backup on GitHub or other site might have helped 
them.


http://www.isfahanlug.org/doku.php?id=vim says:
This domain expired / dropped on 2018-06-28

--
--
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: Command to get the help translations file and set language

[Tony Mechelynck]

Shouldn't the translated help files be (like the translated menu and
messages files already are) part of Vim's version control system, i.e.
shouldn't they live somewhere on Vim's git server (and therefore on
its Mercurial mirror)? Then "make installruntime" (and therefore "make
install") would install them like it already installs the .mo files
and the translated menu files.

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: Command to get the help translations file and set language

[scootergrisen]

Den 28-06-2018 kl. 15:39 skrev Antonio Giovanni Colombo:


 > > Are there something simalar for the help translations?
 > > Like maybe ":set helplang=da something" could download the danish help
 > > files.
 > >
 > We currently don't do that, but I suppose it's possible.  We would need
 > to have the mapping from language to download location in the
 > distribution.  And we might need to ask the translation maintainer to
 > make sure it's in the right format, so we can use the same commands for
 > every language.

As far as I can tell, what is needed for language "ll" is
a ZIPped file containing the
*.llx files, plus tags-ll, plus READMEll.txt
The files themselves are updated from time to time,
so the ZIPped file can change more or less once per month.
If the files are managed by Bram, then we could just send him
the updated ZIPped file for a given language.
If not, the maintainer should be able to upload files to vim.org 
.


 > More interesting: How can we fetch updates?  Assuming that the
 > translations change once in a while, it must be possible for the user to
 > get the latest.

That would involve checking the modification date of the ZIPped file,
the problem being that the modification date of the "last" version
should be available somewhere. The modification date of the tags-ll
file could be a good place. In theory it should reflect the last
modification date (usually I prepare a new tags-ll file after
updating the documentation, just to play it safe).

Hope it helps, Antonio


I think its better the translators dont have to make zip files.
The translations would could be uploaded somewhere like GitHub and then 
when there is a Vim release the zip files could be created/updated at 
the same time or something like that.

Automatically by a computer.
If not possible automatically by a computer then manually by one person 
instead of many translators have to create zip files.


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

[Bram Moolenaar]

Patch 8.1.0124
Problem:has('vcon') returns true even for non-win32 terminal.
Solution:   Check the terminal type. (Nobuhiro Takasaki, closes #3106)
Files:  src/evalfunc.c


*** ../vim-8.1.0123/src/evalfunc.c  2018-06-24 19:01:55.411752372 +0200
--- src/evalfunc.c  2018-06-28 15:48:43.199224854 +0200
***
*** 6609,6615 
  #endif
  #ifdef FEAT_VTP
else if (STRICMP(name, "vcon") == 0)
!   n = has_vtp_working();
  #endif
  #ifdef FEAT_NETBEANS_INTG
else if (STRICMP(name, "netbeans_enabled") == 0)
--- 6609,6615 
  #endif
  #ifdef FEAT_VTP
else if (STRICMP(name, "vcon") == 0)
!   n = is_term_win32() && has_vtp_working();
  #endif
  #ifdef FEAT_NETBEANS_INTG
else if (STRICMP(name, "netbeans_enabled") == 0)
*** ../vim-8.1.0123/src/version.c   2018-06-28 15:29:48.085656078 +0200
--- src/version.c   2018-06-28 15:49:29.070921349 +0200
***
*** 791,792 
--- 791,794 
  {   /* Add new patch number below this line */
+ /**/
+ 124,
  /**/

-- 
There are three kinds of persons: Those who can count and those who can't.

 /// 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: Command to get the help translations file and set language

[Antonio Giovanni Colombo]

> > Are there something simalar for the help translations?
> > Like maybe ":set helplang=da something" could download the danish help
> > files.
> >
> We currently don't do that, but I suppose it's possible.  We would need
> to have the mapping from language to download location in the
> distribution.  And we might need to ask the translation maintainer to
> make sure it's in the right format, so we can use the same commands for
> every language.

As far as I can tell, what is needed for language "ll" is
a ZIPped file containing the
*.llx files, plus tags-ll, plus READMEll.txt
The files themselves are updated from time to time,
so the ZIPped file can change more or less once per month.
If the files are managed by Bram, then we could just send him
the updated ZIPped file for a given language.
If not, the maintainer should be able to upload files to vim.org.

> More interesting: How can we fetch updates?  Assuming that the
> translations change once in a while, it must be possible for the user to
> get the latest.

That would involve checking the modification date of the ZIPped file,
the problem being that the modification date of the "last" version
should be available somewhere. The modification date of the tags-ll
file could be a good place. In theory it should reflect the last
modification date (usually I prepare a new tags-ll file after
updating the documentation, just to play it safe).

Hope it helps, Antonio

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

[Bram Moolenaar]

Patch 8.1.0123
Problem:MS-Windows: colors are wrong after setting 'notgc'.
Solution:   Only call control_console_color_rgb() for the win32 terminal.
(Nobuhiro Takasaki, closes #3107)
Files:  src/option.c


*** ../vim-8.1.0122/src/option.c2018-06-24 23:53:25.153526495 +0200
--- src/option.c2018-06-28 15:26:10.110799983 +0200
***
*** 8819,8828 
  # endif
highlight_gui_started();
  # ifdef FEAT_VTP
-   control_console_color_rgb();
/* reset t_Co */
if (is_term_win32())
set_termname(T_NAME);
  # endif
  }
  #endif
--- 8819,8831 
  # endif
highlight_gui_started();
  # ifdef FEAT_VTP
/* reset t_Co */
if (is_term_win32())
+   {
+   control_console_color_rgb();
set_termname(T_NAME);
+   init_highlight(TRUE, FALSE);
+   }
  # endif
  }
  #endif
*** ../vim-8.1.0122/src/version.c   2018-06-28 14:54:38.764565527 +0200
--- src/version.c   2018-06-28 15:29:00.809904697 +0200
***
*** 791,792 
--- 791,794 
  {   /* Add new patch number below this line */
+ /**/
+ 123,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
132. You come back and check this list every half-hour.

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

[Jason Franklin]

I see now.  Thanks for the explanation!

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

[Bram Moolenaar]

Jason Franklin wrote:

> I was a little confused by this patch, and I was hoping you'd enlighten me.
> 
> 1. I see that the error messages from the test don't show up when I restored
> 'modifiable' in the original patch.  So I didn't see them while working.
> 
> 2. They also go away when using ":setlocal" instead of ":set", as you did.
> 
> This seems weird to me, and I'm not exactly sure why this works.  Since
> 'modifiable' is always local to the buffer, shouldn't ":set" work just as
> well?  I'm just having trouble making sense of your commit message.
> 
> I'm puzzled.

What happened is that I removed restoring 'modified', ran the tests and
it looked OK.  But then CI failed.  But without an actual error message.
I then figured that what happens is that because 'modified' is off in
testdir/messages, the test script is unable to tell us what went wrong.

The obvious mistake was to use "set" instead of "setlocal".  Your
original change worked around that be resetting 'modified', which also
resets the global (default) value.  This is the value picked up by new
buffers, thus the global value for the local option.

-- 
Why is it called "Windows"?  "Gates" would be more appropriate...

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

[Bram Moolenaar]

Patch 8.1.0122
Problem:Translators don't always understand the maintainer message.
Solution:   Add a comment that ends up in the generated po file. (Christian
Brabandt, closes #3037)
Files:  src/message.c


*** ../vim-8.1.0121/src/message.c   2018-06-23 19:22:45.610486284 +0200
--- src/message.c   2018-06-28 14:52:34.909193468 +0200
***
*** 982,988 
--- 982,992 
  {
s = mch_getenv((char_u *)"LANG");
if (s != NULL && *s != NUL)
+   // The next comment is extracted by xgettext and put in po file for
+   // translators to read.
msg_attr((char_u *)
+   // Translator: Please replace the name and email address
+   // with the appropriate text for your translation.
_("Messages maintainer: Bram Moolenaar "),
HL_ATTR(HLF_T));
  }
*** ../vim-8.1.0121/src/version.c   2018-06-28 12:05:07.089006904 +0200
--- src/version.c   2018-06-28 14:53:46.820830021 +0200
***
*** 791,792 
--- 791,794 
  {   /* Add new patch number below this line */
+ /**/
+ 122,
  /**/

-- 
In a world without fences, who needs Gates and Windows?

 /// 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: Command to get the help translations file and set language

[Bram Moolenaar]

> I dont know much about Vim but i saw running ":set spl=da spell" will 
> ask to download the files.
> 
> I havent tried it much but it seems smart if the spell check files can 
> be downloaded for a language and set the language at the same time so i 
> dont have to figure out where to download and what folder to place the 
> fine in etc.
> 
> Are there something simalar for the help translations?
> Like maybe ":set helplang=da something" could download the danish help 
> files.
> 
> That would make it easier to get and use them instead of having to 
> figure out all kinds of things.

We currently don't do that, but I suppose it's possible.  We would need
to have the mapping from language to download location in the
distribution.  And we might need to ask the translation maintainer to
make sure it's in the right format, so we can use the same commands for
every language.

More interesting: How can we fetch updates?  Assuming that the
translations change once in a while, it must be possible for the user to
get the latest.

-- 
All true wisdom is found on T-shirts.

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

[Jason Franklin]

Hey Bram,

I was a little confused by this patch, and I was hoping you'd enlighten me.

1. I see that the error messages from the test don't show up when I restored
'modifiable' in the original patch.  So I didn't see them while working.

2. They also go away when using ":setlocal" instead of ":set", as you did.

This seems weird to me, and I'm not exactly sure why this works.  Since
'modifiable' is always local to the buffer, shouldn't ":set" work just as
well?  I'm just having trouble making sense of your commit message.

I'm puzzled.

Thanks,
Jason

-- 
-- 
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: The translated help files

[Bram Moolenaar]

> Why not collect all the translated help files the same place instead of 
> all these different links to websites 
> (https://www.vim.org/translations.php) that uses different way to get 
> the files?
> 
> Also some of the links dont work any longer.
> Persian and polish at the moment says not found.
> 
> It would be sad if the translations are lost just because some website 
> is shut down.

This was done so that each translator (or team) could update the
translations whenever they like.  The number of updates is much larger
than for other runtime files, if the translation is actively being
worked on.

We can assume users will only get one of the packages and know where to
find it.  Putting them in a central place doesn't really help for that.

It should be possible to put them in github, but that's completely up to
the translator.

-- 
hundred-and-one symptoms of being an internet addict:
131. You challenge authority and society by portnuking people

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

Command to get the help translations file and set language

[scootergrisen]

I dont know much about Vim but i saw running ":set spl=da spell" will 
ask to download the files.


I havent tried it much but it seems smart if the spell check files can 
be downloaded for a language and set the language at the same time so i 
dont have to figure out where to download and what folder to place the 
fine in etc.


Are there something simalar for the help translations?
Like maybe ":set helplang=da something" could download the danish help 
files.


That would make it easier to get and use them instead of having to 
figure out all kinds of things.


--
--
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] SAS syntax and indent scripts

[Bram Moolenaar]

Keny Hu wrote:

> That makes sense. Thanks for the tip. Here is the updated indent file.

Thanks, I'll include this one.

-- 
hundred-and-one symptoms of being an internet addict:
126. You brag to all of your friends about your date Saturday night...but
 you don't tell them it was only in a 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: Segfault with termdebug in versions after v8.1.105 (FEAT_VARTABS)

[Bram Moolenaar]

Markus Braun wrote:

> I spend some more time reading the code. It seems that the member `vts` of
> struct `BalloonEval` needs to be initialized in `check_due_timer()` after
> allocating the storage. Otherwise the pointer `vts` has arbitrary value and
> `vim_free()` is called in `get_beval_info()` for this uninitialized pointer.
> 
> The attached patch solves the problem for me. I don`t know if this is the
> best solution.

I'm glad you managed to figure this out.

I think the safest is to use alloc_clear().

-- 
hundred-and-one symptoms of being an internet addict:
128. You can access the Net -- via your portable and cellular phone.

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

[Bram Moolenaar]

Patch 8.1.0121
Problem:Crash when using ballooneval related to 'vartabstop'.
Solution:   Initialize balloonEval->vts to NULL. (Markus Braun)
Files:  src/ex_cmds2.c, src/gui_beval.c, src/gui_w32.c, src/gui.c


*** ../vim-8.1.0120/src/ex_cmds2.c  2018-05-12 15:36:03.0 +0200
--- src/ex_cmds2.c  2018-06-28 11:54:26.812645846 +0200
***
*** 1419,1425 
bevalexpr_due_set = FALSE;
if (balloonEval == NULL)
{
!   balloonEval = (BalloonEval *)alloc(sizeof(BalloonEval));
balloonEvalForTerm = TRUE;
}
if (balloonEval != NULL)
--- 1419,1425 
bevalexpr_due_set = FALSE;
if (balloonEval == NULL)
{
!   balloonEval = (BalloonEval *)alloc_clear(sizeof(BalloonEval));
balloonEvalForTerm = TRUE;
}
if (balloonEval != NULL)
*** ../vim-8.1.0120/src/gui_beval.c 2018-06-23 19:22:45.606486311 +0200
--- src/gui_beval.c 2018-06-28 11:58:57.003085639 +0200
***
*** 111,138 
return NULL;
  }
  
! beval = (BalloonEval *)alloc(sizeof(BalloonEval));
  if (beval != NULL)
  {
  #ifdef FEAT_GUI_GTK
beval->target = GTK_WIDGET(target);
-   beval->balloonShell = NULL;
-   beval->timerID = 0;
  #else
beval->target = (Widget)target;
-   beval->balloonShell = NULL;
-   beval->timerID = (XtIntervalId)NULL;
beval->appContext = XtWidgetToApplicationContext((Widget)target);
  #endif
beval->showState = ShS_NEUTRAL;
-   beval->x = 0;
-   beval->y = 0;
beval->msg = mesg;
beval->msgCB = mesgCB;
beval->clientData = clientData;
- #ifdef FEAT_VARTABS
-   beval->vts = NULL;
- #endif
  
/*
 * Set up event handler which will keep its eyes on the pointer,
--- 111,129 
return NULL;
  }
  
! beval = (BalloonEval *)alloc_clear(sizeof(BalloonEval));
  if (beval != NULL)
  {
  #ifdef FEAT_GUI_GTK
beval->target = GTK_WIDGET(target);
  #else
beval->target = (Widget)target;
beval->appContext = XtWidgetToApplicationContext((Widget)target);
  #endif
beval->showState = ShS_NEUTRAL;
beval->msg = mesg;
beval->msgCB = mesgCB;
beval->clientData = clientData;
  
/*
 * Set up event handler which will keep its eyes on the pointer,
*** ../vim-8.1.0120/src/gui_w32.c   2018-06-23 19:22:45.606486311 +0200
--- src/gui_w32.c   2018-06-28 11:59:35.478867007 +0200
***
*** 8922,8949 
return NULL;
  }
  
! beval = (BalloonEval *)alloc(sizeof(BalloonEval));
  if (beval != NULL)
  {
beval->target = s_textArea;
-   beval->balloon = NULL;
  
beval->showState = ShS_NEUTRAL;
-   beval->x = 0;
-   beval->y = 0;
beval->msg = mesg;
beval->msgCB = mesgCB;
beval->clientData = clientData;
- #ifdef FEAT_VARTABS
-   beval->vts = NULL;
- #endif
  
InitCommonControls();
cur_beval = beval;
  
if (p_beval)
gui_mch_enable_beval_area(beval);
- 
  }
  return beval;
  }
--- 8922,8942 
return NULL;
  }
  
! beval = (BalloonEval *)alloc_clear(sizeof(BalloonEval));
  if (beval != NULL)
  {
beval->target = s_textArea;
  
beval->showState = ShS_NEUTRAL;
beval->msg = mesg;
beval->msgCB = mesgCB;
beval->clientData = clientData;
  
InitCommonControls();
cur_beval = beval;
  
if (p_beval)
gui_mch_enable_beval_area(beval);
  }
  return beval;
  }
*** ../vim-8.1.0120/src/gui.c   2018-05-13 17:03:53.0 +0200
--- src/gui.c   2018-06-28 12:01:22.930259972 +0200
***
*** 745,751 
--- 745,756 
/* Always create the Balloon Evaluation area, but disable it when
 * 'ballooneval' is off. */
if (balloonEval != NULL)
+   {
+ # ifdef FEAT_VARTABS
+   vim_free(balloonEval->vts);
+ # endif
vim_free(balloonEval);
+   }
balloonEvalForTerm = FALSE;
  # ifdef FEAT_GUI_GTK
balloonEval = gui_mch_create_beval_area(gui.drawarea, NULL,
*** ../vim-8.1.0120/src/version.c   2018-06-28 11:28:04.797455530 +0200
--- src/version.c   2018-06-28 12:02:15.657963770 +0200
***
*** 791,792 
--- 791,794 
  {   /* Add new patch number below this line */
+ /**/
+ 121,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
129. You cancel your newspaper subscription.

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

Patch 8.1.0120

[Bram Moolenaar]

Patch 8.1.0120
Problem:Buffer 'modified' set even when :sort has no changes.
Solution:   Only set 'modified' when lines are moved. (Jason Franklin)
Files:  src/ex_cmds.c, src/testdir/test_sort.vim


*** ../vim-8.1.0119/src/ex_cmds.c   2018-06-24 23:53:25.149526513 +0200
--- src/ex_cmds.c   2018-06-28 11:22:44.383108832 +0200
***
*** 398,403 
--- 398,404 
  colnr_T   end_col;
  int   sort_what = 0;
  int   format_found = 0;
+ int   change_occurred = FALSE; // Buffer contents changed.
  
  /* Sorting one line is really quick! */
  if (count <= 1)
***
*** 616,627 
  lnum = eap->line2;
  for (i = 0; i < count; ++i)
  {
!   s = ml_get(nrs[eap->forceit ? count - i - 1 : i].lnum);
if (!unique || i == 0
|| (sort_ic ? STRICMP(s, sortbuf1) : STRCMP(s, sortbuf1)) != 0)
{
!   /* Copy the line into a buffer, it may become invalid in
!* ml_append(). And it's needed for "unique". */
STRCPY(sortbuf1, s);
if (ml_append(lnum++, sortbuf1, (colnr_T)0, FALSE) == FAIL)
break;
--- 617,635 
  lnum = eap->line2;
  for (i = 0; i < count; ++i)
  {
!   linenr_T get_lnum = nrs[eap->forceit ? count - i - 1 : i].lnum;
! 
!   // If the original line number of the line being placed is not the same
!   // as "lnum" (accounting for offset), we know that the buffer changed.
!   if (get_lnum + ((linenr_T)count - 1) != lnum)
!   change_occurred = TRUE;
! 
!   s = ml_get(get_lnum);
if (!unique || i == 0
|| (sort_ic ? STRICMP(s, sortbuf1) : STRCMP(s, sortbuf1)) != 0)
{
!   // Copy the line into a buffer, it may become invalid in
!   // ml_append(). And it's needed for "unique".
STRCPY(sortbuf1, s);
if (ml_append(lnum++, sortbuf1, (colnr_T)0, FALSE) == FAIL)
break;
***
*** 644,650 
mark_adjust(eap->line2 - deleted, eap->line2, (long)MAXLNUM, -deleted);
  else if (deleted < 0)
mark_adjust(eap->line2, MAXLNUM, -deleted, 0L);
! changed_lines(eap->line1, 0, eap->line2 + 1, -deleted);
  
  curwin->w_cursor.lnum = eap->line1;
  beginline(BL_WHITE | BL_FIX);
--- 652,660 
mark_adjust(eap->line2 - deleted, eap->line2, (long)MAXLNUM, -deleted);
  else if (deleted < 0)
mark_adjust(eap->line2, MAXLNUM, -deleted, 0L);
! 
! if (change_occurred || deleted != 0)
!   changed_lines(eap->line1, 0, eap->line2 + 1, -deleted);
  
  curwin->w_cursor.lnum = eap->line1;
  beginline(BL_WHITE | BL_FIX);
*** ../vim-8.1.0119/src/testdir/test_sort.vim   2017-09-23 18:58:18.0 
+0200
--- src/testdir/test_sort.vim   2018-06-28 11:21:15.071564844 +0200
***
*** 1,13 
! " Test sort()
  
! :func Compare1(a, b) abort
  call sort(range(3), 'Compare2')
  return a:a - a:b
! :endfunc
  
! :func Compare2(a, b) abort
  return a:a - a:b
! :endfunc
  
  func Test_sort_strings()
" numbers compared as strings
--- 1,13 
! " Tests for the "sort()" function and for the ":sort" command.
  
! func Compare1(a, b) abort
  call sort(range(3), 'Compare2')
  return a:a - a:b
! endfunc
  
! func Compare2(a, b) abort
  return a:a - a:b
! endfunc
  
  func Test_sort_strings()
" numbers compared as strings
***
*** 45,51 
call assert_fails('call sort([3.3, 1, "2"], 3)', "E474")
  endfunc
  
! " Tests for the :sort command
  func Test_sort_cmd()
let tests = [
\ {
--- 45,51 
call assert_fails('call sort([3.3, 1, "2"], 3)', "E474")
  endfunc
  
! " Tests for the ":sort" command.
  func Test_sort_cmd()
let tests = [
\ {
***
*** 1167,1181 
\   '1.234',
\   '123.456'
\]
!   \ }
\ ]
  
for t in tests
  enew!
  call append(0, t.input)
  $delete _
! exe t.cmd
  call assert_equal(t.expected, getline(1, '$'), t.name)
endfor
  
call assert_fails('sort no', 'E474')
--- 1167,1220 
\   '1.234',
\   '123.456'
\]
!   \ },
!   \ {
!   \'name' : 'alphabetical, sorted input',
!   \'cmd' : 'sort',
!   \'input' : [
!   \   'a',
!   \   'b',
!   \   'c',
!   \],
!   \'expected' : [
!   \   'a',
!   \   'b',
!   \   'c',
!   \]
!   \ },
!   \ {
!   \'name' : 'alphabetical, sorted input, unique at end',
!   \'cmd' : 'sort u',
!   \'input' : [
!   \   'aa',
!   \   'bb',
!   \   'cc',
!   \   'cc',
!   \],
!   \'expected' : [
!   \   'aa',
!   \   'bb',
!   \   'cc',
!   \]
!   \ },
\ ]
  
for t in tests
  enew!
  call 

Re: [patch] Make :sort only set when the buffer changed

[Bram Moolenaar]

Jason Franklin wrote:

> I noticed that the :sort command always sets 'modified'.
> 
> This patch makes :sort check whether or not it actually changed
> the buffer.
> 
> Tests included.

Thanks.  One case where it is not correct: with "sort u" when the last
line is dropped.  I'll correct that.

I don't see why you prepend "l:" to local variables.  I dropped that.

-- 
I'm writing a book.  I've got the page numbers done.

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