Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

vimdev · Vim (Vi IMproved) text editor developers list

The Yahoo! Groups Product Blog

Check it out!

Group Information

? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 67116 - 67145 of 71394   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#67116 From: Roland Puntaier <roland.puntaier@...>
Date: Sun Nov 18, 2012 2:25 pm
Subject: increase font size and you don't see the command line any more (bug?)
roland.puntaier@...
Send Email Send Email
 
Hi!

One probably doesn't change the font size very often, but I recently did and
could not see the command line any more. Looking into the code I've seen
that vim increases the window size instead of adapting the line number,
but interestingly not so for windows. I happen to use Xmonad,
where window size does not change, so I first regarded this as a bug.
Still the behavior seems not sensible to me. When I change the font size
I don't think of changing the window size.
Or: The windows size seems more important to me than the line number.

If you agree, please apply the following patch:

diff -r 57e8b75298d6 src/gui.c
--- a/src/gui.c    Tue Oct 23 05:35:34 2012 +0200
+++ b/src/gui.c    Sun Nov 18 11:34:58 2012 +0100
@@ -905,13 +905,7 @@
   # endif
           gui_mch_set_font(gui.norm_font);
   #endif
-    gui_set_shellsize(FALSE,
-#ifdef MSWIN
-        TRUE
-#else
-        FALSE
-#endif
-        , RESIZE_BOTH);
+    gui_set_shellsize(FALSE, TRUE, RESIZE_BOTH);
       }

       return ret;



Regards,
Roland

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

#67117 From: Roland Puntaier <roland.puntaier@...>
Date: Sun Nov 18, 2012 2:34 pm
Subject: AttributeError module object has no attribute stderror
roland.puntaier@...
Send Email Send Email
 
Hello,

the above error is issued when closing gvim with python3 configured (for
vim it's displayed too short to be seen). With this patch it's gone:

diff -r 57e8b75298d6 src/if_python3.c
--- a/src/if_python3.c    Tue Oct 23 05:35:34 2012 +0200
+++ b/src/if_python3.c    Sun Nov 18 10:11:49 2012 +0100
@@ -657,7 +657,6 @@
   static PyObject *globals;

   static int PythonIO_Init(void);
-static void PythonIO_Fini(void);
   PyMODINIT_FUNC Py3Init_vim(void);

   /******************************************************
@@ -685,7 +684,6 @@
       // acquire lock before finalizing
       pygilstate = PyGILState_Ensure();

-    PythonIO_Fini();
       Py_Finalize();
       }

@@ -989,13 +987,6 @@
       return PythonIO_Init_io();
   }

-    static void
-PythonIO_Fini(void)
-{
-    PySys_SetObject("stdout", NULL);
-    PySys_SetObject("stderr", NULL);
-}
-
   /******************************************************
    * 3. Implementation of the Vim module for Python
    */

Regards,
Roland

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

#67118 From: glts <676c7473@...>
Date: Sun Nov 18, 2012 4:50 pm
Subject: Re: Implementation of script support for non-uniform tabstops
676c7473@...
Send Email Send Email
 
Hi

On Saturday, November 17, 2012 7:02:23 PM UTC+1, T. Banner wrote:
> I am aware that elastic tabstops is not something many people use
> (yet). Still, for me it is a very nice feature to use with a gedit
> plugin, but since my favourite editor is vim, I was hoping that
> support for this might appear here, in the form of introducing
> non-uniform tabstop support.

A quick search of this list tells me that there is a patch for elastic
tabstops floating around. See here:

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

You can apply the patch to your own build of Vim and see how it goes!

glts

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

#67119 From: Daniel Harding <dharding@...>
Date: Sun Nov 18, 2012 7:09 pm
Subject: Re: increase font size and you don't see the command line any more (bug?)
dharding@...
Send Email Send Email
 
This is exactly the same as a patch I have been using on my Linux system
for some time, to work around an issue where setting lines after gvim
has started does not limit the window size to the size of the screen
(which can result in the same symptom - the command line being below the
bottom of the screen).  It does limit the size on Windows (which is what
the documentation says it should do).  I posted about this awhile back
(under the subject 'Trying to understand :set lines=999 behavior') but
no one was able to explain why there is a difference between Windows and
non-Windows platforms, nor was there any input as to whether the
behavior should be changed or a note added to the documentation.  I
support changing the behavior, as long as no one can come up with a
reason as to why it would break backwards compatibility.  Anyway, thanks
for the patch - I was intending to post mine, but simply hadn't gotten
around to it.

Cheers,

Daniel

Roland Puntaier wrote:
> Hi!
>
> One probably doesn't change the font size very often, but I recently did and
> could not see the command line any more. Looking into the code I've seen
> that vim increases the window size instead of adapting the line number,
> but interestingly not so for windows. I happen to use Xmonad,
> where window size does not change, so I first regarded this as a bug.
> Still the behavior seems not sensible to me. When I change the font size
> I don't think of changing the window size.
> Or: The windows size seems more important to me than the line number.
>
> If you agree, please apply the following patch:
>
> diff -r 57e8b75298d6 src/gui.c
> --- a/src/gui.c    Tue Oct 23 05:35:34 2012 +0200
> +++ b/src/gui.c    Sun Nov 18 11:34:58 2012 +0100
> @@ -905,13 +905,7 @@
>    # endif
>            gui_mch_set_font(gui.norm_font);
>    #endif
> -    gui_set_shellsize(FALSE,
> -#ifdef MSWIN
> -        TRUE
> -#else
> -        FALSE
> -#endif
> -        , RESIZE_BOTH);
> +    gui_set_shellsize(FALSE, TRUE, RESIZE_BOTH);
>        }
>
>        return ret;
>
>
>
> Regards,
> Roland
>


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

