Re: The future of the Vim project

[Benjamin Fritz]

On Sun, Aug 13, 2023 at 12:02 PM Christian Brabandt 
wrote:
>
> I haven't seen any complaints/issues for the TOhtml plugin, so I think
> we are good here, even so it may need some love to e.g. support popups
> or virtual text. Not sure if this would be easily addable to a plugin
> (or even makes sense).
>

Easy to add? No, probably not. But I would certainly like to include it
sometime:

  https://sourceforge.net/p/vim-tohtml/issues/29/

Patches welcome, especially if they come with a test so I don't need to
figure out how to do it. :)

I think virtual text and other such text properties should probably be
off by default with an option to turn them on, although that may make
the interaction with various other features more complex.

-- 
-- 
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/CAMaohidqZMhG9jcHUuw8piOODyy%2BOY0_%3Df%2Bk8-YxEEwHxdnuAg%40mail.gmail.com.

Re: Problem with vim.org mailing list aliases?

[Benjamin Fritz]

On Sun, Aug 13, 2023 at 2:51 AM Christian Brabandt 
wrote:
>
>
> Hi Ben,
> I did not see anything from your email, and no messages are pending.
> Don't know what's going on. I suppose you did use your email address
> which which you are subscribed? (fritzophrenic) ? Other than that
> you configured to not get any mail, I don't know what's going on.
>
> FWIW: the vim-...@vim.org should still be aliased to
> vim_dev@googlegroups.com as far as I know.
>
> Best,
> Christian
>

Yes, I just did a "reply all" from the email you CC'd me on. I don't
know why it wouldn't have worked. I copy-pasted my response with a few
minor edits into the web interface just now, since somehow it appears to
have been lost.

-- 
-- 
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/CAMaohidimsBGrOMeutsWuF1V8bE1DKmxei2SpjiuDUyNdLFJYA%40mail.gmail.com.

Re: Updated TOhtml

[Benjamin Fritz]

On Fri, Jan 20, 2023 at 3:57 PM Bram Moolenaar  wrote:
>
>
> Benjamin Fritz wrote:
>
> > This updates the TOhtml changelog to reflect the changes made in the Vim
> > runtime so far in Vim 9.0, and also fixes the new g:html_no_doc and
> > g:html_no_modeline options when generating HTML in diff mode.
> >
> > I have added tests for these new options in my dev repository:
> >
https://sourceforge.net/p/vim-tohtml/code/ci/default/tree/testdir/test_nodoc.vim
> >
> > I'm going to try fixing a couple more known bugs tomorrow and sending
> > another update, but wanted to get this out since it syncs my repo with
the
> > main Vim github changes.
> >
> > Let me know if anything looks off! I've been a bit off the grid lately
when
> > it comes to Vim development, so I'm a bit rusty.
>
> I almost missed this, it somehow ended up in my spam folder.  I'll
> include it now.  You didn't send more recent files in the mean time,
> right?
>

I did not send more recent files yet, thanks for checking. I have work in
progress that I didn't get to finish. I'll aim toward another small bugfix
release by the end of February.

-- 
-- 
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/CAMaohif9zwOtCyQv0PT9QPwHtW%3DfinL-AzF7eZ2hsK0Y8KWfBw%40mail.gmail.com.

Updated TOhtml

[Benjamin Fritz]

Hi, Bram!

This updates the TOhtml changelog to reflect the changes made in the Vim
runtime so far in Vim 9.0, and also fixes the new g:html_no_doc and
g:html_no_modeline options when generating HTML in diff mode.

I have added tests for these new options in my dev repository:
https://sourceforge.net/p/vim-tohtml/code/ci/default/tree/testdir/test_nodoc.vim

I'm going to try fixing a couple more known bugs tomorrow and sending
another update, but wanted to get this out since it syncs my repo with the
main Vim github changes.

Let me know if anything looks off! I've been a bit off the grid lately when
it comes to Vim development, so I'm a bit rusty.

-- 
Ben

-- 
-- 
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/CAMaohieY-%2BNp%3DX0gVwBH7SszC-EMGGvCLzr0pc02kmp4fdb1nA%40mail.gmail.com.
<>

Re: New TOhtml version

[Benjamin Fritz]

On Wed, Nov 20, 2019 at 3:59 PM Bram Moolenaar  wrote:
>
>
> Ben Fritz wrote:
>
> >
> > I didn't check inside the archive that TortoiseHg created for me
> > before sending, I didn't realize the mess it made with the directory
> > tree. Sorry about that. I will be sure to check for that, next time!
> >
> > It does look like the 2html.vim file that was missing from the latest
> > runtime files update is included in the archive, however, so you don't
> > need a new copy.
>
> The version I have now is dated 2018 Nov 11.  Is there a newer one?
>

Yes, the version contained in the archive starts with:

" Vim syntax support file
" Maintainer: Ben Fritz 
" Last Change: 2019 Nov 13

-- 
-- 
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/CAMaohiff08HTdp_W8OSfDmP%3Dw_VQoANK3yJ%3D9Vs5drOJXWPVVQ%40mail.gmail.com.

Re: New TOhtml version

[Benjamin Fritz]

On Thu, Nov 14, 2019 at 3:36 PM Bram Moolenaar  wrote:
>
>
> Ben Fritz wrote:
>
> > Attached is a new TOhtml version to include, which fixes a couple
notable
> > bugs:
> >
> >- Tabstops are now calculated correctly when tabs are intermixed with
> >syntax highlighted groups.
> >- The g:html_prevent_copy option now works again in modern browsers
(and
> >is done in a standards-compliant way instead of relying on
unspecified
> >behavior)
> >- Misc. other minor improvements and bugfixes.
> >
> > Also some new features:
> >
> >- Support for termguicolors
> >- Added TOhtmlProgress highlight group to allow changing the color of
> >the progress bar (it was invisible on some default configurations I
was
> >running in)
>
> I'll include it, thanks.
>

I didn't check inside the archive that TortoiseHg created for me before
sending,
I didn't realize the mess it made with the directory tree. Sorry about
that. I
will be sure to check for that, next time!

It does look like the 2html.vim file that was missing from the latest
runtime
files update is included in the archive, however, so you don't need a new
copy.

-- 
-- 
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/CAMaohidXaGAdip%2BT%3D5N74X7B9QEwBER9S1QABQXx%2BauH7Hv5qQ%40mail.gmail.com.

New TOhtml version

[Benjamin Fritz]

Hi, Bram!

Attached is a new TOhtml version to include, which fixes a couple notable
bugs:

   - Tabstops are now calculated correctly when tabs are intermixed with
   syntax highlighted groups.
   - The g:html_prevent_copy option now works again in modern browsers (and
   is done in a standards-compliant way instead of relying on unspecified
   behavior)
   - Misc. other minor improvements and bugfixes.

Also some new features:

   - Support for termguicolors
   - Added TOhtmlProgress highlight group to allow changing the color of
   the progress bar (it was invisible on some default configurations I was
   running in)

-- 
-- 
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/CAMaohieJu1DJf2WL06iDf7nR_CLq_Ey408epx2jGO41KdKAvUg%40mail.gmail.com.


vim-tohtml_v8.1.2.tar.gz
Description: application/gzip

Looks like Vim Tips wiki is moving

[Benjamin Fritz]

Wikia has a banner announcement on the Vim wiki pages that they're moving
us to a new domain name:

https://community.wikia.com/wiki/Help:Fandom_domain_migration

I assume it will be "vim.fandom.com" but haven't seen that stated
explicitly anywhere yet.

