Re: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

['Andy Wokula' via vim_dev]

Am 08.05.2017 um 22:28 schrieb Gary Johnson:

On 2017-05-08, 'Andy Wokula' via vim_dev wrote:

Am 08.05.2017 um 12:53 schrieb Bram Moolenaar:

For flexibility this needs to work recursively.  We could do something
like:

let saved_options = options_save()
... do your stuff ...
call options_restore(saved_options)

The options being saved should be small to keep this efficient.  We need
to make a list of the ones that are useful, such as 'ignorecase' and
'gdefault'.


What about a different approach:

Have a mode (for debugging only) in which builtin commands and
functions complain when options they use are not at the default
value.  This way the script writer learns which options need to be
set and restored.


Problems usually occur not with the options the script writer has
set to non-default values, but with options the script user has set
to non-default values.  This mode is not going to tell the writer
which options users may have set.


I hit the Send button, then it hit me ... right.


The safest approach, and the one most considerate of the user, is
for the plugin to save and restore the current value of any option
it depends on and sets.


But the question remains how to most easily and certainly find out
*which* options to set.  It should be more transparent which commands
(and functions) are affected by which options.

When everybody knows that for sure (maybe via dedicated help page?)
:commandaffected by  'option', ...
...
function()  affected by  'option', ...
...
h   affected by 'whichwrap', ...

then there could be a helper which traces executed (builtin) commands
and functions along a given way of execution, eg within the scope of a
modifier command, and fills a v:variable ... something like that.
Sounds like a lot of work ... each builtin command and function would
need to support it.
And :normal commands (e.g. `h' affected by 'whichwrap') are probably not
included.  Maybe `:normal h' is included, but not `feedkeys("h")' (out of
modifier command scope).

--
Andy

--
--
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] netrw-mf with g:netrw_liststyle =3 (#1692)

[Charles E Campbell]

Maxim Kolodyazhny wrote:
>
> VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May 03 2017 12:11:53)
> Included patches: 1-313, 315-596
>
> |../ foo/ | bar/ | | file.txt | file.txt |
>
> If I press mf on file.txt, both files will be marked
>
>
Actually, both files are highlighted; only one is actually marked.  See 
:help netrw-mf and look for "Known Problem".

Regards,
Chip Campbell

-- 
-- 
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: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

[Tony Mechelynck]

I'd rather remove as little existing stuff as possible, especially
when (for someone who knows how to read the help) it is known to work
as specified. Why not concentrate on the items in todo.txt before we
start waving sabers around into the existing code?

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: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

[h_east]

Hi Bram and all,

2017-5-8(Mon) 19:53:37 UTC+9 Bram Moolenaar:
> Christian Brabandt wrote:
> 
> > On Mi, 03 Mai 2017, h_east wrote:
> > 
> > > 'gdefault' invertes the 'g' flag of `:substitute`.
> > > In addition to 'edcompatible', it also inverts the 'c' flag.
> > > 
> > > When using `:substitute` with plugin, save and restore of the above 
> > > options are necessary, it is a little weird.
> > > 
> > > I propose to stop supporting these options.
> > > Please check the attached patch.
> > 
> > I made a little github code search for some vim settings. The results 
> > are a bit surprising:
> > 
> > Search Term Results
> > ---
> > set edcompatible6
> > set gdefault8,289
> > set langnoremap 718
> > set nolangremap 207
> > set termguicolors   3,425
> > set t_Co98,886
> > set laststatus  75,336
> > set nocompatible94,745
> > set incsearch   79,623
> > 
> > So gdefault seems to be popular to a certain degree. I wouldn't have 
> > thought that, it is just such an obscure option.
> > 
> > By contrast the usage of edcompatible can be neglected, that option 
> > seems to be in almost no use. Somewhat surprisingly, 'langnoremap' is 
> > still somewhat widespread, also it is replaced by 'langremap' option.
> > 
> > The relative newly introduced option termguicolors already seems to have 
> > widespread (at least it is already used more than the langnoremap 
> > option, which was introduced earlier).
> > 
> > I also included a search for settings I expected to be in wide use, e.g. 
> > 'nocompatible', 't_Co', 'laststatus' and 'incsearch' and that seems to 
> > be the case.
> > 
> > Coming back to the topic:
> > I am all for removing those options, however this is a hard change that 
> > may break scripts and will probably also annoy users (especially of 
> > 'gdefault', from which I would expect several bug reports, if that 
> > option will be dropped).
> > 
> > I see two possible solutions:
> > 
> > 1) start echoing warning messages, that those options are deprecated and 
> > after a grace period (e.g. the switch to Vim9) remove those options.
> > 2) make a distinction between interactive usage and script usage and for 
> > the script usage provide a clean environment where those options are not 
> > set, so scripts/functions do not need to handle that. That could also be 
> > enhanced later for other settings or even mappings.
> > 
> > 2 seems to be the cleaner approach and does not bug the user much, so 
> > that might be preferable. However I don't know how hard to implement 
> > this would be.
> > 
> > But anyhow, either approach is okay for me.
> 
> The problem with removing options is that you always hurt some users.
> And most probably the ones that just use whatever they have on their
> system.  Thus complaints might come very late.  Neovim is certainly not
> a good indication, because these users have made a choice to use a
> non-standard Vi/Vim.
> 
> Also, when one option only has 0.01% usage, and we remove a dozen of
> them, we are already at 0.12%, one in a thousand users.  That's likely
> more than users of more advanced features.