#67120 From: So8res <so8res@...>
Date: Sun Nov 18, 2012 9:24 pm
Subject: Vim patches page link is broken
so8res@...
Send Email Send Email
 
On the vim patches page [1] the link to vim_dev mailinglist patches [2] is
broken.

More generally, where should such website bugs be reported and how are they
fixed?

[1] http://www.vim.org/patches.php
[2] https://groups.google.com/group/vim_dev/web/vim-patches

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

#67121 From: Nick Gravgaard <me@...>
Date: Sun Nov 18, 2012 10:23 pm
Subject: Re: Implementation of script support for non-uniform tabstops
me@...
Send Email Send Email
 
> > I am aware that elastic tabstops is not something many people use
> > (yet). Still, for me it is a very nice feature to use with a gedit
> > plugin, but since my favourite editor is vim, I was hoping that
> > support for this might appear here, in the form of introducing
> > non-uniform tabstop support.
>
> A quick search of this list tells me that there is a patch for elastic
> tabstops floating around.

I'd love to see elastic tabstops get added to Vim, but if it's not going to get
added to the main code base, could we at least have the ability to set
non-uniform tabstops on different lines? Many text widgets have this
functionality now, so it's a shame that Vim cannot do this yet. Not only would
this make elastic tabstops easier to implement, but it would also be useful for
the implementation of many other table and layout related features.

Nick

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

#67122 From: Ben Fritz <fritzophrenic@...>
Date: Mon Nov 19, 2012 12:28 am
Subject: Re: Implementation of script support for non-uniform tabstops
fritzophrenic@...
Send Email Send Email
 
On Sunday, November 18, 2012 4:23:29 PM UTC-6, Nick Gravgaard wrote:
> > > I am aware that elastic tabstops is not something many people use
>
> > > (yet). Still, for me it is a very nice feature to use with a gedit
>
> > > plugin, but since my favourite editor is vim, I was hoping that
>
> > > support for this might appear here, in the form of introducing
>
> > > non-uniform tabstop support.
>
> >
>
> > A quick search of this list tells me that there is a patch for elastic
>
> > tabstops floating around.
>
>
>
> I'd love to see elastic tabstops get added to Vim, but if it's not going to
get added to the main code base, could we at least have the ability to set
non-uniform tabstops on different lines? Many text widgets have this
functionality now, so it's a shame that Vim cannot do this yet. Not only would
this make elastic tabstops easier to implement, but it would also be useful for
the implementation of many other table and layout related features.
>
>

I did a little thinking about this. Obviously there is not a good way to STORE
these non-uniform tabstops on a line-by-line basis in a file.

But maybe there could be 2 new features that could combine together to create
the ability to do things like elastic tabstops or tables in the middle of text
nicely, without backwards-incompatible changes and keeping in the spirit of
other Vim options:

1. Implement variable-width tabstops by allowing a comma-separated list to be
used as a value for 'tabstop'. For example, setting ts=4,2,8 would have the
first tab in the line stop at column 4, the next stop at column 6, and all other
tabs stop at 14, 22, 30, ...
2. Implement a 'tabstopexpr' option which would be set to an expression giving
the value of 'tabstop' to use for v:lnum (which could potentially be a different
comma-separated list for each line depending on context)

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

#67123 From: "John Beckett" <johnb.beckett@...>
Date: Mon Nov 19, 2012 4:52 am
Subject: RE: Vim patches page link is broken
johnb.beckett@...
Send Email Send Email
 
