Re: Patch 8.2.4510

[Manuel Ortega]

> After requiring to use ":var" and disallow ":va", to make Vim9 scripts 
> more readable, I was wondering if we should do this for more commands. 
> Especially using "en" instead of "endif" makes a script harder to 
> understand. So why not do it for all the flow commands? 
>
> Let me know if you think this restriction is too much. 
>

I think this is too much.

Besides enforcing a mere stylistic preference, it would eliminate 
objectively useful things.  E.g.,  "en" for "endif" is really handy in 
command line mode when putting together quick things.

-Manny

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7526e2e9-a92c-4cc9-af40-a7364f7dfcb4n%40googlegroups.com.

Re: Vim9 script feature-complete

[Manuel Ortega]

On Friday, January 7, 2022 at 2:01:49 PM UTC-6 Bram Moolenaar wrote:

>
> Manuel Ortega wrote: 
>
> > I very much hope that one thing will be changed. Currently '#' only 
> starts 
> > a comment when it's followed by a space, if I understand correctly. 
> Please 
> > make it instead behave like almost every other language that uses '#' as 
> a 
> > comment character, and *don't* require that it be followed by a space. 
> > 
> > The choice of '"' as the comment character in vimscript of course proved 
> a 
> > bit awkward, but forcing it to be '#' rather than '#' is even 
> worse 
> > IMO. 
> > 
> > I note that if you look in the dictionary of comment characters found 
> > inside the popular NerdCommenter plugin, there are exactly ZERO entries 
> for 
> > which '#' is mandatory. There are five entries that indicate a 
> > style preference for '#' but allow '#'. And there are 134 entries 
> > for which '#', with no following space, is a comment character. (For 125 
> > of these 134, that's the primary or sole comment character). 
> > 
> > If one of the goals of vim9script is to be more like what a user 
> expects, 
> > then '#' and not '#' should be the comment-starter. 
>
> Where do you read that there must be a space after the #?


Ah, it seems I misremembered the details.  But my point remains pretty much 
the same.  I'd said it was unexpected for the comment char of vim9script to 
be '#'; it's at least as unexpected for it to be '#', and 
even more unexpected for it to be "'#', unless it's the start of the 
line".  That makes things worse than the old way, not better.

Otherwise it could be confused with an autoload script item.


Then the right thing to do would be to change the autoload syntax to not 
use '#'.  The main point of vim9script is to break backwards compatibility 
to "fix" stuff, right?  I would say having a normal and sensible 
comment-char, after all these years of an awkward one, it more important 
than keeping the autoload syntax the same.

And it definitely doesn't behave more like other langs (which seems to be 
one of vim9's goals).  '#' in bash, ruby, etc. don't require a space 
beforehand.  There are ZERO entries in the aforementioned NerdCommenter 
dictionary for '#'.

-Manny

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/76ca1584-5714-4e8a-9fd1-1dc2746fb163n%40googlegroups.com.

Re: Vim9 script feature-complete

[Manuel Ortega]

I very much hope that one thing will be changed.  Currently '#' only starts 
a comment when it's followed by a space, if I understand correctly.  Please 
make it instead behave like almost every other language that uses '#' as a 
comment character, and *don't* require that it be followed by a space.

The choice of '"' as the comment character in vimscript of course proved a 
bit awkward, but forcing it to be '#' rather than '#' is even worse 
IMO.

I note that if you look in the dictionary of comment characters found 
inside the popular NerdCommenter plugin, there are exactly ZERO entries for 
which '#' is mandatory.  There are five entries that indicate a 
style preference for '#' but allow '#'.  And there are 134 entries 
for which '#', with no following space, is a comment character.  (For 125 
of these 134, that's the primary or sole comment character).

If one of the goals of vim9script is to be more like what a user expects, 
then '#' and not '#' should be the comment-starter.

-Manny

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/fef65f25-37f4-42fc-87a9-2ab31ea8607bn%40googlegroups.com.

Re: gui segfault macos-10.11.6 vim-8.1.1566 openmotif-2.3.8

[Manuel Ortega]

On Tuesday, June 18, 2019 at 4:50:09 AM UTC-5, raf wrote:
> hi,
> 
> macosx-10.11.6
> vim-8.1.1566
> XQuartz-2.7.11
> openmotif-2.3.8 (via macports-2.5.4)
> 
> i just tried to upgrade vim on macos for the first time in a year
> (from 8.1.10 to 8.1.1566) and it segfaults if i run "vim -g" or
> "vim" and then ":gui" from within it.
> 
> $ configure \
> --disable-darwin \
> --with-x \
> --enable-gui=motif \
> --enable-multibyte \
> --with-mac-arch=current \
> --with-features=huge \
> --disable-acl
> [...]

Try --enable-gui=athena instread and see if you get the same crash.  If not, it 
might be a bug in motif.

-Manny

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ed2442b7-926f-4009-a757-87bf70eba442%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Window-local and Tab-local previous directories?

[Manuel Ortega]

On Tuesday, May 14, 2019 at 12:17:06 PM UTC-4, yega...@gmail.com wrote:
> Hi,
> 
> On Sat, May 11, 2019 at 10:12 AM Manuel Ortega  wrote:
> >
> > On Friday, May 10, 2019 at 5:20:08 PM UTC-4, Bram Moolenaar wrote:
> >
> > > I think that's the best way we provide this functionality.  But I like
> > > to hear from others.
> >
> > I think this is adding complexity, a maintenance burden, and yet another
> > corner for corner-cases to hide in, all   for the sake of a *very* niche
> > use-case.  (Has anybody complained about this yet in all the years of :lcd
> > existing?)
> >
> 
> When the ":cd -" or ":tcd -" or ":lcd -" commands are used, a user will
> expect to go back to the previous directory. When a tab-local directory
> is used, a user will expect that the previous current directory will be
> the one before the last :tcd command used for the current tabpage. With
> the current implementation, the previous directory will be the current
> directory before invoking the last ":cd" or ":tcd" or ":lcd" command.
> This may not be the expected directory.
> 
> For example, let us say you are using a separate tabpage for each
> project.  You use the ":tcd" command to switch to the project specific
> root directory in each tabpage. Now you change the directory in one of
> the tabpages to look at some files inside the corresponding project. Now
> the previous directory of all the other tabpages will also be changed.
> If you go to some other tabpage and use the ":tcd -" command, the
> current directory will be changed to that of the other project and not
> the current project.  This may not be expected behavior.

This does not address anything in my objection.

-Manny

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/2b1c0926-b470-4c41-b607-753b6d43df92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Window-local and Tab-local previous directories?

[Manuel Ortega]

On Friday, May 10, 2019 at 5:20:08 PM UTC-4, Bram Moolenaar wrote:

> I think that's the best way we provide this functionality.  But I like
> to hear from others.

I think this is adding complexity, a maintenance burden, and yet another corner 
for corner-cases to hide in, all   for the sake of a *very* niche use-case.  
(Has anybody complained about this yet in all the years of :lcd existing?)

This seems to be exactly the sort of thing for which a user should just make 
some custom ":Lcd" or ":Tcd" that  e.g. uses the DirChanged autcommand event to 
store the value of getcwd() in some w:variable (or t:variable) for possible 
later use.

-Manny

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/077f0c7f-9810-4a88-9cf8-9a89926b8dfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patchlevel 8.1.698 broke clearing of vim status line when switching between tabs

[Manuel Ortega]

On Thu, Apr 18, 2019 at 11:42 AM  wrote:

> On Thursday, April 18, 2019 at 5:21:50 PM UTC+2, Manuel Ortega wrote:
> > Yes: all you need to do is use an autocommand event like say TabEnter
>  or TabLeave to do e.g. ':silent redraw` whenever a tab is entered/left.
>
> That works, thank you! (Altough it does make loading several files with
> 'vim -p' a bit slower and the redrawing is noticeable. Perhaps it would
> make sense to add a "redrawcommandline" command?)
>

The :redraw was just an example to get you started.  `:echo ""`  or even
`:echo` should work as well, and wouldn't require repainting the whole
screen.  I'm sure there are lots of other ways to do it; no need to add a
new vim command.

-Manny

-- 
-- 
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: Patchlevel 8.1.698 broke clearing of vim status line when switching between tabs

[Manuel Ortega]

On Thu, Apr 18, 2019 at 6:16 AM  wrote:

> Hi,
>
> I'm the user who originally reported this.
>
> On Thursday, April 18, 2019 at 8:43:31 AM UTC+2, Christian Brabandt wrote:
> > Yes as mentioned before, it might be unexpected, that the last output
> > from a command or a plugin will be erased just by switching the tabpage.
> >
> > Or perhaps said differently: Why would you expect message output to be
> > cleared just by switching the tabpage? (and the answer is not, because
> > that's what Vim used to do ;))
>
> When the tab is switched, the context usually changes. So the command
> output is likely no longer relevant (or that's my personal feeling - I know
> too little about vim to have a strong opinion on this).
>
> Is there a way to force clearing the output programmatically in vimrc? If
> so, that would probably be enough for me.
>

Yes: all you need to do is use an autocommand event like say TabEnter  or
TabLeave to do e.g. ':silent redraw` whenever a tab is entered/left.

There is no reason to change Vim here.

-Manny

-- 
-- 
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 for text property feature

[Manuel Ortega]

Unfortunately without a simple example or two, I don't understand this at
all.   (I not only don't see what it does, I also don't see why this would
benefit anything.)

-Manny

-- 
-- 
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: Problem with Vim 8.1.332 and 8.1.347 viewing .tgz files

[Manuel Ortega]

On Fri, Sep 7, 2018 at 4:23 PM Bram Moolenaar  wrote:

>
> Gary Johnson wrote:
>
> > I frequently use vim to read the contents of .tgz files.  This has
> > recently stopped working.  It works fine with my old Vim 7.2.333 on
> > Ubuntu and 8.0.1567 on Cygwin, but my newer 8.1.332 on Ubuntu and
> > 8.1.347 on Fedora fail as follows.
> >
> > $ /usr/local/bin/vim -N -u NORC --cmd 'set
> rtp=/usr/local/share/vim/vim81'
> /usr/share/doc/texlive-doc/generic/pstricks/pst-user.tgz
> >
> > The resulting buffer contains this.
> >
> > " tar.vim version v29
> > " Browsing tarfile
> /usr/share/doc/texlive-doc/generic/pstricks/pst-user.tgz
> > " Select a file with cursor and press ENTER
> >
> > bzip2: /usr/share/doc/texlive-doc/generic/pstricks/pst-user.tgz is
> not a bzip2 file.
> > tar: This does not look like a tar archive
> > tar: Exiting with failure status due to previous errors
> >
> > It doesn't matter what .tgz file I try to open, the failure is the
> > same.  I chose the one above because it was convenient.
>
> I thought this work, but now that I double check it also doesn't work
> for me.  I think best is to use the "file" command to check the actual
> compression type.
>

I think it's a bad idea to use `file`, even if `file` is available on all
platforms (I don't know whether it is).

This will make the opening of *all* compressed files slower while we wait
for a shellout.  Plus the output of `file` varies with the system and the
age of the system.  So do the available options passable to `file`.  This
is more trouble than it's worth.

Improperly-named archives are the vast minority, and it's not reasonable to
require Vim to sort through that crap at the expensive of slowing down the
vast majority of cases.

If a file is wrongly-named, that's not Vim's problem.  It's not Vim's
problem for the same reason that it's not Vim's problem if someone named an
MS-word file with the incorrect extension ".txt", and opening it in Vim
 results in a buffer full of gibberish.

-Manny

-- 
-- 
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: Scrolling in Vim

[Manuel Ortega]

On Sun, Aug 26, 2018 at 10:29 AM Jason Franklin <
jrfrank...@georgiasouthern.edu> wrote:

> Normally, scrolling up in vim (i.e., to view the last parts of a file)
> will allow you to scroll past
> the last line of the file.  I'd like for Vim to stop at the end of the
> file and not let me go further.
> This would also mean that scrolling would be locked when a buffer is
> completely visible in
> a window.
>
> I've worked on a basic patch to do this.  It needs some tests and what
> not, but it looks
> solid so far.
>
> Does any one have a preference either way?  If the main guys (Bram, et.
> al.) object, let
> me know so I don't do a bunch of work for nothing.
>

I *like* the present behavior.  It's sometimes useful, too (like for
comparisons in split windows).  IMHO any changes would need to be put
behind an option that's OFF by default.

-Manny

-- 
-- 
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: Using terminal window for external commands in the GUI

[Manuel Ortega]

On Sun, Mar 18, 2018 at 5:04 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2018-03-19 5:25 GMT+09:00 Manuel Ortega <mannyvim...@gmail.com>:
>
>>
>>
>> Finally, another reason to not put "!" in  by default just yet is
>> that the colors are hard to read if your colorscheme has a black or nearly
>> black background.  This is *not* a MacVim specific problem.  There is an
>> open thread about this on GitHub, I think.  Maybe that should be solved
>> before making "!cmd" result in nigh-invisible output.
>>
>
> That is rather a well-known, classic issue that blue is hardly visible on
> a dark background color, as is written in the comment of
> app-defaults/XTerm-color.  That has happened with color consoles as well.
> Perhaps we could "correct" the pixel values of blue (color4) and light blue
> (color12) just like the XTerm-color comment suggests, but there seems to be
> pros and cons as to what values are better than the current ones.  Anyway,
> it is the fact that xterm has been shipped with them and that nobody has
> never stopped it.
>

One disanalogy here is that if the default colors of one's terminal
emulator (e.g., Terminal.app) are unreadable, *one can change them
easily*.  That is not the case of the colors that appear in a vim
`:terminal`, whether in the GUI or not.  There's no vim setting for making
that blue lighter.  All you can do (I assume) is manually edit some source
code before compiling.  On some github thread there's discussion of making
this changeable.  I really hope it gets done.

-Manny

-- 
-- 
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: Using terminal window for external commands in the GUI

[Manuel Ortega]

On Sun, Mar 18, 2018 at 5:04 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2018-03-19 5:25 GMT+09:00 Manuel Ortega <mannyvim...@gmail.com>:
>
>> On Sun, Mar 18, 2018 at 4:10 PM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>> 2018-03-19 4:26 GMT+09:00 Bram Moolenaar <b...@moolenaar.net>:
>>>
>>>>
>>>> Until recently, the GUI used a "dumb" terminal for external commands.
>>>> With patch 8.0.1616 it is now possible to run an external command inside
>>>> the GUI window.  Try it out with:
>>>> :set go+=!
>>>> :!cat testdir/color_ramp.txt
>>>>
>>>
>>> Seems like we need to run :so testdir/color_ramp.vim before running the
>>> cat command; there seems to be no color_ramp.txt in the repo...
>>>
>>> And the result is...very impressive!  Not only colors are displayed
>>> correctly, but also its drawing is noticeably faster than that of the
>>> "dumb" terminal.
>>>
>>
>> On the contrary, the drawing is much, much slower than with the dumb
>> terminal, when using the MacVim gui.  I don't know if this is a MacVim
>> specific problem or not, but it makes using the non-dumb terminal into what
>> I would call a regression (it's that slow and laggy).
>>
>
> Are you sure that MacVim has already included Patch 8.0.1616?  How can you
> conclude that using the new non-dumb terminal would result in "regression".
>

No, but it has at least 8.0.1609 which is the relevant one.

It would be a regression because the performance of `:!ls` would be worse
than it used to be.


>
>> Also, when using the dumb terminal to show `!ls`, I see:
>>
>> ```
>> :!ls
>> onetwo three
>> four   five   six
>> [blank line]
>> Press ENTER or type command to continue
>> ```
>> But when using "!" in  on MacVim, the blank line is in a different
>> place.  It's right below `:!ls`, and before the output of the `ls`
>> command.  Then the "Press ENTER" part has no blank line above it to
>> separate it from the `ls` output.
>>
>
> I can't reproduce.  BTW, you are talking about 'cpo' (cpoptions) here and
> below, but it should be 'go' (guioptions).  Are they typos?
>

Yes, I meant to say ``.  That was a typo.

I'm surprised you can't reproduce.  I can get this even with `--clean` or
`-u NONE -U NONE -N --noplugin` etc.


>
>
>>
>> Finally, another reason to not put "!" in  by default just yet is
>> that the colors are hard to read if your colorscheme has a black or nearly
>> black background.  This is *not* a MacVim specific problem.  There is an
>> open thread about this on GitHub, I think.  Maybe that should be solved
>> before making "!cmd" result in nigh-invisible output.
>>
>
> Anyway, it is the fact that xterm has been shipped with them and that
> nobody has never stopped it.
>

But we're talking about the GUI, not an xterm.  People expect their GUI to
not have the quirks of terminal emulators.  And besides: if it's
unreadable, it's unreadable, and thus shouldn't be foisted upon the users
by default when the dumb-but-legible terminal works just fine.

-Manny

-- 
-- 
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: Using terminal window for external commands in the GUI

[Manuel Ortega]

On Sun, Mar 18, 2018 at 4:10 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2018-03-19 4:26 GMT+09:00 Bram Moolenaar :
>
>>
>> Until recently, the GUI used a "dumb" terminal for external commands.
>> With patch 8.0.1616 it is now possible to run an external command inside
>> the GUI window.  Try it out with:
>> :set go+=!
>> :!cat testdir/color_ramp.txt
>>
>
> Seems like we need to run :so testdir/color_ramp.vim before running the
> cat command; there seems to be no color_ramp.txt in the repo...
>
> And the result is...very impressive!  Not only colors are displayed
> correctly, but also its drawing is noticeably faster than that of the
> "dumb" terminal.
>

On the contrary, the drawing is much, much slower than with the dumb
terminal, when using the MacVim gui.  I don't know if this is a MacVim
specific problem or not, but it makes using the non-dumb terminal into what
I would call a regression (it's that slow and laggy).

Also, when using the dumb terminal to show `!ls`, I see:

```
:!ls
onetwo three
four   five   six
[blank line]
Press ENTER or type command to continue
```
But when using "!" in  on MacVim, the blank line is in a different
place.  It's right below `:!ls`, and before the output of the `ls`
command.  Then the "Press ENTER" part has no blank line above it to
separate it from the `ls` output.

Finally, another reason to not put "!" in  by default just yet is that
the colors are hard to read if your colorscheme has a black or nearly black
background.  This is *not* a MacVim specific problem.  There is an open
thread about this on GitHub, I think.  Maybe that should be solved before
making "!cmd" result in nigh-invisible output.

-Manny

-- 
-- 
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: Moving away from SourceForge

[Manuel Ortega]

> We're currently responding to a DDOS that's unrelated to the recent issues. I 
> also don't even own a suit.

It's one thing after another.  The fact that the later thing is unrelated to 
the previous thing is no comfort, when there keeps on being later things.  In 
fact, it makes it even worse.

-Manny

-- 
-- 
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: Moving away from SourceForge

[Manuel Ortega]

The vim website has been unreachable again, all morning.  I can't look in the 
scripts section for a syntax file I need.

I was looking forward to a change of provider.  Is Vim really staying with 
sourceforge just because one of their suits said "pretty please"?

-Manny

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

8.0.1270 breaks tests on macOS

[Manuel Ortega]

>From test_ins_complete.vim:
Found errors in Test_ins_complete():
function RunTheTest[34]..Test_ins_complete line 58: Expected 'Xtest11.one'
but got 'xterm_ramp.vim'
TEST FAILURE
make[2]: *** [report] Error 1
make[1]: *** [scripttests] Error 2
make: *** [test] Error 2

-Manny

-- 
-- 
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: More test failures on macOS

[Manuel Ortega]

On Saturday, November 4, 2017 at 5:24:05 PM UTC-4, Manuel Ortega wrote:
> I just tried building 8.0.1264 from a fresh git clone.  There are more test 
> failures on macOS 10.12.6:

Bisection reveals that the offending patch is 8.0.1263.

-Manny

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

More test failures on macOS

[Manuel Ortega]

I just tried building 8.0.1264 from a fresh git clone.  There are more test
failures on macOS 10.12.6:

rom test_undo.vim:
Found errors in Test_undo_write():
function RunTheTest[34]..Test_undo_write line 8: Expected ['one one one',
'two', 'two', 'three'] but got ['one one onejust some text', 'two', 'two',
'three']
function RunTheTest[34]..Test_undo_write line 10: Expected ['one one one',
'two', 'two'] but got ['one one onejust some text', 'two', 'two']
function RunTheTest[34]..Test_undo_write line 12: Expected ['one one one']
but got ['one one onejust some text']
function RunTheTest[34]..Test_undo_write line 14: Expected [''] but got
['just some text']
function RunTheTest[34]..Test_undo_write line 16: Expected ['one one one']
but got ['one one onejust some text']
function RunTheTest[34]..Test_undo_write line 18: Expected ['one one one',
'two', 'two'] but got ['one one onejust some text', 'two', 'two']
function RunTheTest[34]..Test_undo_write line 20: Expected ['one one one',
'two', 'two', 'three'] but got ['one one onejust some text', 'two', 'two',
'three']
TEST FAILURE
make[2]: *** [report] Error 1
make[1]: *** [scripttests] Error 2
make: *** [test] Error 2

I'm beginning to wonder what the point of CI is if it's not going to catch
this kind of thing.  It seems like every few weeks I'm reporting something
like this.

-Manny

-- 
-- 
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: Security risk of vim swap files

[Manuel Ortega]

On Tue, Oct 31, 2017 at 6:30 AM, Hanno Böck  wrote:

>
> 3. Ideally they also shouldn't leak currently edited filenames (e.g.
> they shouldn't be called /tmp/.test.txt.swp, but more something
> like /tmp/.vim_swap.123782173)
>

But Vim needs to know which swapfile is associated with which non-swap
file.  How can it do that, other than by having the swapfile's name contain
the original file's name?

Anyway I don't think it's Vim's job to cover up for foolish admins.

-Manny

-- 
-- 
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: Tests hang with 8.0.1223

[Manuel Ortega]

On Thu, Oct 26, 2017 at 4:49 PM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> On Thursday, October 26, 2017 at 4:41:13 PM UTC-4, Manuel Ortega wrote:
> > On macOS 10.12.6, Vim 8.0.1223 builds but `make test` hangs somewhere in
> the middle of running tests.


Bisection reveals that the offending patch is 8.0.1222.

-Manny

-- 
-- 
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: Tests hang with 8.0.1223

[Manuel Ortega]

On Thursday, October 26, 2017 at 4:41:13 PM UTC-4, Manuel Ortega wrote:
> On macOS 10.12.6, Vim 8.0.1223 builds but `make test` hangs somewhere in the 
> middle of running tests.  What I see at the hung stage is:
> 
> 
> "motion.txt" [readonly] 1343 lines, 51602 characters
> Executing Test_vim_did_enter()
> Executing Test_win_tab_autocmd()
> "motion.txt"
> 
> 
> And it stays there until I hit Ctrl-C, whereupon the rest of the tests 
> continue.

Whoops, that was too quick a description.  After I hit Ctrl-C, I see the Press 
ENTER prompt, and then if I hit enter I get a vim window with two tabs.  One 
tab is "No Name", the other is the help file "motion.txt" with the cursor on 
line 439.

If I :qall, *then* the other tests keep going.

-Manny

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

Tests hang with 8.0.1223

[Manuel Ortega]

On macOS 10.12.6, Vim 8.0.1223 builds but `make test` hangs somewhere in
the middle of running tests.  What I see at the hung stage is:

"motion.txt" [readonly] 1343 lines, 51602 characters
Executing Test_vim_did_enter()
Executing Test_win_tab_autocmd()
"motion.txt"

And it stays there until I hit Ctrl-C, whereupon the rest of the tests
continue.

This is reproducible every time, even after freshly git cloning the repo.

-Manny

-- 
-- 
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] use strikethrough for diff filetype

[Manuel Ortega]

On Tue, Oct 3, 2017 at 10:29 PM, Ben Fritz  wrote:

> On Monday, October 2, 2017 at 1:05:03 PM UTC-5, Bram Moolenaar wrote:
> > Christian wrote:
> >
> > > Bram,
> > > since Vim can now display strikethrough attributes (in the gui), let's
> > > make a bit more use of it.
> > >
> > > This patch adds the strikethrough attribute to the diff syntax file for
> > > deleted lines. Since this impacts readability, put the change behind a
> > > switch and document is properly.
> > >
> > > For an example see the attached screenshot.
> >
> > I can't say I like it, I would not use it.  But perhaps someone does.
> >
> > Is setting a variable simpler than letting the user define his own
> > highlight?  Well, I suppose that might not work well when switching
> > colorschemes.  And your trick to copy the attributes from "Special"
> > isn't something I would advertise...
> >
>
> I for one will definitely use it, I didn't remember that strikethrough had
> been added! Thanks for the example, if nothing else!


Am I the only one who looked at the screenshot and found it harder to read
than the non-strikethough version of diff highlighting?  Seriously, the
*color* is what tells the reader which text is the old text.  A big
strikethough does nothing but partially obscure the changed text, which
makes it harder to read and is a bad thing. The problem might even be
sometimes more acute than that.  Maybe one's font has a dotted zero to
distinguish it from 'O'; if the strikethrough obscures the dot in the zero,
then one won't be able to easily tell whether the old character was zero or
'O'.

Anyway, if this suggestion gets adopted, I sure hope there will be some
easy way for the user to turn it off, rather than manually performing
surgery on every installed colorscheme, or setting up a hacky autocmd.

(As a general point, there really needs to be in Vim an easy way to get rid
of, say, all the "{,c}term=bold" or "gui=underline" in a single built-in ex
command.  Something like ":hi clearattribute term bold"  Were there such a
mechanism, it would also easily allow the user to avoid the problem of
strikethrough making diff text less readable.)

-Manny

-- 
-- 
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: No rule to make terminal.c

[Manuel Ortega]

On Tuesday, September 19, 2017 at 6:40:55 PM UTC-4, Tony Mechelynck wrote:
> After applying patches 1128-1129, and the runtime files update between
> them, both Tiny and Huge builds halt as follows (shown here for Tiny):
> 
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
> -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1-o objects/term.o term.c
> make: *** No rule to make target 'terminal.c', needed by
> 'objects/terminal.o'.  Stop.
> exit status 2
> 
> src/Makefile is dated 17 september and both src/shadow-huge/Makefile
> and src/shadow-tiny/Makefile are symlinks to it.

Happens on macOS 10.12.6 too, when I use `make -j4`, which previously worked 
just fine.

-Manny

-- 
-- 
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: Removing FEAT_WINDOWS

[Manuel Ortega]

On Sat, Sep 16, 2017 at 10:31 AM, Bram Moolenaar  wrote:

>
> So I'll graduate FEAT_WINDOWS.  That removes 626 #ifdefs !!!
>

According to the docs, once this happens the only thing differentiating
"tiny" from "small" will be "+visual".  But then those same docs also say
of "+visual" that "Always enabled since 7.4.200."   And I just tested
building a tiny build, and it resulted in "+visual".

This appears to mean that once FEAT_WINDOWS is graduated, there will be no
difference between tiny and small builds (according to the docs).  If
that's the case, then one of "tiny" or "small" should be removed entirely.

-Manny

-- 
-- 
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: 8.0.1039 broke setline()

[Manuel Ortega]

On Mon, Sep 4, 2017 at 3:01 AM, Christian Brabandt <cbli...@256bit.org>
wrote:

>
> On Mo, 04 Sep 2017, Manuel Ortega wrote:
>
> > 8.0.1039 broke setline().  I know this by bisection.  To reproduce:
> >
> > Make a file, testvimrc, that contains one line: "source foo".
> >
> > Create the file "foo", and let it contain only the following:
> >
> >   call setline(1, "Hello There")
> >
> > To show the bug, do: vim -u testvimrc -u NONE -N
> >
> > Expected behavior, which was also the actual behavior before 8.0.1039:
>  I see a
> > new buffer with "Hello There" on the first line.
> >
> > Actual behavior: after 8.0.1039: I see no text whatsoever in the buffer.
> >
> > This is on macOS 10.12.6.
>
> I see the problem. There is a new check for buf->b_ml.ml_mfp == NULL in
> set_buffer_lines that wasn't there previously and this was no problem
> before, because ml_replace would open the buffer if ml_mfp would be
> null. I think we can safely change this check to:
>
> diff --git a/src/evalfunc.c b/src/evalfunc.c
> index 2692de61f..e68e0b00e 100644
> --- a/src/evalfunc.c
> +++ b/src/evalfunc.c
> @@ -9885,7 +9885,7 @@ set_buffer_lines(buf_T *buf, linenr_T lnum, typval_T
> *lines, typval_T *rettv)
>  buf_T  *curbuf_save;
>  intis_curbuf = buf == curbuf;
>
> -if (buf == NULL || buf->b_ml.ml_mfp == NULL || lnum < 1)
> +if (buf == NULL || (buf->b_ml.ml_mfp == NULL && !is_curbuf)|| lnum <
> 1)
>  {
> rettv->vval.v_number = 1;   /* FAIL */
> return;
>
>
> or perhaps even completely remove the check. Not sure if this however
> will break in some situations, but at least I could not break it using
>
> :call setbufline(5, 1, 'foobar')
>
> in the startupfile (when buffer number 5 does not exist yet.
>

I've tried this out over the last few hours and it seems to have restored
the old behavior.  I am, however, unqualified to say whether it's the Right
Fix.

-Manny

-- 
-- 
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: 8.0.1039 broke setline()

[Manuel Ortega]

On Monday, September 4, 2017 at 3:01:53 AM UTC-4, Christian Brabandt wrote:
> On Mo, 04 Sep 2017, Manuel Ortega wrote:
> 
> > 8.0.1039 broke setline().  I know this by bisection.  To reproduce:
> > 
> > Make a file, testvimrc, that contains one line: "source foo".
> > 
> > Create the file "foo", and let it contain only the following:
> > 
> >   call setline(1, "Hello There")
> > 
> > To show the bug, do: vim -u testvimrc -u NONE -N
> > 
> > Expected behavior, which was also the actual behavior before 8.0.1039:  I 
> > see a
> > new buffer with "Hello There" on the first line.
> > 
> > Actual behavior: after 8.0.1039: I see no text whatsoever in the buffer.
> > 
> > This is on macOS 10.12.6.
> 
> I see the problem. There is a new check for buf->b_ml.ml_mfp == NULL in 
> set_buffer_lines that wasn't there previously and this was no problem 
> before, because ml_replace would open the buffer if ml_mfp would be 
> null. I think we can safely change this check to:
[snip]
> 
> or perhaps even completely remove the check. Not sure if this however 
> will break in some situations, but at least I could not break it using
> 
> :call setbufline(5, 1, 'foobar')
> 
> in the startupfile (when buffer number 5 does not exist yet.

Thanks, I'll try this out.

Sorry that my reproduction case was not maximally simple.  One can (with the 
same files defined above)  just do "vim -u foo -N" and the difference beteen 
8.0.1039 and its predecessors will be apparent.

-Manny

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

8.0.1039 broke setline()

[Manuel Ortega]

8.0.1039 broke setline().  I know this by bisection.  To reproduce:

Make a file, testvimrc, that contains one line: "source foo".

Create the file "foo", and let it contain only the following:

  call setline(1, "Hello There")

To show the bug, do: vim -u testvimrc -u NONE -N

Expected behavior, which was also the actual behavior before 8.0.1039:  I
see a new buffer with "Hello There" on the first line.

Actual behavior: after 8.0.1039: I see no text whatsoever in the buffer.

This is on macOS 10.12.6.

-Manny

-- 
-- 
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: 8.0.995 still fails tests on macOS

[Manuel Ortega]

The test failures seem to have been successfully dodged by the workaround in 
8.0.1049.  Thanks!

-Manny

-- 
-- 
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: 8.0.995 still fails tests on macOS

[Manuel Ortega]

On Saturday, September 2, 2017 at 8:54:43 AM UTC-4, Bram Moolenaar wrote:
> Manuel Ortega wrote:
> 
> > > > Still failing on macOS:
> > > > 
> > > > From test_terminal.vim:
> > > > Found errors in Test_terminal_noblock():
> > > > function RunTheTest[24]..Test_terminal_noblock line 21: Pattern 'done' 
> > > > does
> > > > not match 'ccecho
> > > > c'
> > > > function 
> > > > RunTheTest[24]..Test_terminal_noblock[24]..Stop_shell_in_terminal
> > > > line 3: Expected 'dead' but got 'run'
> > > > Caught exception in Test_terminal_noblock(): Vim(bwipeout):E89: No write
> > > > since last change for buffer 22 (add ! to override) @ function
> > > > RunTheTest[24]..Test_terminal_noblock, line 29
> > > > TEST FAILURE
> > > > make[2]: *** [report] Error 1
> > > > make[1]: *** [scripttests] Error 2
> > > > make: *** [test] Error 2
> > > 
> > > It is working on my Mac machine.  Can you use ch_logfile() to find out
> > > what happens?
> > 
> > I've discovered something that might be related to the ongoing test 
> > failures.  Even if it isn't thus related, I think it seems like incorrect 
> > and undesirable behavior.
> > 
> > I've discovered that running `make test` causes Vim to dump entries into my 
> > bash $HISTFILE.  In particular, whenever `make test` is run I can find 
> > lines like these in my $HISTFILE, and I sure didn't type them in myself:
> > 
> > echo $TESTENV
> > echo 
> 
> [...]
> 
> > Oddly, this only seems to happen when $HISTFILE is set to a
> > nonstandard location.  If I leave the variable unset, bash dumps
> > history into ~/.bash_history, where I do not see such lines.  Perhaps
> > the $HISTFILE variable is leaking into Vim, but even then I still
> > don't see why (or even how) Vim could be dumping entries there.  After
> > all, manually doing a vim command of the form "!something" doesn't
> > dump "something" into my $HISTFILE.
> 
> Probably the history is only updated in an interactive shell.
> 
> > I don't want those lines in my $HISTFILE, whether or not they are
> > informative of why the tests are failing on macOS.
> 
> Can you try to add this line to src/testdir/setup.vim:
> 
>   let $HISTFILE = ""
> 
> Or:
> 
>   let $HISTFILE = getwcd() . "/hist"

I've tested both of those workarounds, and they were both successful.  In 
neither case were any commands run inside of tests dumped to my custom 
$HISTFILE.  Nor did they cause a ~/.bash_history to be created and populated.

-Manny

-- 
-- 
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: 8.0.995 still fails tests on macOS

[Manuel Ortega]

On Friday, August 25, 2017 at 6:53:23 PM UTC-4, Manuel Ortega wrote:
> Still failing on macOS:
> 
> 
> From test_terminal.vim:
> Found errors in Test_terminal_noblock():
> function RunTheTest[24]..Test_terminal_noblock line 21: Pattern 'done' does 
> not match 'ccecho 
> c'
> function RunTheTest[24]..Test_terminal_noblock[24]..Stop_shell_in_terminal 
> line 3: Expected 'dead' but got 'run'
> Caught exception in Test_terminal_noblock(): Vim(bwipeout):E89: No write 
> since last change for buffer 22 (add ! to override) @ function 
> RunTheTest[24]..Test_terminal_noblock, line 29
> TEST FAILURE
> make[2]: *** [report] Error 1
> make[1]: *** [scripttests] Error 2
> make: *** [test] Error 2

Still happening even on 8.0.1033.  I'm having a hard time believing I'm the 
only person on macOS seeing this.

In case it's relevant (not sure why it would be, but I'm not an expert), I have 
in my vimrc "set shellcmdflag=-cl".

-Manny

-- 
-- 
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: 8.0.995 still fails tests on macOS

[Manuel Ortega]

On Saturday, August 26, 2017 at 9:50:18 AM UTC-4, Bram Moolenaar wrote:
> Manuel Ortega wrote:
> 
> > Still failing on macOS:
> > 
> > From test_terminal.vim:
> > Found errors in Test_terminal_noblock():
> > function RunTheTest[24]..Test_terminal_noblock line 21: Pattern 'done' does
> > not match 'ccecho
> > c'
> > function RunTheTest[24]..Test_terminal_noblock[24]..Stop_shell_in_terminal
> > line 3: Expected 'dead' but got 'run'
> > Caught exception in Test_terminal_noblock(): Vim(bwipeout):E89: No write
> > since last change for buffer 22 (add ! to override) @ function
> > RunTheTest[24]..Test_terminal_noblock, line 29
> > TEST FAILURE
> > make[2]: *** [report] Error 1
> > make[1]: *** [scripttests] Error 2
> > make: *** [test] Error 2
> 
> It is working on my Mac machine.  Can you use ch_logfile() to find out
> what happens?

I've discovered something that might be related to the ongoing test failures.  
Even if it isn't thus related, I think it seems like incorrect and undesirable 
behavior.

I've discovered that running `make test` causes Vim to dump entries into my 
bash $HISTFILE.  In particular, whenever `make test` is run I can find lines 
like these in my $HISTFILE, and I sure didn't type them in myself:

echo $TESTENV
echo 
aaa
echo 
bbecho
 
eee

Re: 8.0.995 still fails tests on macOS

[Manuel Ortega]

I've run it a few more times, and strangely, the error emitted to the terminal 
during the `make test_terminal` changes:
Executed 18 tests
1 FAILED:
Found errors in Test_terminal_scrape_123():
function RunTheTest[24]..Test_terminal_scrape_123[16]..Check_123 line 7: 
Expected '1' but got ''
function RunTheTest[24]..Test_terminal_scrape_123[16]..Check_123 line 8: 
Expected '2' but got ''
function RunTheTest[24]..Test_terminal_scrape_123[16]..Check_123 line 9: 
Expected '3' but got ''
function RunTheTest[24]..Test_terminal_scrape_123[16]..Check_123 line 10: 
Expected '#00e000' but got '#f0f0f0'
function RunTheTest[24]..Test_terminal_scrape_123[16]..Check_123 line 24: 
Expected '123' but got ''

-- 
-- 
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: 8.0.995 still fails tests on macOS

[Manuel Ortega]

On Tuesday, August 29, 2017 at 12:49:33 AM UTC-4, Kazunobu Kuriyama wrote:
> 2017-08-29 12:16 GMT+09:00 Manuel Ortega <manny...@gmail.com>:
> 
> 
> On Saturday, August 26, 2017 at 9:58:28 AM UTC-4, Manuel Ortega wrote:
> 
> > On Sat, Aug 26, 2017 at 9:50 AM, Bram Moolenaar wrote:
> 
> >
> 
> >
> 
> >
> 
> > It is working on my Mac machine.  Can you use ch_logfile() to find out
> 
> >
> 
> > what happens?
> 
> >
> 
> >
> 
> > Unfortunately, I don't know how to do this.  How do I use a VimScript 
> > function before doing `make test`?
> 
> >
> 
> >
> 
> > -Manny 
> 
> 
> 
> If someone would post the exact instructions I need to follow, then I can do 
> the debugging locally.
> 
> 
> 
> -Manny
> 
> 
> 
> If you don't have any specific instructions other than that from Bram, I 
> think the following will do.
> 
> (1) In order to have the test in question write a log, change the file 
> src/testdir/test_terminal.vim like this:
> 
> diff --git a/src/testdir/test_terminal.vim b/src/testdir/test_terminal.vim
> index d651d0bba..e8cdb4a39 100644
> --- a/src/testdir/test_terminal.vim
> +++ b/src/testdir/test_terminal.vim
> @@ -452,6 +452,8 @@ func Test_terminal_list_args()
>  endfunction
>  
>  func Test_terminal_noblock()
> +  call ch_logfile('/tmp/Test_terminal_noblock.log')
> +
>    let g:buf = term_start()
>  
>    for c in ['a','b','c','d','e','f','g','h','i','j','k']
> @@ -481,6 +483,8 @@ func Test_terminal_noblock()
>    unlet g:job
>    unlet g:lnum
>    bwipe
> +
> +  call ch_logfile('')
>  endfunc
>  
>  func Test_terminal_write_stdin()
> 
> --
> Note that how ch_logfile() is used.  You can change the file path or even the 
> function's behavior.  See :help ch_logfile() for details.  Also, note that 
> ch_logfile('') is used to stop logging.  The resulting file will get very 
> huge, so if you forget to stop it, then ...
> 
> (2) Build Vim as usual.
> 
> (3) Make sure your $PWD is /../vim/src, and run
> 
> $ make test_terminal 
> 
> Then, you'll have the log file /tmp/Test_terminal_noblock.log.

Thanks, Kazunobu.  I did what you said except that I picked a different 
location for the logfile to be recorded to.   I am completely unqualified to 
recognize what lines in the logfile would count as "suspicious".   Shall I zip 
the logifle and post it here?

-Manny

-- 
-- 
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: 8.0.995 still fails tests on macOS

[Manuel Ortega]

On Saturday, August 26, 2017 at 9:58:28 AM UTC-4, Manuel Ortega wrote:
> On Sat, Aug 26, 2017 at 9:50 AM, Bram Moolenaar wrote:
> 
> 
>
> It is working on my Mac machine.  Can you use ch_logfile() to find out
> 
> what happens?
> 
> 
> Unfortunately, I don't know how to do this.  How do I use a VimScript 
> function before doing `make test`?
> 
> 
> -Manny 

If someone would post the exact instructions I need to follow, then I can do 
the debugging locally.

-Manny

-- 
-- 
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: 8.0.995 still fails tests on macOS

[Manuel Ortega]

On Sat, Aug 26, 2017 at 9:50 AM, Bram Moolenaar <b...@moolenaar.net> wrote:

>
> Manuel Ortega wrote:
>
> > Still failing on macOS:
> >
> > From test_terminal.vim:
> > Found errors in Test_terminal_noblock():
> > function RunTheTest[24]..Test_terminal_noblock line 21: Pattern 'done'
> does
> > not match 'ccecho
> > c'
> > function RunTheTest[24]..Test_terminal_noblock[24]..Stop_shell_in_
> terminal
> > line 3: Expected 'dead' but got 'run'
> > Caught exception in Test_terminal_noblock(): Vim(bwipeout):E89: No write
> > since last change for buffer 22 (add ! to override) @ function
> > RunTheTest[24]..Test_terminal_noblock, line 29
> > TEST FAILURE
> > make[2]: *** [report] Error 1
> > make[1]: *** [scripttests] Error 2
> > make: *** [test] Error 2
>
> It is working on my Mac machine.  Can you use ch_logfile() to find out
> what happens?


Unfortunately, I don't know how to do this.  How do I use a VimScript
function before doing `make test`?

-Manny

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

8.0.995 still fails tests on macOS

[Manuel Ortega]

Still failing on macOS:

>From test_terminal.vim:
Found errors in Test_terminal_noblock():
function RunTheTest[24]..Test_terminal_noblock line 21: Pattern 'done' does
not match 'ccecho
c'
function RunTheTest[24]..Test_terminal_noblock[24]..Stop_shell_in_terminal
line 3: Expected 'dead' but got 'run'
Caught exception in Test_terminal_noblock(): Vim(bwipeout):E89: No write
since last change for buffer 22 (add ! to override) @ function
RunTheTest[24]..Test_terminal_noblock, line 29
TEST FAILURE
make[2]: *** [report] Error 1
make[1]: *** [scripttests] Error 2
make: *** [test] Error 2

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

[Manuel Ortega]

On Tuesday, August 1, 2017 at 10:58:05 AM UTC-5, Manuel Ortega wrote:
> On Tuesday, August 1, 2017 at 10:54:29 AM UTC-5, Mats Bertil Tegner wrote:
> > Den tisdag 1 augusti 2017 kl. 15:08:33 UTC+2 skrev Bram Moolenaar:
> > > Patch 8.0.0827
> > > Problem:Coverity: could leak pty file descriptor, theoretically.
> > > Solution:   If channel is NULL, free the file descriptors.
> > > Files:  src/os_unix.c
> > 
> > Hi,
> > 
> > Vim fails to compile after 8.0.826 using GCC 7.1.0 under Slackware-current 
> > x86-64:
> 
> Same on macOS.

Whoops, here's the exact error message:

gcc -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  -g -O2 -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=1-o objects/os_unix.o os_unix.c
os_unix.c:4129:30: error: use of undeclared identifier 'serverName'
setenv("VIM_SERVERNAME", serverName == NULL ? "" : (char *)serverName, 1);
 ^
os_unix.c:4129:64: error: use of undeclared identifier 'serverName'
setenv("VIM_SERVERNAME", serverName == NULL ? "" : (char *)serverName, 1);
   ^
2 errors generated.
make[1]: *** [objects/os_unix.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [first] Error 2

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

[Manuel Ortega]

On Tuesday, August 1, 2017 at 10:54:29 AM UTC-5, Mats Bertil Tegner wrote:
> Den tisdag 1 augusti 2017 kl. 15:08:33 UTC+2 skrev Bram Moolenaar:
> > Patch 8.0.0827
> > Problem:Coverity: could leak pty file descriptor, theoretically.
> > Solution:   If channel is NULL, free the file descriptors.
> > Files:  src/os_unix.c
> 
> Hi,
> 
> Vim fails to compile after 8.0.826 using GCC 7.1.0 under Slackware-current 
> x86-64:

Same on macOS.

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

8.0.645 test failures on macOS 10.12.5

[Manuel Ortega]

On macOS 10.12.5, Vim 8.0.645 builds but the tests fail:

>From test_hlsearch.vim:
Found errors in Test_hlsearch_hangs():
function RunTheTest[24]..Test_hlsearch_hangs line 12: Expected True but got
0
TEST FAILURE
make[2]: *** [report] Error 1
make[1]: *** [scripttests] Error 2
make: *** [test] Error 2

-Manny

-- 
-- 
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] Rectified file detection algorithim of tex flavors (#1754)

[Manuel Ortega]

On Thu, Jun 8, 2017 at 3:49 PM, Bram Moolenaar  wrote:

>
> JackeJR wrote:
>
> > The algorithim for parsing % and % switched the detected
> > filetypes around. i.e. % detected as plaintex, % detected
> > as tex. The fix above corrected the matching.
>
> I do not remembering changing this.  Why has nobody complained?


Nobody's complained because nothing's wrong with it.  (Nor has it changed.)
 The OP is confused.

-Manny

-- 
-- 
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] Clean up Mac code

[Manuel Ortega]

On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2017-04-23 0:02 GMT+09:00 Manuel Ortega <mannyvim...@gmail.com>:
>
>> On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar <b...@moolenaar.net>:
>>>
>>>>
>>>>
>>>> The terms "with darwin" and "without darwin" are very confusing.  There
>>>> is no help for "darwin". Cleaning that up sounds like a good idea.
>>>>
>>>
>>> OK, I'll add some explanation on the darwin feature to os_mac.txt, and
>>> make links between that and the terms.
>>>
>>
>> I seem to remember, from a while back, that "disabling darwin" has a
>> bigger effect than just disconnecting Vim from the macOS clipboard.
>> Something about it messed up (believe it or not) the precomposition (or
>> lack thereof) of unicode, particularly when one did something like ":r
>> !some-cmd".  I think there was a report about this on the vim_mac list a
>> long time ago.
>>
>
> Wasn't that issue fixed later?  I don't see any glitch with
> --disable-darwin build for these 6 years...
>

No, it was not.  I'm not sure if it's a bug, but Vim behaves differently
regarding Unicode precomposition depending on whether --disable-darwin is
passed.

If I `touch` some nonACII filenames like "föo" and "bár" (in a terminal
operating in utf-8), and then fire up vim in that directory where the
touches happened, and then do:
   :let @a = glob("*") | put a

Then doing a `ga` (or `g8`) over the multibyte characters will display
something different depending on whether --disable-darwin was passed or not.

If --disable-darwin is passed during build, then:
  * `ga` over the "ö" in "föo" shows:
111,  Hex 6f,  Octal 157 < ̈> 776, Hex 0308, Octal 1410
  * `g8` over that same character shows: 6f + cc 88

If --disable-darwin is NOT passed during build, then the same operations
show:
  * `ga`: <ö> 246, Hex 00f6, Octal 366
  * `g8`: c3 b6

Again, I don't know whether this is an actual *bug* (or *why* it's
happening), but it just isn't true that the only difference between
--disable-darwin or --enable-darwin is the clipboard.  There is more at
work, and it should be documented to the extent anyone can figure out
what's going on.

-Manny

-- 
-- 
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] Clean up Mac code

[Manuel Ortega]

On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2017-04-23 0:02 GMT+09:00 Manuel Ortega <mannyvim...@gmail.com>:
>
>> On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar <b...@moolenaar.net>:
>>>
>>>>
>>>>
>>>> The terms "with darwin" and "without darwin" are very confusing.  There
>>>> is no help for "darwin". Cleaning that up sounds like a good idea.
>>>>
>>>
>>> OK, I'll add some explanation on the darwin feature to os_mac.txt, and
>>> make links between that and the terms.
>>>
>>
>> I seem to remember, from a while back, that "disabling darwin" has a
>> bigger effect than just disconnecting Vim from the macOS clipboard.
>> Something about it messed up (believe it or not) the precomposition (or
>> lack thereof) of unicode, particularly when one did something like ":r
>> !some-cmd".  I think there was a report about this on the vim_mac list a
>> long time ago.
>>
>
> Wasn't that issue fixed later?  I don't see any glitch with
> --disable-darwin build for these 6 years...
>
>
>>
>> Still, prior to making the suggested list, I think we should first remove
>>> the code relevant to Mac OS 9 and the Carbon GUI.  Please allow me to
>>> reiterate them:
>>>
>>> version7.txt:108 (2005-12-06, 241a8aaa48):
>>> "The support for Mac OS 9 has been removed."
>>>
>>>
>>> src/configure.ac:2231  (2010-07-14, 164fca39bd):
>>> "AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"
>>>
>>> They are backlogs overdue.
>>>
>>>
>>>> How about Carbon?  On my Mac air it appears not to work, Quickdraw.h is
>>>> missing.
>>>>
>>>
>>> They say that Carbon wasn't updated to support 64-bit.  So current
>>> Carbon Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in
>>> a 64-bit environment for one reason or another.  I'm definitely the last
>>> person of this kind.
>>>
>>> And, as you noticed, our build system hasn't maintained in a way to
>>> support it.
>>>
>>
>> I think Carbon Vim was destroyed in three phases:  First, the Carbon code
>>> was alienated from the codebase when the darwin feature is merged there on
>>> 2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
>>> Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
>>> AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
>>> effort for the Carbon code at any rate.
>>>
>>> IIRC, we haven't received any report, patch or request on the breakage
>>> relevant to the Carbon code so far.
>>>
>>> in conclusion, unless someone is willing to work for that, we are no
>>> longer able to maintain it.  Personally, I think it's nearly impossible to
>>> restore it.
>>>
>>
>> I think you are underestimating the Carbon build.  The Carbon GUI is only
>> broken for recent versions of macOS, where there is independently no reason
>> to ask for it because there is MacVim which is infinitely superior.  There
>> is no "work needed to restore it", because there is no need to restore it,
>> because it builds fine on 10.8 and under (and will even run on macOS
>> Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I
>> know it works just fine even on macOS 10.4 and 10.5.
>>
>
> Alas, the reason why I mentioned the exact versions and dates was to avoid
> this sort of misunderstanding...
>

What misunderstanding is that?  You listed versions and dates and then,
despite the fact that the Carbon GUI is usable for older Macs, declared
that we should get rid of it---on the grounds that (1) it doesn't work
anymore and would be nearly impossible to "restore", and (2) that the
Carbon GUI is only for people with 64 bit Macs who nevertheless want a
32bit Vim GUI (and that (3) you are *definitely* the only such person
anyway).

(2) and (3) are false, and (1) doesn't apply in the slightest to older Macs
(10.4-10.6 at *least*, maybe even up to 10.8), which are not ancient or
obscure compared to the sort of stuff that Vim generally bends over
backwards to support.

-Manny

-- 
-- 
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] Clean up Mac code

[Manuel Ortega]

On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar :
>
>>
>>
>> The terms "with darwin" and "without darwin" are very confusing.  There
>> is no help for "darwin". Cleaning that up sounds like a good idea.
>>
>
> OK, I'll add some explanation on the darwin feature to os_mac.txt, and
> make links between that and the terms.
>

I seem to remember, from a while back, that "disabling darwin" has a bigger
effect than just disconnecting Vim from the macOS clipboard.  Something
about it messed up (believe it or not) the precomposition (or lack thereof)
of unicode, particularly when one did something like ":r !some-cmd".  I
think there was a report about this on the vim_mac list a long time ago.

Still, prior to making the suggested list, I think we should first remove
> the code relevant to Mac OS 9 and the Carbon GUI.  Please allow me to
> reiterate them:
>
> version7.txt:108 (2005-12-06, 241a8aaa48):
> "The support for Mac OS 9 has been removed."
>
>
> src/configure.ac:2231  (2010-07-14, 164fca39bd):
> "AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"
>
> They are backlogs overdue.
>
>
>> How about Carbon?  On my Mac air it appears not to work, Quickdraw.h is
>> missing.
>>
>
> They say that Carbon wasn't updated to support 64-bit.  So current Carbon
> Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in a
> 64-bit environment for one reason or another.  I'm definitely the last
> person of this kind.
>
> And, as you noticed, our build system hasn't maintained in a way to
> support it.
>

I think Carbon Vim was destroyed in three phases:  First, the Carbon code
> was alienated from the codebase when the darwin feature is merged there on
> 2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
> Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
> AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
> effort for the Carbon code at any rate.
>
> IIRC, we haven't received any report, patch or request on the breakage
> relevant to the Carbon code so far.
>
> in conclusion, unless someone is willing to work for that, we are no
> longer able to maintain it.  Personally, I think it's nearly impossible to
> restore it.
>

I think you are underestimating the Carbon build.  The Carbon GUI is only
broken for recent versions of macOS, where there is independently no reason
to ask for it because there is MacVim which is infinitely superior.  There
is no "work needed to restore it", because there is no need to restore it,
because it builds fine on 10.8 and under (and will even run on macOS
Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I
know it works just fine even on macOS 10.4 and 10.5.

Maybe the reason there haven't been bug reports is because the people that
have a reason to use it are using it on a machine for which it still
works.  Why would anyone be using a machine that's 32 bit and with an older
macOS?  Because the machines still work fine for doing work in a text
editor, even though they're not good for internet videos or photoshop.

On top of this, people on 10.7 and less have been ruthlessly dumped by
MacVim.  (You can bet it won't be long before the trigger-happy MacVim devs
dump 10.8 and 10.9).  This means those people would have no Vim GUI
whatsoever if you dump the Carbon GUI.  (The X11 GUI on the Mac is worse
than nothing, which is not Vim's fault, but is because of the X11
emulators.)

It may be that when all is said and done Carbon should still be dumped
anyway, but it is not true that (a) nobody uses it, or (b) that nobody
*could* use it, or (c) that keeping it would require a lot of work.

-Manny

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

[Manuel Ortega]

On Fri, Apr 21, 2017 at 5:00 PM, Bram Moolenaar <b...@moolenaar.net> wrote:

>
> Manuel Ortega wrote:
>
> > On Thu, Apr 20, 2017 at 4:32 PM, Bram Moolenaar <b...@moolenaar.net>
> wrote:
> >
> > >
> > > Manuel Ortega wrote:
> > >
> > > > On Thu, Apr 20, 2017 at 3:05 PM, Manuel Ortega <
> mannyvim...@gmail.com>
> > > > wrote:
> > > >
> > > > > This patch unfortunately completely wrecks parallel builds on macOS
> > > > > 10.12.4.
> > > > >
> > > > > make -j4
> > > > > Starting make in the src directory.
> > > > > If there are problems, cd to the src directory and run make there
> > > > > cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make
> > > first
> > > > > .././install-sh -c -d objects
> > > > > make[1]: .././install-sh: No such file or directory
> > > > > CC="gcc -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX" srcdir=. sh
> > > > > ./osdef.sh
> > > > > make[1]: *** [objects/.dirstamp] Error 1
> > > > > make[1]: *** Waiting for unfinished jobs
> > > > > make: *** [first] Error 2
> > > > >
> > > > >
> > > > Forgot to add that this definitely was not the case for 8.0.569.
> > >
> > > I believe that using "make -j4" after "make distclean" never worked.
> > > At least not properly, some things happen in parallel that should be
> > > sequential.
> > >
> > > I'll do an attempt to make this work.
>

8.0.576 seems to fix it, thanks!

-Manny

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

[Manuel Ortega]

On Fri, Apr 21, 2017 at 4:31 PM, Christian Brabandt 
wrote:

>
> We have no influence what is provided on the CI system.


Yeah, that was my guess.

-Manny

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

[Manuel Ortega]

On Fri, Apr 21, 2017 at 11:10 AM, James McCoy <james...@jamessan.com> wrote:

> On Apr 21, 2017 10:25, "Manuel Ortega" <mannyvim...@gmail.com> wrote:
>
> On Thursday, April 20, 2017 at 3:05:41 PM UTC-4, Manuel Ortega wrote:
> > This patch unfortunately completely wrecks parallel builds on macOS
> 10.12.4.
>
> As a side note, now that we know that the problem has nothing to do with
> parallel builds but affects macOS generally: how the heck was this not
> caught by CI?  Is the CI not building on a Macintosh?
>
>
> Travis has GNU coreutils installed. If you check the logs, you'll see that
> it finds /usr/local/bin/gmkdir.
>

Why does the macOS testing machine have GNU coreutils on it, given that Vim
doesn't require GNU coreutils and macOS doesn't come with GNU coreutils?
That's just *asking* for problems like the present one.

-Manny

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

[Manuel Ortega]

On Thursday, April 20, 2017 at 3:05:41 PM UTC-4, Manuel Ortega wrote:
> This patch unfortunately completely wrecks parallel builds on macOS 10.12.4.

As a side note, now that we know that the problem has nothing to do with 
parallel builds but affects macOS generally: how the heck was this not caught 
by CI?  Is the CI not building on a Macintosh?

-Manny

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

[Manuel Ortega]

> Since the patch only contains src/configure.ac, please run 'make autoconf' in 
> the src directory after applying the patch.


That works, thanks.  I hope that the need to run 'make autoconf' will go away 
if this patch gets merged.

-Manny

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

[Manuel Ortega]

On Thu, Apr 20, 2017 at 6:12 PM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

>
> Don't know if this helps, but the output of "./configure" includes this
> line:
>
>   checking for a thread-safe mkdir -p... ./install-sh -c -d
>
> While the error message from "make" is looking for ".././install-sh", one
> dir level up from where "configure" said it was found.
>

Also, I verified that my configuration flags are not the problem.  "git
clean -fdx" followed by plain "./configure" followed by plain "make" bombs
out in the same way.

-Manny

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

[Manuel Ortega]

On Thu, Apr 20, 2017 at 5:59 PM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> On Thu, Apr 20, 2017 at 5:56 PM, Manuel Ortega <mannyvim...@gmail.com>
> wrote:
>
>> On Thu, Apr 20, 2017 at 4:32 PM, Bram Moolenaar <b...@moolenaar.net>
>> wrote:
>>
>>>
>>> Manuel Ortega wrote:
>>>
>>> > On Thu, Apr 20, 2017 at 3:05 PM, Manuel Ortega <mannyvim...@gmail.com>
>>> > wrote:
>>> >
>>> > > This patch unfortunately completely wrecks parallel builds on macOS
>>> > > 10.12.4.
>>> > >
>>> > > make -j4
>>> > > Starting make in the src directory.
>>> > > If there are problems, cd to the src directory and run make there
>>> > > cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make
>>> first
>>> > > .././install-sh -c -d objects
>>> > > make[1]: .././install-sh: No such file or directory
>>> > > CC="gcc -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX" srcdir=. sh
>>> > > ./osdef.sh
>>> > > make[1]: *** [objects/.dirstamp] Error 1
>>> > > make[1]: *** Waiting for unfinished jobs
>>> > > make: *** [first] Error 2
>>> > >
>>> > >
>>> > Forgot to add that this definitely was not the case for 8.0.569.
>>>
>>>
> The make -j flags are a red herring.  I get that error even with plain
> "make" after "git clean -fdx".  It's now impossible to build on macOS 10.12
> from Vim 8.0.570 and up.
>
> To build vim I do:
>
> ./configure -C [some flags]
> make -j4
>
> The "some flags" haven't changed in a really long time.
>

Don't know if this helps, but the output of "./configure" includes this
line:

  checking for a thread-safe mkdir -p... ./install-sh -c -d

While the error message from "make" is looking for ".././install-sh", one
dir level up from where "configure" said it was found.

-Manny

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

[Manuel Ortega]

On Thu, Apr 20, 2017 at 5:56 PM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> On Thu, Apr 20, 2017 at 4:32 PM, Bram Moolenaar <b...@moolenaar.net>
> wrote:
>
>>
>> Manuel Ortega wrote:
>>
>> > On Thu, Apr 20, 2017 at 3:05 PM, Manuel Ortega <mannyvim...@gmail.com>
>> > wrote:
>> >
>> > > This patch unfortunately completely wrecks parallel builds on macOS
>> > > 10.12.4.
>> > >
>> > > make -j4
>> > > Starting make in the src directory.
>> > > If there are problems, cd to the src directory and run make there
>> > > cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make
>> first
>> > > .././install-sh -c -d objects
>> > > make[1]: .././install-sh: No such file or directory
>> > > CC="gcc -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX" srcdir=. sh
>> > > ./osdef.sh
>> > > make[1]: *** [objects/.dirstamp] Error 1
>> > > make[1]: *** Waiting for unfinished jobs
>> > > make: *** [first] Error 2
>> > >
>> > >
>> > Forgot to add that this definitely was not the case for 8.0.569.
>>
>>
The make -j flags are a red herring.  I get that error even with plain
"make" after "git clean -fdx".  It's now impossible to build on macOS 10.12
from Vim 8.0.570 and up.

To build vim I do:

./configure -C [some flags]
make -j4

The "some flags" haven't changed in a really long time.

-Manny

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

[Manuel Ortega]

On Thu, Apr 20, 2017 at 4:32 PM, Bram Moolenaar <b...@moolenaar.net> wrote:

>
> Manuel Ortega wrote:
>
> > On Thu, Apr 20, 2017 at 3:05 PM, Manuel Ortega <mannyvim...@gmail.com>
> > wrote:
> >
> > > This patch unfortunately completely wrecks parallel builds on macOS
> > > 10.12.4.
> > >
> > > make -j4
> > > Starting make in the src directory.
> > > If there are problems, cd to the src directory and run make there
> > > cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make
> first
> > > .././install-sh -c -d objects
> > > make[1]: .././install-sh: No such file or directory
> > > CC="gcc -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX" srcdir=. sh
> > > ./osdef.sh
> > > make[1]: *** [objects/.dirstamp] Error 1
> > > make[1]: *** Waiting for unfinished jobs
> > > make: *** [first] Error 2
> > >
> > >
> > Forgot to add that this definitely was not the case for 8.0.569.
>
> I believe that using "make -j4" after "make distclean" never worked.
> At least not properly, some things happen in parallel that should be
> sequential.
>
> I'll do an attempt to make this work.
>

8.0.573 didn't change anything.  I get the exact same error.

> I believe that using "make -j4" after "make distclean" never worked.

I've been doing it for four years, and with -j2 for another four before
that.  Has it been "improper" the whole time?

-Manny

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

[Manuel Ortega]

On Thu, Apr 20, 2017 at 3:05 PM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> This patch unfortunately completely wrecks parallel builds on macOS
> 10.12.4.
>
> make -j4
> Starting make in the src directory.
> If there are problems, cd to the src directory and run make there
> cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make first
> .././install-sh -c -d objects
> make[1]: .././install-sh: No such file or directory
> CC="gcc -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX" srcdir=. sh
> ./osdef.sh
> make[1]: *** [objects/.dirstamp] Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [first] Error 2
>
>
Forgot to add that this definitely was not the case for 8.0.569.

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

[Manuel Ortega]

This patch unfortunately completely wrecks parallel builds on macOS 10.12.4.

make -j4
Starting make in the src directory.
If there are problems, cd to the src directory and run make there
cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make first
.././install-sh -c -d objects
make[1]: .././install-sh: No such file or directory
CC="gcc -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX" srcdir=. sh ./osdef.sh
make[1]: *** [objects/.dirstamp] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [first] Error 2

-- 
-- 
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] Clean up Mac code

[Manuel Ortega]

On Mon, Apr 17, 2017 at 10:41 AM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2017-04-17 23:24 GMT+09:00 Manuel Ortega <mannyvim...@gmail.com>:
>
>> On Mon, Apr 17, 2017 at 5:19 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>>
>>>
> How about changing the description in eval.txt from
>
> macunix  Compiled for macOS with pasteboard support (default)
>
> to
>
>   macunix  Compiled for macOS with clipboard support (default)
>
>
> Do you think it's OK for our users?
>

That part is OK.

Line 175 of the patch contains a typo ("MAXOS").

-Manny

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

-- 
-- 
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] Clean up Mac code

[Manuel Ortega]

On Mon, Apr 17, 2017 at 5:19 AM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> This is a followup to https://groups.google.com/forum/#!topic/vim_dev/
> 5RFo3q8xvfo where we talked about the feature list items relevant to Mac:
>
>   On macOS, what is known as clipboard in our community is called
> pasteboard.
>

This is false. In Mac-land, it is called the "clipboard", and has been thus
for at least 26 years.

If you go into "Mac Help" from the Help menu of the Finder on Sierra, and
search for "pasteboard", you get one result, and in the text of the body of
that result it is clear that "clipboard" is the real Mac term.  If you
search for "clipboard", you get several results, including some that don't
contain "clipboard" but are about copying and pasting.  If in Preview.app
you Cmd-C a region of a photo, the Edit menu gives you the option "New from
clipboard".  Etc., etc., etc.

In the Apple *developer* docs, what is known in user-land as "the
clipboard" is sometimes called the "pasteboard".  But to be intelligible to
Mac *users*, Vim should call it what *users* call it.  It is called the
"clipboard".

-Manny

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

8.0.539 has test failure on macOS 10.12.4

[Manuel Ortega]

Test results:
ALL DONE
gcc -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  -g -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1-o objects/json_test.o
json_test.c
In file included from json_test.c:19:
./main.c:1021:12: error: use of undeclared identifier 'params'
return params.not_a_term;
   ^
1 error generated.
make[1]: *** [objects/json_test.o] Error 1
make: *** [test] Error 2

-Manny

-- 
-- 
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 improvements for the docs

[Manuel Ortega]

On Wed, Mar 22, 2017 at 5:30 PM, Bram Moolenaar  wrote:

> Ken Takata wrote:
>
> > 2016/2/18 Thu 4:48:46 UTC+9 Bram Moolenaar wrote:
> > > > Mac OS has also some default mappings, but it seems that they are not
> > > > documented.
> > > > https://github.com/vim/vim/blob/master/src/getchar.c#L5307-L5316
> > > > Maybe it's better to add them to the documents.
> > >
> > > I hope someone can do that.  I like complete docs.
> >
> > I have added description for standard mappings on macOS (based on the
> source
> > code).
> > I'm not a macOS user, so review by mac users is welcome.
>
> Thanks.
>
> > BTW, on MS-Windows, Shift-Insert is mapped to * in Insert mode:
> > https://github.com/vim/vim/blob/a37ffaa/src/getchar.c#L5262
> >
> > However, on macOS, Command-v is mapped to * in Insert mode:
> > https://github.com/vim/vim/blob/a37ffaa/src/getchar.c#L5299
> >
> > Isn't it better to map to * also on macOS?
> > This breaks backward compatibility though.
>

I don't think breaking backwards compatibility is a good idea.

-Manny

-- 
-- 
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: Compiler warnings in 8.0.453

[Manuel Ortega]

On Sunday, March 12, 2017 at 3:41:17 PM UTC-4, Manuel Ortega wrote:
> On macOS 10.12.3 Sierra, there have suddenly (within the last day, I think) 
> appeared compiler warnings during the make phase.  This is Vim 8.0.453.  See 
> below.
> 
> 
> -Manny

[SNIP]

Bisection reveals that these warnings were introduced with 8.0.451

-Manny

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

Compiler warnings in 8.0.453

[Manuel Ortega]

On macOS 10.12.3 Sierra, there have suddenly (within the last day, I think)
appeared compiler warnings during the make phase.  This is Vim 8.0.453.
See below.

-Manny

gcc -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  -g -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1-o objects/screen.o screen.c
screen.c:4557:33: warning: comparison of constant 256 with expression of
type
  'char_u' (aka 'unsigned char') is always true
  [-Wtautological-constant-out-of-range-compare]
  && VIM_ISBREAK(c) &&
!VIM_ISBREAK(*ptr))

^
./macros.h:176:29: note: expanded from macro 'VIM_ISBREAK'
#define VIM_ISBREAK(c) ((c) < 256 && breakat_flags[(char_u)(c)])
~~~ ^ ~~~


And then later on:

gcc -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  -g -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1-o objects/json.o json.c
charset.c:1093:10: warning: comparison of constant 256 with expression of
type 'char_u' (aka 'unsigned char') is always
  true [-Wtautological-constant-out-of-range-compare]
&& !VIM_ISBREAK(s[1])
^
./macros.h:176:29: note: expanded from macro 'VIM_ISBREAK'
#define VIM_ISBREAK(c) ((c) < 256 && breakat_flags[(char_u)(c)])
~~~ ^ ~~~
charset.c:1123:28: warning: comparison of constant 256 with expression of
type 'char_u' (aka 'unsigned char') is always
  true [-Wtautological-constant-out-of-range-compare]
&& (col2 == col || !VIM_ISBREAK(*ps))
^~~~
./macros.h:176:29: note: expanded from macro 'VIM_ISBREAK'
#define VIM_ISBREAK(c) ((c) < 256 && breakat_flags[(char_u)(c)])
~~~ ^ ~~~

-- 
-- 
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: More test litter

[Manuel Ortega]

On Tue, Mar 7, 2017 at 9:54 AM, Manuel Ortega <mannyvim...@gmail.com> wrote:

>
> The file I originally reported still reappears after doing a `git clean
> -fdx` and starting over.
>
> I applied Christian's patch.  This stopped src/testdir/xxx from
> reappearing as an untracked file, but now `git status` warns me that
> `src/opt_test.vim` has been modified (this was not a problem when I made my
> original post).
>
> -Manny
>

Well, the latter part was just me being a dope.  I forgot to make a commit
after applying the patch.

Having done that and retested, I can confirm that there is no more test
litter.

-Manny

-- 
-- 
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: More test litter

[Manuel Ortega]

On Tue, Mar 7, 2017 at 3:25 AM, Christian Brabandt <cbli...@256bit.org>
wrote:

> On So, 05 Mär 2017, Bram Moolenaar wrote:
> > Manuel Ortega wrote:
> >
> > > After a build and a `make clean`, I now find that `git status` shows:
> > > "src/testdir/xxx" as an untracked item.
> > >
> > > This should either get cleaned up by `make clean`, or be gitignored.
> >
> > I also had this file, but after deleting it and running tests it doesn't
> > come back.  I suspect this problem is already fixed.
>
> I believe this comes from the newly generated opt_test.vim script.
> Setting verbosefile=xxx will make Vim write out that file.
> Please apply the attached patch
>
> I also saw a leftover netbeans file sometimes. But I couldn't reproduce
> how this one was left over.
>
> I personally don't like how the src/testdir/opt_test.vim is generated.
> Can't we do that as part of test1.in, so that it will always be
> recreated on a new test run and not only when make test is called from
> the src dir?
>
> Also you might want to add the src/testdir/opt_test.vim to the
> .gitignorefile since it is auto generated and it litters the git status
> output.


The file I originally reported still reappears after doing a `git clean
-fdx` and starting over.

I applied Christian's patch.  This stopped src/testdir/xxx from reappearing
as an untracked file, but now `git status` warns me that `src/opt_test.vim`
has been modified (this was not a problem when I made my original post).

-Manny

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

More test litter

[Manuel Ortega]

After a build and a `make clean`, I now find that `git status` shows:
"src/testdir/xxx" as an untracked item.

This should either get cleaned up by `make clean`, or be gitignored.

-Manny

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

[Manuel Ortega]

On Sat, Feb 25, 2017 at 8:21 AM, Bram Moolenaar <b...@moolenaar.net> wrote:

>
> Patch 8.0.0364
> Problem:]s does not move cursor with two spell errors in one line.
> (Manuel
> Ortega)
> Solution:   Don't stop search immediately when wrapped, search the line
> first.
> (Ken Takata)  Add a test.
> Files:  src/spell.c, src/Makefile, src/testdir/test_spell.vim,
> src/testdir/Make_all.mak


