Re: Obsolete (incomplete) help for 'highlight'

[Bram Moolenaar]

Tony Mechelynck wrote:

> AFAICT, the current default for the 'highlight' option is:
> (reformatted here by adding spaces to allow line-wrapping)
> 
> 8:SpecialKey, ~:EndOfBuffer, @:NonText, d:Directory, e:ErrorMsg,
> i:IncSearch, l:Search, m:MoreMsg, M:ModeMsg, n:LineNr, N:CursorLineNr,
> r:Question, s:StatusLine, S:StatusLineNC, c:VertSplit, t:Title,
> v:Visual, V:VisualNOS, w:WarningMsg, W:WildMenu, f:Folded,
> F:FoldColumn, A:DiffAdd, C:DiffChange, D:DiffDelete, T:DiffText,
> >:SignColumn, -:Conceal, B:SpellBad, P:SpellCap, R:SpellRare,
> L:SpellLocal, +:Pmenu, =:PmenuSel, x:PmenuSbar, X:PmenuThumb,
> *:TabLine, #:TabLineSel, _:TabLineFill, !:CursorColumn, .:CursorLine,
> o:ColorColumn
> 
> The last six items are not mentioned in the "default" value at top of
> that help section, nor are their meanings explained in the body of the
> help. This is in runtime/doc /options.txt lines 4028 to 4109. The
> meanings are more or less explanatory, but details would be welcome.
> (Typing :help hl- followed by the highlight name then Enter does find
> the corresponding entry in the syntax.txt helpfile.)

Thanks for noticing.  I'll update the documented default.

-- 
hundred-and-one symptoms of being an internet addict:
21. Your dog has its own home page.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch 8.0.0628

[Bram Moolenaar]

Patch 8.0.0628 (after 8.0.0626
Problem:Cursor disappears after silent mapping. (Ramel Eshed)
Solution:   Do restore the cursor when it was changed, but don't change it in
the first place for a silent mapping.
Files:  src/getchar.c


*** ../vim-8.0.0627/src/getchar.c   2017-06-05 19:32:28.702723156 +0200
--- src/getchar.c   2017-06-07 20:38:30.133907045 +0200
***
*** 2583,2589 
   * get a character: 3. from the user - handle  in Insert mode
   */
/*
!* special case: if we get an  in insert mode and there
 * are no more characters at once, we pretend to go out of
 * insert mode.  This prevents the one second delay after
 * typing an .  If we get something after all, we may
--- 2583,2589 
   * get a character: 3. from the user - handle  in Insert mode
   */
/*
!* Special case: if we get an  in insert mode and there
 * are no more characters at once, we pretend to go out of
 * insert mode.  This prevents the one second delay after
 * typing an .  If we get something after all, we may
***
*** 2617,2624 
mode_deleted = TRUE;
}
  #ifdef FEAT_GUI
!   /* may show different cursor shape */
!   if (gui.in_use)
{
int save_State;
  
--- 2617,2624 
mode_deleted = TRUE;
}
  #ifdef FEAT_GUI
!   /* may show a different cursor shape */
!   if (gui.in_use && State != NORMAL && !cmd_silent)
{
int save_State;
  
***
*** 2913,2928 
  }
  #ifdef FEAT_GUI
  /* may unshow different cursor shape */
! if (gui.in_use)
! {
!   if (cmd_silent)
!   gui_dont_update_cursor(TRUE);
!   else
!   gui_can_update_cursor();
! 
!   if (shape_changed)
!   gui_update_cursor(TRUE, FALSE);
! }
  #endif
  
  --vgetc_busy;
--- 2913,2920 
  }
  #ifdef FEAT_GUI
  /* may unshow different cursor shape */
! if (gui.in_use && shape_changed)
!   gui_update_cursor(TRUE, FALSE);
  #endif
  
  --vgetc_busy;
