Moving to github: proposal for updating guides

2015-03-29 Fir de Conversatie Bruno Sutic 
Hi all,
in Preparations for moving to github thread Bram said it would be a good idea 
to update the following pages:

- http://www.vim.org/develop.php
- http://www.vim.org/mercurial.php

And also create a new page with instructions for git. I went ahead and created 
a change proposal for these.

The files are in the attachment.
If you don't want to download the files, you can read the content here: 
https://gist.github.com/bruno-/19c76f204a901441ad65

The develop.txt and mercurial.txt contain changes for existing pages. 
git.txt contains instructions for fetching the source code with git and 
building/installing vim.

The files are in plain txt format, let me know if some other format is needed.
Feedback is welcome!

Bruno

-- 
-- 
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.
Vim Development
===

Vim source code repository is on hosted on Github:

https://github.com/vim/vim

Apart from Github, development also happens on the vim-dev maillist with people
contributing patches via email. Subscribe if you want to get involved, see
[here](maillist.php#vim-dev).

To see known bugs and next things to work on, use Vim help:

:help todo

The issue tracker is [here](https://github.com/vim/vim/issues).

Making changes to Vim
=

Let's say you want to make a bugfix, small correction or develop a new feature
for Vim.

Vim source code is hosted at github.com and managed by git. Using git is
preferred for developing and bugfixing Vim.

If you are new to Git, here's the recommended resource to get familiarized with
it:

http://git-scm.com/book/en/v2

Installing git
--

To install git:

- on Debian (or Ubuntu) use `$ apt-get install git`
- on OS X install [Homebrew](http://brew.sh) and then use `$ brew install git`
- on Windows install [msysgit](http://msysgit.github.io)

1. Clone the repository
===

Clone Vim repository into `vim/` directory in the current path:

$ git clone https://github.com/vim/vim
$ cd vim

You can now browse and see Vim's source code.

2. Create changes
=

It's now time to make changes to the source code. Here's the workflow to
make this:

- pull the latest changes from Vim remote repository

  $ git checkout master
  $ git pull

- create a new branch in local git repository

  $ git checkout -b fix_annoying_bug

- make changes to the source code

- commit the changes

  $ git add changed/file.xyz
  $ git commit

When writing a commit message, keep the first line short, up to 50 characters
or less. Add more details about the change in the commit message body.

When the feature/bugfix is done, you're ready for the next step: submitting the
change for review and evaluation for merging into Vim's source code.

Depending on your preferences submitting a change can be done in 2 ways:

- by creating and opening a pull request to Vim's main repository via Github
- by creating patch and sending it to vim-dev maillist

2.1 Open a pull request
===

A simple way of proposing a change to Vim's source code is opening a pull
request via Github.

- create a Github account, if you don't have it already

- Fork the Vim repository by going to https://github.com/vim/vim and clicking
  Fork in the upper right corner of the page.
  This creates a copy of Vim's repository for your Github account, example:
  https://github.com/username/vim

- locally, add the forked repository as a git remote

  $ git remote add fork https://github.com/username/vim

- push your local branch 'fix_annoying_bug' to the forked repository

  $ git push -u fork fix_annoying_bug

- In a browser navigate to forked repo https://github.com/username/vim
  and open a pull request to main Vim repository. Make sure you write a good
  description of your change in the pull request message.

Now, it's up to Vim's maintainer to review, comment and consider merging your
change into the main repository.

2.2 Create a patch
==

Another way of submitting changes is by creating a patch and sending it to the
vim-dev maillist. This way you don't have to have a Github account and steps in
'2.1 Open a pull request' should be skipped.

Here's what you do, continuing from steps described in '2. Create changes':

- create a patch file from your changes using git

  $ git format-patch master --stdout  fix_annoying_bug.patch

- send the patch file 'fix_annoying_bug.patch' to the vim-dev list.

Other Vim developers and Vim's maintainer will review, comment and consider
merging your change into the

Re: Preparations for moving to github

2015-03-27 Fir de Conversatie Bruno Sutic 
 Indeed, we haven't even seen *that* reason.  All we've seen is it makes the 
 vocal git users happy.  I don't know why people keep saying the majority of 
 vim users prefer git/github.  This has in no way been established.  The 
 poll this thread created shouldn't be assumed to be a representative 
 sample; it gets self-selected respondants, particularly of two types: people 
 who *really* get excited about git/github, and curmudgeons who don't feel 
 like changing without a compelling reason.  For all we know, the 
 github-preferrers are merely a loud minority.  For all we know, the 
 curmudgeons are a loud minority.  People need to stop taking it for granted 
 that we know the majority of Vim users who clone repos want Vim to go to 
 github.
 
 
 -Manny

Hey guys,
I'm strongly in favor of switching to github and using git. It will bring huge 
benefits to the project in terms of eyeballs looking at the source code, 
reporting bugs and getting involved in smaller tasks like testing  trying out 
new code etc.

Here's a couple objective arguments that back these statements:
- Comparison of trends for git vs mercurial: 
http://www.google.com/trends/explore#q=git%2C%20mercurialcmpt=qtz=

- Comparison of github vs bitbucket trends: 
http://www.google.com/trends/explore#q=github%2C%20bitbucketcmpt=qtz=

- lastly, it has been mentioned a couple times vim plugin community is already 
on github. The objective statement that proves this: github currently has 
42,636 vim related repositories, bitbucket has only 1652 (this is based on a 
simple search for vim on both github and bitbucket).

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

2015-03-25 Fir de Conversatie Bruno Sutic 
On Tuesday, March 24, 2015 at 10:36:32 PM UTC+1, Bram Moolenaar wrote:
 Since Google Code is going to be shut down we need a new place for the
 Vim repository.  Many users have given their opinion and github appears
 to be the preferred site.
 
 This is not without disadvantages, since it means moving from Mercurial
 to git.  Some may like this, some not.  Will take some getting used to.
 I personally prefer the Mercurial commands, they are more obvious to
 use.  You can find help only for how a Mercurial command translates to
 git, e.g. https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone
 
 To see how well this works I have created a SNAPSHOT of the repository.
 This way we can try it out.  I already verified that I can push patches
 there.  However, for now development will remain on code.google.com.
 The issues were already changed after the migration, this will continue.
 
 Look here: https://github.com/vim
 
 Please respond to the list if something doesn't work well.
 
 
 NOTE: Before the actual migration the current repository on github will
 be wiped!
 
 
 -- 
 TIM:Too late.
 ARTHUR: What?
 TIM:There he is!
[They all turn, and see a large white RABBIT lollop a few yards out of the
cave.  Accompanied by terrifying chord and jarring metallic monster noise.]
  Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
 
  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
 ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
 \\\  an exciting new programming language -- http://www.Zimbu.org///
  \\\help me help AIDS victims -- http://ICCF-Holland.org///

This is great news.
From what I can tell, the reactions to this post on reddit vim group, twitter 
and hacker news have been very positive.

I volunteered to help in the previous thread about moving away from Google 
Code.. so if help is needed with drafting or testing new git-related help 
pages, I'm still in.

The pages that will likely need git equivalents are:
- http://www.vim.org/mercurial.php
- http://www.vim.org/develop.php

I'm curious, when a switch is made, will Github's pull request feature be 
used? Or will code contributions still be done with patches via mailing list?

I'd guess a move to pull request workflow will be done since it's so 
effortless on github, but maybe I'm jumping the gun here.

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

2015-03-25 Fir de Conversatie Bruno Sutic 
On Wednesday, March 25, 2015 at 7:52:44 PM UTC+1, Christian Brabandt wrote:
 Hi Bruno!
 
 On Mi, 25 Mär 2015, Bruno Sutic wrote:
 
  On Tuesday, March 24, 2015 at 10:36:32 PM UTC+1, Bram Moolenaar wrote:
   Since Google Code is going to be shut down we need a new place for the
   Vim repository.  Many users have given their opinion and github appears
   to be the preferred site.
   
   This is not without disadvantages, since it means moving from Mercurial
   to git.  Some may like this, some not.  Will take some getting used to.
   I personally prefer the Mercurial commands, they are more obvious to
   use.  You can find help only for how a Mercurial command translates to
   git, e.g. https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone
   
   To see how well this works I have created a SNAPSHOT of the repository.
   This way we can try it out.  I already verified that I can push patches
   there.  However, for now development will remain on code.google.com.
   The issues were already changed after the migration, this will continue.
   
   Look here: https://github.com/vim
   
   Please respond to the list if something doesn't work well.
   
   
   NOTE: Before the actual migration the current repository on github will
   be wiped!
   
   
   -- 
   TIM:Too late.
   ARTHUR: What?
   TIM:There he is!
  [They all turn, and see a large white RABBIT lollop a few yards out of 
   the
  cave.  Accompanied by terrifying chord and jarring metallic monster 
   noise.]
Monty Python and the Holy Grail PYTHON (MONTY) 
   PICTURES LTD
   
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   
   \\\
   ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ 
   \\\
   \\\  an exciting new programming language -- http://www.Zimbu.org
   ///
\\\help me help AIDS victims -- http://ICCF-Holland.org
   ///
  
  This is great news.
  From what I can tell, the reactions to this post on reddit vim group, 
  twitter and hacker news have been very positive.
  
  I volunteered to help in the previous thread about moving away from Google 
  Code.. so if help is needed with drafting or testing new git-related help 
  pages, I'm still in.
  
  The pages that will likely need git equivalents are:
  - http://www.vim.org/mercurial.php
  - http://www.vim.org/develop.php
  
  I'm curious, when a switch is made, will Github's pull request feature be 
  used? Or will code contributions still be done with patches via mailing 
  list?
  
  I'd guess a move to pull request workflow will be done since it's so 
  effortless on github, but maybe I'm jumping the gun here.
 
 Anybody knows, if it is possible to forward issues and pull requests to 
 the vim-dev mailinglist?
 
 Best,
 Christian
 
 -- 
 Müde macht uns die Arbeit, die wir liegenlassen, nicht die, die wir
 tun.
   -- Marie von Ebner-Eschenbach

Hi Christian,
yes, I think it's possible to forward emails to a mailing list.

Someone who has access to the vim organization repository can setup a vim-dev 
email address and configure this.

In the screenshot below I tried to indicate where in the settings you can find 
these options:
http://imgur.com/uejBuep

An email address has to be verified (via clicking the confirmation link in an 
email). If this is a problem for a mailing list, I'm guessing github support 
may be able to bypass the verification step.

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

Google Code shuts down

2015-03-12 Fir de Conversatie Bruno Sutic 
It appears google code is shutting down:
http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

Any thoughts on where will vim source code repo be moved?
I know I'd be more than delighted if it was hosted on Github.

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

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

Re: Google Code shuts down

2015-03-12 Fir de Conversatie Bruno Sutic 
On Thursday, March 12, 2015 at 8:28:45 PM UTC+1, Bram Moolenaar wrote:
 Bruno Sutic wrote:
 
  It appears google code is shutting down:
  http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
  
  Any thoughts on where will vim source code repo be moved?
  I know I'd be more than delighted if it was hosted on Github.
 
 Suggestions are welcome.
 
 It's possible to use a local Mercurial repository with Github, right?
 So the instructions on how to get Vim would only need to change the URL.

Github unfortunately does not have support for Mercurial repos.
However, it is possible to use Mercurial locally and push to any git repo with 
a tool like this: https://github.com/schacon/hg-git

But yes, I think a move to Github would mean more than just changing the URL in 
the instructions.
If it's any worth, I'd gladly volunteer and invest time to help with this.

Since suggestions are welcome, I'd like to propose a couple arguments for 
moving to github and why would that ease vim adoption and installation for new 
users:

- the overwhelming majority of vim plugins are hosted on github. In fact, it 
seems vim plugins exist only on vim.org and github.
- all the vim plugin managers support short name specification for github 
plugins. In short, it looks like the vim (plugin) community is already on 
github.
- google trends on git vs mercurial are pretty clear 
http://www.google.com/trends/explore#q=git%2C%20mercurialcmpt=qtz=
- google trends on github vs bitbucket are even clearer 
http://www.google.com/trends/explore#q=github%2C%20bitbucketcmpt=qtz=
- github.com gets DDOSed occasionally (which is handled really seriously). But 
the github pages (web-page hosting) are a separate service and are rock solid

I tried to keep to arguments as much as possible and I hope they make sense!

-- 
-- 
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] Gui colorschemes in terminal

2014-12-11 Fir de Conversatie Bruno Sutic 
I'm not sure if I add any value to the discussion here, but I would be so glad 
to see this merged/included into vim.

Also, there's a discussion about this on vim reddit here: 
http://www.reddit.com/r/vim/comments/2ozwe4/24_bit_vim_in_osx_iterm2_a_reality/

(that's how I found about this in the first place).

On Saturday, January 26, 2013 10:09:49 PM UTC+1, ZyX wrote:
 The following patch adds support for guifg/guibg properties of highlight 
 groups in ISO-8613-3 (at least 
 http://invisible-island.net/xterm/ctlseqs/ctlseqs.html page states it is 
 ISO-8613-3) supporting terminals (only Konsole and ConEmu are currently known 
 to support this). This patch have two intentions: add actual gui colorschemes 
 support for konsole users and create a reason for other terminal emulator 
 authors to add support for true color.
 
 diff -r 274c841f033a -r f15e368e2fc6 runtime/doc/options.txt
 --- a/runtime/doc/options.txt Fri Jan 25 20:11:01 2013 +0100
 +++ b/runtime/doc/options.txt Sun Jan 27 00:44:09 2013 +0400
 @@ -3341,6 +3341,16 @@
   This option cannot be set from a |modeline| or in the |sandbox|, for
   security reasons.
  
 + *'guicolors'* *'gcol'*
 +'guicolors' 'gcol'   boolean (default off)
 + global
 + {not in Vi}
 + {not available when compiled without the 
 + |+termtruecolor| feature}
 + When on, uses |highlight-guifg| and |highlight-guibg| attributes in 
 + terminal (thus using 24-bit color). Requires ISO-8613-3 compatible 
 + terminal.
 +
   *'guicursor'* *'gcr'* *E545* *E546* *E548* *E549*
  'guicursor' 'gcr'string  (default n-v-c:block-Cursor/lCursor,
   ve:ver35-Cursor,
 diff -r 274c841f033a -r f15e368e2fc6 runtime/doc/various.txt
 --- a/runtime/doc/various.txt Fri Jan 25 20:11:01 2013 +0100
 +++ b/runtime/doc/various.txt Sun Jan 27 00:44:09 2013 +0400
 @@ -399,6 +399,7 @@
  m  *+tcl/dyn*Tcl interface |tcl-dynamic| |/dyn|
 *+terminfo*   uses |terminfo| instead of termcap
  N  *+termresponse*   support for |t_RV| and |v:termresponse|
 +m  *+termtruecolor*  24-bit color in xterm-compatible terminals support
  N  *+textobjects*|text-objects| selection
 *+tgetent*non-Unix only: able to use external termcap
  N  *+title*  Setting the window 'title' and 'icon'
 diff -r 274c841f033a -r f15e368e2fc6 src/auto/configure
 --- a/src/auto/configure  Fri Jan 25 20:11:01 2013 +0100
 +++ b/src/auto/configure  Sun Jan 27 00:44:09 2013 +0400
 @@ -1,11 +1,9 @@
  #! /bin/sh
  # Guess values for system-dependent variables and create Makefiles.
 -# Generated by GNU Autoconf 2.65.
 +# Generated by GNU Autoconf 2.69.
  #
  #
 -# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
 -# 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation,
 -# Inc.
 +# Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
  #
  #
  # This configure script is free software; the Free Software Foundation
 @@ -89,6 +87,7 @@
  IFS=  $as_nl
  
  # Find who we are.  Look in the path if we contain no directory separator.
 +as_myself=
  case $0 in #((
*[\\/]* ) as_myself=$0 ;;
*) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
 @@ -133,6 +132,31 @@
  # CDPATH.
  (unset CDPATH) /dev/null 21  unset CDPATH
  
 +# Use a proper internal environment variable to ensure we don't fall
 +  # into an infinite loop, continuously re-executing ourselves.
 +  if test x${_as_can_reexec} != xno  test x$CONFIG_SHELL != x; then
 +_as_can_reexec=no; export _as_can_reexec;
 +# We cannot yet assume a decent shell, so we have to provide a
 +# neutralization value for shells without unset; and this also
 +# works around shells that cannot unset nonexistent variables.
 +# Preserve -v and -x to the replacement shell.
 +BASH_ENV=/dev/null
 +ENV=/dev/null
 +(unset BASH_ENV) /dev/null 21  unset BASH_ENV ENV
 +case $- in # 
 +  *v*x* | *x*v* ) as_opts=-vx ;;
 +  *v* ) as_opts=-v ;;
 +  *x* ) as_opts=-x ;;
 +  * ) as_opts= ;;
 +esac
 +exec $CONFIG_SHELL $as_opts $as_myself ${1+$@}
 +# Admittedly, this is quite paranoid, since all the known shells bail
 +# out after a failed `exec'.
 +$as_echo $0: could not re-execute with $CONFIG_SHELL 2
 +as_fn_exit 255
 +  fi
 +  # We don't want this to propagate to other subprocesses.
 +  { _as_can_reexec=; unset _as_can_reexec;}
  if test x$CONFIG_SHELL = x; then