Seems to work so far, thanks!

-Manny

-- 
-- 
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 ]s command broke recently

[Manuel Ortega]

On Thu, Feb 23, 2017 at 10:10 PM, Ken Takata <ktakata65...@gmail.com> wrote:

> Hi,
>
> 2017/2/24 Fri 8:42:16 UTC+9 Manuel Ortega wrote:
> > The ]s command for moving to the next spelling error has become broken
> recently.  Sometime within the last three weeks I would guess.
> >
> >
> > Create a text file called "foo" containing the following text (one line):
> >
> >
> > This was a tricky problem.  We're given a sheep, and a shoezp  where A
> is the incumbent senator and the dzenj said hello.
> >
> >
> > Now from the terminal do `vim -u NONE -i NONE -N --noplugin foo`.
> >
> >
> > Then do ":set spell".  The two error words are then highlighted.  Hit ]s
> twice to put the cursor on the word "dzenj".  Now hit ]s again.
> >
> >
> > Expected behavior: the cursor cycles around and lands on the world
> "shoezp".
> >
> >
> > Actual behavior: Despite seeing a "search hit BOTTOM, continuing at TOP"
> message (as I should), the cursor stays stuck on the last error word
> "dzjenj" and won't cycle around.
> >
> >
> > I note that the [s command cycles between the two erros as expected.
> Only ]s is broken.
> >
> > This is not an artifact of the test file containing only one line,
> because if I add other lines to "foo" that contain no spelling errors, I
> see the same behavior.
> >
> >
> > This is macOS 10.12.3, vim 8.0.363.
>
> It seems that this occurs when the cursor is in the first line and there
> are
> no wrong words after the second line.  Maybe, this was so for a long time,
> not broken recently.
>