So8res wrote:
> On the vim patches page [1] the link to vim_dev mailinglist
> patches [2] is broken.
>
> More generally, where should such website bugs be reported
> and how are they fixed?
>
> [1] http://www.vim.org/patches.php
> [2] https://groups.google.com/group/vim_dev/web/vim-patches

Thanks, reporting vim.org problems here is good, or direct to
Bram, or direct to me and I will arrange with Bram.

Bram: Do you want me to remove the "Other Vim patches" section
from [1] (and email you when done)? I don't think the list was
established elsewhere, so it needs to be removed?

John

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

#67124 From: Sergey Khorev <sergey.khorev@...>
Date: Mon Nov 19, 2012 9:38 am
Subject: Re: Vim patches page link is broken
sergey.khorev@...
Send Email Send Email
 
> Thanks, reporting vim.org problems here is good, or direct to
>
> Bram, or direct to me and I will arrange with Bram.

Speaking of the site, does it also make sense to remove tip search in "Search
for Vim Tips" section? Probably a link to the wiki would be enough.

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

#67125 From: Nick Gravgaard <me@...>
Date: Mon Nov 19, 2012 1:43 pm
Subject: Re: Implementation of script support for non-uniform tabstops
me@...
Send Email Send Email
 
On Mon, Nov 19, 2012, at 0:28, Ben Fritz wrote:
> On Sunday, November 18, 2012 4:23:29 PM UTC-6, Nick Gravgaard wrote:
> > > > I am aware that elastic tabstops is not something many people use
> > > > (yet). Still, for me it is a very nice feature to use with a gedit
> > > > plugin, but since my favourite editor is vim, I was hoping that
> > > > support for this might appear here, in the form of introducing
> > > > non-uniform tabstop support.
> > >
> > > A quick search of this list tells me that there is a patch for elastic
> > > tabstops floating around.
> >
> > I'd love to see elastic tabstops get added to Vim, but if it's not going to
get added to the main code base, could we at least have the ability to set
non-uniform tabstops on different lines? Many text widgets have this
functionality now, so it's a shame that Vim cannot do this yet. Not only would
this make elastic tabstops easier to implement, but it would also be useful for
the implementation of many other table and layout related features.
>
> I did a little thinking about this. Obviously there is not a good way to
> STORE these non-uniform tabstops on a line-by-line basis in a file.
>
> But maybe there could be 2 new features that could combine together to
> create the ability to do things like elastic tabstops or tables in the
> middle of text nicely, without backwards-incompatible changes and keeping
> in the spirit of other Vim options:
>
> 1. Implement variable-width tabstops by allowing a comma-separated list
> to be used as a value for 'tabstop'. For example, setting ts=4,2,8 would
> have the first tab in the line stop at column 4, the next stop at column
> 6, and all other tabs stop at 14, 22, 30, ...
> 2. Implement a 'tabstopexpr' option which would be set to an expression
> giving the value of 'tabstop' to use for v:lnum (which could potentially
> be a different comma-separated list for each line depending on context)

This sounds interesting. Are there any other Vim settings that work on
different lines? If so, how do they work?

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

#67126 From: Ben Fritz <fritzophrenic@...>
Date: Mon Nov 19, 2012 2:58 pm
Subject: Re: Implementation of script support for non-uniform tabstops
fritzophrenic@...
Send Email Send Email
 
On Monday, November 19, 2012 7:43:32 AM UTC-6, Nick Gravgaard wrote:
> > But maybe there could be 2 new features that could combine together to
>
> > create the ability to do things like elastic tabstops or tables in the
>
> > middle of text nicely, without backwards-incompatible changes and keeping
>
> > in the spirit of other Vim options:
>
> >
>
> > 1. Implement variable-width tabstops by allowing a comma-separated list
>
> > to be used as a value for 'tabstop'. For example, setting ts=4,2,8 would
>
> > have the first tab in the line stop at column 4, the next stop at column
>
> > 6, and all other tabs stop at 14, 22, 30, ...
>
> > 2. Implement a 'tabstopexpr' option which would be set to an expression
>
> > giving the value of 'tabstop' to use for v:lnum (which could potentially
>
> > be a different comma-separated list for each line depending on context)
>
>
>
> This sounds interesting. Are there any other Vim settings that work on
>
> different lines? If so, how do they work?

The ones that come to mind immediately are indentexpr and foldexpr, and to a
lesser extent formatexpr. I think indentexpr is the most similar to what
tabstopexpr would do.