-- 
-- 
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] Patch v8.0.0677 breaks wincmd usage in FileType autocommands (#1839)

[Benjamin Fritz]

> On Sun, Jul 16, 2017 at 10:08 AM, Bram Moolenaar 
wrote:
> > > >
> > > > The resizing should work since 8.0.0688.
> > > >
> > > > If you have remaining problems, please give a reproducible example.
> > > >
> > >
> > > For resizing, if I use "exe 'resize' sizevar", it works.
> > >
> > > If I use "exe sizevar 'wincmd _'" instead, it does not work, I get
> > > "E788: Not allowed to edit another buffer now"
> > >
> > > For determining whether a quickfix window is a location list or a
> > > quickfix list, is there a different way to do that besides
> > > attempting a ":copen" command? I get the same error for that
> > > command, even if I'm already in the quickfix list and therefore it
> > > doesn't even need to switch buffers.
> >
> > Not sure what you are doing, but this works:
> >
> > au FileType qf 20wincmd _
> >
> >
>
>
> I tried that exact command in version 8.0.692 and I get an E788
> message, after starting with "gvim -N -u NONE -i NONE" on Windows 7
> (64-bit).
>
> I will try compiling the latest version to see if that helps, but if
> it's fixed, it isn't version 688 that did it.

I build version 8.0.724 and the behavior of "wincmd _" is now fixed, but
I don't see any patch description that seems to apply between 692 and
724. Any ideas which patch actually fixed it? I'm trying to decide
whether I'm curious enough to try a bisect.

-- 
-- 
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 cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Jun 9, 2016 at 2:56 PM, Charles E Campbell <
drc...@campbellfamily.biz> wrote:
>  if libraries are used, the system may update the library (while one
> is on holiday), potentially rendering encrypted text unreadable.  I know
> that these things should be done in a backwards compatible fashion, but
> Murphy's Law plus having many users guarantees trouble will happen.
>
> I agree that libraries will get better testing, though.
>

Good point. So we should be sure to link statically to the library.

Of course if the system updates to a new Vim we could still have the
problem.

It sounds like once the encryption is finished we should add a reference
version encrypted file to the tests, and test that vim can decrypt it. Then
the test will fail if a library update breaks the decryption.

-- 
-- 
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 cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 10:47 AM, Manuel Ortega 
wrote:
>
> The purpose of *Vim*'s cryptography, as Bram is trying to stress and
nobody seems to ever internalize, is to keep data secret from neighbors and
family members, i.e., people not sophisticated enough or motivated enough
to e.g., realize that it's VimCrypt, find that webpage, know what a perl
script is, know how to apply it, etc.

I disagree. If that's the case, then why did Vim ever get a new cryptmethod
at all? zip is just fine for those purposes.

>  It is pretty clearly implied in ":h encrypt" that the purpose of Vim's
encryption is not to keep data secret from people who even partly know what
they're doing.
>

I disagree here too. In :help encryption I see "The encrypted text cannot
be read without the right key" and "You could do this to edit very secret
text." In :help 'cryptmethod' I see blowfish and blowfish2 described as
"medium strong encryption." Nowhere do I get the impression Vim's
cryptography is not secure enough to keep data secret from people who know
what you're doing. In fact I get the opposite impression, that Vim's
cryptography is probably strong enough for most purposes if you use
"blowfish2".

> For this purpose, it works.
>
> But really: it shouldn't be Vim's job to encrypt files on disk anymore
than it's Vim's job to do compression and decompression.  There are plugins
to use GPG transparently like there are for compressing and decompressing
transparently.
>

And I disagree yet again here. If encryption is not built into the editor,
then you cannot use features like swap files or undo files or you risk
exposing decrypted text in those files. I think it's a great feature to
support encryption in the editor itself to avoid exposing data like that.
Additionally the editor could lock the memory to prevent unencrypted data
in a buffer from getting saved off to swap space. I don't know whether Vim
does that (it probably should), but there's no way you could do that
outside of Vim. So either you need some sort of editor built into your
encryption program with fewer features than Vim, or you need to do the
encryption within Vim, or Vim needs to provide better hooks for external
tools to encrypt in multiple places.

-- 
-- 
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 cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 9:54 AM, Benjamin Fritz <fritzophre...@gmail.com>
wrote:
>
> The help entry blowfish and blowfish2 both say "medium strong
encryption". An "implementation flaw" is mentioned for blowfish, but IIUC
the flaw is severe enough to make it much, much weaker than blowfish2. Why
are they both summarized as the same strength?
>

Ah, I see some stronger warnings in :help encrypt. I think those should be
emphasized more and maybe cross-referenced in the help for 'cryptmethod'.

-- 
-- 
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 cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 6:08 AM, Bram Moolenaar  wrote:
>
>
> Ben Fritz wrote:
>
> > On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar 
wrote:
> > > The original blowfish encryption is not broken, it's just weaker than
it
> > > should be.  It's still a lot stronger than zip.
> >
> > Is it? This page makes it sound like "blowfish" was pretty much
completely
> > broken if you knew any of the plaintext:
https://dgl.cx/2014/10/vim-blowfish
>
> Your definition of broken is wrong.  Broken means it doesn't work at
> all.  e.g., Vim crashes when using it, or when decrypting you can't get
> back the original text.  When do you call a car broken?  When you can't
> drive.  Not when you can't open the window.
>

I call something "broken" when it cannot serve its intended purpose.
Cryptography's purpose is to keep data secret. If that article is correct,
then with "blowfish" (not "blowfish2") there is a trivial attack that can
expose *at least* 64 characters of text in a file without ever knowing the
password. I'm not clear on the details (the article hand-waves a bit) but
potentially the rest of the file may also be recoverable.

If the encrypted file is the basis of a [password manager](
http://www.vim.org/scripts/script.php?script_id=5340) for example, then
this is quite bad. At least the first password is probably compromised if
an attacker gains access to the file.

If anything, this makes "blowfish" *worse* than zip in many scenarios. At
least with zip the attacker needs to work for it.

> > For example, if you had plugin that always writes a predictable header
text
> > to an encrypted file before the actual sensitive data, the attacker
would
> > know some plaintext. I'm certainly not comfortable using "blowfish",
> > knowing it had exploitable flaws fixed in blowfish2. I thought
"blowfish"
> > was just around to let people read their old data (and hopefully
convert to
> > blowfish2).
> >
> > And while I can probably *personally* use a strong-enough passphrase to
let
> > the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it
to
> > anyone else, since I know most people choose passwords that can fall way
> > too fast with modern tools and techniques. I'd consider "blowfish2" to
be
> > broken for *general use* as well since you need a REALLY good password
for
> > it to provide any long-term security guarantees. Once we increase the
KDF
> > iterations sufficiently I would warn when saving in blowfish2 as well,
in
> > favor of the new method(s) using a better KDF.
>
> My favorite example is when I have some text that I don't want my
> neighbor to read.  Any encryption that Vim provides works for that.
>

That's a straw-man argument. You could also do ggg?G to rot13 the buffer
which would keep my neighbor or my kids from reading the file. If that's
not enough then a simple plugin to do a Caesar cipher as a
BufWritePre/BufRead would also do the trick. But nobody would seriously
suggest either of those are secure. Encryption must have a higher standard
than keeping out your non-hacker friends.

The help entry blowfish and blowfish2 both say "medium strong encryption".
An "implementation flaw" is mentioned for blowfish, but IIUC the flaw is
severe enough to make it much, much weaker than blowfish2. Why are they
both summarized as the same strength?

> Also keep in mind that, no matter how strong your encryption is, there
> is always a weak point.  Rembember key loggers?  There never ever is
> 100% reliable encryption.
>
> So please don't overreact.
>

This is true. Neither Vim nor any other encryption tool will protect from a
compromised system. I don't expect Vim to keep me safe from everything. But
I do expect, if I encrypt a file with any modern crypto tool, that I don't
need to worry if that file is snagged off my cloud storage, or someone
steals my USB stick, or something. Representing a crypto implementation as
"secure" when it is trivial to recover some number of bytes in a file is
going to leak someone's sensitive data because they trusted you. I don't
think it's overreacting to say "we shouldn't present weak crypto as strong
enough to keep using".

Maybe "broken" is too changed a word, I'll stop using it. I'll put it this
way:

zip - insecure, all of your file can be recovered with commonly available
tools. Not recommended.
blowfish - insecure, part or all of your file can be recovered with known
methods. Not recommended.
blowfish2 - secure for small files if you use a very strong password and
nobody else has write access.
proposed new methods - secure if you don't use a very weak password like
"123456", "password", or "letmein".

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

Re: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Wed, Mar 23, 2016 at 5:51 PM, Benjamin Fritz <fritzophre...@gmail.com>
wrote:
>
> I thought "blowfish" was just around to let people read their old data
(and hopefully convert to blowfish2).

That reminds me of something else. Why isn't 'modified' set when you change
cryptmethod or the encryption password?

-- 
-- 
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 cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar  wrote:
>
> > Speaking of defaults: I think Vim should default to the strongest
> > method available. I additionally think Vim should warn on saving with
> > a known broken format such as the original blowfish implementation, or
> > the zip algorithm, or even blowfish2 without a decent KDF. Maybe even
> > compile without the broken algorithms altogether unless the user
> > specifically passes --include-bad-crypto to the configure script or
> > something.
>
> This has the danger of writing a file on one system, go on holiday and
> find out you can't open it on your laptop (that actually happened to me).
>

That makes some sense, however it only applies to people who edit the same
file on multiple systems, AND they don't have the same version of Vim on
each of those systems.

If you don't need that capability, having the old broken systems still in
the code makes it too easy to make a mistake that could compromise your
security.

DROWN recently showed some of the problems with keeping older known-broken
crypto code enabled by default. I think it makes sense to keep the code
there for people who deliberately choose to use it. But getting rid of it
by default can potentially remove an attack vector.

At the very least, we should warn when saving in an insecure format.

> I think there should be some number of months between making a new
> method available and making it the default.
>

OK, that's fair.

> The original blowfish encryption is not broken, it's just weaker than it
> should be.  It's still a lot stronger than zip.

Is it? This page makes it sound like "blowfish" was pretty much completely
broken if you knew any of the plaintext: https://dgl.cx/2014/10/vim-blowfish

For example, if you had plugin that always writes a predictable header text
to an encrypted file before the actual sensitive data, the attacker would
know some plaintext. I'm certainly not comfortable using "blowfish",
knowing it had exploitable flaws fixed in blowfish2. I thought "blowfish"
was just around to let people read their old data (and hopefully convert to
blowfish2).

And while I can probably *personally* use a strong-enough passphrase to let
the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it to
anyone else, since I know most people choose passwords that can fall way
too fast with modern tools and techniques. I'd consider "blowfish2" to be
broken for *general use* as well since you need a REALLY good password for
it to provide any long-term security guarantees. Once we increase the KDF
iterations sufficiently I would warn when saving in blowfish2 as well, in
favor of the new method(s) using a better KDF.

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

[Benjamin Fritz]

On Sat, Mar 5, 2016 at 7:27 AM, Bram Moolenaar  wrote:
>
>
> Ben Fritz wrote:
> >
> > For Pathogen, you install by unzipping all files for a plugin, into a
> > directory under "bundle":
> >
> > ~/.vim/bundle/someplugin/plugin/foo.vim
> > ~/.vim/bundle/someplugin/autoload/bar.vim
> > ~/.vim/bundle/someplugin/syntax/beez.vim
> >
> > With packages, the default 'packpath' is the same as runtimepath. The
> > example code creates a ~/.vim/pack/my/always directory. Is "always"
> > synonymous with "someplugin" above? I.e. is "always" what you'd get
> > from cloning an existing plugin not designed specifically for a
> > packages setup?
>
> "always" is just a name.  You got the directory name wrong.  I renamed
> to avoid confusion.  So now for one plugin:
>
> If you don't have a package but a single plugin, you need to create the
extra
> directory level:
> % mkdir -p ~/.vim/pack/my/ever/something
> % cd ~/.vim/pack/my/ever/something
> % unzip /tmp/myplugin.zip
>
> You would now have these files:
> pack/my/ever/something/plugin/foo.vim
> pack/my/ever/something/syntax/some.vim
>

I don't see this reflected in the help yet. I think the name "always" is
fine if it is explained.

I attached a patch that does this explaining and clears up a few other
points of confusion I had.

Also it changes ":loadplugin" to ":packadd" because ":loadplugin" doesn't
seem to exist anymore.

See attached.

> > What's "my" for? Is that the way to package multiple plugins together?
> > Is it necessary or can "someplugin" go directly under "pack"? The help
> > just mentions looking for an "ever" directory, it doesn't talk about
> > any intervening directories.
>
> "my" is the name of the package that you choose.  As the help says:
>
> The directory name "my" is arbitrary, you can pick anything you like.
>

Thanks, that was another point of confusion I had. I didn't even realize
"my" was the package name.

> > You talked about dependencies...with this method, won't you
> > potentially have multiple copies of every dependency, if every plugin
> > that has a dependency defines a package instead to bundle the plugin
> > with all its dependencies?
>
> I would expect people who create several plugins that depend on a common
> library to have one package with all these plugins.
>

Ah, so this would be where true plugin managers come in. A plugin manager
could be expected to track the dependencies between multiple plugins and
create a package for all related plugins in a group.

> > From the help for 'packpath' I expected every directory under ~/.vim
> > and ~/.vim/after to be searched recursively for an "ever" directory. I
> > don't see anything special about the "pack" directory in the help, but
> > just putting a new "ever" directory under my existing "bundles" and
> > moving anything inside doesn't seem to do anything. Is it because I
> > need a "my" directory of some kind? Or is "pack" actually special? How
> > does 'packpath' relate to this?
>
> All packages go under "pack".
>

OK, "pack" was never mentioned explicitly, only in examples, so I described
it as I currently understand it.

Please correct me if I'm wrong.

-- 
-- 
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.
5e39757c53cc6e77635ddfbea0aa9b6a8c0077a4
 runtime/doc/options.txt |  3 ++-
 runtime/doc/repeat.txt  | 33 ++---
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index 09518c0..5945297 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -5403,7 +5403,8 @@ A jump table for the options with a short description can 
be found at |Q_op|.
*'packpath'* *'pp'*
 'packpath' 'pp'string  (default: see 'runtimepath')
{not in Vi}
-   Directories used to find packages.  See |packages|.
+   Directories that are searched for a "pack" directory where |packages|
+   can be added.
 
 
*'paragraphs'* *'para'*
diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt
index 1b9e54f..985ffac 100644
--- a/runtime/doc/repeat.txt
+++ b/runtime/doc/repeat.txt
@@ -419,23 +419,30 @@ Rationale:
 
 A Vim package is a directory that contains one or more plugins.  The
 advantages over normal plugins:
-- A package can be downloaded as an archive and unpacked in its own directory.
-  That makes it easy to updated and/or remove.
-- A package can be a git, mercurial, etc. repository.  That 

Re: Cannot compile gvimext with MinGW after patch 7.4.724

[Benjamin Fritz]

On Mon, Jun 22, 2015 at 11:38 PM, Ben Fritz  wrote:
>
> Today I noticed that I can no longer compile gvimext.dll, due to the code
added in patch 724.
>
> I compile with MinGW as follows:
>
> make -f Make_ming.mak -j%NUMBER_OF_PROCESSORS% GUI=yes FEATURES=HUGE
PYTHON="C:/Python27" PYTHON_VER=27 DYNAMIC_PYTHON=yes DEBUG=yes
LUA="C:/LUA/lua-5.2.3" LUA_VER=52
>
> Leading to the following error:
>
> gvimext.cpp: In member function 'virtual HRESULT
CShellExt::QueryContextMenu(HMENU, UINT, UINT, UINT, UINT)':
> gvimext.cpp:654:6: error: 'MENUITEMINFO' has no member named 'hbmpItem'
>
> Commenting out the if (showIcons) code block at line 651 lets the code
compile, but obviously I'm missing that functionality now.
>

Wow, it's hard to believe this has still not been fixed.

I finally grabbed a git checkout of the Vim source and ran into this again,
because I'd forgotten about my hacked "solution".

The attached patch fixes it in a much better way. For some reason the
makefile for gvimext was omitting _WIN32_WINNT (as suggested by Bram) even
though the makefile for Vim itself sets the value.

I updated the gvimext makefile to more closely match the Vim makefile.

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


fix_gvimext_build.patch
Description: Binary data

Re: How to update with local changes

[Benjamin Fritz]

On Fri, Jan 15, 2016 at 5:08 PM, Pavol Juhas  wrote:
>
>
> I don't know what is the "secret" phase in Mercurial.  It is however
possible to disable "git push" for some specific branch, for example:
>

Phases in Mercurial apply to a changeset. There are three: "Draft",
"Public", and "Secret". The Secret phase prevents that changeset (and all
its descendants) from being pushed. Changesets are created in "Draft" and
automatically move to "Public" if you push them to another repository.
Mercurial's history-editing commands such as rebase will refuse to work on
"Public" changesets, to prevent you from messing with history other people
may have pulled already.

> git checkout -b local origin/master
> git config branch.local.pushremote /dev/null
>
> Branch "local" is now the active branch, and "git pull" would update it
with a new stuff from the master branch on origin.  "git push" would
however not work, because it is set to use /dev/null as its destination.
 (You can still push from the "local" branch, but will need to give it an
explicit destination.)
>

Nice! I'll check that out sometime. I'm very slowly coming up to speed on
git. I think I'm at a point where I no longer *hate* using it.

I still feel like it gets in my way and requires my full attention to use,
though.

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

Should MatchParen plugin restore current window?

[Benjamin Fritz]

Currently the MatchParen plugin distributed with Vim, will automatically
cycle through all windows with :windo, when you use the :NoMatchParen or
:DoMatchParen command.

This causes problems with (for example) the LargeFile plugin from Dr. Chip,
since that plugin calls NoMatchParen *prior to* reading the file, and then
expects the window to remain unchanged.

Should this command save the current window and jump back to it?

Or should that be the responsibility of plugin authors?

-- 
Ben

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

[Benjamin Fritz]

On Mon, Oct 26, 2015 at 4:39 PM, Bram Moolenaar  wrote:
>
>
> Ben Fritz wrote:
>
> > On Sunday, October 25, 2015 at 7:55:29 AM UTC-5, Bram Moolenaar wrote:
> > > *** 94,101 
> > >   The latest news about Vim can be found on the Vim home page:
> > > http://www.vim.org/
> > >
> > > ! If you have problems, have a look at the Vim FAQ:
> > > !   http://vimdoc.sf.net/vimfaq.html
> > >
> > >   If you still have problems or any other questions, use one of the
mailing
> > >   lists to discuss them with Vim users and developers:
> > > --- 98,106 
> > >   The latest news about Vim can be found on the Vim home page:
> > > http://www.vim.org/
> > >
> > > ! If you have problems, have a look at the Vim documentation or tips:
> > > !   http://www.vim.org/docs.php
> > > !   http://vim.wikia.com/wiki/Vim_Tips_Wiki
> > >
> >
> > So, there is still an FAQ that may be good to point people toward:
> >
> >   https://vimhelp.appspot.com/vim_faq.txt.html
> >
> > I think it initially came from the one you removed, actually.
>
> There is another version of the FAQ:
>
> http://vimdoc.sourceforge.net/htmldoc/vimfaq.html
>
> Which one is better?
>

Isn't that just an alternate URL of the same document you already removed?

The appspot version is more recently updated, but I think they both come
from the same original source. Since the appspot version is actively
maintained I like it better :-)

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

[Benjamin Fritz]

On Fri, Sep 25, 2015 at 12:30 PM, Benjamin Fritz <fritzophre...@gmail.com>
wrote:
>
>
>
> On Fri, Sep 25, 2015 at 11:38 AM, Bram Moolenaar <b...@moolenaar.net>
wrote:
> >
> >
> > Why do I keep getting a copy of your message through Hostway?
> >
>
> I don't know, it's not just my emails either. I'm getting annoyed by that
as well. I think somebody must have subscribed some sort of mailing list or
something.

Found it, it's this user:

vps-supp...@hostway.com

Should we ban that address for now, or send them a nice email first
requesting that they change their setup to NOT echo everything back to the
sender?

They are already set as "moderated" so their emails can't be coming from
vim_dev; they must be directed at the sender or something.

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

[Benjamin Fritz]

On Fri, Sep 25, 2015 at 11:38 AM, Bram Moolenaar  wrote:
>
>
> Why do I keep getting a copy of your message through Hostway?
>

I don't know, it's not just my emails either. I'm getting annoyed by that
as well. I think somebody must have subscribed some sort of mailing list or
something.

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

[Benjamin Fritz]

On Fri, Jun 19, 2015 at 5:24 PM, Benjamin Fritz fritzophre...@gmail.com
wrote:

  Coverity should run automatically.  I haven't checked the output
  recently.  There used to be quite a few false positives, maybe it's
  better now.
 
  I'm not sure the Vim results are available to others or can be made
  available.
 

 According to https://scan.coverity.com/projects/241 Vim's last scan was
in 2013.

By the way, that scan had these results:

vim: 302,420 line of code and 0.27 defect density

Defect Density is measured in detected defects per 1000 lines of code. So
Vim has about 3 defects per 10,000 lines of code.

Coverity says projects of similar size have about a 0.5 for defect density
on average. So we're in pretty good shape. :-)

(Just for fun, https://scan.coverity.com/projects/2227 neovim/neovim:
208,104 line of code and 0.43 defect density)

-- 
-- 
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: Crash when new tags file loaded while waiting for tag selection

[Benjamin Fritz]

On Mon, May 4, 2015 at 1:05 PM, Bram Moolenaar b...@moolenaar.net wrote:


 Benjamin Fritz wrote:

  The attached test_vimrc.vim sets up a command that (on Windows)
  generates  a tags file asynchronously and then calls back into Vim using
  --remote-expr to add that tags file to the 'tags' option.
 
  The test_vimrc.vim also sets the 'cscopetag' option to enable selecting
  between multiple tag matches.
 
  After sourcing this test file, I can reliably make Vim crash as follows
  (edit the let ctags_exec line to match your own exuberant ctags path):
 
  1. cd to a project top-level directory with at least one large code
 subdirectory following C/C++ coding practices of having function
 declarations separate from function definitions.
  2. Execute the :Ctags command and wait for it to finish
  3. cd into the large code subdirectory and edit a code file
  4. Go to a function call within the code file
  5. Execute the :Ctags command again, but don't wait for it to finish
  6. Before the tags processing completes, use CTRL-] to select the tag
 for the function your cursor is on (presumably, you will have 2
 matches, one for the function prototype and one for the function
 definition)
  7. Wait for the :Ctags command to finish
  8. Try entering a number to select the tag to jump to
  9. Vim crashes
 
  I'm using gvim 7.4.629 64-bit on Windows 7. I do have a couple custom
  patches applied but nothing affecting tags processing.

 Can someone reproduce it and get a stack trace, so that we know where it
 happens?  Or a valgrind log, might be even better.


Did you need a different kind of stack trace than the gdb bt backtrace I
provided?

-- 
-- 
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: Preparations for moving to github

[Benjamin Fritz]

On Fri, Mar 27, 2015 at 12:18 PM, Bram Moolenaar b...@moolenaar.net wrote:
  Bram, is there a chance you'd be willing to also push to a Mercurial
  mirror using one of the various bridge methods, either automatically
  via repository hook or manually when you push patches to the public
  repo?

 I do not plan to push to more than one repository, as the use is very
 limited.  But if someone wants to setup an automatic mechanism to mirror
 a repository, e.g. on Bitbucket, that's fine.  We can mention this on
 the vim.org pages.  Although using Mercurial to pull from Github is
 likely to work for most people.


What about if you just needed to do a one-time setup, to automatically
push to Hg when you push to your public Git repository, using a
repository hook and one of the bridges?

Then (if you really start using pull requests) you could pull from
either system easily as well.

  If so, are we definitely set on GitHub? Has anyone found a hosting
  site that allows you to have one landing page for both a git and a Hg
  repository?

 Github is preferred by most users.  There is not going to be a place
 that 100% of the users are 100% happy with.  Of course there will be
 some pain when switching over, it is unavoidable.  Also when sticking
 with Mercurial (as I have experienced with Zimbu already).


Github is preferred by most *git* users. Because they already use git
and already have a Github account.

But Github doesn't support Mercurial AT ALL. Sure there is hg-git but it
isn't always smooth, and Hg users will still be limited to git clones on
Github for contributing.

If we use Bitbucket (or another service that supports both), nobody
needs to learn a new tool. And we can combine both repositories together
under one project page. People could clone server-side from either
repository depending on their system of choice, and that decision
wouldn't impact their ability to easily contribute back.

Of course, I suppose we could always link to two sites from one vim.org
page. But I'd rather any Hg repository be just as valid as the Github
one, not some read-only mirror nobody looks at. But it sounds like that
is the way it is heading.

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

Crash when new tags file loaded while waiting for tag selection

[Benjamin Fritz]

The attached test_vimrc.vim sets up a command that (on Windows)
generates  a tags file asynchronously and then calls back into Vim using
--remote-expr to add that tags file to the 'tags' option.

The test_vimrc.vim also sets the 'cscopetag' option to enable selecting
between multiple tag matches.

After sourcing this test file, I can reliably make Vim crash as follows
(edit the let ctags_exec line to match your own exuberant ctags path):

1. cd to a project top-level directory with at least one large code
   subdirectory following C/C++ coding practices of having function
   declarations separate from function definitions.
2. Execute the :Ctags command and wait for it to finish
3. cd into the large code subdirectory and edit a code file
4. Go to a function call within the code file
5. Execute the :Ctags command again, but don't wait for it to finish
6. Before the tags processing completes, use CTRL-] to select the tag
   for the function your cursor is on (presumably, you will have 2
   matches, one for the function prototype and one for the function
   definition)