I'll test the patch (thanks!), but note that the bug is not contingent on
the cursor being in the first line of the file.  The test file was
deliberately small to show the problem.  I can see it even if there are
many lines both before and after the line containing the two errors.

-Manny

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

The ]s command broke recently

[Manuel Ortega]

The ]s command for moving to the next spelling error has become broken
recently.  Sometime within the last three weeks I would guess.

Create a text file called "foo" containing the following text (one line):

This was a tricky problem.  We're given a sheep, and a shoezp  where A is
the incumbent senator and the dzenj said hello.

Now from the terminal do `vim -u NONE -i NONE -N --noplugin foo`.

Then do ":set spell".  The two error words are then highlighted.  Hit ]s
twice to put the cursor on the word "dzenj".  Now hit ]s again.

Expected behavior: the cursor cycles around and lands on the world "shoezp".

Actual behavior: Despite seeing a "search hit BOTTOM, continuing at TOP"
message (as I should), the cursor stays stuck on the last error word
"dzjenj" and won't cycle around.

I note that the [s command cycles between the two erros as expected.  Only
]s is broken.

This is not an artifact of the test file containing only one line, because
if I add other lines to "foo" that contain no spelling errors, I see the
same behavior.

This is macOS 10.12.3, vim 8.0.363.

-Manny