as_bourne_compatible=if test -n \\${ZSH_VERSION+set}\  (emulate sh) 
 /dev/null 21; then :
emulate sh
 @@ -166,7 +190,8 @@
  else
exitcode=1; echo positional parameters were not saved.
  fi
 -test x\$exitcode = x0 || exit 1
 +test x\$exitcode = x0 || exit 1
 +test -x / || exit 1
as_suggested=  
 as_lineno_1=;as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested 
 as_lineno_1a=\$LINENO

Bracketed paste for terminal vim

2014-07-11 Fir de Conversatie Bruno Sutic 
Hello!

I got really excited about one discovery, so I'd like to start a discussion and 
see if there is a possible fit into vim's feature roadmap.

So, apparently all modern terminals have a feature to tell programs when 
something is pasted.
Terminal does this by wrapping the paste content with sequences \e[200~ and 
\e[201~.

Because of this, terminal programs (specifically vim) *could* tell a difference 
when something is typed vs pasted.
This is nicely explained in the blog article here: 
http://cirw.in/blog/bracketed-paste

And this is not just theory - the same guy wrote a small plugin that enables 
this for vim, link: https://github.com/ConradIrwin/vim-bracketed-paste  (it's 
less than 30 lines of viml)

I tried the plugin and it works great! (I'm on OS X, Terminal.app)
The punch line is: as a terminal vim user, I don't have to use `:set paste` 
ever again!

Now, what do you think: does this feature belong in the plugin domain or 
should it eventually be part of vim?

I'm just a user, so I couldn't help with any of that, but I like the feature so 
much - maybe my enthusiasm will infect someone else! :)

Bruno

-- 
-- 
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: Bracketed paste for terminal vim

2014-07-11 Fir de Conversatie Bruno Sutic 
On Friday, July 11, 2014 11:35:24 PM UTC+2, Bram Moolenaar wrote:
 Bruno Sutic wrote:
 
 
 
  I got really excited about one discovery, so I'd like to start a
 
  discussion and see if there is a possible fit into vim's feature
 
  roadmap.
 
  
 
  So, apparently all modern terminals have a feature to tell programs
 
  when something is pasted.
 
  Terminal does this by wrapping the paste content with sequences
 
  \e[200~ and \e[201~.
 
  
 
  Because of this, terminal programs (specifically vim) *could* tell a
 
  difference when something is typed vs pasted.  This is nicely
 
  explained in the blog article here:
 
  http://cirw.in/blog/bracketed-paste
 
  
 
  And this is not just theory - the same guy wrote a small plugin that
 
  enables this for vim, link:
 
  https://github.com/ConradIrwin/vim-bracketed-paste  (it's less than 30
 
  lines of viml)
 
  
 
  I tried the plugin and it works great! (I'm on OS X, Terminal.app)
 
  The punch line is: as a terminal vim user, I don't have to use `:set
 
  paste` ever again!
 
  
 
  Now, what do you think: does this feature belong in the plugin
 
  domain or should it eventually be part of vim?
 
  
 
  I'm just a user, so I couldn't help with any of that, but I like the
 
  feature so much - maybe my enthusiasm will infect someone else! :)
 
 
 
 Sounds useful.
 
 
 
 Since what version of xterm and screen is this supported?  I suspect
 
 older versions do not support it.
 
 
 
 -- 
 
 BEDEVERE: Look!  It's the old man from scene 24 - what's he Doing here?
 
 ARTHUR:   He is the keeper of the Bridge.  He asks each traveler five
 
   questions ...
 
 GALAHAD:  Three questions.
 
  Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
 
 
 
  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
 
 ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
 
 \\\  an exciting new programming language -- http://www.Zimbu.org///
 
  \\\help me help AIDS victims -- http://ICCF-Holland.org///

Hi Bram,
glad you think it's useful.

So I just googled it:
it turns out this is available in xterm for years. Here's the blog post from 
2009 showing how to make it work with vim and xterm:
http://help.lockergnome.com/linux/Bug-504244-Vim-script-turn-xterm-bracketed-paste-mode--ftopict511918.html
I found other online resources mentioning this in 2010, 2011. But the above 
link is the earliest.

About screen - here's the patch from March 2013, so I guess it's been added 
there just recently:
https://lists.gnu.org/archive/html/screen-devel/2013-03/msg0.html

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

Need help with understanding vimscript code snippet

2014-03-29 Fir de Conversatie Bruno Sutic 
Hi,
I'm posting this to vim_dev because it is related to plugin development 
(apologies if it should go to vim_use).

Recently, I discovered Tim Pope's vim-rsi plugin 
(https://github.com/tpope/vim-rsi).
I was mind-blown to discover you can actually use Meta (alt key) mappings in 
terminal vim. I tried to set this up before myself, but google searches weren't 
returning anything useful.

Now I'm trying to hack/tweak vim-rsi, but I'm utterly puzzled by the following 
snippet:
https://github.com/tpope/vim-rsi/blob/master/plugin/rsi.vim#L49-55

:helpgrep does not return anything on F31
Does anyone know how that works? What are those Fxx?

Thanks

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

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

Re: [bug] netrw with netrw_liststyle = 3

2013-11-20 Fir de Conversatie Bruno Sutic 
Hi,
thank you for the notice. I've been using netrw v150j for a couple of days
now, and I haven't had this problem.
Thank you for fixing it!


On Tue, Nov 19, 2013 at 4:52 PM, Charles Campbell 
charles.e.campb...@nasa.gov wrote:

 Charles E Campbell wrote:

 Bruno Sutic wrote:

 Hi,
 I discovered netrw  liststyle=3 aka tree style listing a couple days
 ago. (I love it!)
 Ever since, I've had a weird issue where I would open a file and it
 would be completely blank.  snip


 I'll look into it (and I was able to duplicate it -- thanks for the good
 directions).

 Hello!

 I'm not sure if I replied to you on this yet -- please try v150j of netrw,
 available from my website: http://www.drchip.org/
 astronaut/vim/index.html#NETRW .  I believe that it fixes this problem
 (there was also a bugtracker entry on this same problem).

 Regards,
 Charles Campbell


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

 --- You received this message because you are subscribed to a topic in the
 Google Groups vim_dev group.
 To unsubscribe from this topic, visit https://groups.google.com/d/
 topic/vim_dev/07wTmXWz2EU/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 vim_dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


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

[question] filetype name with dot (example included)

2013-10-08 Fir de Conversatie Bruno Sutic 
Hello vimers!
I'm using vim-handlebars filetype plugin, link to source: 
https://github.com/nono/vim-handlebars
I noticed the plugin is setting filetype with a dot in the name.
Link to the relevant line in the source code:
https://github.com/nono/vim-handlebars/blob/master/ftdetect/handlebars.vim#L2

Vim seems to be fine with that (see :h 'ft'), but the line above does not seem 
right. It is essentially loading 2 filetypes, but then running additional 
files with runtime!, which seems redundant.

I downloaded the project locally and experimented with removing the runtime 
from the line above.
But it seems I can't 'nail' all the functionality: either handlebars syntax is 
missing, or 'matchit' plugin support for html or handlebars is not working.
Basically, I don't know how to use this and the docs are terse.

My question is: what is the idiomatic, proper way in vim to use filetype with 
dot (2 filetypes at once)?
Is there a (good) plugin that uses this trick in a different way, so I can 
learn from it? Do you know what might be the problem here?

Any help with this is appreciated!
Bruno

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

[bug] netrw with netrw_liststyle = 3

2013-10-02 Fir de Conversatie Bruno Sutic 
Hi,
I discovered netrw  liststyle=3 aka tree style listing a couple days ago. (I 
love it!)
Ever since, I've had a weird issue where I would open a file and it would be 
completely blank. When I hit :e! content of the file appears as it should.
I decided to investigate this a bit, and it turns out there might be a bug with 
this listing style (n!).

Anyway, here are the steps I came up to consistently reproduce the bug:

$ vim -u NORC -N
:let g:netrw_liststyle = 3
:Ex
enter on file1  - file 1 content appears normally
:Ex
enter on file1 - file 1 content appears normally
:Ex
enter on file1 - now file 1 buffer is blank. In the bottom of the screen 
there's a [modified] even though I have not modified a file!
:e!   - file 1 content appears

There's been other weird behaviors when entering buffers, but this one can be 
reproduced consistently in least number of steps.

Here's the info about the plugin and vim version:
- netrw v150f   (downloaded directly from maintainers website)
- vim 7.4, patches 1 - 41, compiled with features 'huge'

I can provide whole ':version' list if necessary.

Please let me know if I can be of more help regarding 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/groups/opt_out.

Re: Alternate file with netrw buffer in Vim 7.4 - bug or change?

2013-08-26 Fir de Conversatie Bruno Sutic 
Hi guys,
I prefer the old way, but I'm sure everyone will be happy as long as there is a 
setting to tweak this.

On Monday, August 26, 2013 8:51:33 PM UTC-7, Tony Mechelynck wrote:
 On 27/08/13 03:39, tooth pik wrote:
 
  On Mon, Aug 26, 2013 at 03:39:22PM -0700, Gary Johnson wrote:
 
  On 2013-08-26, David Fishburn wrote:
 
  On Aug 26, 2013, at 1:34 PM, Bram Moolenaar wrote:
 
  Bruno Sutic wrote:
 
 
 
  What do you think is this a bug or new behavior?
 
  Thanks
 
 
 
  I also see this problem.  I prefer the old way, I often go back to the
 
  directory view.  I thought Charles had changed it...
 
 
 
 
 
  I prefer the new way.
 
  After opening the file I explored to I would want to toggle back
 
  and forth between the last file edited not explorer.
 
 
 
  As long as we're voting, I prefer the old way.
 
 
 
  +1 for the new way -- if I want netrw back I'll ask for it
 
 
 
 
 
 Abstention.
 
 
 
 Either way is good for me. If I want to refer to more than one file from 
 
 a netrw directory listing I'll open them with o (i.e. in a new window) 
 
 then switch windows to get at them, either by clicking the respective 
 
 status lines or thanks to the following mappings defined in my vimrc:
 
 
 
go to next window down or right
 
   map F11   C-Ww
 
go to next window left or up
 
   map S-F11 C-WW
 
 
 
 Best regards,
 
 Tony.
 
 -- 
 
 inoculatte:
 
   To take coffee intravenously when you are running late.

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

Alternate file with netrw buffer in Vim 7.4 - bug or change?

2013-08-25 Fir de Conversatie Bruno Sutic 
Hi,
I noticed a new behavior with vim 7.4 and netrw plugin.
Alternate buffer command (normal mode C-^ key) works differently than in vim 
7.3.

Here are the steps how to see the difference:
*vim 7.3*
1. /usr/bin/vim -u NORC -N (starting vim7.3)
2. :e Gemfile   (open any random file)
3. :E(show netrw plugin buffer)
4. in netrw buffer browse and open other random file - Gemfile.lock
5. C-^ (alternate buffer)
At this point vim shows netrw buffer opened in step 3

*vim 7.4* (the same steps)
1. vim -u NORC -N (starting vim7.4)
2. :e Gemfile
3. :E
4. in netrw buffer browse and open other random file - Gemfile.lock
5. C-^
At this point vim 7.4 shows 'Gemfile' file opened in step 2

What do you think is this a bug or new behavior?
Thanks

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

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