7. Wait for the :Ctags command to finish
8. Try entering a number to select the tag to jump to
9. Vim crashes

I'm using gvim 7.4.629 64-bit on Windows 7. I do have a couple custom
patches applied but nothing affecting tags processing.

-- 
-- 
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_vimrc.vim
Description: Binary data

linebreak and conceal display problems

[Benjamin Fritz]

I know there have been recent problem with linebreak when combined with
conceal, I think I have found one or two more.

With the attached test.vim file as a .vimrc, enter the following text:

bbeetabtab;tabsome text

The expected output is:

ee--;some text

However, instead of that, I see only:

ee-

Removing the set linebreak line from test.vim shows:

ee;some text

Note there are extra '-' characters added for listchars, and they are the
wrong color.

Removing set nowrap (regardless of linebreak setting) shows:

ee;some text

Note that there are still extra '-' characters, but they are the correct
color now, and the text is not improperly concealed.

I observed this issue in 64-bit gvim 7.4.608 HUGE and also 7.4.552 HUGE
running in Windows 7. I hoped that patches 579 or 587 would fix the issue,
but apparently there are more problems remaining.

-- 
-- 
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.vim
Description: Binary data

shiftwidth() function documentation error

[Benjamin Fritz]

shiftwidth() *shiftwidth()*
Returns the effective value of 'shiftwidth'. This is the
'shiftwidth' value unless it is zero, in which case it is the
'tabstop' value.  To be backwards compatible in indent
plugins, use this: 
if exists('*shiftwidth')
  func s:sw()
return shiftwidth()
  endfunc
else
  func s:sw()
return sw
  endfunc
endif
 And then use s:sw() instead of sw.

I think the else block should be:

else
  func s:sw()
return (sw ? sw : ts)
  endfunc
endif

-- 
-- 
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: improved folding legibility [patch included]

[Benjamin Fritz]

On Fri, Sep 12, 2014 at 11:06 AM, Bram Moolenaar b...@moolenaar.net wrote:

 Thanks, I'll put it in the todo list.  I'll await comments for a little
 while.

I'll try to test it with TOhtml this weekend, since it currently depends on
the fold text to get the fold levels of nested closed folds.

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

CursorLine highlight invisible in DiffChanged areas

[Benjamin Fritz]

I'm not sure if this ever worked, but I noticed today that with
'cursorline' set, there is no highlight on lines that have DiffChange
highlighting.

Moving the cursor to a line without DiffChange highlighting makes the
cursor visible again.

I think this is a bug; it makes cursorline much less useful in diff mode.

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

LUA interface giving me trouble with garbage collection patch

[Benjamin Fritz]

I want to finish up this patch to fix a crash in Vim:
https://groups.google.com/d/topic/vim_dev/dnN58kO5Vg4/discussion

I changed luaV_setref() to return a value if garbage collection cannot
safely proceed.

But, I do not know how to get that return value back to the code
calling it from eval.c, via set_ref_in_lua(). Can someone please
explain briefly how the function calls in the LUA interface work? I
cannot figure out how to get a return value back from lua_call(), in
the C code.

-- 
-- 
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: Fixed crash in garbage collector by removing recursion

[Benjamin Fritz]

On Mon, Jun 23, 2014 at 2:11 PM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:


 Finally, setting references in the LUA interface doesn't currently
 allow aborting for failure using this patch. I could not figure out,
 how to get a return value from lua_call. Can someone familiar with the
 LUA interface code please help with this?


Still an issue. I think maybe I need to try a new thread.


 Thanks for making this patch!

 Did you run the tests under valgrind? That's a very good way to check
 for any memory access problems and leaks.  Instructions are in
 src/testdir/Makefile.  There are a few false positives, compare to a Vim
 without your patch.


I ran the tests (make test, that is) under valgrind. A *few* false
positives?! Almost every test had at least one definite leak in the
output file.

I'm not sure I did it right, I did uncomment this line in the makefile:

+LEAK_CFLAGS = -DEXITFREE

and also the valgrind line from the test makefile.

Then I did make clean, make, make test

I copied off the test directory from before the patch and compared to
after the patch. For most test cases the only differences are in PID,
total heap size, and some address shifting.

For Test 16, there are plenty of differences in the possible leak
stuff. Before the test valgrind reports:

  possibly lost: 1,210,076 bytes in 7,894 blocks

After the patch it becomes:

  possibly lost: 1,224,143 bytes in 8,193 blocks

I'm really hoping that is a bunch of false positives; nothing looked
especially interesting but obviously I didn't take the time to examine
each line in detail. Test 16 is for the secure option which should
have nothing to do with the garbage collection changes, and most of
the supposed problems seem to have to do with the GUI startup.

I also used the makefile as a template to run valgrind on Vim while
running the crashtest.vim script that this patch fixes (after editing
counts to let it run in valgrind in faster than 2 years). The result
is exactly the same as every test except for test 16, except the heap
max size is a whole lot bigger.

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

Fixed crash in garbage collector by removing recursion

[Benjamin Fritz]

The attached patch seems to fix the crash reported here:

https://groups.google.com/d/topic/vim_dev/Nr8Ja4Zjghw/discussion

The fix is simple in concept: any recursive call can be replaced with
an explicit stack to cheat your way into an iterative algorithm. So
that is what I did. I kept the calling structure unchanged, but pass
an explicit stack around for hash tables and lists. If the stack is
non-null, setting the reference just adds an item to the stack instead
of actually dropping into the HT or list to set its children. Setting
the children of a list or HT will continue processing the stack until
the stack is empty rather than only processing one item.

Sourcing the attached crashtest.vim before the patch crashes Vim
every time. After the patch, Vim is busy for nearly a minute, but then
recovers, and does not crash.

Memory use seems to be handled correctly. Looking at the memory column
in Windows Vista's Task Manager, I sourced the script, then did
:unlet dict list to free up the memory created in the script that
still has a reference. Doing this repeatedly gave me the following
memory use:

After :unlet  After :source
29500   174100
16016   173832
29436   175872
20748   174076
32892   180872
24568   173656
31772   180896
27168   175796
33008   182448
27244   175732
33144   181944
28864   177812
34500   182464
28516   176716

As you can see, Vim's memory footprint seems to fluctuate a little,
possibly due to fragmentation or something, but does not continue
definitely growing. I would appreciate if someone tested with Valgrind
or something to make sure.

There are problems remaining.

First, if I don't use :unlet dict list, but instead source the script
again and allow the previous values to be garbage collected, Vim stays
busy for at least an hour. I don't know if it ever finishes because I
killed the process. I used gdb on MinGW to see that Vim DOES get
through the set reference calls in the garbage collector which my
patch fixed; so I expect Vim is busy with the recursive calls to
actually free the garbage-collected memory. These could probably be
fixed in the same way I fixed the reference setting recursion. I think
this deserves a separate patch.

Secondly, the explicit stacks rely on malloc'ing more memory during
garbage collection, to create the stack entries. If this malloc fails,
I have simply abandoned the current garbage collection run without
doing anything. Should this throw a user-visible error? If it happens
too often Vim may run out of memory, it would be good to give the user
an opportunity to save their work and restart Vim gracefully.

Related to this, I wasn't sure whether I needed to reset any of these
values when aborting the garbage collection:

want_garbage_collect = FALSE;
may_garbage_collect = FALSE;
garbage_collect_at_exit = FALSE;

Do any of these need to be set TRUE to allow Vim another try at
garbage collection later?

Finally, setting references in the LUA interface doesn't currently
allow aborting for failure using this patch. I could not figure out,
how to get a return value from lua_call. Can someone familiar with the
LUA interface code please help with this?

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


crashtest.vim
Description: Binary data


iter_GC_set_ref.patch
Description: Binary data

Re: Compile error in Vim 7.4.324 on Solaris

[Benjamin Fritz]

On Tue, Jun 17, 2014 at 10:45 AM, Danek Duvall duv...@comfychair.org wrote:
 Ben Fritz wrote:

 Thanks, that got me further. But the build still fails:

 OLD_PO_FILE_INPUT=yes gmsgfmt -v -o pl.mo pl.po
 headerfield `Language-Team' missing in header
 found 1 fatal errors
 *** Error code 1
 make: Fatal error: Command failed for target `pl.mo'

 No idea; that doesn't happen for me.  I'm using GNU gettext 0.16.1, FWIW.


I can't tell what version of gettext I have, in /usr/bin/gettext,
because it isn't respecting any of -v, --version, -h, or --help.

I do have GNU gettext 0.10.35 as ggettext but I don't see a way to
override gettext like you showed me with msgfmt.

I looked into the configure script, and found the --disable-nls
flag. I'm not sure what this does, but it seemed related to gettext,
so I tried using it.

The build and install both succeeded, and Vim seems to be working as I
need it to.

So what did I cripple by using --disable-nls? Did that just remove
the translations or something?

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

Compile error in Vim 7.4.324 on Solaris

[Benjamin Fritz]

I get this error from both make and make install when building on Solaris:

Processing file zh_CN.cp936.po...
ERROR: Line 2899 (zh_CN.cp936.po): Invalid character found.
*** Error code 2
make: Fatal error: Command failed for target `zh_CN.cp936.mo'

I did notice a few warnings earlier in make about not being able to
convert between encodings for some other language files.

I seem to be able to use Vim fine even after the make install had
this error, but I'm just using the English-language version.

I do see that the $(GUI_BUNDLE) build target is after languages in the
makefile, so I'm a little worried I might be missing something and I
just haven't noticed yet.

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

Cannot build Vim compatible with my version of Windows

[Benjamin Fritz]

I asked this over on StackOverflow [1] and was advised to come here. Hopefully
there are some Windows/Visual Studio experts here who can help.

I am a non-admin user on a Windows 7 (32 bit) computer, and also an admin user
on a Windows 7 64-bit computer. I am trying to build the Vim text editor from
source code to install on the 32-bit machine (to a place I have access, like
C:\Vim).

I have successfully built both a 64-bit and 32-bit version of Vim on my 64-bit
computer. Both of them run fine on the 64-bit computer. I can verify with
dumpbin.exe as detailed at [2] that the 32-bit build really actually is a
32-bit build. Doing :version within Vim while running the 32-bit build also
confirms this.

But when I try running that same executable on the 32-bit machine, I see This
version of gvim.exe is not compatible with the version of Windows you're
running. Check you computer's system information to see whether you need a x86
(32-bit) or x64 (64-bit) version of the program, and then contact the software
publisher. For kicks, I tried the 64-bit build of Vim and got the same message.
I tried setting compatibility mode on the executable before running it, but get
the same result. Additionally, only Windows Server 2008 and a few version of
Windows Vista appear in the list of compatibility modes: I was going to try
Windows XP but it does not appear in the list. I actually discovered this by
running the compiled install.exe, but Vim itself does the same thing.

Now, when I download an installer from cream.sf.net instead of trying to build
my own Vim, Vim installs fine and then launches fine. Furthermore, I can see the
full list I originally expected in the compatibility mode list of the installed
executable. So I must be doing something wrong when I build.

The only difference I can think of, aside from running from a packaged
installer, is that I'm compiling on a 64-bit machine, and using Visual Studio
2010 rather than Cygwin to build. But it is very strange that neither the 32-bit
nor the 64-bit build works; I would always expect at least one of them to work!
What could I be doing wrong?

[1] 
http://stackoverflow.com/questions/23478373/this-version-is-not-compatible-with-the-version-of-windows-youre-running
[2] 
http://blogs.technet.com/b/windowshpc/archive/2009/03/27/how-to-tell-if-a-exe-file-is-a-32-bit-or-64-bit-application-using-dumpbin.aspx

-- 
-- 
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: Concatenate two performed actions into one (to make it repeatable by '.' and undoable at once)

[Benjamin Fritz]

On Sat, Apr 5, 2014 at 4:09 PM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:

 On Saturday, April 5, 2014 2:02:23 PM UTC-5, Bram Moolenaar wrote:
 
  You can record into a register and replay that.
 

 This is not an option for the desired use case, of creating a plugin
 to automatically insert closing parentheses and the like as you type
 the opening character. For that we need to be able to move the cursor
 in insert mode without breaking undo and without knowing in advance
 that we need to be recording a macro. One cannot start recording a
 macro with a mapping, 'q' does not function in a mapping according to
 the help. So the user would manually need to start recording before
 typing every single time, so mapping every insert-mode entry key would
 not only be annoying, it wouldn't work. Plus, one would want a plugin
 such as this to be itself recordable in a macro, which can't be done
 if you must record a macro to accomplish the task.

 I have no clue how you could repeat the changes a plugin makes with ..
 The plugin could do anything, with any kind of advanced logic.  How
 would . know what to repeat?  It can't possibly know that you inserted
 ) in a specific place and repeat that.


Well at least we could join the undo sequence so u/C-R work properly
afterward. Potentially repeat.vim can help here.

I know that by abusing setline() in previous versions of Vim,
delimitMate and other plugins managed to get this working.

But now nobody seems to have found a working hack.

It would be better to support it intentionally. For example, with an
insert-mode command to chain two changes together.

:undojoin works for arbitrary ex commands. Why can't we have something
similar for insert mode segments?

-- 
-- 
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: Issue 28 in vim: out of the box, gVim 7.3.46 for Win32 cannot write swap files on Windows 7

[Benjamin Fritz]

On Mon, Dec 2, 2013 at 12:14 PM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:

 On Wednesday, November 13, 2013 10:39:10 PM UTC-6, v...@googlecode.com wrote:
  Comment #12 on issue 28 by fritzoph...@gmail.com: out of the box, gVim
 
  7.3.46 for Win32 cannot write swap files on Windows 7
 
  http://code.google.com/p/vim/issues/detail?id=28
 
 
 
  This patch will use environment variables for the temp directories for
 
  both 'directory' and 'backupdir' options.

 Hi, Bram. I didn't see this patch mentioned in the recently updated todo.txt.

 Did you miss this or decide not to include it?

 Wasn't there another patch for the same problem?
 Or was that just for the installer?


The installer patch made it so the shortcuts created by the installer
start in a directory where the user has write access.

But you can still launch Vim from a different directory if you don't
use the shortcut. For example, from a cmd.exe prompt in the Program
Files or Windows directories.

So this patch makes Vim use $TEMP and $TMP environment variables for
swap and backup files before the hard-coded C:\TEMP and C:\TMP which
don't exist on recent versions of Windows. Thus there should always be
a writable directory usable for swap and backup files. Previously only
the hard-coded values were used.

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

Re: Issue 28 in vim: out of the box, gVim 7.3.46 for Win32 cannot write swap files on Windows 7

[Benjamin Fritz]

On Mon, Aug 12, 2013 at 2:04 AM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:

 On Sunday, August 11, 2013 12:52:16 PM UTC-5, v...@googlecode.com wrote:
  Comment #7 on issue 28 by brammool...@gmail.com: out of the box, gVim
 
 When I launch a newly installed Vim with no files, it always launches
 in C:\Program Files (x86)\vim or something like that, which is not
 writable unless you run Vim elevated with admin privileges.

 How do you launch Vim?  Do you really mean Vim or gVim?  I suppose gVim,
 since from a console you always have a current directory.


Yes, I mean gvim, sorry.

 Since the
 directory is not writable, it falls back to C:\Temp or C:\TMP which
 does not exist. Vim should use $TEMP and $TMP instead. These go
 somewhere under C:\Users\yourusername on Windows 7.

 I don't think that $TEMP is a good default current directory.  The
 desktop isn't so bad, although $HOME is probably what most people
 expect.  Obviously this only matters if you do :w file.


I don't want $TEMP as the default current directory.

But the 'directory' option, controlling the swap file, should contain
$TEMP instead of C:\Temp.

On Windows XP and before, $TEMP is defaulted to C:\Temp. But it can be changed.

On Windows 7 (and maybe Vista, maybe 8, I don't know) C:\Temp does not
exist at all unless the user creates it. $TEMP defaults to
C:\Users\johndoe\AppData\Local\Temp

The user should always have write access to $TEMP, and that's where
Windows expects temp files to go, so it is a GOOD place for swap
files. Especially when the current directory is not writable.

Since C:\Temp does NOT exist by default, it is a BAD fallback for swap files.

 The main problem is: How can Vim know that the current directory is not
 given by the user?


Forget about current directory. The only reason it matters for this
discussion, is that the 'directory' option contains it by default, and
it's easy for that to be a non-writable location on properly
configured Windows. The problem is bad hard-coded paths in 'directory'
which should be found from environment variable instead.

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

Re: Improving vim startup time for very large files

[Benjamin Fritz]

On Wed, Jul 17, 2013 at 10:49 AM, Mike Williams
mike.willi...@globalgraphics.com wrote:

 Does anyone have hard numbers?  I have just loaded an ~900MB PDF file in ~7s
 (Win7 x64, 8GB, Core2Duo 2.3GHz), my normal VIM config (although I do have
 maxmem always set to maximum).

Now try writing it. I suppose if Vim is only being used as a viewer
this might be a non-issue, but I discovered the problem when trying to
create a file with a huge number of lines to test how Vim responded
to...something. I don't exactly remember what I was trying to test,
only that I gave up on having Vim create the file and instead did it
using command-line tools (a huge pain on Windows), and then eventually
gave up on testing in general because Vim was taking so long to
manipulate the file.

 First time to load the file took an age
 (40s) due to loading it off disk

That sounds about right. Or maybe longer.

 - once it is in the OS file cache
 restarting vim to read the file was quick (I'd expect some delay with such a
 large file).  Is this the sort of pattern you are seeing?


I don't recall.

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

'autochdir' causes setbufvar() to change directory

[Benjamin Fritz]

Eric Van Dewoestine found this while investigating an eclim issue I was
having.

When 'autochdir' is set, calling setbufvar() changes Vim's current
directory to that of the buffer having its variable set. I think this
should not happen.

Reproduced using the following on Solaris with Vim 7.4a.6, and also on
Windows (slightly modified) with Vim 7.3.822.

mkdir test1
mkdir test2
touch test1/test1.txt
touch test2/test2.txt
gvim -N -u NONE -i NONE test1/test1.txt test2/test2.txt

:set autochdir
:pwd
/accts/btfritz/temp/test1

:call setbufvar('test2', 'myvar', foobar)
:pwd
/accts/btfritz/temp/test2

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

Re: Breaking undo in Insert mode

[Benjamin Fritz]

On Thu, Jul 11, 2013 at 10:36 AM, Ben Fritz fritzophre...@gmail.com wrote:
 On Thursday, July 4, 2013 4:44:26 AM UTC-5, Bram Moolenaar wrote:

 Perhaps we can somehow detect that CTRL-R = had the side effect of

 changing the text and then split undo.  When it only returns the text to

 be inserted, there is no need to split undo.


 Even though it won't fix it all the way, I think this is a good idea. It will 
 make things a lot better at least.

 Then we can do this obviously simplified example without breaking undo:

 inoremap Space C-R=\LTSpaceCR

Wasn't this supposedly fixed?

7.3.1290 (after 7.3.1253) CTRL-R = in Insert mode starts new insert

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

Re: Breaking undo in Insert mode

[Benjamin Fritz]

On Tue, Jul 9, 2013 at 5:54 AM, Bram Moolenaar b...@moolenaar.net wrote:

 That can be done by returning cursor key sequences.  No need for
 setline():

 imap ( C-R=LeftParen()CR
 fun! LeftParen()
   return ()\Left
 endfun
 imap ) C-R=RightParen()CR
 fun! RightParen()
   return \Right
 endfun


I don't remember how setline() solves the problem, but just returning
cursor sequences doesn't work, because it breaks undo/redo/repeat.

If I insert abc(123) with mappings like, then press '.' somewhere
else, I will only get the 123 inserted. Pressing 'u' after inserting
abc(123) + 456 will only undo the  + 456.

The mappings that used to work to get around this are complicated;
hence the reason I'm using a plugin instead of simple mappings; but
previously somehow using setline() allowed all of undo, redo, and
repeat to work as if there were not any mappings. Now only repeat
works.

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

Re: Breaking undo in Insert mode

[Benjamin Fritz]

On Thu, Jul 4, 2013 at 4:44 AM, Bram Moolenaar b...@moolenaar.net wrote:
 Does the delimitMate return the text to be inserted or does it use
 setline()?  In the last case it can't be fixed really.


It actually uses setline().

I think we might need a new (intentional) feature that allows moving
the cursor in insert mode without breaking undo, or, something like
undojoin that allows chaining the next insert with this one.

Basically I want something that allows mappings like here:

http://vim.wikia.com/wiki/Automatically_append_closing_characters

to not break the undo sequence.

At least, delimitMate still doesn't break repeating with '.'; only undo/redo.

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

Re: Breaking undo in Insert mode

[Benjamin Fritz]

On Mon, Jul 8, 2013 at 1:59 PM, Bram Moolenaar b...@moolenaar.net wrote:

 Benjamin Fritz wrote:

 On Thu, Jul 4, 2013 at 4:44 AM, Bram Moolenaar b...@moolenaar.net wrote:
  Does the delimitMate return the text to be inserted or does it use
  setline()?  In the last case it can't be fixed really.

 It actually uses setline().

 Why?  What does it do that can't be done by returning a string?


Type:

iabc(

get (where | is the cursor):

  abc(|)

now continue typing 123) + 456;

get:

  abc(123) + 456;|

Note how the parenthesis got inserted automatically, but manually
entering ) did not insert a second ) but rather moved the cursor over
the existing one.

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

[no subject]

[Benjamin Fritz]

I use the delimitMate plugin by Israel Chauca Fuentes:

  http://www.vim.org/scripts/script.php?script_id=2754
  https://github.com/Raimondi/delimitMate

I found this plugin to be the best at automatically inserting the
closing character for paired characters like (..), [..], etc. It is
customizeable, and until recently, did not affect undo/redo/repeat.

But, this plugin uses setline() internally, taking advantage of the
bug fixed recently, that calling setline() in insert mode does not
break the undo sequence. So, in Vim 7.3.1169, I can type the following:

  aone two threeEsc

Pressing 'u' would undo the entire insertion. With 7.3.1298, pressing
'u' removes each word individually, because Space triggers some logic
in delimitMate.

It is even more annoying when delimitMate actually inserts anything.
Typing the following with delimitMate installed:

  aone two(threeEsc

Will actually insert the text:

  one two(three)

So far, so good. Pressing '.' to repeat likewise still works. But when
pressing 'u', in 1169 the entire insert is undone. In 1298, the first
press gets rid of three) and the second press gets rid of the rest.

Similar problems also occur when using the mapping to skip past an
existing ) instead of inserting a new one when pressing ) in insert
mode.

I think, what is needed, is a method in insert mode, to insert text
after the cursor and/or move the cursor, without breaking the undo
sequence. The setline() thing was always a hack, I admit.

Oddly it looks like Israel's name is on the 7.3.1200 issue description,
so presumably he's aware of this. But the latest version of his plugin
from GitHub breaks as described. And honestly I think it somewhat
strange that I need a complicated plugin using setline(), etc. to avoid
breaking undo/redo for something as simple as inserting an extra ) while
typing in insert mode, or moving the cursor beyond the ) when typing a
new one.

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

Re: Building with Python 2 and 3

[Benjamin Fritz]

Back on-list.

I should mention, autoconf --version prints Autoconf version 2.13.

The default src/auto/configure script works in revision 1169, however,
so I don't really NEED to resolve any make autoconf issues.

On Wed, Jun 12, 2013 at 10:20 AM, Benjamin Fritz
fritzophre...@gmail.com wrote:
 On Tue, Jun 11, 2013 at 4:59 PM, Andrei Olsen andrei.ol...@gmail.com wrote:

 Weird. It doesn't fail here with Autoconf v2.68. Does it fail with unpatched 
 file too or just with patched?



 make autoconf from the 'src' directory gets the command failed for
 target `autoconf' message on unmodified 7.3.1169.

 I thought at first maybe it had something to do with some file or
 another not having the execute bit set, because with the other couple
 versions I unzipped on Windows. But with 1169 I unzipped on the
 Solaris machine with the unzip command, and all the configure
 scripts anyway already had the execute bit set when I did it that way.
 Still...is there a list of files somewhere that need the execute bit
 set? Maybe one or two don't have it.

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

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

Re: Building with Python 2 and 3

[Benjamin Fritz]

On Tue, Jun 11, 2013 at 1:29 PM, Andrei Olsen andrei.ol...@gmail.com wrote:
 On Tuesday, June 11, 2013 5:42:08 PM UTC+2, Ben Fritz wrote:
 On Monday, June 10, 2013 8:26:57 PM UTC-5, Andrei Olsen wrote:
  Also, though unrelated to this problem, older GCC compilers (version  4) 
  do not accept -pthread on Solaris, so to add support for multithreading 
  using the POSIX threads library we need to use -pthreads.
 
  I added a fix for this as well.

 Hi! I tried using the patch (applied against 7.3.969) to get the -pthreads 
 fix you provided.

 The patch applied (with offsets) and I did make autoconf from the src 
 directory, but I get:

 configure.in:995:AC_MSG_RESULT(no); LIBS=$libs_save_old
 configure.in:999: AC_MSG_RESULT(no)
 *** Error code 1
 make: Fatal error: Command failed for target `autoconf'

 I can't figure out the problem.

 It wasn't caused by the patch, I get the same message (with different line 
 numbers) without the patch applied. Any ideas how to get around this?

 This should do it for 969.

Nope, thanks though. This patch applies without offsets at least, but
when doing make autoconf I still get a generic command failed
message.

I attached the full output this time.

Something I notice that looks weird in configure.in is this check:

if test X$PYTHON_CONFDIR = X; then
AC_MSG_RESULT([can't find it!])
else

Vim highlights everything after the ' in can't as a string, up to a
couple lines down where there is another apostrophe (in a comment?).
sh syntax is quite foreign to me at this point I'm afraid, this may be
perfectly valid syntax and Vim is highlighting wrong.

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




make_autoconf.out
Description: Binary data

Re: [regression after update 7.3.{865,969}] [patch] :wviminfo! writes only new history entries, misses old entries read by :rviminfo!

[Benjamin Fritz]

On Thu, Jun 6, 2013 at 2:37 PM, Roland Eggner ed...@systemanalysen.net wrote:
 Hi Ben!

 On 2013-06-06 Thursday at 07:27 -0700 Ben Fritz wrote:
 On Thursday, June 6, 2013 3:08:24 AM UTC-5, Roland Eggner wrote:
  … …
  I reported not clearly enough, I am afraid.  There are 2 probably related 
  bugs:
 
  (1)  Commit “7.3.880  Problem:  When writing viminfo, old history lines may
  replace lines written more recently by another Vim instance.  Solution:  
  Mark
  history entries that were read from viminfo and overwrite them when 
  merging with
  the current viminfo.” turned the viminfo feature effectively to a 
  “vimforget”
  feature.  The patch provided below reverts this.

 Certainly not the best solution.

 The patch may have broken :wviminfo, but the normal method of writing and
 reading viminfo (on Vim enter and exit) is much more useful after the patch.

 May I assume, your certainty is based on a test of my patch in a setup 
 following
 the description I provided together with the patch?  What particular
 shortcomings did you encounter?


I must have misunderstood your patch. You said your patch reverted the
history-preserving change. I had the impression from your description
that this is the only change you made. I did not apply and test the
patch. I thought for some reason you were fixing :rviminfo and
:wviminfo at the expense of the normal method, or were getting rid of
the changes that allowed history to be merged instead of overwritten.
These were the concerns I meant to raise. If this is not the case,
then you may ignore my previous message.

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

Re: FW: use of vim signs

[Benjamin Fritz]

On Mon, Jun 3, 2013 at 3:45 PM, ZyX ZyX zyx@gmail.com wrote:


 The basic idea of having an issue tracker is that *all* bugs, feature
 requests and pull requests (PR's) go there.

Yes, if the developers decide they're worth doing anyway. It would
replace the TODO list.

 Thus you don't need to sync
 anything since there is nothing to sync with. I.e. switching to issue
 tracker means shutting down vim-dev mailing list.

No. Some projects (TortoiseSVN for example) require that all issues be
vetted on a mailing list before they go in the bug tracker. Entering a
bug in the tracker without agreement on the mailing list means the bug
gets rejected without inspection. Then only relevant information to
resolving or reproducing the bug goes in the issue tracker. Discussion
about how to fix the bug (or whether to fix it) can go on in the
mailing list. Many projects have a mailing list as first contact, and
then the response is not I'll add it to the TODO list, it is filed
as bug ID 123456.

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

Re: modeless-selection distorts all characters in gVim

[Benjamin Fritz]

On Wed, Apr 17, 2013 at 4:20 PM, Dimitar DIMITROV mitk...@yahoo.fr wrote:

 Dimitar wrote:

 On Wed, Apr 17, 2013 at 11:06 AM, Ben Fritz fritzophre...@gmail.com
 wrote:
 
  See image attached to my next message for what I see.
 
  And please bottom-post.
 
 Thanks Ben, can't see clearly your image but maybe indeed the bug was
 fixed in your version. Here is what I see (attached image)


Thanks for sending the screenshot. I don't see character distortion,
so I assume you're talking about the partial white background on some
of the letters.

So, it looks to me like the following is a description of your problem:

1. You launched gvim 7.3.409 on  operating system.
2. You entered :e and then stayed in command-line mode
3. You selected some text *in the buffer* with the mouse
4. You see white backgrounds under some of your black letters within
the selection

Is this a correct problem description? If so, WHAT OPERATING SYSTEM
ARE YOU USING? I don't see your issue still in Windows 7.

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

Re: modeless-selection distorts all characters in gVim

[Benjamin Fritz]

On Wed, Apr 17, 2013 at 11:06 AM, Ben Fritz fritzophre...@gmail.com wrote:

 See image attached to my next message for what I see.

 And please bottom-post.


Image attached.

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


attachment: vim-modeless-selection.PNG

Re: Runtime file updates [Was: Re: Typo in help file]

[Benjamin Fritz]

On Friday, April 5, 2013 3:16:54 PM UTC-5, Bram Moolenaar wrote:
 Ben Fritz wrote:
 
  I'd like to take this one step further. The runtime files are already
  largely maintained by people other than Bram. Bram, would you be
  opposed to using Mercurial to PULL changes to runtime files, from a
  separate public clone of the main Vim repository? Runtime file
  maintainers who like, could then maintain their files directly in a
  clone of the Vim repository and push to the vim-runtime repository
  whenever they have a version ready for release.
 
 The current method is working quite well. There is not much overhead
 for me. Only disadvantage is that you get ten updates at the same time,
 every two weeks or so. I don't think the version history is interesting
 enough that someone misses it.


Obviously if it doesn't work for you, then it doesn't work.

But, while the current method works great for you, it's not as nice for the
maintainers.

Conceptually, all the runtime files are part of Vim. They should be
maintainable within a clone of the Vim repository. New potential
contributors who want to change something should be able to get a clone of
the Vim repository and start hacking. If every maintainer works in their own
little custom repository it causes headaches in merging later.

If a maintainer DOES choose to edit their files in a clone of Vim's
repostory, they face the problem that none of their commits will ever be an
ancestor of any commits on trunk. So they will have their own personal
branch forever. I've made my branch explicit in my clone for TOhtml to make
things easier to keep track of, but it is still quite annoying when I go to
make an update after a long absence, because I need to merge in a bunch of
files from the default branch, even though the TOhtml files I'm pulling in
are identical (minus timestamps).

Finally, as Ingo points out, tracking what changed in any given runtime
update is tricky. This would be easier if you could see the history. I DO
think the history is interesting, and I don't think anything would be lost
by showing it, warts and all as Mercurial types like to say. You would
still presumably tag each C code update, and would pull/merge runtime
updates in batches, so the main line of the default branch would remain
much the same as it is now. The only difference is that runtime updates
would have a second parent which could be examined to see what changed and
how.

 A new method with a repository has many new problems:
 - How to control access to the public repository? Only the actual
 maintainer must be allowed to check in changes. So we need a small
 group of people to maintain the access rights.

I was thinking that a small team of only a few people would control the
public vim-runtime or vim-unstable or whatever repository. They get changes
from maintainers on vim_dev and do a quick review before pushing to the
repository. Maintainers could email files as they have been doing, but would
be encouraged to set up a clone of the vim repository as well so that the
vim-runtime admins can just pull the changes with Mercurial as well.

 - What if the maintainer can't be reached? This happens a lot.

This is a separate problem that happens now as well. I don't see using
Mercurial causing any additional problems in this area. And it could make
things better. Some maintainers might opt for a more team-maintenance mode
for their files so that if they don't respond for a while, important patches
like the 'cpo' handling can be applied without them. Other maintainers might
drop out for a while, but will easily be able to see what changes have been
made and against which version of their files when and if they come back.

 - I still need to pull for changes once in a while, it is unlikely this
 will happen more often than what happens now.

That's OK. If users are interested in getting changes faster, they can pull
them into their own private repository clone. Otherwise, they can wait for
your blessing on a stable version. Right now there is no way for users to
get changes faster unless the maintainer CCs vim_dev when sending you a new
version.

And I agree with Ingo here, I don't care as much about the speed of updates,
as I care about being able to see quickly what happened in those updates.
Currently when you push a set of revisions, I glance at the commit log for
each C code change, but I then go into every runtime file of interest to me
and examine the changes to figure out what happened there. You could make
this a lot better by writing brief summaries of the content of those runtime
updates.

Since Vim is already developed in Mercurial, I think it would be less work
for you to just make the changelog of the runtime files visible to anybody
interested in what changes were made and why.

 - The version in the public respository will differ from what I have. I
 often reject new files or new versions of a file because it contains
 mistakes.

It may differ somewhat, but if you make 

Re: [patch] Handle files with mixed LF - CRLF line endings when doing tag search

[Benjamin Fritz]

On Wed, Apr 3, 2013 at 5:22 AM, Lech Lorens lech.lor...@gmail.com wrote:

 On 02-Apr-2013 Ben Fritz fritzophre...@gmail.com wrote:
  On Monday, April 1, 2013 11:43:38 AM UTC-5, Bram Moolenaar wrote:
  
   I wonder how many users actually run into files where only some lines
  
   end in a CR. I would consider such a file broken, and first thing would
  
   be to strip them all off.
  
 
  It's quite frequent where I work. I even have an autocmd that reloads the
  file in DOS format if it detects mixed line endings. It sets nomodified
  but doesn't save, so if I don't make any further changes, the file on-disk
  remains unchanged.

 But it is a kind of a half-solution.

Agreed. And I didn't create the autocmd for this particular problem, I created
it because I was tired of seeing ^M characters in my file. My first attempt
was to use syntax highlighting to just hide them but special character
highlighting prevented that from working.

 When you modify a single line in
 the file and write it, you end up with a number of changed lines.

Yes, but I think I made my autocmd smart enough to use whichever fileformat
will change the fewest lines.

 How do
 you cope with that? In this case I can't simply check in the file
 – I have to undo the line endings modifications which is quite a tedious
 and annoying task.

I do just check in the file, without undoing the line ending modifications.
Where I work we're only really concerned that all changes get peer reviewed.
Plus, a good external diff tool will be able to ignore line ending changes.
Maybe that doesn't work for you.

 I'll be extremely happy to get a hint how I should go about this
 problem.


The best solution is probably to get everybody on your team to use a
consistent file format. But I agree Vim should not choke because they don't.

  The problem is that many other editors, including Visual Studio and
  UltraEdit, may read in Unix file format correctly, but depending on
  how they are configured, will insert Windows line endings on any *new*
  lines. UltraEdit will even preserve line ending style of any
  copy-pasted text. That *sounds* like a feature but in reality it is
  incredibly annoying.

 I beg to differ. In my opinion the real problem is that Vim refuses to
 cooperate. The compilers can deal with it, ctags and cscope can deal
 with it, all other editors can deal with it[1]. Vim can't and now that I'm
 trying to make Vim more friendly, I hear Vim is fine and I should fix
 the files. Vim may be my favourite editor but – sorry – in this
 particular case it is inferior to everything out there.


I may not have been clear. I meant the source of the bad files was other
editors acting stupidly. Vim could handle things fine if those editors would
just save the file in a consistent format, or allow you to see that the lines
are not consistent, as Vim does.

I think Vim should accept the output of stupid editors without jumping through
hoops. I would actually welcome this patch or a similar one. Rather than doing
two searches couldn't we just always insert \r\? before the $ in the search
pattern? Like Bram I don't like the idea of two searches whenever a tag is not
found but I doubt very much that an extra single optional character will cause
a big performance hit. Do you really need to match any number of \r
characters?

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

Re: Omnicomplete shows strange behavior when preview window is enabled

[Benjamin Fritz]

On Tue, Feb 12, 2013 at 3:37 PM, Christian Brabandt cbli...@256bit.org wrote:

 On Fr, 08 Feb 2013, Ben Fritz wrote:

 On Friday, February 8, 2013 9:37:18 PM UTC-6, Ben Fritz wrote:
  On Fri, Feb 8, 2013 at 9:32 PM, Benjamin Fritz fritzophre...@gmail.com 
  wrote:
 
   The attached vimrc.vim file (when used as the .vimrc, with no
 
   non-standard plugins), can reproduce the issue on the attached test.c
 
   file with the attached tags file.
 

 Ben, Benjamin,
 can you check, whether this patch fixes the problem for you?

 diff -r ba8835947b8b src/screen.c
 --- a/src/screen.c  Wed Feb 06 19:58:43 2013 +0100
 +++ b/src/screen.c  Tue Feb 12 22:28:06 2013 +0100
 @@ -545,6 +545,10 @@
 }
  #endif
  }
 +#ifdef FEAT_INS_EXPAND
 +if (pum_visible()) /* win_update() might have overwritten the popup menu 
 */
 +   pum_redraw();
 +#endif
  #if defined(FEAT_SEARCH_EXTRA)
  end_search_hl();
  #endif


Yes, this patch works, at least for my toy test case! Thanks!

I don't run self-compiled Vim at work on Windows (at least not yet).
But it certainly acts like the same issue I've reproduced with my toy
example. I did get the toy example by paring down my own Vim config
after all.

 Bram, I think, this patch fixes an issue, that the completion menu is
 not correctly displayed when the preview window is used (and the windows
 are scrolled). It might be possible, that it also fixes those issues
 from the todo list:

 ,
 | popup completion menu closes quickly when there is a fold in the buffer. 
 (Jan
 | Christoph Ebersbach, 2011 Jul 3)
 `