-- 
-- 
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: test failures on macOS 10.12.2

[Manuel Ortega]

On Tuesday, January 10, 2017 at 1:31:03 PM UTC-6, Manuel Ortega wrote:
> On macOS 10.12.2, with a fresh pull of the repo up to 8.0.169, there are 
> suddenly test failures:
> 
> 
> 
> VIMRUNTIME=../../runtime; export VIMRUNTIME;  ../vim -f  -u unix.vim -U NONE 
> --noplugin --not-a-term -U NONE -S runtest.vim test_channel.vim
> 
> Vim: Caught deadly signal ABRT
> 
> 
> Vim: Finished.
> /bin/sh: line 1: 26731 Abort trap: 6           ../vim -f -u unix.vim -U NONE 
> --noplugin --not-a-term -U NONE -S runtest.vim test_channel.vim
>                                                             make[2]: *** 
> [test_channel.res] Error 134
>                      make[1]: *** [scripttests] Error 2
>                                                        make: *** [test] Error 
> 2
> ---
> 
> 
> On top of this, the terminal is messed up after the test failure occurs.
> 
> 
> -Manny

Testing reveals that version 8.0.168 is just fine.

-Manny

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

test failures on macOS 10.12.2

[Manuel Ortega]

On macOS 10.12.2, with a fresh pull of the repo up to 8.0.169, there are
suddenly test failures:


VIMRUNTIME=../../runtime; export VIMRUNTIME;  ../vim -f  -u unix.vim -U
NONE --noplugin --not-a-term -U NONE -S runtest.vim test_channel.vim
Vim: Caught deadly signal ABRT

Vim: Finished.
/bin/sh: line 1: 26731 Abort trap: 6   ../vim -f -u unix.vim -U
NONE --noplugin --not-a-term -U NONE -S runtest.vim test_channel.vim
make[2]: ***
[test_channel.res] Error 134
 make[1]: *** [scripttests] Error 2
   make: *** [test]
Error 2
---

On top of this, the terminal is messed up after the test failure occurs.

-Manny

-- 
-- 
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 25 birthday presentation

[Manuel Ortega]

On Wed, Dec 14, 2016 at 2:39 PM, Bram Moolenaar  wrote:

>
> Hello Vim users!
>
> On November 2nd I did a presentation about Vim at Google Zurich.
> This is exactly 25 years since the first public version of Vim was
> built.
>

Dear Bram,

Since the audio is bad, would you mind posting just the slides to vim.org?
It'd be much nicer to flip through them at will, rather than deal with a
video of them being flipped irregularly.

-Manny

-- 
-- 
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] make line commands use visual lines in softwrap (enhancement) (#1164)

[Manuel Ortega]

On Thu, Oct 13, 2016 at 4:00 PM, yashamon  wrote:

> What about D, V command, etc? these behave terribly with wrapped text.
>
For the D command, just do dg$.  If you don't like typing three characters,
make up a mapping.

-Manny

-- 
-- 
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: omission in :h file-pattern?

[Manuel Ortega]

On Thu, Sep 1, 2016 at 1:46 AM, Christian Brabandt <cbli...@256bit.org>
wrote:

> Am 2016-09-01 07:41, schrieb Dominique Pellé:
>
>> Manuel Ortega <mannyvim...@gmail.com> wrote:
>>
>> The docs at :h file-pattern don't mention it, but I seem to be able to use
>>> "\=" just fine in autocmd patterns, and it seems to mean what it means
>>> in :h
>>> pattern-overview ("zero or one").
>>>
>>> For instance, `au SomeGroup *.[xgb]z2\= some_command` will fire on files
>>> with any of the following extensions:
>>>
>>>   .xz
>>>   .gz
>>>   .bz2
>>>   .bz
>>>
>>> Maybe this a fluke and it's not supposed to work this way.  But if it is
>>> supposed to work this way it should be in the docs at :h file-pattern
>>>
>>> -Manny
>>>
>>
>> I think that it's not expected and I see it a bug.
>> glob2regpat() gives what look like unexpected
>> results for:
>>
>> :echo glob2regpat('a\=')
>> Actual: ^a\=$
>> Expected: ^a\\=$
>>
>> :echo glob2regpat('a\+')
>> Actual: ^a\+$
>> Expected: ^a\\+$
>>
>> :echo glob2regpat('a\d')
>> Actual: ^a\d$
>> Expected: ^a\\d$
>>
>> And many probably many other cases
>> where \ is special in regexp, but not special
>> in glob special characters.
>>
>
> I believe this is not true. The documentation mentions this:
> ,[ :h file-pattern ]-
> |   *file-pattern*
> | The pattern is interpreted like mostly used in file names:
> |   *   matches any sequence of characters; Unusual: includes path
> |   [...]
> |   \   special meaning like in a |pattern|
> |   [...]
> `
>
> So one can expect '\=' to work like a regexp pattern.
>

I think my point stands: the docs need to be expanded (provided this is how
filename-patterns are *supposed* work).  Because the tiny phrase "\
special meaning like in a |pattern|" doesn't seem to even remotely suggest
"a backslash followed by X will have the same meaning that \X does in a
|pattern|".  (Nor does it suggest restricted versions of that, such as "a
backslash followed by a multi-item will have the same meaning that it does
in a |pattern|").  The tiny phrase is *compatible* with the longer one, but
docs are supposed to do more than that.

"\special meaning like in a pattern" is hopelessly vague.  What special
meaning does "\" have in a pattern?  Just that sometimes characters that
follow it are interepreted non-literally.  So the vague phrase in question
looks rather like it only means "as with patterns, the backslash is a
special character in that sometimes what comes after it is interpreted
non-literally".  That does not enable the user to conclude "\= will work in
a file-pattern just like it does in a regex".

-Manny

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

omission in :h file-pattern?

[Manuel Ortega]

The docs at :h file-pattern don't mention it, but I seem to be able to use
"\=" just fine in autocmd patterns, and it seems to mean what it means in
:h pattern-overview ("zero or one").

For instance, `au SomeGroup *.[xgb]z2\= some_command` will fire on files
with any of the following extensions:

  .xz
  .gz
  .bz2
  .bz

Maybe this a fluke and it's not supposed to work this way.  But if it is
supposed to work this way it should be in the docs at :h file-pattern

-Manny

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

Small doc fixes for lambda

[Manuel Ortega]

At ":h lambda", there is some erroneous markup.  It mistakenly is
 "|expr1|", which takes the user to the help for the ternary conditional!
I think what was meant was "{expr1}", but even better would just be
"{expr}".

The following diff fixes it, along with one tiny, unrelated omission.

-Manny

diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
index 011807b..617d3b5 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -1215,13 +1215,13 @@ See below |functions|.

 lambda expression *expr-lambda* *lambda*
 -
-{args -> expr1} lambda expression
+{args -> expr} lambda expression

 A lambda expression creates a new unnamed function which returns the
result of
-evaluating |expr1|.  Lambda expressions differ from |user-functions| in
+evaluating {expr}.  Lambda expressions differ from |user-functions| in
 the following ways:

-1. The body of the lambda expression is an |expr1| and not a sequence of
|Ex|
+1. The body of the lambda expression is an {expr} and not a sequence of
|Ex|
commands.
 2. The prefix "a:" should not be used for arguments.  E.g.: >
  :let F = {arg1, arg2 -> arg1 - arg2}
@@ -1981,7 +1981,7 @@ assert_notmatch({pat}, {text} [, {msg}]) none  assert
{pat} not matches {text}
 assert_true({actual} [, {msg}])  none  assert {actual} is true
 asin({expr}) Float arc sine of {expr}
 atan({expr}) Float arc tangent of {expr}
-atan2({expr}, {expr}) Float arc tangent of {expr1} / {expr2}
+atan2({expr1}, {expr2}) Float arc tangent of {expr1} / {expr2}
 browse({save}, {title}, {initdir}, {default})
  String put up a file requester
 browsedir({title}, {initdir}) String put up a directory requester

-- 
-- 
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: Diff should indicate if no differences detected

[Manuel Ortega]

On Sun, Aug 28, 2016 at 6:05 AM, toothpik  wrote:

> On Sat, Aug 27, 2016 at 08:32:09PM -0700, JohnBeckett wrote:
> > Bram recently fixed :diffoff!
> > https://groups.google.com/forum/#!topic/vim_dev/h1nREhhF7mY
>
> > That reminds me of a diff frustration.
>
> > Suppose I have two files expected.txt and output.txt, each over 1000
> > lines. Running a test program creates the second file, and it should
> > be the same as the first. I use something like the following to diff:
>
> > :tabe expected.txt
> > :vert diffs output.txt
>
> > When I last viewed those files, I may have exited with the cursor on
> > the last line. I use the code from ":help restore-cursor" to restore
> > the cursor position, so the diff shows the cursor at the bottom.
>
> there's your problem right there


No, that's not the problem.

I know I said above that the OP exactly described my problem, but I
should've been clearer. I don't use any cursor-restoring stuff, but I run
into this issue sometimes, and I have never in my life run the code from
":h restore-cursor" or anything like it.

It *might* be that cursor-restoring makes the symptoms worse than they
would otherwise be, but there is an underlying deficiency in vim.

-Manny

-- 
-- 
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: Diff should indicate if no differences detected

[Manuel Ortega]

On Sat, Aug 27, 2016 at 11:32 PM, JohnBeckett 
wrote:

> Bram recently fixed :diffoff!
> https://groups.google.com/forum/#!topic/vim_dev/h1nREhhF7mY
>
> That reminds me of a diff frustration.
>
> Suppose I have two files expected.txt and output.txt, each over 1000
> lines. Running a test program creates the second file, and it should be the
> same as the first. I use something like the following to diff:
>
> :tabe expected.txt
> :vert diffs output.txt
>
> When I last viewed those files, I may have exited with the cursor on the
> last line. I use the code from ":help restore-cursor" to restore the cursor
> position, so the diff shows the cursor at the bottom.
>
> Problem: If the only difference is near the top, all I see in the left and
> right windows is a single line representing the folded "no difference"
> text. To be sure there is no difference, I have to gg in *both* windows.
>
> I could use [c in just one window and take the fact that nothing happens
> as an indication that the two files are identical, but that is not
> satisfying. It also fails to show the diff if the only difference is that
> the file in the other window has had a new line inserted at the top.
>
> Using zb is the same: it does not show the diff if the only difference is
> that the file in the other window has had a new line inserted at the top.
>
> Can something be done to give a more convincing display of whether the two
> buffers have a difference? The problem is that Vim's logic for positioning
> the top line of the window shows the minimum amount of text in the above
> scenario (possibly just a single fold line). It would be nice if some extra
> logic said "this is a diff, so if there is a difference, scroll *both*
> windows down as much as possible".
>

Thank you for writing this up clearly (both the problem and a
solution-description).  This exact thing has been bugging me for a year or
two now.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 1:31 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

>
> It may be true that setting go+=M will reduce memory usage and make
> startup faster.  But I would say the benefit gained by doing that is quite
> marginal.
>

It makes a noticeable difference to me.  That's part of why I do it.


> Hence, in comparison with those heavy tasks, what is gained by go+=M is
> negligible.
>

That's not the only reason someone would want to disable the system menus.
Some users just don't want to stare at all that garbage.  It's the *same*
justification for the existence of *tons* of other options.

I disable the system menu.vim so that I can source my own custom version
that's very bare-bones.  It doesn't cause a noticeable speedup and my
screen is uncluttered.  Thus the gain by having go+=M is not negligible.


> I don't understand why go+=M is so important for some people.
>

I don't understand why suddenly having a system vimrc after years with none
is so important for some people.  Nor do I understand why, if we're going
to have one, some people are so desperate that "syntax on" and "filetype
blah" be in it.  Is it that important to be able to delete one or two lines
that are proably already in your vimrc?

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

Perhaps another way to fix this would be if the user could have a
~/.vim/menu.vim that is treated like ~/.vim/filetype.vim is treated.  I.e.,
that Vim will load the ~/.vim/menu.vim before it loads
$VIMRUNTIME/menu.vim.  That way, a user could in his own ~/.vim/menu.vim
set some variables that will cause most or all of the $VIMRUNTIME/menu.vim
to be skipped.  No need for +=M.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 1:47 PM, Gary Johnson <garyj...@spocom.com> wrote:

> On 2016-07-27, Manuel Ortega wrote:
> > On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson wrote:
> >
> > On 2016-07-27, Manuel Ortega wrote:
> >
> > > What if "syntax on" and "filetype plugin indent on" were moved
> into the
> > autocmd
> > > group "vimStartup" that the proposed system vimrc defines, under
> VimEnter
> > > autocmds:
> > >
> > > au VimEnter * syntax on
> > > au VimEnter * filetype plugin on
> > >
> > > This way, everyone who wants them still gets them, and +=M
> still works
> > > without modification.  As an added bonus, both of the "ons" can be
> > prevented
> > > from ever happening using the same "au!" line that kills the
> others in
> > that
> > > group.
> >
> > From ":help VimEnter", the VimEnter event occurs 'After doing all
> > the startup stuff, including loading .vimrc files, executing the
> > "-c cmd" arguments, creating all windows and loading the buffers in
> > them.'
> >
> > Enabling filetype detection after buffers are loaded is too late.
> >
> >
> > Filetype *detection* is on by default in Vim.  It's not being "turned
> on" by
> > "filetype plugin indent on".  So what you say will be too late is not too
> > late.
>
> What makes you think filetype detection is on by default?  That's
> not what I observe.


Because all the files I tested it with had modelines and like an idiot I
forgot about that.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 11:40 AM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

>
>> I agree that "syntax on" and "filetype on" (maybe even "filetype plugin
>> indent on") are pretty core features that should probably be enabled by
>> default, as nearly everyone will use them.
>>
>
>
>> However, I disagree that this should come at the expense of being able
>> to set up specific options. Anything done in the default settings should
>> be modifiable by the user, and it looks like in this situation that is
>> not possible, if the default settings are always sourced.
>>
>
> I would have no problem with "syntax on" going in a system vimrc if it
> didn't have unfixable side-effects.
>
> Perhaps it's possible for Bram to change the behavior of "syntax on" so
> that it doesn't cause menu.vim to be loaded.  Same for "filetype on".
>
> Or perhaps it's possible for Bram to change them so that menu.vim isn't
> loaded until after the user's vimrc is loaded.  Then the user could at
> least set the "did_install_*" variables.
>
> -Manny
>

What if "syntax on" and "filetype plugin indent on" were moved into the
autocmd group "vimStartup" that the proposed system vimrc defines, under
VimEnter autocmds:

au VimEnter * syntax on
au VimEnter * filetype plugin on

This way, everyone who wants them still gets them, and +=M still works
without modification.  As an added bonus, both of the "ons" can be
prevented from ever happening using the same "au!" line that kills the
others in that group.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 3:51 AM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega <mannyvim...@gmail.com>
> wrote:
>
>> On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar <b...@moolenaar.net>
>> wrote:
>>
>>>
>>>
>>> " Switch syntax highlighting on when the terminal has colors or when
>>> using the
>>> " GUI (which always has colors).
>>> if _Co > 2 || has("gui_running")
>>>   syntax on
>>>
>>
>> Wait a sec.  If "syntax on" is done here, then won't it be impossible to
>> use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
>> say that in order for that to work, it must be done "before switching on
>> syntax or filetype recognition".  But if syntax is turned on here, by the
>> time the  "set go+=M" in his .vimrc is encountered it will be too late,
>> right?
>>
>
> Indeed, that is the case (I tried it).  If you put "syntax on" in the
> system vimrc, then the user cannot use "set go+=M".   I think this is a
> good reason to remove "syntax on" from the proposal.  If it's left in, you
> might as well just eliminate "M" as one of the guioptions, because it's
> totally unusable unless it goes in the local machine's system vimrc, which
> many users will not be able to change, or will not want to tweak it every
> time they build a new Vim.
>

If "syntax on" is in the system vimrc as proposed, then I can't seem to
find any way *at all* to disable the loading of the system menu.vim (short
of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)

Not only that, but the variables in menu.vim intended to be settable by the
user to stop certain segments from loading, i.e.,

let did_install_default_menus = 1
let no_buffers_menu =1
let did_install_syntax_menu = 1

... have no effect in the user's vimrc because menu.vim is already loaded
by the system vimrc's "syntax on".

Please, please, remove "syntax on" from the proposal.  There is no way for
the user to undo its side-effects.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar <b...@moolenaar.net>
> wrote:
>
>>
>>
>> " Switch syntax highlighting on when the terminal has colors or when
>> using the
>> " GUI (which always has colors).
>> if _Co > 2 || has("gui_running")
>>   syntax on
>>
>
> Wait a sec.  If "syntax on" is done here, then won't it be impossible to
> use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
> say that in order for that to work, it must be done "before switching on
> syntax or filetype recognition".  But if syntax is turned on here, by the
> time the  "set go+=M" in his .vimrc is encountered it will be too late,
> right?
>

Indeed, that is the case (I tried it).  If you put "syntax on" in the
system vimrc, then the user cannot use "set go+=M".   I think this is a
good reason to remove "syntax on" from the proposal.  If it's left in, you
might as well just eliminate "M" as one of the guioptions, because it's
totally unusable unless it goes in the local machine's system vimrc, which
many users will not be able to change, or will not want to tweak it every
time they build a new Vim.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar  wrote:

>
> " Only do this part when compiled with support for autocommands.
> if has("autocmd")
>
>   " Enable file type detection.
>   " Use the default filetype settings, so that mail gets 'tw' set to 72,
>   " 'cindent' is on in C files, etc.
>   " Also load indent files, to automatically do language-dependent
> indenting.
>   filetype plugin indent on
>

This is a plea to not enable ftplugins.  They make using vim analogous to
driving a car whose mirrors, seat adjustment, and radio station keep
automatically changing depending on what direction the car is pointing.

I like that none of this will happen with '-u NONE'.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Mon, Jul 25, 2016 at 4:00 PM, Bram Moolenaar  wrote:

>
> Hirohito Higashi wrote:
>
> > I think it is better to change the default value of Vim body for some
> > of the options.
> >
> > i.e.
> > set wildmenu
> > set ruler
> > set showcmd
> > set tags=./tags;,tags;
> > etc...
> >
> > Obviously useful things should be changed.
>
> A few people have mentioned setting 'wildmenu'.  I also have that set.
> I wonder if there are real disadvantages to setting it by default?
>

What are the advantages to *setting* it?  This looks like a shining example
of "personal preference".

Keep in mind that most of these defaults are for options that new users
> would not even know about.  It's possible that a few users don't like it
> and have to disable it in their .vimrc.  So long as that number is
> small (less than 1%?) that would be an acceptable price for helping new
> users enjoying Vim more.
>

Much of what is in the proposal works contrary to that purpose.

> Keep in mind that most of these defaults are for options that new users
> would not even know about.

This also means some of them are going to be unexpected, even jarring, to
new users.

-Manny

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

[Manuel Ortega]

On Mon, Jul 25, 2016 at 2:00 PM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

>
>
> On Mon, Jul 25, 2016 at 1:41 PM, Hisashi T Fujinaka <ht...@twofifty.com>
> wrote:
>
>>
>> Well, --huge is breaking on OSX for me again. I'm seeing if I can figure
>> out where it broke. I wish I knew how to use bisect...
>>
>
> What are your ./configure flags?  I am building with huge features on OSX
> with no problems.
>

By the way, --huge is the default now, so you shouldn't need to pass it at
the command line.

Bram: "./configure --help" still claims that the default level is "normal".

-Manny

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

[Manuel Ortega]

On Mon, Jul 25, 2016 at 1:41 PM, Hisashi T Fujinaka 
wrote:

>
> Well, --huge is breaking on OSX for me again. I'm seeing if I can figure
> out where it broke. I wish I knew how to use bisect...
>

What are your ./configure flags?  I am building with huge features on OSX
with no problems.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Sun, Jul 24, 2016 at 12:09 PM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar <b...@moolenaar.net>
> wrote:
>
>>
>>
>> Probably not:
>>
>>   " these two leave files behind
>>   set backup
>>   set undofile
>>
>>   " may conflict with a user mapping
>>   inoremap  u
>>
>>   " hard to revert
>>   if has('syntax') && has('eval')
>> packadd matchit
>>   endif
>>
>> Comments?
>>
>
>
> Definitely not!  Especially "matchit", since it's hard to reverse.  I
> don't want that thing.   will leave unexpected litter around,
> which is ban enough; but since the litter will start with dots it will
> unintentionally wind up making it into tarballs because people will forget
> that such files are lurking.  Also, the "backup" related things will mess
> up "creation date" in mac OS depending on how they're configured.
> Currently the creation date is preserved on macOS by Vim's default settings.
>

Scratch what I said about creation-date on macOS.  By default that isn't
preserved.  (I mistakenly thought it was because setting  will preserve
it, and the docs for  say that it is on by default for "unix".
Apparently OS X doesn't count as "unix", because on OS X  is set to
"auto".  Probably the docs should be corrected here.)

But add that setting  will leave litter around on the filesystem.
Please don't leave unexpected litter around on the filesystem.   Among
other things, such backup files are bound to unintentionally get captured
in tarballs.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar  wrote:

>
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default.  Currently these are in
> $VIMRUNTIME/vimrc_example.vim.  Most of these only have a visual effect
> or slightly change how editing works.  You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings.  This is
> the most common and also most tricky part.  Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy.  But including the
> matchit plugin is not easy to revert.
>
> What we can probably always do:
>
>   set backspace=indent,eol,start
>   set history=50" keep 50 lines of command line history
>   set ruler " show the cursor position all the time
>   set showcmd   " display incomplete commands
>   set incsearch " do incremental searching
>

Please do not set   It's one of the more annoying things in all
of Vim, and very likely to bring an unexpected "what the heck?"

  " Don't use Ex mode, use Q for formatting
>   map Q gq
>
>   " In many terminal emulators the mouse works just fine, thus enable it.
>   if has('mouse')
> set mouse=a
>   endif
>   if _Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
>   endif
>
>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>
> augroup vimrcEx
> au!
>
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
>
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event
> handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
>   \ if line("'\"") >= 1 && line("'\"") <= line("$") |
>   \   exe "normal! g`\"" |
>   \ endif
>
> augroup END
>   else
> set autoindent  " always set autoindenting on
>   endif
>

I am very opposed to everything in the above augroup.  There is no reason
to foist this stuff on people just because "7" is changing to "8".   Also
that BufReadPost autocmd is not easily reversible for newbs, since it's not
a simple "set".

Please don't "setlocal" a  value for text files.  Don't mess with
this at all, but if you do, don't make it "setlocal".  It is extremely
annoying to have Vim sometimes hard-wrap lines and sometimes not, depending
on which kind of file you're in---unless one specifically authorized this
by purposely turning filetype plugins on or having a plugin/package that
does this for certain 

  if has('langmap') && exists('+langnoremap')
> set langnoremap
>   endif
>
>
> Probably not:
>
>   " these two leave files behind
>   set backup
>   set undofile
>
>   " may conflict with a user mapping
>   inoremap  u
>
>   " hard to revert
>   if has('syntax') && has('eval')
> packadd matchit
>   endif
>
> Comments?
>


Definitely not!  Especially "matchit", since it's hard to reverse.  I don't
want that thing.   will leave unexpected litter around, which is
ban enough; but since the litter will start with dots it will
unintentionally wind up making it into tarballs because people will forget
that such files are lurking.  Also, the "backup" related things will mess
up "creation date" in mac OS depending on how they're configured.
Currently the creation date is preserved on macOS by Vim's default settings.

I'm not in general opposed automatically to the idea of making a small
tweak or two for Vim 8, provided they won't affect too many people.  E.g.,
 is probably OK.   But this proposal has too many of them, and
for no good reason.  Frankly, for no reason at all other than "they happen
to appear in an example of a vimrc".  Probably all that should happen is
that  is the default.  Definitely add nothing that requires
more than  a simple "set" cmd to reverse, and nothing that affects the
filesystem.

-Manny

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

Re: Syntax highlight error in .vim ??

[Manuel Ortega]

On Thu, Jul 21, 2016 at 3:46 PM, Charles E Campbell <
drc...@campbellfamily.biz> wrote:

> Ken Takata wrote:
> > Hi,
> >
> > 2016/7/20 Wed 13:41:57 UTC+9 Tony Mechelynck wrote:
> >> On Wed, Jul 20, 2016 at 4:55 AM, skywind3...@163.com
> >>  wrote:
> >>> Reproduce:
> >>> 1. vim abc.vim:
> >>> 2. add this line:
> >>> let my_dict = { "key1":"val1", "key2": "val2", "key3": "val3",
> "key4":"val4" }
> >>>
> >>> Issue:
> >>> highlight color is incorrect for my_dict,
> >>>
> >>> screen capture:
> >>> 
> >>> skywind3...@163.com
> >>>
> >> I can reproduce it. If I put one space after each colon, then all
> >> strings (keys and values both) get the Constant highlight (or whatever
> >> is linked to it); but not if there is no space after a colon, as in
> >> the first and last value in the screenshot.
> >>
> >> Adding Cc to Dr. Chip Campbell, who maintains the vim.vim syntax
> >> script. The version I'm using is 7.4-50 (May 02, 2016), as distributed
> >> with the current Vim (7.4.2080).
> >>
> >> Space or no space after a comma doesn't matter; but no space after a
> >> colon changes the highlight of both the value after the colon and the
> >> next following key. The syntax script seems to get out of sync,
> >> mistaking the closing quote, comma and opening quote for a "string"
> >> entity (as between val1 and key2 in the provided screenshot).
> >>
> >>
> >> Best regards,
> >> Tony.
> > There is a patch for this reported by mattn few months ago:
> > https://groups.google.com/d/topic/vim_dev/1D-wzFoi3Wo/discussion
> >
> I see no problem highlighting this with the latest syntax/vim.vim, which
> is on my website: http://www.drchip.org/astronaut/vim/index.htm#SYNTAX_SH
> .
>

I just tried the latest astro version, and I still see the bug.  The bug is
that the highlighting is different depending on whether there is a space
after the colons or not.

This bug has been around for a long time.  It's been fixed once or twice,
only to reappear in later editions.

-Manny

-- 
-- 
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: Why isn't shelltemp=0 the default?

[Manuel Ortega]

On Sun, Jul 10, 2016 at 1:23 PM, Bram Moolenaar <b...@moolenaar.net> wrote:

>
> Manuel Ortega wrote:
>
> > On Saturday, June 14, 2014 at 11:51:59 AM UTC-4, Justin M. Keyes wrote:
> > > With shelltemp=0, Vim automatically falls back to using temp files if
> > > pipes don't work. So why isn't shelltemp=0 the default?
> > >
> > > If I understand correctly, 'shelltemp' affects:
> > >
> > > :!
> > > :w !foo
> > > :r !foo
> > >
> > > But it does _not_ affect system(). Is that because it just hasn't been
> > > implemented for system(), or is it a design decision? system() often
> > > has temp file permissions issues on Windows[1][2][3][4], so using
> > > pipes could make system() more reliable.
> > >
> > > Another question. :help 'shelltemp' says:
> > >
> > > The advantage of using a temp file is that the file type and
> encoding
> > > can be detected.
> > > The FilterReadPre, FilterReadPost and FilterWritePre,
> > > FilterWritePost autocommands event are not triggered when
> > > 'shelltemp' is off.
> > >
> > > Is there a technical reason this can't be done?
> > >
> > > Thanks!
> > >
> > > [1]
> https://groups.google.com/forum/#!msg/vim_use/JSXaM9YjWKo/HtHn36WFb_kJ
> > > [2]
> https://groups.google.com/forum/#!msg/vim_use/adD_-9yBCEU/Y0ul-OwXGpYJ
> > > [3] https://github.com/mattn/gist-vim/issues/48#issuecomment-12916349
> > > [4]
> https://groups.google.com/forum/#!msg/vim_use/oU7y-hmQoNc/2qQnkPl6aKkJ
> > >
> > > Justin M. Keyes
> >
> > I would very much like to know the answer to the OP's question, since
> > I would like the ability to force system() to obey 
>
> It's implementation.  system() uses get_cmd_output(), which always uses
> temp files.  Making it use pipes is going to be some work.  And it won't
> be 100% the same, thus it should be enabled explicitly.
>
> There are some subtle differences, but they may cause a hang, thus
> changing defaults isn't a good idea.


I think it should be part of the documentation of system() that it will not
obey   Looking in ':h system()' I see the phrase "Pipes are
not used", but it has the appearance of applying only to the special case
mentioned in the immediately preceding text, namely the case where {input}
is both given and is a list.  It would be clearer if there were an empty
line between "list items converted to NULs)."  and "Pipes are not used".

It should also be part of the docs for  that turning it off will
not affect system().

-Manny

-- 
-- 
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: screen garbled when using execute()

[Manuel Ortega]

On Sunday, July 10, 2016 at 8:49:41 AM UTC-4, Bram Moolenaar wrote:
> Manuel Ortega wrote:
> 
> > I'm seeing some screen rendering problems with the new execute()
> > function.
> > 
> > To reproduce:
> > 
> > vim -u NONE -N somenonemptyfile
> > :echo execute("!ls")
> > 
> > I expect: the same thing that "redir=>h | !ls |redir END | echo h"
> > shows, i.e., ":!ls", except without a HIT ENTER prompt.
> > 
> > I see: ":!ls" and a HIT ENTER prompt, followed by (if I indeed hit
> > enter) a garbled screen that is only fixable by ":redraw!"
> > 
> > Note that I'm much more concerned about the garbled screen than the HIT
> > ENTER (though I don't see why that's there when using execute()). And
> > "ls" is just an example; I know full well that if I really wanted the
> > dir contents this is the wrong way to do it.
> > 
> > The docs say that execute() is the equivalent of "cmd" sandwiched by a
> > manual redir operation.  But the cmd "!ls" sandwiched by a redir
> > operation doesn't result in a garbled screen.
> > 
> > I observe this in both the console version and MacVim.
> 
> Keep in mind that by default execute() works silently.  But an external
> command will still output text.  This is the same as with redir:
> 
>   redir => output
>   silent !ls
>   redir END
>   echo output
> 
> This also messes up the screen.  This is explained at ":help :silent"
> I'll add a hint at the help for execute().  Especially that for an
> external command system() should be used.

Aaargh, I forgot about the "silent" part of execute().  Sorry for the noise.

-Manny

-- 
-- 
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: Why isn't shelltemp=0 the default?

[Manuel Ortega]

On Saturday, June 14, 2014 at 11:51:59 AM UTC-4, Justin M. Keyes wrote:
> With shelltemp=0, Vim automatically falls back to using temp files if
> pipes don't work. So why isn't shelltemp=0 the default?
> 
> If I understand correctly, 'shelltemp' affects:
> 
> :!
> :w !foo
> :r !foo
> 
> But it does _not_ affect system(). Is that because it just hasn't been
> implemented for system(), or is it a design decision? system() often
> has temp file permissions issues on Windows[1][2][3][4], so using
> pipes could make system() more reliable.
> 
> Another question. :help 'shelltemp' says:
> 
> The advantage of using a temp file is that the file type and encoding
> can be detected.
> The FilterReadPre, FilterReadPost and FilterWritePre,
> FilterWritePost autocommands event are not triggered when
> 'shelltemp' is off.
> 
> Is there a technical reason this can't be done?
> 
> Thanks!
> 
> [1] https://groups.google.com/forum/#!msg/vim_use/JSXaM9YjWKo/HtHn36WFb_kJ
> [2] https://groups.google.com/forum/#!msg/vim_use/adD_-9yBCEU/Y0ul-OwXGpYJ
> [3] https://github.com/mattn/gist-vim/issues/48#issuecomment-12916349
> [4] https://groups.google.com/forum/#!msg/vim_use/oU7y-hmQoNc/2qQnkPl6aKkJ
> 
> Justin M. Keyes

I would very much like to know the answer to the OP's question, since I would 
like the ability to force system() to obey 

-Manny

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

screen garbled when using execute()

[Manuel Ortega]

I'm seeing some screen rendering problems with the new execute()
function.

To reproduce:

vim -u NONE -N somenonemptyfile
:echo execute("!ls")

I expect: the same thing that "redir=>h | !ls |redir END | echo h"
shows, i.e., ":!ls", except without a HIT ENTER prompt.

I see: ":!ls" and a HIT ENTER prompt, followed by (if I indeed hit
enter) a garbled screen that is only fixable by ":redraw!"

Note that I'm much more concerned about the garbled screen than the HIT
ENTER (though I don't see why that's there when using execute()). And
"ls" is just an example; I know full well that if I really wanted the
dir contents this is the wrong way to do it.

The docs say that execute() is the equivalent of "cmd" sandwiched by a
manual redir operation.  But the cmd "!ls" sandwiched by a redir
operation doesn't result in a garbled screen.

I observe this in both the console version and MacVim.

-Manny

-- 
-- 
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: A plea against the name "execute()"

[Manuel Ortega]

>
> call and call() are also. But I don't think it makes confusing.


But it does, for new users and people learning VimScript.  I'm not confused
*anymore* about :substitute/substitute(), because I've now done a ton of
vimscripting.  But when I was new, I can't tell you how many times that
messed me up when looking for documentation, and when trying to remember
which one can take which flags.

It's so easy to avoid doing things that confuse people for no good reason.

-Manny

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

A plea against the name "execute()"

[Manuel Ortega]

I don't have positive suggestion for an alternative, but...

Please, please don't name the new function "execute()".  It only breeds
confusion because there is already a command called "execute".  It really
sucks when this happens, like with substitute() and :substitute.  New users
get confused, because ":H substitute" takes one to the docs for the
function, when they are looking for how to use the command.  And there are
differences between the function and the command that become confusing when
they have the same name (like which flags are allowed).  Now with
"execute", the command will let you do a :redir inside it, but the function
won't.

-Manny

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

7.4.1999 brings test failures on Mac OS X

[Manuel Ortega]

`make test` results in the following on OS X 10.11.5, and patch 7.4.1999.
Didn't happen with 7.4.1997.

Executed 101 tests
1 FAILED:
Found errors in Test_evalcmd():
function RunTheTest[9]..Test_evalcmd line 17: command did not fail: call
evalcmd("call NestedRedir()")


>From test_alot.vim:
Found errors in Test_evalcmd():
function RunTheTest[9]..Test_evalcmd line 17: command did not fail: call
evalcmd("call NestedRedir()")

Test results:


>From test_alot.vim:
Found errors in Test_evalcmd():
function RunTheTest[9]..Test_evalcmd line 17: command did not fail: call
evalcmd("call NestedRedir()")
TEST FAILURE
make[2]: *** [report] Error 1
make[1]: *** [test] Error 2
make: *** [test] Error 2

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

Intermittent test failures on OS X 10.11.5

[Manuel Ortega]

Sometimes, but not always (I would say 1 out of 5 times) building and
testing after a `git clean -fdx` results in the following:

>From test_channel.vim:
Found errors in Test_call():
function RunTheTest[9]..Test_call[2]..3_run_server line 37: 'Can''t
start test_channel.py'
TEST FAILURE
make[2]: *** [report] Error 1
make[1]: *** [test] Error 2
make: *** [test] Error 2

I build after configuring with:
--disable-gui
--without-x
--disable-netbeans
--disable-nls

-Manny

-- 
-- 
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 causing display artifacts in the GUI

[Manuel Ortega]

On Wed, Jun 15, 2016 at 10:23 AM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

> 2016-06-15 23:02 GMT+09:00 Manuel Ortega <mannyvim...@gmail.com>:
>
>> On Wed, Jun 15, 2016 at 5:48 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>> I couldn't reproduce the bug with Athena, GTK+ 2, GTK+ 3 GUIs, but did
>>> with MacVim, although I'm not sure which X11 GUI the reporter meant by that
>>> doubly quoted word, "regular."  I wish the description could be more
>>> specific in order to save other devs' time.
>>>
>>> As to the mentioned "-1H", it looked to me that it was part of a piece
>>> of control code with CSI chopped off.  Accordingly, I guessed it's original
>>> form was "ESC|-1H" (= stop highlight forcefully cf.
>>>  screen_stop_highlight() of screen.c).
>>>
>>> Along that line, I dug into the issue and arrived at gui_write() of
>>> gui.c.
>>>
>>> What I found there was, when a given control code had a parameter and
>>> the parameter was a negative integer, the function was unable to handle it
>>> correctly.  IOW, because the minus sign in "-1H" was not considered as part
>>> of an integer by the function and was not handled in the succeeding switch
>>> statement as control code either, "-1H" was eventually passed to GUI as
>>> ordinary text and appeared on the screen.
>>>
>>> The attached patch should fix our own issue I've just described, and
>>> hopefully, resolve the MacVim issue, too.
>>>
>>
>> Thanks for this, I'll test the patch.
>>
>
> Let me know if you find any problem with it.
>
>>
>> I was not more specific about the X11 GUI because, as far as I know,
>> there is only one X11 GUI that works "out of the box" on the Mac: Athena.
>> I've never been able to make the others work.  Even --enable-gui=auto won't
>> work; one has to explicitly request Athena.  So it was with Athena that I
>> got the bug to occur.
>>
>
> I thought you did tests on Linux while I knew you were a Mac user.  Alas,
> then my wording was too harsh to you.  I apologize to you for this.
>

No need to apologize: I'm the one who used the word "regular" to stand for
"the only X11 that works out of the box"  :)

