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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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