I'm pretty sure it will fix this issue, since that's what I thought
was affecting me.

 ,
 | Completion menu disappears when using 'cursorcolumn'. (Sven-Hendrik Haase,
 | 2011 May 23)
 `


This one I've never seen first-hand.

 But I am not sure, as reproducing the issue seems quite complicated (see
 the long thread on vim_use about how to reproduce it). Do you have more
 infos how to reproduce those issues?

 regards,
 Christian

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

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

Re: Can't paste Unicode Delta symbol (Δ) into vim nor gVim

[Benjamin Fritz]

On Fri, Sep 14, 2012 at 12:56 PM, Tony Mechelynck
antoine.mechely...@gmail.com wrote:

 I know there are sometimes weird transcodings when sending to the list,
 and that the charset in the Content-Type header is not always obeyed. I'm
 sending this message in UTF-8 because its content wouldn't tolerate anything
 else. How do you see the following letters from U+00A0 and above? (I could
 have added more but I thought these ones were enough.) (The names are from
 memory, I didn't cross-check with Unicode.)

 for French:
 é LATIN SMALL LETTER E WITH ACUTE ACCENT
 É LATIN CAPITAL LETTER E WITH ACUTE ACCENT
 ù LATIN SMALL LETTER U WITH GRAVE ACCENT
 Î LATIN CAPITAL LETTER I WITH CIRCUMFLEX
 œ LATIN SMALL LIGATURE OE
 ΠLATIN CAPITAL LIGATURE OE

 for Danish:
 æ LATIN SMALL LIGATURE AE
 Æ LATIN CAPITAL LIGATURE AE
 ø LATIN SMALL LETTER O WITH DIAGONAL
 Ø LATIN CAPITAL LETTER O WITH DIAGONAL

 for Icelandic:
 Þ LATIN CAPITAL LETTER THORN
 ð LATIN SMALL LETTER ETH

 for Spanish:
 ñ LATIN SMALL LETTER N WITH TILDE
 Ñ LATIN CAPITAL LETTER N WITH TILDE

 for Polish:
 ł LATIN SMALL LETTER L WITH BAR

 for Czech, Croatian, etc.:
 Č LATIN CAPITAL LETTER C WITH CARON

 for Esperanto:
 ĉ LATIN SMALL LETTER C WITH CIRCUMFLEX
 Ŝ LATIN CAPITAL LETTER S WITH CIRCUMFLEX
 ŭ LATIN SMALL LETTER U WITH BREVE
 Ŭ LATIN CAPITAL LETTER U WITH BREVE

 for Greek: small letters + space + final sigma, then capitals:
 αβγδεζηθικλμνξοπρστυφχψω ς
 ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ

 for Russian: lowercase then uppercase (with yo after ye and short i after
 i):
 абвгдеёжзийклмнопрстуфхцчшщъыьэюя
 АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ



These all look valid to me both on the list and in GMail. Weird.

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

update help for omnifunc and formatprg

[Benjamin Fritz]

:help 'omnifunc' should include text:

This option cannot be set from a |modeline| or in the |sandbox|, for
security reasons.

to match :help 'completefunc' (experimentation shows this is true for
'omnifunc' as well, thankfully).

Similarly, :help 'formatprg' now says:

The expression may be evaluated in the |sandbox|, see
|sandbox-option|.

When it should instead say:

This option cannot be set from a |modeline| or in the |sandbox|, for
security reasons.

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

setting formatexpr from a modeline

[Benjamin Fritz]

I was a little surprised to see that setting formatexpr from a
modeline works, since many other -expr options are disallowed in a
modeline. It looks like this is allowed because Vim remembers it got
set from a modeline and therefore executes it in the sandbox.

But :help 'formatexpr' says:

The expression may be evaluated in the |sandbox|, see
|sandbox-option|.  That stops the option from working, since changing
the buffer text is not allowed.

So, why allow setting formatexpr at all from a modeline? It won't work
properly if it does happen.

On a related note, it might be worth noting for options like
formatexpr and foldexpr which can be set in a modeline but will then
run in the sandbox, that setting it from a modeline WILL cause it to
run in the sandbox, not that it may be evaluated in the sandbox
without any indication of why it would run in the sandbox.

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

Re: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]

[Benjamin Fritz]

On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:

 On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
   How about setting up an independent repo (not a clone) at
   http://vim-runtime.googlecode.com/
   Code license: GNU GPL v2
 
  runtimefiles are all (or better they all should be) licensed under Vim 
  licences.

 Yeah, but Google Code only has a few allowed licenses. Vim License is
 not one of them. Bram has dual-licensed Vim under GPL v2 and Vim
 License to allow putting it on Google Code.

 The dual-license wasn't created for that reason :-).

 I suppose it's OK to list the work as GPL, since it's the more
 restrictive.  Thus stays on the safe side.


My mistake, I thought that was the reason, since it wasn't
dual-licensed to my knowledge until the Mercurial repo. Can you
enlighten us?

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

Re: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]

[Benjamin Fritz]

On Wed, May 23, 2012 at 8:42 PM, James McCoy james...@jamessan.com wrote:
 On Wed, May 23, 2012 at 08:31:48PM -0500, Benjamin Fritz wrote:
 On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar b...@moolenaar.net wrote:
 
  Ben Fritz wrote:
 
  On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
How about setting up an independent repo (not a clone) at
http://vim-runtime.googlecode.com/
Code license: GNU GPL v2
  
   runtimefiles are all (or better they all should be) licensed under Vim 
   licences.
 
  Yeah, but Google Code only has a few allowed licenses. Vim License is
  not one of them. Bram has dual-licensed Vim under GPL v2 and Vim
  License to allow putting it on Google Code.
 
  The dual-license wasn't created for that reason :-).
 
  I suppose it's OK to list the work as GPL, since it's the more
  restrictive.  Thus stays on the safe side.
 

 My mistake, I thought that was the reason, since it wasn't
 dual-licensed to my knowledge until the Mercurial repo. Can you
 enlighten us?

 The old CVS repository shows that the license text was added to
 runtime/doc/uganda.txt back in 2001[0] and it mentioned the GPL dual
 licensing then.

 [0]: 
 http://vim.cvs.sourceforge.net/viewvc/vim/vim/runtime/doc/uganda.txt?r1=1.53r2=1.54;

I did not realize that. What are the reasons, then, for the dual
license? I feel kind of silly for not noticing until we went to the
Google Code repository. I do remember seeing a big licensing
discussion back around that time, where I learned that Google Code
only allows a limited set of licenses, GPL among them, so the fact
that Vim is dual-licensed allowed it to be in Google Code at all. I
guess the change wasn't made for that purpose though. So what were the
reasons, whenever the change was made (for curiosity's sake)?

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

Completion menu closes when it shouldn't

[Benjamin Fritz]

I was trying to reproduce an issue I've been having in a minimal config,
and failed to reproduce it reliably, but ended up finding what looks like
a new issue. Perhaps they are related.

First, the issue I was *trying* to reproduce:

Sometimes while using a completion menu, either Eclim's user-completion
these days, or the built-in omni-completion for C code in the past, the
menu will inexplicably disappear. Completion is still active even
without the menu displayed, as evidenced by:

1. -- User defined completion (^U^N^P) match X of Y displayed at bottom
   of screen.
2. Preview window open with the 'info' element of the current completion
   item (I have completeopt set to menuone,preview).
3. Pressing C-N or C-P or Up or Down changes the preview window
   text and the value of X in the string displayed at the bottom.

This issue seems to occur more frequently if I have multiple windows open
in the same tab page, or if the completion menu is very wide. But today I
encountered the issue with only a single window open.

Sometimes as I cycle through completion items, the completion menu
flashes on long enough to see the color and the text, but too fast to
actually read the text before it goes away.

Now for the problem I could actually reproduce. It is different enough
that I doubt the two are related, but maybe I'm lucky:

Start Vim with gvim -N -u NONE -i NONE. Source the attached script in an
empty buffer and start user completion by pressing C-XC-U. The
completefunc set up by the script will sleep for about a second between
adding matches (calling complete_check() every 250ms). Wait for the entire
list to show up (20 items) and then press Down and Up to cycle through
items in the list. Accept any item, then press ccC-XC-U to clear the
line and try again. This time, don't wait for the full list. Immediately
press Down as soon as the first few entries show up. For me, the first
item in the list is selected and completion ends.

If I use C-N or C-P instead of Up or Down the menu stays open, but
as soon as I use either Up or Down before the list finishes building,
the menu closes with whatever item is currently selected.

I'm on Windows XP 64-bit, using Vim without Cream:

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Apr 30 2012 14:21:53)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-514
Compiled by digitec...@spamdancingpaper.com
Huge version with GUI.

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


testbadcompletion.vim
Description: Binary data

Re: [Patch] Re: 'backupcopy' and Windows Vista symbolic links

[Benjamin Fritz]

On Fri, Mar 23, 2012 at 11:35 PM, David Pope d.e.p...@gmail.com wrote:


 Is there any feedback on this patch, or on the way the fix was presented?
  As I said earlier, I'm new to vim development so I'm all ears.  :)  Is
 there someone I need to direct this patch toward, e.g. someone who deals
 primarily with the Windows version of vim, to get it vetted/updated for
 mainline inclusion?


I'd like to test, but currently the only computers I use are stuck on
Windows XP and I'm not able to. The machine I was using at the time I
originally encountered the issue was a dual-boot Windows Vista/Ubuntu
machine, which now has a bad motherboard.

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

Re: 'backupcopy' and Windows Vista symbolic links

[Benjamin Fritz]

On Thu, Mar 15, 2012 at 2:28 PM, Bram Moolenaar b...@moolenaar.net wrote:

 David Pope wrote:

 On Wednesday, July 20, 2011 3:54:09 PM UTC-4, Craig Barkhouse wrote:

  The mch_is_linked() function in os_win32.c only checks if there is
  more than one hard link (i.e. name) for the file.  It doesn't check
  if the file is a symbolic link.  By contrast the Unix code does
  check if the file is a symbolic link.
 
  Sounds like a TODO item.

 Hello all, did this ever get turned into a TODO item?  I've
 encountered this myself (I'm syncing all my vim configuration across
 machines using Dropbox, with symbolic links for .vim/, .vimrc, and
 .gvimrc).

 I see in the latest Mercurial code that mch_is_linked() still only
 checks for hard links.  If it's not already in someone's TODO bucket I
 can work on a fix.  The APIs are straightforward in the versions of
 Windows that support symlinks; I suspect more of the work will be in
 figuring out how to get that support into vim without breaking binary
 compatibility on older systems.  Would the maintainers be interested
 in seeing a patch for this?

 A patch definitely helps.  And a way to reproduce the problem.


Reproduction is easy.

1. Create a symbolic link on Windows. (e.g. mklink link_path target_path)
2. open the file in Vim
3. write the file from Vim

The symbolic link has been destroyed, now it's a real file separate
from the file it was originally linked to.

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

Re: plugin/tohtml.vim :TOcss command

[Benjamin Fritz]

On Wed, Mar 7, 2012 at 3:28 PM, Benjamin Fritz fritzophre...@gmail.com wrote:
 Also, I mostly do
 development on a branch on a clone listed on Vim's google code site.
 Let me know if you want commit access instead of just mailing patches
 around, I'll probably be pretty liberal about it as long as nobody
 tries to update/establish tagged versions.

 I'd like access.  I saw mentions in the comments about looking at Hg
 logs and history, but never found the URL or name of the clone.  I'll
 look closer at the google code site.  Let me know if you need me to
 send my SSH pubkey or other credentials.

 After some web searching it looks like sadly you cannot add committers
 to server-side clones of a project. You could create a server-side
 clone of my clone and we could pull back and forth as needed, or I can
 create a new full-blown project, but I'd rather go for the former
 option rather than creating a new project on google code or BitBucket.


Oops, I meant to include the clone location:
http://code.google.com/r/fritzophrenic-vim-clone/

And I suppose I should probably move to vim_dev for further development talk.

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

Re: Patch 7.3.443

[Benjamin Fritz]

On Wed, Feb 15, 2012 at 10:54 PM, Bram Moolenaar b...@moolenaar.net wrote:
 Please try the patch below.  I currently do not have a Windows machine
 to try this out.

I feel like an idiot, but I cannot get the patch to apply cleanly; and
importing into mq just says the patch is empty!

Can someone see what I'm doing wrong? I admit I've only successfully
used the command-line patch tool once or twice ever in the past.

F:\Documents\Ben\vimpatch --version
patch 2.5.9
Copyright (C) 1988 Larry Wall
Copyright (C) 2003 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert

F:\Documents\Ben\vimpatch -i ..\vim-patches\bram_bad_shellxquote.diff -p2
missing header for context diff at line 3 of patch
patching file src/misc2.c
Hunk #1 FAILED at 3230.
1 out of 1 hunk FAILED -- saving rejects to file src/misc2.c.rej
missing header for context diff at line 26 of patch
patching file src/option.c
Hunk #1 FAILED at 3935.
1 out of 1 hunk FAILED -- saving rejects to file src/option.c.rej
missing header for context diff at line 61 of patch
patching file src/os_win32.c
Hunk #1 FAILED at 3908.
Hunk #2 FAILED at 3958.
2 out of 2 hunks FAILED -- saving rejects to file src/os_win32.c.rej

F:\Documents\Ben\vimhg revert --all
reverting src\misc2.c
reverting src\option.c
reverting src\os_win32.c

F:\Documents\Ben\vimpatch -i ..\vim-patches\bram_bad_shellxquote.diff -p1
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|*** ../vim-7.3.444/src/misc2.c  2012-01-20 17:15:47.0 +0100
|--- src/misc2.c 2012-02-16 05:34:37.0 +0100
--
File to patch:
F:\Documents\Ben\vimREM convert to unix format in gvim...

F:\Documents\Ben\vimpatch -i ..\vim-patches\bram_bad_shellxquote.diff -p2
patch:  malformed patch at line 12: 3240 

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

Re: Patch 7.3.443

[Benjamin Fritz]

On Wed, Feb 15, 2012 at 12:36 PM, Andy Wokula anw...@yahoo.de wrote:
 So you're saying, we must escape all special characters, INCLUDING
 QUOTES, and surround in parentheses?


 Yes, including quotes!

 That's...special.


 But solves all problems so far.

Yes, but that doesn't mean I need to like it :-P

Bram, you said at one point you don't want to start escaping things.
Specifically, you wrote:

 A command may intentionally use  and | to separate commands.  Always
 escaping them will break this intentional use.

It looks like using parentheses and always escaping everything
(including quotes) allows the intentional use to work. What do you
think of this? If it is an acceptable solution, how should we
accomplish the always escaping? Should Vim automatically escape  
 ( ) @ ^ | and  whenever shell is cmd.exe and shellxquote is ( ? Or
should we add a new option (set by default)?

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

Re: Patch 7.3.443

[Benjamin Fritz]

On Wed, Feb 15, 2012 at 12:36 PM, Andy Wokula anw...@yahoo.de wrote:
 Am 15.02.2012 17:22, schrieb Ben Fritz:

 New settings:
      shellcmdflag: /c
      shellxquote: (
 and escape special chars with `^'.


 So you're saying, we must escape all special characters, INCLUDING
 QUOTES, and surround in parentheses?


 Yes, including quotes!

 That's...special.


 But solves all problems so far.