(Seriously, it is weird that --enable-gui=auto doesn't just pick Athena on
a stock OS X machine.)


I found it harder to get it to show its face in Athena than in MacVim.
>>
>
> I think it indicates MacVim is more efficient than the GUIs based on
> general-purpose cross-platform toolkits and thus more faithful to commands
> from the Vim core.  So I don't like to call this issue a MacVim bug but a
> proof of its excellence.
>

I didn't mean to suggest it was a MacVim bug.  I hope it didn't come off
like that.  It looked to me, when I reported the problem, that either this
was a subtle bug in the new  code, or there was some subtle bug
elsewhere that the new  simply uncovered.  Judging from the patch, it
was the latter.

-Manny

-- 
-- 
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 causing display artifacts in the GUI

[Manuel Ortega]

On Wed, Jun 15, 2016 at 10:02 AM, Manuel Ortega <mannyvim...@gmail.com>
wrote:

> On Wed, Jun 15, 2016 at 5:48 AM, Kazunobu Kuriyama <
> kazunobu.kuriy...@gmail.com> wrote:
>
>> I couldn't reproduce the bug with Athena, GTK+ 2, GTK+ 3 GUIs, but did
>> with MacVim, although I'm not sure which X11 GUI the reporter meant by that
>> doubly quoted word, "regular."  I wish the description could be more
>> specific in order to save other devs' time.
>>
>> As to the mentioned "-1H", it looked to me that it was part of a piece of
>> control code with CSI chopped off.  Accordingly, I guessed it's original
>> form was "ESC|-1H" (= stop highlight forcefully cf.
>>  screen_stop_highlight() of screen.c).
>>
>> Along that line, I dug into the issue and arrived at gui_write() of gui.c.
>>
>> What I found there was, when a given control code had a parameter and the
>> parameter was a negative integer, the function was unable to handle it
>> correctly.  IOW, because the minus sign in "-1H" was not considered as part
>> of an integer by the function and was not handled in the succeeding switch
>> statement as control code either, "-1H" was eventually passed to GUI as
>> ordinary text and appeared on the screen.
>>
>> The attached patch should fix our own issue I've just described, and
>> hopefully, resolve the MacVim issue, too.
>>
>
> Thanks for this, I'll test the patch.
>

So far the patch seems to make the problem go away in MacVim.


-Manny

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