*** ../vim-8.0.0627/src/version.c   2017-06-05 19:56:01.124964522 +0200
--- src/version.c   2017-06-07 20:39:19.821545423 +0200
***
*** 766,767 
--- 766,769 
  {   /* Add new patch number below this line */
+ /**/
+ 628,
  /**/

-- 
Shift happens.
-- Doppler

 /// 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: wrong command-line redraw when using 'out_io': 'buffer' with job_start()

[Ramel Eshed]

On Friday, May 5, 2017 at 11:23:57 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > > > On Sunday, April 30, 2017 at 9:24:13 PM UTC+3, Bram Moolenaar wrote:
> > > > > Ramel Eshed wrote:
> > > > > 
> > > > > > On Sunday, April 30, 2017 at 5:25:08 PM UTC+3, Bram Moolenaar wrote:
> > > > > > > Ramel Eshed wrote:
> > > > > > > 
> > > > > > > > This is not the case with every job, but redirecting the 
> > > > > > > > following
> > > > > > > > script output to a buffer causes messages to disappear from 
> > > > > > > > command
> > > > > > > > line:
> > > > > > > >  
> > > > > > > > -- loop.sh --
> > > > > > > > #!/bin/bash
> > > > > > > > for i in `seq 1 1000`;
> > > > > > > > do
> > > > > > > > echo $i
> > > > > > > > sleep 0.008s
> > > > > > > > done
> > > > > > > > 
> > > > > > > > vim -u NONE -N
> > > > > > > > :call job_start('loop.sh', {'out_io': 'buffer', 'out_buf':1})
> > > > > > > > 
> > > > > > > > while the numbers are running try to do :pwd -this command's 
> > > > > > > > output
> > > > > > > > will disappear.
> > > > > > > > 
> > > > > > > > Also (not related to this issue), the buffer (which the job 
> > > > > > > > output was
> > > > > > > > redirected to) is only updated in normal and insert mode but 
> > > > > > > > not while
> > > > > > > > typing in command-line mode. Is it possible to update the 
> > > > > > > > buffer also
> > > > > > > > for command-line?
> > > > > > > 
> > > > > > > I suspect these are opposite requests.  Vim can only update the 
> > > > > > > whole
> > > > > > > screen, because the redraw causes any output from commands to be
> > > > > > > cleared. When looking at the output of :pwd, Vim is probably in 
> > > > > > > Normal
> > > > > > > mode, thus redraws to show the new buffer content.
> > > > > >
> > > > > > If I use
> > > > > > :call job_start('ls -lR /', {'out_io': 'buffer', 'out_buf':1})
> > > > > > instead of the above script, I can still see the :pwd command 
> > > > > > output.
> > > > > > How come it's not cleared as well?
> > > > > >
> > > > > > > I could check if we can update the window only. This probably 
> > > > > > > only works
> > > > > > > when the command line has not scrolled.
> > > > > 
> > > > > I have sent out patch 8.0.0592.  This attempts to update the buffer 
> > > > > that
> > > > > shows job output as often as possible.  And it tries to keep the 
> > > > > command
> > > > > line and command output.  Please check it out.  It does update the
> > > > > buffer more often than before, and should keep the output of commands
> > > > > like ":pwd".  It may cause new problems, I only tested a few things.
> > > > > 
> > > > I tested this patch with my plugins and it seems that both issues are
> > > > solved now. There is a minor issue with text and cursor flickering in
> > > > the command line, you can play with the sleep delay in the script
> > > > above and see if there is something you can do.
> > > > Many thanks!
> > > 
> > > It is unlikely the cursor flickering can be fixed.  It has to be
> > > switched off to be able to redraw the window for the modified buffer.
> > > 
> > Besides of the cursor, the part of the command that has already been
> > typed flickers as well, can you see that?
> 
> It might be possible to fix that, if we overwrite the command line and
> clear the rest.  Perhaps someone wants to have a go at that.
> 
> > Also, I found a problem with the command line completion menu - it is
> > cleared while the buffer is updated. You can see that by running my
> > example above after :set wildmode=list. While the buffer is updated
> > try to type :set and then hit tab -the completion menu will be
> > cleared.
> 
> Hmm, perhaps msg_scrolled isn't set in that situation, and we need to
> check another flag.
> 

Did anyone have a chance to look at this? both issues still exist.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Regularly exiting vim sets xterm in bracketed paste mode (#1671)

[Ramel Eshed]

On Tuesday, June 6, 2017 at 11:58:50 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > Any updates about this issue?
> > I'm using gnome terminal 2.31.3 (which comes with RHEL6) and must set t_BE= 
> > to avoid the corrupted pate issue in the terminal after exiting Vim.
> > 
> > I think that there is no reason to break old behavior, even if there is a 
> > workaround for that.
> 
> The support for bracketed paste was added for good reasons.  That before
> this many terminals that aren't actually an xterm worked fine, even when
> $TERM is set to xterm, doesn't mean this will keep working forever.
> The basic problem is that if a terminal isn't really an xterm, then it
> can break at any time.  That isn't Vim's fault.  We will try to make it
> work even when the user did not setup his system exactly right, but in
> this case I don't see how we can detect a "bad terminal".  I wish every
> terminal had a way to tell us its features instead of relying on setting
> $TERM correctly.
> 
> There should also be a way to separate a term response from what the
> user typed.  Haven't seen any progress on that, unfortunately.
> 

OK, I understand. Thank you for this 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.0.0626

[Ramel Eshed]

On Tuesday, June 6, 2017 at 11:25:30 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Monday, June 5, 2017 at 8:32:57 PM UTC+3, Bram Moolenaar wrote:
> > > Patch 8.0.0626
> > > Problem:In the GUI the cursor may flicker.
> > > Solution:   Check the cmd_silent flag before updating the cursor shape.
> > > (Hirohito Higashi, closes #1637)
> > > Files:  src/getchar.c
> > > 
> > > 
> > > *** ../vim-8.0.0625/src/getchar.c 2017-04-08 18:41:07.339941299 +0200
> > > --- src/getchar.c 2017-06-05 19:28:16.696484466 +0200
> > > ***
> > > *** 2913,2920 
> > >   }
> > >   #ifdef FEAT_GUI
> > >   /* may unshow different cursor shape */
> > > ! if (gui.in_use && shape_changed)
> > > ! gui_update_cursor(TRUE, FALSE);
> > >   #endif
> > >   
> > >   --vgetc_busy;
> > > --- 2913,2928 
> > >   }
> > >   #ifdef FEAT_GUI
> > >   /* may unshow different cursor shape */
> > > ! if (gui.in_use)
> > > ! {
> > > ! if (cmd_silent)
> > > ! gui_dont_update_cursor(TRUE);
> > > ! else
> > > ! gui_can_update_cursor();
> > > ! 
> > > ! if (shape_changed)
> > > ! gui_update_cursor(TRUE, FALSE);
> > > ! }
> > >   #endif
> > >   
> > >   --vgetc_busy;
> > > *** ../vim-8.0.0625/src/version.c 2017-06-05 18:46:20.497845949 +0200
> > > --- src/version.c 2017-06-05 19:06:06.449739127 +0200
> > > ***
> > > *** 766,767 
> > > --- 766,769 
> > >   {   /* Add new patch number below this line */
> > > + /**/
> > > + 626,
> > >   /**/
> > > 
> > > -- 
> > > "How is your new girlfriend?"
> > > "90-60-90 man!"
> > > "What, pale purple?"
> > > 
> > >  /// 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
> > > ///
> > 
> > Hi Bram,
> > 
> > This match makes the cursor disappear using the following mapping (tested 
> > on linux):
> > 
> > gvim -u NONE -N
> > :noremap   
> > 
> > now hit  -> no cursor
> 
> Yes, that is wrong.  I was wondering about the conditions anyway.  I
> would think that if shape_changed isn't set then nothing should happen.
> How about this:
> 
> #ifdef FEAT_GUI
> /* may unshow different cursor shape */
> if (gui.in_use && shape_changed && !cmd_silent)
>   gui_update_cursor(TRUE, FALSE);
> #endif
> 
> But then we perhaps get the flicker again?  An alternative is to not
> call gui_update_cursor() for NORMAL mode:
> 
> #ifdef FEAT_GUI
>   /* may show different cursor shape */
>   if (gui.in_use && State != NORMAL && !cmd_silent)
>   {
>   int save_State;
> 
>   save_State = State;
>   State = NORMAL;
>   gui_update_cursor(TRUE, FALSE);
>   State = save_State;
>   shape_changed = TRUE;
>   }
> #endif
> 
> -- 

Both options solved my problem, but I'm not sure about the original denite 
plugin issue.

Thanks

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Search for Russian letter range `[а-яА-Я ]` misses the letters `ё` and `Ё` (#1751)

[Nikolay Aleksandrovich Pavlov]

2017-06-07 16:47 GMT+03:00 Ruslan Kabatsayev :
> Not correct, not semantically. What Vim does is deliberately ignoring
> LC_COLLATE while grep acts according to this category which puts “ё”
> between “е” and “ж” like in the Russian alphabet.
>
> I'm not really sure that LC_COLLATE or even any LC_* influences this. Even
> if I unset all LC_* variables and set LC_ALL=en_US.UTF-8, I still get the
> expected behavior of grep and sed.

You need to set LC_COLLATE to some locale that uses cyrillic letters
on its own, *but has different alphabet* (specifically the one which
does not have “ё” between “а” and “я”). I do not know how libc authors
determine defaults for languages foreign to locale, but most likely
they just took DUCET (Default Unicode Collation Element Table) and
only altered needed locales, this is the intended DUCET usage after
all: (from http://unicode.org/reports/tr10/)

> Instead, the goal of DUCET is to provide a reasonable default ordering for 
> all scripts that are not tailored. Any characters used in the language of 
> primary interest for collation are expected to be tailored to meet all the 
> appropriate linguistic requirements for that language. For example, for a 
> user interested primarily in the Malayalam language, DUCET would be tailored 
> to get all details correct for the expected Malayalam collation order, while 
> leaving other characters (Greek, Cyrillic, Han, and so forth) in the default 
> order, because the order of those other characters is not of primary concern. 
> Conversely, a user interested primarily in the Greek language would use a 
> Greek-specific tailoring, while leaving the Malayalam (and other) characters 
> in their default order in the table.

>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Search for Russian letter range `[а-яА-Я ]` misses the letters `ё` and `Ё` (#1751)

[Nikolay Aleksandrovich Pavlov]

2017-06-07 14:17 GMT+03:00 Christian Brabandt :
> Hm, ё is 'ё' U+0451 Dec:1105 CYRILLIC SMALL LETTER IO (io) , while я
> is
> 'я' U+044F Dec:1103 CYRILLIC SMALL LETTER YA (ja) .
> Also Ё is 'Ё' U+0401 Dec:1025 CYRILLIC CAPITAL LETTER IO (IO) , while
> А is
> 'А' U+0410 Dec:1040 CYRILLIC CAPITAL LETTER A (A=) .
>
> So both letters are clearly out of your range. I would say Vim is correct
> here.

Not correct, not semantically. What Vim does is deliberately ignoring
LC_COLLATE while grep acts according to this category which puts “ё”
between “е” and “ж” like in the Russian alphabet.

>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.