Parentheses are still weird :-(

C:\eclim-git\eclimcmd /c echo abc)
abc)

C:\eclim-git\eclimcmd /c (echo abc))
) was unexpected at this time.

C:\eclim-git\eclimcmd /c (echo abc^))
) was unexpected at this time.

C:\eclim-git\eclimcmd /c (echo abc^^))
abc)

C:\eclim-git\eclimcmd /c (echo abc^(^))
) was unexpected at this time.

C:\eclim-git\eclimcmd /c (echo ^abc^)^)
abc)

C:\eclim-git\eclimcmd /c (^(echo abc^) ^ ^(pause^))
abc
Press any key to continue . . .

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

Re: Patch 7.3.443

[Benjamin Fritz]

On Wed, Feb 15, 2012 at 1:10 PM, Benjamin Fritz fritzophre...@gmail.com wrote:
 Parentheses are still weird :-(

 C:\eclim-git\eclimcmd /c echo abc)
 abc)


I just realized this one is invalid anyway, since MS says you need to
escape a literal ) and here the user does not

 C:\eclim-git\eclimcmd /c (echo abc))
 ) was unexpected at this time.

 C:\eclim-git\eclimcmd /c (echo abc^))
 ) was unexpected at this time.


Hence, neither of these work. If the user is doing the right thing,
they will have escaped the ).

 C:\eclim-git\eclimcmd /c (echo abc^^))
 abc)


If the user properly escapes the ), Vim will actually execute with ^^^)

 C:\eclim-git\eclimcmd /c (echo abc^(^))
 ) was unexpected at this time.


Again, user ought to have escaped the () to begin with.

 C:\eclim-git\eclimcmd /c (echo ^abc^)^)
 abc)


The above command would result from :!echo abc) so we know quoting works!

 C:\eclim-git\eclimcmd /c (^(echo abc^) ^ ^(pause^))
 abc
 Press any key to continue . . .

And so does the auto-escaping of parens intentionally used for grouping.