AFAIK for indentexpr and foldexpr, Vim evaluates the expression on every line
starting at the first, setting v:lnum to the line being evaluated for each line.
Normally a user sets the expression to a function, like ":set
indentexpr=MyFunIndent(v:lnum)".

If these two options were to be implemented, I imagine elastic tabstops could be
done fairly simply in vimscript by using getline() to get some context around
v:lnum and returning an appropriate string for the tabstops in the line.

I have no idea how complex these two options would be to implement.

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

#67127 From: Matthew Winn <vim@...>
Date: Mon Nov 19, 2012 4:21 pm
Subject: Re: Implementation of script support for non-uniform tabstops
vim@...
Send Email Send Email
 
On Sun, 18 Nov 2012 16:28:19 -0800 (PST), Ben Fritz
<fritzophrenic@...> wrote:

> 1. Implement variable-width tabstops by allowing a comma-separated list to be
used as a value for 'tabstop'. For example, setting ts=4,2,8 would have the
first tab in the line stop at column 4, the next stop at column 6, and all other
tabs stop at 14, 22, 30, ...

I implemented a patch to do this a few years ago, when I was out of
work and decided to grab something off the TODO list to keep me busy.
(It's since been taken over by someone else.) During the initial
discussion it was decided that it wasn't a good idea to have multiple
values in the "tabstop" option in case someone tried to treat its
value as a number, so I eventually settled on "vartabstop" as the name
of the option.

--
Matthew Winn

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

#67128 From: "Christian Brabandt" <cblists@...>
Date: Mon Nov 19, 2012 5:02 pm
Subject: Re: Implementation of script support for non-uniform tabstops
cblists@...
Send Email Send Email
 
On Mon, November 19, 2012 17:21, Matthew Winn wrote:
> On Sun, 18 Nov 2012 16:28:19 -0800 (PST), Ben Fritz
> <fritzophrenic@...> wrote:
>
>> 1. Implement variable-width tabstops by allowing a comma-separated list
>> to be used as a value for 'tabstop'. For example, setting ts=4,2,8 would
>> have the first tab in the line stop at column 4, the next stop at column
>> 6, and all other tabs stop at 14, 22, 30, ...
>
> I implemented a patch to do this a few years ago, when I was out of
> work and decided to grab something off the TODO list to keep me busy.
> (It's since been taken over by someone else.) During the initial
> discussion it was decided that it wasn't a good idea to have multiple
> values in the "tabstop" option in case someone tried to treat its
> value as a number, so I eventually settled on "vartabstop" as the name
> of the option.

Thanks for your work. Are you still maintaining this patch? Or where can
one find the latest patch. I found one patch against Vim 7.1 I think,
but I figured, it probably doesn't apply anymore and it was pretty big.

I think, once this patch is included, adding a 'tabstopexpr' setting isn't
much work. That should be reasonable, just replace a bunch of buf->b_p_ts
by a call to a function which returns the tabstop setting.

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

#67129 From: Sergey Khorev <sergey.khorev@...>
Date: Mon Nov 19, 2012 5:09 pm
Subject: Update for MzScheme interface
sergey.khorev@...
Send Email Send Email
 
Hi,

Attached is an update for MzScheme interface. It features:

* Improved interaction with garbage collector in newer versions of
Racket: leaving SIGSEGV to GC, references to buffer/windows are now
truly uncollectable.
* Simplified and cleaned up macros: now Vim uses the latest API and
compatibility macros allow to use older versions of MzScheme.
Previously we used macros that made new API look like an older one.
* eval function of the interface is now able to convert Vim funcrefs
into Scheme functions

--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?

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

#67130 From: Lech Lorens <lech.lorens@...>
Date: Mon Nov 19, 2012 5:15 pm
Subject: Re: Implementation of script support for non-uniform tabstops
lech.lorens@...
Send Email Send Email
 
On 19 November 2012 18:02, Christian Brabandt <cblists@...> wrote:
> On Mon, November 19, 2012 17:21, Matthew Winn wrote:
>> I implemented a patch to do this a few years ago, when I was out of
>> work and decided to grab something off the TODO list to keep me busy.
>> (It's since been taken over by someone else.) During the initial
>> discussion it was decided that it wasn't a good idea to have multiple
>> values in the "tabstop" option in case someone tried to treat its
>> value as a number, so I eventually settled on "vartabstop" as the name
>> of the option.
>
> Thanks for your work. Are you still maintaining this patch? Or where can
> one find the latest patch. I found one patch against Vim 7.1 I think,
> but I figured, it probably doesn't apply anymore and it was pretty big.

It might be me that Matt is referring to as a person that took over
maintaining the feature. In fact I only updated the patch to be
applicable to the source code of Vim as of 2010. Look for the branch
called feat/var-tabstops in vim_extended at repo.or.cz:
http://repo.or.cz/w/vim_extended.git

Cheers,
Lech

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

#67131 From: Charles Campbell <Charles.E.Campbell@...>
Date: Mon Nov 19, 2012 5:22 pm
Subject: [ptch] permit subdirectories with help
Charles.E.Campbell@...
Send Email Send Email
 
Hello!

I've attached a patch which allows subdirectories with help. Actually,
the tags system already permitted subdirectories; what this patch does
is extend helptags to search through subdirectories, creating
appropriate tags.

The patch is experimental, and I've only tested it under Linux (I hope
to test it under Windows later).  Needs testing under other o/s'es!  I
don't have access to macos or vms, for example.

Regards,
Chip Campbell

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

#67132 From: Ben Fritz <fritzophrenic@...>
Date: Mon Nov 19, 2012 6:08 pm
Subject: mail.vim filetype needs to set 'comments' option
fritzophrenic@...
Send Email Send Email
 
Bram, it came up on vim_use (
https://groups.google.com/d/topic/vim_use/XnKfkjc9bSY/discussion ) that the
mail.vim filetype plugin does not currently set the 'comments' option.

I think you should add:

setl comments+=n:>

to the mail.vim ftplugin you maintain in case the user or another ftplugin has
changed the 'comments' option from the default value, so that gq works as
expected if the user simply sets the filetype.

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

#67133 From: Christian Brabandt <cblists@...>
Date: Mon Nov 19, 2012 6:47 pm
Subject: Re: mail.vim filetype needs to set 'comments' option
cblists@...
Send Email Send Email
 
Hi Ben!

On Mo, 19 Nov 2012, Ben Fritz wrote:

> Bram, it came up on vim_use (
https://groups.google.com/d/topic/vim_use/XnKfkjc9bSY/discussion ) that the
mail.vim filetype plugin does not currently set the 'comments' option.
>
> I think you should add:
>
> setl comments+=n:>
>
> to the mail.vim ftplugin you maintain in case the user or another
> ftplugin has changed the 'comments' option from the default value, so
> that gq works as expected if the user simply sets the filetype.

And also set b:undo_ftplugin accordingly.

regards,
Christian
--
Es muß für einen Architekten schon blöd sein, wenn ihm dauernd was einfällt.

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

#67134 From: Christian Brabandt <cblists@...>
Date: Mon Nov 19, 2012 6:50 pm
Subject: Re: Implementation of script support for non-uniform tabstops
cblists@...
Send Email Send Email
 
Hi Lech!

On Mo, 19 Nov 2012, Lech Lorens wrote:

> On 19 November 2012 18:02, Christian Brabandt <cblists@...> wrote:
> > On Mon, November 19, 2012 17:21, Matthew Winn wrote:
> >> I implemented a patch to do this a few years ago, when I was out of
> >> work and decided to grab something off the TODO list to keep me busy.
> >> (It's since been taken over by someone else.) During the initial
> >> discussion it was decided that it wasn't a good idea to have multiple
> >> values in the "tabstop" option in case someone tried to treat its
> >> value as a number, so I eventually settled on "vartabstop" as the name
> >> of the option.
> >
> > Thanks for your work. Are you still maintaining this patch? Or where can
> > one find the latest patch. I found one patch against Vim 7.1 I think,
> > but I figured, it probably doesn't apply anymore and it was pretty big.
>
> It might be me that Matt is referring to as a person that took over
> maintaining the feature. In fact I only updated the patch to be
> applicable to the source code of Vim as of 2010. Look for the branch
> called feat/var-tabstops in vim_extended at repo.or.cz:
> http://repo.or.cz/w/vim_extended.git

I thought that Repo was closed by Markus some time ago. Anyhow, at a
first look, it looks like it is still active (although unmaintained),
but it seems to be seriously broken, at least I get a lot of

404 Not Found - Missing one of the blob diff parameters

errors.

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

#67135 From: Lech Lorens <lech.lorens@...>
Date: Mon Nov 19, 2012 7:33 pm
Subject: Re: Implementation of script support for non-uniform tabstops
lech.lorens@...
Send Email Send Email
 
On 19 November 2012 19:50, Christian Brabandt <cblists@...> wrote:
> Hi Lech!
>
> On Mo, 19 Nov 2012, Lech Lorens wrote:
>> It might be me that Matt is referring to as a person that took over
>> maintaining the feature. In fact I only updated the patch to be
>> applicable to the source code of Vim as of 2010. Look for the branch
>> called feat/var-tabstops in vim_extended at repo.or.cz:
>> http://repo.or.cz/w/vim_extended.git
>
> I thought that Repo was closed by Markus some time ago. Anyhow, at a
> first look, it looks like it is still active (although unmaintained),
> but it seems to be seriously broken, at least I get a lot of
>
> 404 Not Found - Missing one of the blob diff parameters
>
> errors.
>
> regards,
> Christian

Hi Christian,

I guess this is a problem with the web interface at repo.or.cz, not
with the git repository itself. I cloned the repository without any
problems from git://repo.or.cz/vim_extended.git

Cheers,
Lech

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

#67136 From: Bram Moolenaar <Bram@...>
Date: Mon Nov 19, 2012 8:24 pm
Subject: RE: Vim patches page link is broken
Bram@...
Send Email Send Email
 
John Beckett wrote:

> So8res wrote:
> > On the vim patches page [1] the link to vim_dev mailinglist
> > patches [2] is broken.
> >
> > More generally, where should such website bugs be reported
> > and how are they fixed?
> >
> > [1] http://www.vim.org/patches.php
> > [2] https://groups.google.com/group/vim_dev/web/vim-patches
>
> Thanks, reporting vim.org problems here is good, or direct to
> Bram, or direct to me and I will arrange with Bram.
>
> Bram: Do you want me to remove the "Other Vim patches" section
> from [1] (and email you when done)? I don't think the list was
> established elsewhere, so it needs to be removed?

I thought we copied the patches to somewhere...

If we don't have this list somewhere I think we should delete that
section.  Let me know if you have an update for the file.

--
Portable Computer:  A device invented to force businessmen
to work at home, on vacation, and on business trips.

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

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

#67137 From: So8res <so8res@...>
Date: Mon Nov 19, 2012 9:13 pm
Subject: Feature request: allow substitute to take i and I flags
so8res@...
Send Email Send Email
 
The substitute() function already can take the 'g' flag which causes the
substitution to be global. There's no way to force the search to be case
(in)sensitive, though. This means that plugins must either save & restore
ignorecase before using substitute() or be OK with the case sensitivity of their
substitutions changing at the user's whim.

Is there a good reason why substitute() doesn't already take the i/I flags?

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

#67138 From: Christian Brabandt <cblists@...>
Date: Mon Nov 19, 2012 9:17 pm
Subject: Re: Feature request: allow substitute to take i and I flags
cblists@...
Send Email Send Email
 
Hi So8res!

On Mo, 19 Nov 2012, So8res wrote:

> The substitute() function already can take the 'g' flag which causes
> the substitution to be global. There's no way to force the search to
> be case (in)sensitive, though. This means that plugins must either
> save & restore ignorecase before using substitute() or be OK with the
> case sensitivity of their substitutions changing at the user's whim.
>
> Is there a good reason why substitute() doesn't already take the i/I
> flags?

It should probably be documented. Other then that, the \c and \C atoms
work. See :h \c

regards,
Christian
--
Takt ist, wenn man's genau betrachtet, eine Art von Hellseherei.
		 -- S. O. Jewett

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

#67139 From: So8res <so8res@...>
Date: Mon Nov 19, 2012 9:52 pm
Subject: Functions with [range] do not preserve the cursor line
so8res@...
Send Email Send Email
 
I think functions with [range] should preserve the cursor line. Assume you have:

function RangeTest() range
   echo line('.')
endfunction

And you put the cursor on line 2 and :%call RangeTest()

This function will echo 1, because the cursor is moved to the beginning of the
range *before* entering the function.

I was attempting to create a function which does a search-replace (:s) without
moving the cursor (using winsaveview() and winrestview()). It turns out this is
not possible, because the cursor is moved before winsaveview() can be called.

Is this the intended behavior, or is it a bug? If it's intended, is there a way
to save the winview before entering a function with [range]?

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

#67140 From: "John Beckett" <johnb.beckett@...>
Date: Mon Nov 19, 2012 11:14 pm
Subject: RE: Vim patches page link is broken
johnb.beckett@...
Send Email Send Email
 
Bram Moolenaar wrote:
>> Bram: Do you want me to remove the "Other Vim patches"
>> section from [1] (and email you when done)? I don't think the
>> list was established elsewhere, so it needs to be removed?
>
> I thought we copied the patches to somewhere...
>
> If we don't have this list somewhere I think we should delete
> that section.  Let me know if you have an update for the file.

You and I exchanged a couple of emails in April 2011 around the
time the Google Groups page with the patches was closed down.
I suggested putting the patch list on the Vim Tips wiki (which is
maintained so junk edits are removed, and which would allow
people to update the information without requiring a vim.org
manager to edit the html at vim.org). You did not seem to favour
that idea, and said that we should add any information that was
on the removed pages to vim.org, unless it's already there.
I'm not aware of anything being done at vim.org.

The chain of links a reader of the mailing list might follow is:

At the first of these, "About this group" goes to the second:
http://groups.google.com/group/vim_use
http://groups.google.com/group/vim_use/about

Which says "See http://www.vim.org/maillist.php for information
on this group".

The sidebar download link on each vim.org page goes to:
http://www.vim.org/download.php

"Patches Include the latest improvements" has link to:
http://www.vim.org/patches.php

That page has a section on "Other Vim patches" with a link to
the vim_dev page that no longer exists.

Please say what you prefer now:

1. Put the patch list on the wiki; link to that from
    vim.org/patches.php

2. Replace the "Other Vim patches" section at
    vim.org/patches.php with the list of patches.

3. Put the patch list on some other vim.org page such as
    vim.org/unofficial.php
    Link to that from vim.org/patches.php

I'll do any of the above, or something else, if wanted (and
would post an update here, and directly email Bram if he does
not notice the post).

John

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

#67141 From: vim@...
Date: Mon Nov 19, 2012 11:21 pm
Subject: Issue 94 in vim: Better support is needed for DocBook 5 in filetype.vim and filetype/docbk.vim
vim@...
Send Email Send Email
 
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 94 by shlomif@...: Better support is needed for DocBook 5
in filetype.vim and filetype/docbk.vim
http://code.google.com/p/vim/issues/detail?id=94

What steps will reproduce the problem?
1. Try opening a DocBook/XML 5 file such as
https://bitbucket.org/shlomif/shlomi-fish-homepage/src/d3f1e09a1269d87d84d594139\
8bfa8c6030820af/lib/docbook/5/xml/human-hacking-field-guide-v2.xml?at=default
using "vim human*.xml" or "gvim human*.xml".
2. "set ft?" will indicate it as xml instead of as docbk.
3. After doing "set ft=docbk" some of the tags won't be highlighted.

What version of the product are you using? On what operating system?

I'm using git from vim-hg on Linux.

The problem is that DocBook/XML 5 did away with the DOCTYPE and are instead
using namespaces. The attached file fixes part of the problem, but I've
delayed working out the difference in tags between DocBook 4 and DocBook 5
for later on.

I am going to work on it on this branch:

https://code.google.com/r/shlomif-changes/source/list?name=shlomif_docbook5_supp\
ort

Best regards,

-- Shlomi Fish

Attachments:
	 docbook-5-hg.diff  473 bytes

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

#67142 From: Andy Wokula <anwoku@...>
Date: Tue Nov 20, 2012 12:19 am
Subject: Re: Functions with [range] do not preserve the cursor line
anwoku@...
Send Email Send Email
 
Am 19.11.2012 22:52, schrieb So8res:
> I think functions with [range] should preserve the cursor line.

Don't break scripts that count on this.

> Assume you have:
>
> function RangeTest() range
>    echo line('.')
> endfunction
>
> And you put the cursor on line 2 and :%call RangeTest()
>
> This function will echo 1, because the cursor is moved to the
> beginning of the range *before* entering the function.
>
> I was attempting to create a function which does a search-replace (:s)
> without moving the cursor (using winsaveview() and winrestview()). It
> turns out this is not possible, because the cursor is moved before
> winsaveview() can be called.
>
> Is this the intended behavior, or is it a bug? If it's intended, is
> there a way to save the winview before entering a function with
> [range]?

Example: remove trailing white space in range (default `%'), keeping
      cursor position, last search pattern etc.

      :no <Leader>ss  :v/^-- $/s/\s\+$//e<C-B>KeepView InFunc! <C-E>
      :ou <Leader>ss|sunm <Leader>ss
      " final <CR> could be added

for :KeepView and :InFunc, see
http://vim.sourceforge.net/scripts/script.php?script_id=3800

:KeepView   does winsaveview() and winrestview()
:InFunc     does no more than executing the argument within a function
              to make use of  :h function-search-undo

You can insert any other command instead of
      v/^-- $/s/\s\+$//e
that accepts a range.

--
Andy

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

#67143 From: Nick Gravgaard <me@...>
Date: Tue Nov 20, 2012 12:24 am
Subject: Re: Implementation of script support for non-uniform tabstops
me@...
Send Email Send Email
 
On Mon, Nov 19, 2012, at 16:21, Matthew Winn wrote:
> On Sun, 18 Nov 2012 16:28:19 -0800 (PST), Ben Fritz
> <fritzophrenic@...> wrote:
>
> > 1. Implement variable-width tabstops by allowing a comma-separated list to
be used as a value for 'tabstop'. For example, setting ts=4,2,8 would have the
first tab in the line stop at column 4, the next stop at column 6, and all other
tabs stop at 14, 22, 30, ...
>
> I implemented a patch to do this a few years ago, when I was out of
> work and decided to grab something off the TODO list to keep me busy.
> (It's since been taken over by someone else.) During the initial
> discussion it was decided that it wasn't a good idea to have multiple
> values in the "tabstop" option in case someone tried to treat its
> value as a number

Was this the reason for this feature not making it into the official
version of Vim? If so, is there another way to remain backwards
compatible with stuff that expects its value to be a number?

> so I eventually settled on "vartabstop" as the name of the 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

#67144 From: Andy Wokula <anwoku@...>
Date: Tue Nov 20, 2012 12:27 am
Subject: Re: Functions with [range] do not preserve the cursor line
anwoku@...
Send Email Send Email
 
Am 19.11.2012 22:52, schrieb So8res:
> I think functions with [range] should preserve the cursor line. Assume
> you have:
>
> function RangeTest() range
>    echo line('.')
> endfunction
>
> And you put the cursor on line 2 and :%call RangeTest()
>
> This function will echo 1, because the cursor is moved to the
> beginning of the range *before* entering the function.
>
> I was attempting to create a function which does a search-replace (:s)
> without moving the cursor (using winsaveview() and winrestview()). It
> turns out this is not possible, because the cursor is moved before
> winsaveview() can be called.
>
> Is this the intended behavior, or is it a bug? If it's intended, is
> there a way to save the winview before entering a function with
> [range]?

One more hint: when you call that function from a mapping and you want a
default range of `%', try the following:

cno <expr> <SID>% getcmdpos()==1 ? "%" : ""

" remove trailing ^M
no <script> <Leader>sm  :<SID>%InFunc s/\r$//e<C-B>KeepView <C-E>
ou <Leader>sm|sunm <Leader>sm

--
Andy

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

#67145 From: Nate Soares <nate@...>
Date: Tue Nov 20, 2012 12:29 am
Subject: Re: Functions with [range] do not preserve the cursor line
nate@...
Send Email Send Email
 
That's a nifty command and mapping, but I had no trouble with getting a custom command to use the range correctly. (You can just use -range, pass <line1> and <line2> to the function, and have the function do winsaveview() and winrestview(), which is what I do now.)

Then you can also default to the whole file much cleaner e.g. with -range=%. But I'm not trying to write a command, I'm trying to write a function.

The question is, is there any way to do this in a function that takes a range, called like:

%call SomeUniformApiFunction()

I'm not struggling to get the functionality, I'm struggling to expose a sane (function) API for the functionality.


On Mon, Nov 19, 2012 at 4:19 PM, Andy Wokula <anwoku@...> wrote:
Am 19.11.2012 22:52, schrieb So8res:

I think functions with [range] should preserve the cursor line.

Don't break scripts that count on this.


Assume you have:

function RangeTest() range
   echo line('.')
endfunction

And you put the cursor on line 2 and :%call RangeTest()

This function will echo 1, because the cursor is moved to the
beginning of the range *before* entering the function.

I was attempting to create a function which does a search-replace (:s)
without moving the cursor (using winsaveview() and winrestview()). It
turns out this is not possible, because the cursor is moved before
winsaveview() can be called.

Is this the intended behavior, or is it a bug? If it's intended, is
there a way to save the winview before entering a function with
[range]?

Example: remove trailing white space in range (default `%'), keeping
    cursor position, last search pattern etc.

    :no <Leader>ss  :v/^-- $/s/\s\+$//e<C-B>KeepView InFunc! <C-E>
    :ou <Leader>ss|sunm <Leader>ss
    " final <CR> could be added

for :KeepView and :InFunc, see
http://vim.sourceforge.net/scripts/script.php?script_id=3800

:KeepView   does winsaveview() and winrestview()
:InFunc     does no more than executing the argument within a function
            to make use of  :h function-search-undo

You can insert any other command instead of
    v/^-- $/s/\s\+$//e
that accepts a range.

--
Andy


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

--
You received this message 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

Messages 67116 - 67145 of 71394   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help