Certainly I have proposed to remove the option easily.
That's right, I should suggest a good solution before choosing to remove the 
option.
You have maintained "Vim specification" for over 20 years.
I don't know if your judgment is always right :-), but I would to respect your 
opinion strongly.

> 
> Besides that, plugin writers also have a problem with very common
> options, such as 'wrapscan' and 'ignorecase'.  We are nog going to
> remove these.  Having an easy way to set these to their default, and
> restore them later (without side effects), would be very useful.
> 
> For flexibility this needs to work recursively.  We could do something
> like:
> 
>   let saved_options = options_save()
>   ... do your stuff ...
>   call options_restore(saved_options)
> 
> The options being saved should be small to keep this efficient.  We need
> to make a list of the ones that are useful, such as 'ignorecase' and
> 'gdefault'.

For 'ignorecase' and 'smartcase', We have `\c` or `\C` that can ignore that 
setting.  (`:help /\c`, `:help /\C`)
Also, for 'magic', We have `\m` and `\M`.  (`:help /\m`, `:help /\M`)

It may be good if there is a similar mechanism for 'wrapscan', 'gdefault' and 
'edcompatible'.

Thanks.
--
Best regards,
Hirohito Higashi (h_east)

-- 
-- 
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: RFE: 'listchars' entry for soft-hyphen

[Tony Mechelynck]

On Mon, May 8, 2017 at 2:35 PM, Dominique Pellé
 wrote:
> Bram Moolenaar  wrote:
>
>> Tony Mechelynck wrote:
>>
>>> I notice that at the moment, the soft-hyphen (U+00AD) is displayed as
>>> a blank character cell. I suggest to add an entry in 'listchars' (e.g.
>>> shy:c) to display it as a glyph of the user's choice, so that e.g.
>>>
>>>   :set lcs=eol:¶,tab:\|_,extends:>,precedes:<,conceal:*,nbsp:·,shy:↔
>>>
>>> (assuming UTF-8 'encoding') would, in addition to what it already
>>> does, display a soft-hyphen as a double-arrow in SpecialKey
>>> highlighting. (I suppose that the added code would be similar to what
>>> already exists for the no-break space.)
>>>
>>> A different default (a hyphen in SpecialKey, maybe?) might be felt
>>> more useful: Bram (and other coders), what do you think?
>>
>> Adding an item in 'lcs' sounds like a good idea.
>>
>> Doing this with a conceal item is more complex, and there are some side
>> effects (perhaps desirable though).
>
> Perhaps we can have a more generic approach for any kind of characters
> by specifying its code point. For example, to show a regular dash for U+00AD:
>
>  :set lcs=U+00AD:-
>
> Although doing this can become dangerous: if 'lcs' is in a mode line,
> it can change any character!
>
> Dominique

Modelines are best for setting local options; but 'listchars' is
global. At the moment, and even with the proposed addition,
'listchars' applies only to a very limited set of characters, all of
them "special" one way or another, and IMHO this is a GoodThing™;
OTOH, the notion of allowing it for any character (other than colon
and comma, as documented; or maybe unless backslash-escaped, but by
how many backslashes?) has its advantages, but in that case it might
be better to restrict that option to non-sandboxed (and non-modeline)
operations, since setting it from a modeline will change the display
of every present and future buffer in possibly surprising ways. (For
instance, with just 26 custom items, namely
a:n,b:o,c:p,d:q,e:r,f:s,g:t,h:u,i:v,j:w,k:x,l:y,m:z,n:a,o:b,p:c,q:d,r:e,s:f,t:g,u:h,v:i,w:j,x:k,y:l,z:m,
or the equivalent in terms of whatever syntax would be settled upon, a
modeline might ROT13 the display of _every_ present or future buffer
in the present instance of Vim: imagine the newbie user's reaction!)

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.