I think we should do the auto-escaping, with shellxquote=(, and
additionally add a help note by :! and system() that According to the
Microsoft documentation for cmd.exe, you either need to escape (with a
^ character) any of these characters appearing literally in your
command, or surround them in quotes ():  ( ) @ ^ |. Should we
mention that Vim will escape them again, and also escape ?

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

Re: vimgrep fails when 'autochdir' is set

[Benjamin Fritz]

Thanks, everyone. The curwin-w_localdir variable was exactly what I
was looking for, and the tertiary operator makes it a little clearer
what is going on in the directory restore code.

I took your suggestions and additionally moved the directory restore
calls into the ((un)?load|wipe)_dummy_buffer functions so that it is
easier to maintain in the future, if these functions are used
elsewhere. The root cause of the problem was that many of the
functions from buffer.c called by these dummy_buffer functions were
using the DO_AUTOCHDIR macro, though presumably an appropriately
defined autocmd would do the same thing, so whenever we touch the
dummy buffer we need to restore the directory. Presumably creating a
dummy buffer should never have lasting effects on the current
directory!

Updated patch attached to fix that 'autochdir' causes :vimgrep to
fail, based on 7.3.421. I did have one more question: I noticed that
the pre-existing code dynamically allocates memory of static size
MAXPATHL for both dirname_start and dirname_now. I have kept this and
done the same thing for the restore_start_dir function I added, but I
wonder, is there a reason the path string cannot be stack-allocated
instead? Is it to limit stack size or something, since MAXPATHL can be
somewhat large?

-- 
Ben

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


acd_breaks_vimgrep.patch
Description: Binary data

Re: Synchronizing or merging undo across platforms

[Benjamin Fritz]

On Sun, Nov 27, 2011 at 11:31 PM, Christian Brabandt cbli...@256bit.org wrote:
 Hi Bram!

 On So, 27 Nov 2011, Bram Moolenaar wrote:


 Christian Brabandt wrote:

 
  When using a separate 'undodir' directory to store the undofiles, Vim
  uses the complete path of the file as filename, replacing the path
  separators ('/') by '%'. So far this works as documented by :h
  'undodir'.
 
  Now when using :rundo with a filename, that contains the complete path
  and using '%' as directory separators, those '%' will be replaced by
  the current file name (as documented by :h filename-modifiers) and
  surprise surprise Vim won't be able to read the undofile.
 
  So this is just plain wrong in this case. So here is a patch, that
  fixes that. This applies only to :rundo and I am not sure, whether
  this should also apply to :wundo (I tend not to apply it there) but
  this should be kept in mind.
 
  Bram, please check and apply.

 In most places where you can use a file name % is expanded.  And it's
 also useful, especially in the form %:h to get the directory.

 I don't understand. Using '%' as path separators contradicts the usage
 your pointing out. How am I supposed to :rundo an undofile, that
 contains the '%'-separator?


Wouldn't you just escape the '%' characters? fnameescape() should do
it for you I think. So you should just do:

:exec rundo fnameescape(undofile(@%))

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

Re: patch for Win32 sxq/shcf defaults, and question about option defaults

[Benjamin Fritz]

On Sun, Nov 27, 2011 at 9:18 AM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:


 What is the reason for only updating the default value of options, if
 P_WAS_SET is false? I get that we don't want to override the actual
 value of the option if the user set it to something, but don't we want
 to update the default value? E.g. shouldn't we do something like this,
 throughout option.c?

       int     idx3;

       idx3 = findoption((char_u *)shcf);
 -     if (idx3 = 0  !(options[idx3].flags  P_WAS_SET))
 -     {
 -         p_shcf = (char_u *)-c;
 -         options[idx3].def_val[VI_DEFAULT] = p_shcf;
 +     if (idx3 = 0)
 +     {
 +         options[idx3].def_val[VI_DEFAULT] = (char_u *)-c;
 +         if (!(options[idx3].flags  P_WAS_SET))
 +         {
 +             p_shcf = options[idx3].def_val[VI_DEFAULT];
 +         }
       }

 When the user has set the option that we must not change it back to the
 default.  When the user has changed the option, we should assume he
 knows what he is doing and leave the value alone.


Right, I get that we shouldn't set the value of the option, if the
user has already set it.

But I would think, we should always set the default value of the
option, regardless of whether the user has set the option or not.

Do we gain anything by leaving the default value at the initial
default, which will not work with the user's chosen shell?

Other options do this as well, I started updating shellxquote, etc. in
the same area as my patch before I realized the same logic (or
similar) applies to a large number of other options.

 Only setting 'shcf' to the default would have to use the current value
 of 'shell' to be right.  Not some stored value for an older value of
 'shell'.  I don't think we have logic for that yet, would require some
 refactoring to trigger the logic to fetch the default value when setting
 an option to its default value.  Might be worth it though.


Are you saying, re-default the shellxquote, shellquote, etc. options
if the user changes 'shell'? That could be worthwhile...a little
beyond the scope of what I'm trying to do here, though.

-- 
Ben

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

patch for Win32 sxq/shcf defaults, and question about option defaults

[Benjamin Fritz]

Fixed item from todo list:

 Win32: When 'shell' is cmd.exe this command fails:
   echo system('c:/path/echo.exe foo bar')
 Should we set the default for 'shellxquote' to a double quote, when 'shell'
 contains cmd in the tail?  (Benjamin Fritz, 2008 Oct 13)
 Also set 'shellcmdflag' to include /s.

While making my changes, I noticed the following strange behavior.

If a user's .vimrc sets the value of 'shellxquote' or 'shellcmdflag',
then the default value is not updated by the code I touched, because
of the checks for the P_WAS_SET flag.

But this means, if the user has this in their .vimrc on Windows:

set shell=sh
set shellxquote=\
set shellcmdflag=-c

Then a later command of :set shell shellxquote shellcmdflag will
set the values to cmd.exe, , and /c respectively. But if in
their .vimrc they only have:

set shell=sh

then Vim automatically sets shellxquote and shellcmdflag to \ and
-c, respectively.

However, if the user later does :set shell shellxquote
shellcmdflag, they get cmd.exe, \, and -c.

More to the point for this patch, if the user has in their .vimrc on
Windows, because they were enlightened back in 2008, 'set
shellxquote=\ shellcmdflag=/s /c', then after this patch this is
unnecessary, but if they try to set these values to their defaults,
they will get the *old* defaults.

What is the reason for only updating the default value of options, if
P_WAS_SET is false? I get that we don't want to override the actual
value of the option if the user set it to something, but don't we want
to update the default value? E.g. shouldn't we do something like this,
throughout option.c?

int idx3;

idx3 = findoption((char_u *)shcf);
-   if (idx3 = 0  !(options[idx3].flags  P_WAS_SET))
-   {
-   p_shcf = (char_u *)-c;
-   options[idx3].def_val[VI_DEFAULT] = p_shcf;
+   if (idx3 = 0)
+   {
+   options[idx3].def_val[VI_DEFAULT] = (char_u *)-c;
+   if (!(options[idx3].flags  P_WAS_SET))
+   {
+   p_shcf = options[idx3].def_val[VI_DEFAULT];
+   }
}

-- 
Ben

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

Re: patch for Win32 sxq/shcf defaults, and question about option defaults

[Benjamin Fritz]

On Fri, Nov 18, 2011 at 11:40 PM, Benjamin Fritz
fritzophre...@gmail.com wrote:
 Fixed item from todo list:

 Win32: When 'shell' is cmd.exe this command fails:
       echo system('c:/path/echo.exe foo bar')
 Should we set the default for 'shellxquote' to a double quote, when 'shell'
 contains cmd in the tail?  (Benjamin Fritz, 2008 Oct 13)
 Also set 'shellcmdflag' to include /s.

 While making my changes, I noticed the following strange behavior.

 If a user's .vimrc sets the value of 'shellxquote' or 'shellcmdflag',
 then the default value is not updated by the code I touched, because
 of the checks for the P_WAS_SET flag.

 But this means, if the user has this in their .vimrc on Windows:

 set shell=sh
 set shellxquote=\
 set shellcmdflag=-c

 Then a later command of :set shell shellxquote shellcmdflag will
 set the values to cmd.exe, , and /c respectively. But if in
 their .vimrc they only have:

 set shell=sh

 then Vim automatically sets shellxquote and shellcmdflag to \ and
 -c, respectively.

 However, if the user later does :set shell shellxquote
 shellcmdflag, they get cmd.exe, \, and -c.

 More to the point for this patch, if the user has in their .vimrc on
 Windows, because they were enlightened back in 2008, 'set
 shellxquote=\ shellcmdflag=/s /c', then after this patch this is
 unnecessary, but if they try to set these values to their defaults,
 they will get the *old* defaults.

 What is the reason for only updating the default value of options, if
 P_WAS_SET is false? I get that we don't want to override the actual
 value of the option if the user set it to something, but don't we want
 to update the default value? E.g. shouldn't we do something like this,
 throughout option.c?

        int     idx3;

        idx3 = findoption((char_u *)shcf);
 -       if (idx3 = 0  !(options[idx3].flags  P_WAS_SET))
 -       {
 -           p_shcf = (char_u *)-c;
 -           options[idx3].def_val[VI_DEFAULT] = p_shcf;
 +       if (idx3 = 0)
 +       {
 +           options[idx3].def_val[VI_DEFAULT] = (char_u *)-c;
 +           if (!(options[idx3].flags  P_WAS_SET))
 +           {
 +               p_shcf = options[idx3].def_val[VI_DEFAULT];
 +           }
        }

 --
 Ben


Oops, I forgot. Discussion of the fixed issue, for those with memories
shorter than 3 years:

http://groups.google.com/group/vim_dev/browse_thread/thread/3d1cc6cb0c0d27b3/756e7b2dafeb34f8

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

Re: patch for Win32 sxq/shcf defaults, and question about option defaults

[Benjamin Fritz]

Darnit, also forgot to attach the patch.

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


sxq_shcf_defaults.patch
Description: Binary data

Re: Fwd: FocusLost, FocusGained, and system() calls

[Benjamin Fritz]

On Wed, Oct 26, 2011 at 11:12 AM, Bram Moolenaar b...@moolenaar.net wrote:

 Benjamin Fritz wrote:

   I'm not sure what the problem is.  Why would there be FocusLost and
   FocusGained events for a system() call?
  
 
  Exactly. I was not expecting to see either event, but I see
  FocusGained anyway (problem 1). So at the very least, I would expect
  to see FocusLost to go with the FocusGained, but I do not (problem 2).
  Trying to work around the the problem, I set eventignore to contain
  FocusGained, and also tried setting it to all, but cannot ignore the
  FocusGained event (problem 3).
 
  The script given in the post is very simple but demonstrates the
  problem well. Apparently it was not reproducible except on Windows.
 
  You probably get FocusGained because Vim checks for changed buffers when
  returning from an external command.  In a way it's true that Vim gets
  back control.
 
  - Bram
 

 Maybe, which is why I was OK with getting the events. After all, a
 black console window pops up briefly on Windows when running most
 (all?) external commands.

 But, I'd still expect to get FocusLost and FocusGained in pairs. And
 barring that, I'd at least expect to be able to explicitly ignore one
 or both of them by setting 'eventignore' properly.

 The script contains:

        set ei=all
        echomsg system(xterm -e 'echo system command; exit')
        set ei

 The problem is that the autocommands trigger later.  The focus events
 are put in the type ahead buffer.  That's to avoid asynchronous
 autocommands causing trouble.


OK. So, how would one temporarily ignore Focus\(Lost\|Gained\) autocommands?

And, why don't we get FocusLost? I would expect never to get one
without the other.

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

Re: Fwd: FocusLost, FocusGained, and system() calls

[Benjamin Fritz]

On Wed, Oct 26, 2011 at 3:26 PM, Bram Moolenaar b...@moolenaar.net wrote:
  The script contains:
 
         set ei=all
         echomsg system(xterm -e 'echo system command; exit')
         set ei
 
  The problem is that the autocommands trigger later.  The focus events
  are put in the type ahead buffer.  That's to avoid asynchronous
  autocommands causing trouble.
 

 OK. So, how would one temporarily ignore Focus\(Lost\|Gained\) autocommands?

 Somehow read a character.  Haven't tried what would work.

This works:

augroup TEST
au!
autocmd FocusLost * echomsg focus lost
autocmd FocusGained * echomsg focus gained
augroup END

set ei=all
echomsg system(echo system command)
echo press any key to continue
call getchar()
set ei

By works I mean that I do not see a focus gained message. It
appears your diagnosis is on the right track.


 And, why don't we get FocusLost? I would expect never to get one
 without the other.

 I get both.  I'm on Unbutu with GTK.  Perhaps MS-Windows is different?

Yeah Gary Johnson tried on Fedora 11 and got neither the FocusGained
nor the FocusLost events either with or without the eventignore
setting. It certainly looks like Windows acts differently.

With this on Windows XP 64-bit (eventignore removed):

autocmd FocusLost * echomsg focus lost
autocmd FocusGained * echomsg focus gained

set ei=all
echomsg system(echo system command)
set ei

I get only FocusGained...no FocusLost.

I get the same thing with the commands in there (uncommented).

 These are Windows messages WM_KILLFOCUS and WM_SETFOCUS, thus it's not
 under control of Vim.


That's not a good sign. Is there some way to make sure Vim notices it
lost focus when using system()?

As a workaround, maybe using feedkeys() somehow can reset the
eventignore to allow ignoring of FocusGained? This seems VERY kludgy
though, even if it works.

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

Re: Fwd: FocusLost, FocusGained, and system() calls

[Benjamin Fritz]

On Sun, Sep 25, 2011 at 6:59 AM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben -

 On Sat, Sep 24, 2011 at 7:34 AM, Bram Moolenaar b...@moolenaar.net wrote:
 
  I'm not sure what the problem is.  Why would there be FocusLost and
  FocusGained events for a system() call?
 

 Exactly. I was not expecting to see either event, but I see
 FocusGained anyway (problem 1). So at the very least, I would expect
 to see FocusLost to go with the FocusGained, but I do not (problem 2).
 Trying to work around the the problem, I set eventignore to contain
 FocusGained, and also tried setting it to all, but cannot ignore the
 FocusGained event (problem 3).

 The script given in the post is very simple but demonstrates the
 problem well. Apparently it was not reproducible except on Windows.

 You probably get FocusGained because Vim checks for changed buffers when
 returning from an external command.  In a way it's true that Vim gets
 back control.

 - Bram


Maybe, which is why I was OK with getting the events. After all, a
black console window pops up briefly on Windows when running most
(all?) external commands.

But, I'd still expect to get FocusLost and FocusGained in pairs. And
barring that, I'd at least expect to be able to explicitly ignore one
or both of them by setting 'eventignore' properly.

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

Fwd: unexpected behavior of :let-@

[Benjamin Fritz]

I posted this a while ago on vim_use, but no response. It looks like
either a bug or a very misleading :help entry.

The thread is about how using :let-@ will automatically append a ^J
character if the text ends in ^M (useful for yanked text, but causes
unintended side effects when editing a recorded macro).

http://groups.google.com/group/vim_use/browse_thread/thread/fa96cad79cdfaadb/

-- Forwarded message --
From: Ben Fritz fritzophre...@gmail.com
Date: Tue, Jul 26, 2011 at 1:40 PM
Subject: Re: unexpected behavior of :let-@
To: vim_use vim_...@googlegroups.com




On Jul 26, 12:57 pm, ZyX zyx@gmail.com wrote:
 Reply to message «unexpected behavior of :let-@»,
 sent 20:36:08 26 July 2011, Tuesday
 by Ben Fritz:

 Not related to documentation fix, but you can use `setreg()' to avoid this
 behavior.


Nice! I'd forgotten about setreg(), finding it completely unnecessary
after being pointed to :let-@. I guess I'll be revisiting it. I do see
that for it to work as I want, I need to explicitly give the 'c' flag
as the type.

:help setreg() indicates that you should be able to change the type of
a register which already has content:

               You can also change the type of a register by appending
               nothing:
                       :call setreg('a', '', 'al')

But, I tried:

:let @a='^M'
:reg a → ^M^J
:call setreg('a','','ac')
:reg a → ^M^J

Did I misunderstand how this is supposed to work? I would expect the
^J to be removed after changing the type.

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

Re: Clarification of U command

[Benjamin Fritz]

On Tue, Aug 2, 2011 at 3:30 PM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz -
 Change:

 U Undo all latest changes on one line.  {Vi: while not
   moved off of it}

 to:


 U                     Undo all changes on the most recently modified line
                       until just after a different line was changed or 
 editing
                       started on this line. If no changes since the last U
                       command, undo the last U.  {Vi: only when cursor has 
 not
                       moved off last modified line}


 Thanks for the hint that this was unclear.  The text must have been
 there forever.  How about this:

 U                       Undo all latest changes on one line, the line where
                        the latest change was made. |U| itself also counts as
                        a change, and thus |U| undoes a previous |U|.
                        {Vi: while not moved off of the last modified line}


Much better, but latest changes is still not well-defined. Consider:

line 1: one two three
line 2: a b c

Put cursor on two and daw, then move to line 2 and delete the b with
x. Then go back to line 1 and insert some text.

Previously, I believed for some reason that pressing U on line 1 would
revert to one two three. I now understand that pressing U anywhere
will revert line 1 to one three.

Maybe add text like, 'Latest changes refers to changes not
interrupted by changes to other lines.' This could come afterward if
needed, in the longer text which explains details of the interaction
between u, CTRL-R, and U.

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

Re: 'backupcopy' and Windows Vista symbolic links

[Benjamin Fritz]

On Thu, Jul 7, 2011 at 6:34 AM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:

 :help 'backupcopy' indicates that the default value of auto should
 Do The Right Thing when the file is really a symbolic link:

       The auto value is the middle way: When Vim sees that renaming file
       is possible without side effects (the attributes can be passed on and
       the file is not a link) that is used.  When problems are expected, a
       copy will be made.

 I confirm that my 'backupcopy' is set to auto, but when writing to a
 symbolic link in Windows Vista, the link gets destroyed.

 The following fixes the problem:

      for some reason, backupcopy=auto doesn't work on Windows to keep
      symbolic links. I use these in my vimfiles directory to override
 some
      runtime files which I really edit in the vim source repository.
     autocmd BufWritePre ~/vimfiles/* set backupcopy=yes
     autocmd BufWritePost ~/vimfiles/* set backupcopy

 I don't think this ought to be necessary. Am I missing something? If
 not, this looks like a bug. But, I cannot imagine I'm the first person
 to notice this.

 Note, I was lead to this solution (in a roundabout way) from here:

 http://superuser.com/questions/193872/vim-destroys-symbolic-links-under-windows

 There is the mch_is_linked() function which is supposed to detect links
 on a file.  I don't know why it doesn't work in this situation.  Are you
 using a recent version of Vim?


Yes, the Vim without Cream install for 7.3.206. I'm not running as
administrator, but required admin access to create the links. That
doesn't affect anything, does it? I can try again from the admin
account later if it might.

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

Re: CCTree feature request and question

[Benjamin Fritz]

On Wed, Jun 15, 2011 at 6:11 PM, hari.rangara...@gmail.com
hari.rangara...@gmail.com wrote:
 Ben,

 You mentioned a crash, but I didn't quite get where. Did it crash after the
 error message? The error message says aval is Null.



Oops, I initially got a crash, but it turned out to be some weird
out-of-memory situation which a system reboot fixed. I was not able to
reproduce it after the reboot, so I removed the text about a crash.
Apparently I missed a spot and accidentally left vim_dev on the
addressee list. Sorry for the noise and confusion.

-- 
Ben

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

Re: Mercurial Workflow: Feature seperation via named branches

[Benjamin Fritz]

One more interesting response, maybe worth looking into.

On Thu, Jun 16, 2011 at 4:03 AM, Pierre-Yves David
pierre-yves.da...@logilab.fr wrote:
 On Wed, Jun 15, 2011 at 03:17:36PM -0500, Benjamin Fritz wrote:

 Yes, this is the case. It is somewhat strange (especially in the
 open-source world) but it is what it is. Bram is the
 benevolent-dictator-for-life of Vim and still maintains it by
 accepting patch files from Vim community (in pretty much any format
 but normally in Mercurial's nowadays) and then releasing each coherent
 change as a patch which he also happens to apply and keep in
 Mercurial. The nice thing is that within Vim's internal scripting
 language you can check for not only a specific version but also a very
 specific patch level using something like v:version == 703 
 has('patch219') for the specific changeset you quote. Due to this
 release strategy, it's convenient to be able to refer to specific
 changesets by version ID. But since there are not a bunch of
 intermediate changesets, tagging each one still only results in a few
 hundred tags per major version, rather that the hundreds of thousands
 you indicated would cause a problem.

 You might consider using and extension digging into a revision content to
 *generate* this patch-version number instead of tagging every single
 changetset.

 --
 Pierre-Yves David


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

Re: Mercurial Workflow: Feature seperation via named branches

[Benjamin Fritz]

On Wed, Jun 15, 2011 at 12:51 PM, Matt Mackall m...@selenic.com wrote:
 2011/6/15  mercurial-requ...@selenic.com:
  Also, I think you underestimate how badly things can go algorithmically
  for people who are not aware that particular things aren't designed to
  scale. For instance, we've had people who've tagged essentially every
  commit in a 100k cset repo. That's simply not going to work well and
  we're not going to be able to tweak things so it does.
 
 I'm curious about what problems might arise from tagging nearly every
 commit. For instance, Vim is maintained in Mercurial at
 http://code.google.com/p/vim , and each new patch added is tagged with
 the patch number. What specific problems might occur from this
 practice?

 Slow startup for any command that needs tags info is the primary risk.
 This is cached now so it's generally fast, but the cache will need to be
 rebuilt at each tagging point. You probably won't see any pain here for
 a long time.

 You seem to have an unusual model:

 changeset:   2891:acda456c788a
 tag:         v7-3-219
 user:        Bram Moolenaar b...@vim.org
 date:        Mon Jun 13 02:04:00 2011 +0200
 files:       src/os_mac_conv.c src/os_macosx.m src/version.c src/vim.h
 description:
 updated for version 7.3.219
 Problem:    Can't compile with GTK on Mac.
 Solution:   Add some #ifdef trickery. (Ben Schmidt)

 It seems like you bump the version number in version.c on basically
 every change, then tag it as a release.


Yes, this is the case. It is somewhat strange (especially in the
open-source world) but it is what it is. Bram is the
benevolent-dictator-for-life of Vim and still maintains it by
accepting patch files from Vim community (in pretty much any format
but normally in Mercurial's nowadays) and then releasing each coherent
change as a patch which he also happens to apply and keep in
Mercurial. The nice thing is that within Vim's internal scripting
language you can check for not only a specific version but also a very
specific patch level using something like v:version == 703 
has('patch219') for the specific changeset you quote. Due to this
release strategy, it's convenient to be able to refer to specific
changesets by version ID. But since there are not a bunch of
intermediate changesets, tagging each one still only results in a few
hundred tags per major version, rather that the hundreds of thousands
you indicated would cause a problem.

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

Re: CCTree feature request and question

[Benjamin Fritz]

I included vim_dev due to the crash. This is using the CCTree plugin
available on vim.org:

On Wed, Jun 15, 2011 at 4:16 PM, Benjamin Fritz fritzophre...@gmail.com wrote:
 On Wed, Jun 15, 2011 at 4:05 PM, hari.rangara...@gmail.com
 hari.rangara...@gmail.com wrote:
 version 1.51 with enhanced symbol processing enabled should get what you
 want because of the second pass it does to catch out on symbols cscope
 missed out.


 Cool, I'll need to try it out when I find a function cscope fails on.
 I wasn't expecting it to already be working!


I downloaded 1.51, and got a weird error message. I narrowed it down a little:

First, I did a :cs add of 3 databases.

Then, I did a CCTreeLoadDB with the first database. This worked fine.

Next, I did a CCTreeAppendDB with the next database. I get as output
from start to finish:

Added cscope database U:\CSCOPE~1\ECAP30~1.OUT
Added cscope database U:\CSCOPE~1\ECACOM~1.OUT
Added cscope database U:\CSCOPE~1\CEFSA-~1.OUT

 0 4212   U:\CSCOPE~1\ECAP30~1.OUTnone
 1 5912   U:\CSCOPE~1\ECACOM~1.OUTnone
 2 1704   U:\CSCOPE~1\CEFSA-~1.OUTnone
6 more lines
6 more lines
CCTree: Done loading database. xRef Symbol Count: 740. Time taken:
9.598038 secs
Error detected while processing function
163..137..139..102..SNR28_CCTreeMakeCommaListUnique..40:
line5:
E713: Cannot use empty key for Dictionary
Error detected while processing function 163..137:
line   12:
E171: Missing :endif

My Vim version is the Vim without Cream build for 7.3.198 on Windows XP.

I find this very strange. I THINK (if I'm reading the error messages
correctly) the line that causes the error is the  let valdict[aval] =
''  line in the below code fragment from cctree.vim, but it sure
looks correct to me:

let valdict = {}
let reslist = ''
for aval in a:lstval
if !has_key(valdict, aval)
let valdict[aval] = ''
let reslist .= (aval . ,)
endif
endfor

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

Re: Patch 7.3.191

[Benjamin Fritz]

On Thu, May 19, 2011 at 11:40 AM, Bram Moolenaar b...@moolenaar.net wrote:
 I wonder, if we might re-use this option to implement a similar
 extended attribute on Mac OS? See the following tip about saving the
 encoding information with the file, in the com.apple.TextEncoding
 extended attribute. I have no real idea how this stuff works (a google
 search didn't turn up very much of use) but it looks like something
 very useful which Vim could do if we can figure out how it is supposed
 to work. There are probably other extended attributes which might be
 more appropriate than the encoding, but I don't think encoding is that
 far off the intent of this option. Maybe, though, it's better to just
 do it in an autocmd like in the tip below:

 http://vim.wikia.com/wiki/Display_UTF-8_characters_in_Mac_Quicklook

 Is this actually being used and widely supported?



That, I don't know. I have never had and probably never will have a
Mac. I don't even really know which extended attributes there are or
are commonly used. If there is one for file type, that would probably
be a better thing to use for a resurrected osfiletype option. The
specific one mentioned in the tip could conceiveably be used for
encoding detection, and it would make sense to set it when writing,
but it can readily be done in vimscript for now. I wish I could find
documentation of the valid values, etc. I suspect most IANA encoding
names should work, but I have no idea what the magic number used in
the tip is for, and I really have no first-hand knowledge of any of
this. From the little I could find, extended attributes in general
should allow storing any useful information about the file to
unambiguously determine file type, file encoding, and possibly other
things as well. But I have no idea whether there are any widely-used
standard values.

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

Re: no error raised for :let list[out-of-range] = value

[Benjamin Fritz]

On Wed, Apr 20, 2011 at 7:15 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.au wrote:
 On 21/04/11 10:10 AM, Ben Fritz wrote:

 On Apr 19, 4:40 am, Yukihiro Nakadairayukihiro.nakada...@gmail.com
 wrote:

 When assigning or deleting list item no error raised for out-of-range
 index.

    :let list = []
    :let list[0] = 0
    :echo list
    []

    :let list = []
    :unlet list[0]

 I expected E684: list index out of range: 0 or similar error.


 This one is a feature. It lets you easily grow a list.

 How?

 Ben.


Oops nevermind, I missed the part where the list remained empty even
after setting the element to a value. I did not read carefully enough
and was apparently thinking of Perl. I'd consider it a bug.

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

Re: Automated tool for recent changesets?

[Benjamin Fritz]

On Mon, Apr 11, 2011 at 10:38 AM, Bram Moolenaar b...@moolenaar.net wrote:

 Ben Fritz wrote:

 Bram, I'm just curious: it looks like most of the very recent
 changesets (up to patch 160) are problems of the sort that static
 analysis or other automated tools would find. Were these the result of
 some automated tool or did someone just find a bunch and report them
 quietly? Which tool, if one was used?

 http://scan.coverity.com

 It finds some potential problems, and lots of false positives.


I had a suspicion that might have been it. I use Coverity at work and
have noted several bugs of the same sort as the recent changsets
fixed. You say it finds a lot of false positives (which it does
sometimes I admit, especially in auto-generated code); do you have any
thoughts on whether it's the tool, the configuration, or just the fact
that Vim's code is 20 years old and pretty solid already? I know from
talking to folks at Coverity that a lot of their code is just to
suppress false positives and they report an average false positive
rate of about 20% overall (I've seen about 30% on my projects at
work). It might be possible to get the Coverity folks who run the scan
project to tweak some options for better false positive rates,
depending on what type they're reporting.

I get the impression you're not too impressed with the tool, from your
false positives comment and a previous patch a long time ago which
basically said make Coverity be quiet. I'm wondering, on the whole,
do you consider it useful or mostly a nuisance/distraction?

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

Re: Unexpected behavior loading cp1252 file as latin1

[Benjamin Fritz]

On Wed, Feb 2, 2011 at 9:59 AM, Benjamin Fritz fritzophre...@gmail.com wrote:
 On Tue, Feb 1, 2011 at 7:11 PM, Rhialto rhia...@falu.nl wrote:
 On Tue 01 Feb 2011 at 09:30:48 -0800, Ben Fritz wrote:
 Converting from cp1252 to latin1 should fail depending on the
 characters in the file, but latin1 to cp1252 should always work,
 shouldn't it? I understand cp1252 to be a superset of latin1. Is it
 because the system mis-represents its encoding to Vim as latin1 when
 really it is cp1252 or something?

 If this means that I get cp1252 characters in my file which I tried to
 keep pure Latin 1, this is very wrong... my system doesn't display those
 obnoxious microsoft extensions.


 For now, if this bothers you, you can set your encoding to something
 other than latin1 (like utf-8) and do a setglobal fenc=latin1. Also
 update your fileencodings option so that latin1 actually gets
 detected.

 Now you will get a warning if you try to save a file and there are
 non-latin1 characters in it.


I see this in :help version7.txt (line 2470):

Win32: Set the default for 'isprint' back to the wrong default @,~-255,
because many people use Windows-1252 while 'encoding' is latin1.

Maybe this is related?

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

Re: Unexpected behavior loading cp1252 file as latin1

[Benjamin Fritz]

On Tue, Feb 1, 2011 at 7:11 PM, Rhialto rhia...@falu.nl wrote:
 On Tue 01 Feb 2011 at 09:30:48 -0800, Ben Fritz wrote:
 Converting from cp1252 to latin1 should fail depending on the
 characters in the file, but latin1 to cp1252 should always work,
 shouldn't it? I understand cp1252 to be a superset of latin1. Is it
 because the system mis-represents its encoding to Vim as latin1 when
 really it is cp1252 or something?

 If this means that I get cp1252 characters in my file which I tried to
 keep pure Latin 1, this is very wrong... my system doesn't display those
 obnoxious microsoft extensions.


For now, if this bothers you, you can set your encoding to something
other than latin1 (like utf-8) and do a setglobal fenc=latin1. Also
update your fileencodings option so that latin1 actually gets
detected.

Now you will get a warning if you try to save a file and there are
non-latin1 characters in it.

I think it is a problem that with encoding=latin1, Vim acts
differently and you will not get a warning for non-latin1 characters.
But apparently a very common (and probably not very serious) problem.

cp1252 is basically the same as latin1, with a few extras thrown in
where latin1 doesn't have anything useful. So as long as you don't
intentionally include any non-latin1 characters, your file will be
identical to one saved as a strict latin1 file.

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

Plugin to supplement latest TOhtml

[Benjamin Fritz]

The latest TOhtml (7.3_v7) included in the last runtime update
includes updates to the auto-detection of HTML encoding from the
'fenc' and 'enc' options in Vim.

One of the updates was to add an option so that the user can add
auto-detection of encodings that the plugin does not use by default
(TOhtml now only uses by default those encodings listed by name in
:help encoding-names).

I have made a separate plugin, tohtml_wincp, that will add all
installed codepages to the auto-detect mechanism on a Windows system.
Just like the TOhtml plugin, only those encodings with widespread
browser support will automatically be used, but you can specify to use
any of them manually.

http://www.vim.org/scripts/script.php?script_id=3316

If you frequently work with alternate encodings on a Windows system,
you might like to install this plugin.

I could not find a good way to do something similar on Unix-like
systems. According to the man pages I could find, iconv --list should
give a good starting point, but its output is system dependent. If you
frequently work with alternate encodings on Unix, and want to make
something similar, please share!

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

Re: Vim cannot find xxd utility

[Benjamin Fritz]

On Wed, Nov 10, 2010 at 9:23 AM, Benjamin Fritz fritzophre...@gmail.com wrote:
 On Wed, Nov 10, 2010 at 5:45 AM, Bram Moolenaar b...@moolenaar.net wrote:

 In Vim 7.3.35, :echo $PATH does not include the Vim install directory.
 It does include this directory in Vim 7.3.27.

 I remember there were modifications of how Vim works with the system
 PATH back in version 7.3.34, perhaps that is where the error was
 introduced.

 I don't think this is caused by patch 7.3.34.  It adds a few calls to
 change directory, but it does not touch $PATH.


 Hmm, ok. I will try an hg bisect sometime this week at home, if
 someone doesn't beat me to it. It's got a pretty narrow range anyway
 :-)


Weird. I could not reproduce the problem at all at home with my
self-compiled Vim.

I will try installing the latest and greatest at work...perhaps there
was a problem with the 7.3.35 installer I downloaded from the Cream
site somehow.

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

[patch] Respect 'autochdir' when editing with --remote

[Benjamin Fritz]

Attached patch fixes the bug mentioned here:

http://groups.google.com/group/vim_dev/browse_thread/thread/dc24d36b9eee0b35/4e93a957979436ef

It turned out to have very little to do with the :drop command, but
rather the fact that --remote and friends would temporarily change
directories and then restore the previous directory (which is
incorrect in the case of 'acd' being set) after the :drop command.

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


remote_acd.patch
Description: Binary data

Re: Beta release: use of 'fencoding' in TOhtml

[Benjamin Fritz]

On Thu, Oct 7, 2010 at 12:39 AM, Benjamin Fritz fritzophre...@gmail.com wrote:
 A while back on vim_dev, there was a suggestion for TOhtml to use the
 'fencoding' of the source buffer for the HTML encoding of the
 generated file.

 This thread discusses it, and I eventually included an initial beta
 version that does exactly this:

 http://groups.google.com/group/vim_dev/browse_thread/thread/c41f797237e46f45

 Also included is detection of the proper 'fileencoding' from the
 user-specified HTML encoding, if given.

 I have not received any feedback on the initial release, but I have
 acted on my musings and created a second beta version that removes
 specific encodings from the automatic detection, which are not
 supported on all 5 major browsers, according to
 http://wiki.whatwg.org/wiki/Web_Encodings.

 Please try it out and send me any comments! See attached patch against
 the current latest Vim (Mercurial changeset fae782ef63dd), or go to
 http://code.google.com/p/vim-2html-test/downloads/list for the fully
 patched files. Most users should not notice any differences, unless
 they had specific encoding-related problems in the past, in which case
 hopefully the updates solve more problems than they create.

 One thing in particular I'd like to know, is it worthwhile to provide
 platform-specific code, that adds additional encodings based on your
 system? For example, Windows users might like windows-1252 detected
 automatically by default. Is there a good way to figure out what the
 supported encodings are for a given system? Maybe, code like this
 would be better as a separately distributed plugin, since most users
 can probably just use UTF-8 with no problems.


Oops, found one bug, where converting to UTF-8 for all Unicode
encodings did not also convert the fencoding.

Here's an updated patch. New fully-patched files also have been
uploaded as indicated above.

I'll probably give it about another week to collect comments before
submitting to Bram if there are no issues.

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


2html_v7b3_fenc.patch
Description: Binary data

Re: Suggest ':TOhtml' to use 'fileencoding' rather than 'encoding' as default html charset

[Benjamin Fritz]

The attached patch against the latest 7.3.3 changeset in Mercurial
adds the requested use of 'fencoding' instead of 'encoding' when it is
set to determine the HTML charset.

Additionally, it will now support a lot more encodings, and
automatically set the file encoding of the new file to match the
charset.

All encodings that are both native to Vim (listed by name in :help
encoding-names) and appear in the IANA registry (
http://www.iana.org/assignments/character-sets ) are supported. Note
that not all of these encodings are supported by major web browsers or
the w3c validator. New options are provided to override specific
encodings in the charset detection, or there is still
g:html_use_encoding to override all automatic detection. It is
probably a good idea to use this option if publishing to a web page.

There may be some charsets that previously were automatically detected
that no longer are, and there are some encodings supported by Vim
which I could not find in the IANA registry.

Unfortunately, I could not find a list of widely supported charsets,
so I just used all the ones in Vim and the IANA registry, as mentioned
previously. If there is such a list, would it be a good idea to limit
the automatically detected charsets to those in the list? Along those
lines, it could be a good idea to automatically use UTF-8 in place of
UTF-16 and UTF-32. Currently these charsets are selected as-is.

So, consider this a beta release. PLEASE test and comment, I expect
some changes may be needed before final submission.

Patch is attached, or the files are available for download at the site
I use for the TOhtml test suite:

http://code.google.com/p/vim-2html-test/downloads/list

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


2html_encoding.patch
Description: Binary data

Re: 2html.vim causes Vim to crash with a SIGSEGV?!

[Benjamin Fritz]

On Thu, Sep 2, 2010 at 8:49 AM, Peter Odding pe...@peterodding.com wrote:

 while running the 2html script, Vim died with a
 SIGSEGV signal. [Snip]


 Note that `PublishTest()' (referenced in `bt.txt') isn't defined in my
 publish plug-in; it's defined in my ~/.vimrc and does basically the same
 thing that the first Vim script snippet on [2] does. The main difference is
 that it publishes 20 files instead of 4, except that those files still
 aren't published because Vim keeps crashing :-). I don't think the crash is
 related to which files are published...


It might actually be related. If 2html is doing something wrong, it
must only be on certain inputs, because I have a test suite I run it
through that uses an exhaustive set of all the options (except for
font, encoding, and no_progressbar), and have never seen a crash:

http://code.google.com/p/vim-2html-test

Maybe you could give a sample of the input that crashes Vim?

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

setwinvar unavailable in restricted mode

[Benjamin Fritz]

I got a bug report for the 2html plugin, that two setwinvar() calls
are throwing an error.

It appears the problem was that the user was running Vim with the -Z flag.

:help setwinvar() says it acts just like settabwinvar(), which in turn
says it is not available in the sandbox. :help sandbox does not
mention restricted mode, and :help -Z does not mention the sandbox,
but from some quick testing, the first several functions I tested that
are not available in the sandbox, are also not available in restricted
mode.

Is this behavior intentional? It seems strange to me.

The error raised is strange too...E145: Shell commands not allowed in rvim.

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

Re: Suggest ':TOhtml' to use 'fileencoding' rather than 'encoding' as default html charset

[Benjamin Fritz]

On Sat, Aug 28, 2010 at 10:00 PM, Tony Mechelynck
antoine.mechely...@gmail.com wrote:

 I don't know what is being done ATM, but I'd always include the line

 meta http-equiv=Content-Type content=text/html; charset=whatever /

 (replacing whatever by the charset name) somewhere near the start of the
 head element. You may want to use a synonym, e.g. iso-8859-1 for Latin1,
 but that's just the finishing touch.


Yes, that's mostly what it does now, except it omits the line if it
could not determine the charset, always uses 'encoding' instead of
'fileencoding', and specifies the encoding in the ?xml line instead
when optionally using xhtml. I think using utf-8 as a fallback instead
of leaving it out entirely would be a better idea.

The user can specify the charset now, but then the fileencoding will
be wrong unless the user remembers to manually set it (or if it gets
inherited...'fileencoding' seems to act like a global-local option).

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

Re: Suggest ':TOhtml' to use 'fileencoding' rather than 'encoding' as default html charset

[Benjamin Fritz]

On Sat, Aug 28, 2010 at 4:16 PM, Tony Mechelynck
antoine.mechely...@gmail.com wrote:

 From my understanding, 'fileencoding' is the encoding Vim is supposed

 to use to read/write the file. So, it does make sense that we should
 use this instead of just 'encoding' for the charset of the generated
 html. Does anyone know why TOhtml has used 'encoding' instead? I have
 not touched the charset detection code yet, other than to move it from
 the 2html.vim file into the autoload/tohtml.vim file.

 You got it right, and it does indeed make sense.
 One possibility is that anything can be represented in UTF-8, including text
 not yet saved from the latest edit of the file, and possibly incompatible
 with the 'fileencoding' - such text is of course in error, and will cause an
 error if one tries to save it.


Ok, I think I'll make the edit, then.

Your response gives me an idea to fix something else that's been
bothering me. Currently, if Vim cannot determine the correct charset
to use, it defaults to not including one at all. I think I'll have it
default the charset and file encoding to UTF-8 if neither the
fileencoding nor the encoding option gives a valid charset. The user
should be able to manually leave out the charset and manually set the
encoding if desired.

Here's what I'm thinking in more detail:

For one buffer:
1. If user specified a charset, try to determine 'fileencoding' from
charset. If this fails, warn the user they will need to manually set
the fileencoding.
2. If no charset is specified, try to determine a charset from the
'fileencoding' option. If successful, use the same 'fileencoding' and
the associated charset in the generated buffer.
3. If could not determine charset from 'fileencoding', try again with
'encoding'. If successful, set 'fileencoding' to blank in the new html
buffer and use the charset from the 'encoding' option.
4. If could not determine charset from either 'encoding' or
'fileencoding', default to UTF-8 and warn the user.

Multiple buffers in diff mode will be done similarly, except that we
will determine the charset as above for ALL buffers. If they differ,
set 'fileencoding' to blank and use the charset from 'encoding' (or
UTF-8 if cannot determine charset from 'encoding').

What do you think? Or maybe this is too complicated and I should just
use 'encoding' as done currently?

What do you think?

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

Re: Validation fixes in 2html

[Benjamin Fritz]

On Sat, Aug 7, 2010 at 12:25 AM, Benjamin Fritz fritzophre...@gmail.com wrote:
 Test if you're interested, but I'm running a script that will generate
 with a fairly exhaustive set of options. I'll compare the output
 sometime tomorrow afternoon or evening to the same files generated
 with the unpatched version. I'll report back when I have the results


Well...done looking over the results. Nothing unexpected changed.

I've created a google code project for the test script:

https://code.google.com/p/vim-2html-test/

I'm far from certain I'm going to keep using it, the number of
settings makes it quite daunting to actually look at all the possible
combinations. I did it this time and small changes should be pretty
easy but holy CRAP that took a long time to go through, and the repo
is pretty darn big.

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

Validation fixes in 2html

[Benjamin Fritz]

Attached patch fixes a number of bugs in TOhtml, mostly markup
validation fixes for xhtml and for non-CSS generation.

I've tested a small set of options on a couple of files and it looks
like it doesn't break anything, but of course the potential is there.
Test if you're interested, but I'm running a script that will generate
with a fairly exhaustive set of options. I'll compare the output
sometime tomorrow afternoon or evening to the same files generated
with the unpatched version. I'll report back when I have the results
but I'm pretty confident the patch can be included if I don't get back
before the next beta release.

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


2html_validation_fixes.patch
Description: Binary data