Re: Patch 7.4.570
Hi tux., 2015/1/15 Thu 8:02:35 UTC+9 tux. wrote: > Ken Takata schrob am Mittwoch, 14. Januar 2015 um 23:52 Zeit: > > > Did you set RUBY_VER and RUBY_VER_LONG properly? > > MSVC 2010, RUBY_VER = 22, RUBY_VER_LONG = 2.2.0: > > I can reproduce Cesar's error. Please make sure that you are using Ruby 2.2's header files. E.g.: ActiveScriptRuby 2.2 is built with MSVC10 and has headers for MSVC10. http://www.artonx.org/data/asr/ (Japanese) When I use Ruby 2.1's header files with the setting RUBY_VER=22, RUBY_VER_LONG=2.2.0, I got the same error. Regards, Ken Takata -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal: range('a', 'c') should be ['a', 'b', 'c']
Vimple (https://github.com/dahu/vimple) offers:
:echo string#range('a', 'z')
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Proposal: range('a', 'c') should be ['a', 'b', 'c']
On Thursday, January 15, 2015 at 7:29:16 PM UTC+9, Barry Arthur wrote:
> Vimple (https://github.com/dahu/vimple) offers:
>
> :echo string#range('a', 'z')
Well, I don't want plugin. I want builtin function.
FYI, vital.vim is also having char_range
https://github.com/vim-jp/vital.vim/blob/651a0236e597e7ed8a600369c3bf78dfc262ae20/autoload/vital/__latest__/Data/List.vim#L132-L137
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Proposal: range('a', 'c') should be ['a', 'b', 'c']
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15-Jan-2015 12:24, mattn wrote:
>
> Well, I don't want plugin. I want builtin function.
Can you demonstrate that this is needed frequently? Which common tasks
would benefit from this? (And why would a short library function not
suffice?)
The only use case I've encountered so far is generating a list of
a..z, which I do this way: split('abcdefghijklmnopqrstuvwxyz', '\zs')
I think we have to trade convenience vs. complexity; Vim's codebase is
large enough. And the (already raised) issue of how to handle
multi-char strings isn't nice (char2nr() has this problem, too, but
that's a truly essential function).
- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJUt6+TAAoJEA7ziXlAzQ/v820H/3zMK84+Ekro4g18xIk3Clvb
6KP7p+1IytcpJOgqVPQXx4hOZLr+2pmQNrfUkb5imshWGUWCx+686hFQFYBFDN4P
Tx8LBsRm+BCp2oOKxRcp2T7vPiVQNfB9QsqGcsI6scNvRuV2xYtxlvV/aYRTI0Hn
WAkPhgA1E8IYigWDJKFLe/gsw7p9/GISjAdKlC1DLpyMyDluPxiYPvlacb19fqVZ
9rxQOh/1OYtyDQwKZyTV9rUETzHZPUeLzG/30mIgVryoOi15jwxdCKYwvLrpU6MC
teUqeug/iota//NcEYpZvVZL5R8kWAy5g1tdfqEs8kL9CDFarvmkxSRjLNyekiw=
=TgHo
-END PGP SIGNATURE-
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.570
Am 2015-01-15 10:15, schrieb Ken Takata: Please make sure that you are using Ruby 2.2's header files. I use Ruby 2.2.0 compiled with MSVC 2010 by myself. :-) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.576
Hi Bram!
On 2015-01-14 Wednesday at 17:52 +0100 Bram Moolenaar wrote:
> Patch 7.4.576
> Problem:Redrawing problem with 'relativenumber' and 'linebreak'.
> Solution: Temporarily reset 'linebreak' and restore it in more places.
> (Christian Brabandt)
This hunk intentionally dropped from Christians 2 patches
(he merged them in a single patch lastly)?
--- vim-7.4.576/src/normal.c
+++ vim-7.4.529-linebreak_bug/src/normal.c
@@ -2162,6 +2162,9 @@ do_pending_operator(cap, old_col, gui_ya
#ifdef FEAT_VIRTUALEDIT
virtual_op = MAYBE;
#endif
+#ifdef FEAT_LINEBREAK
+curwin->w_p_lbr = FALSE;
+#endif
if (!gui_yank)
{
/*
There were two todo entries regarding this issue. The second entry done, too?
Patch to fix wrong formatting if 'linebreak' is set. (Christian Brabandt, 2014
Nov 12)
Thanks to you and Christian!
Bugfixes whithin a few days, or even within a few hours frequently, this
is really an excellent support :)
--
Roland Eggner
--
--
You received this message from the "vim_dev" maillist.
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.
pgp646emdwNGY.pgp
Description: PGP signature
[patch] syntax highlighting very slow with valgrind syntax
Hi Syntax highlighting with vim-7.4.580 can be very slow with valgrind file types. For example, try to open the attached valgrind2.log file using: $ vim -u NONE -c 'syntax on' -c 'setfiletype valgrind' valgrind2.log Notice 2 problems: 1) syntax highlighting is _very_ slow. It takes about 20 sec to redraw the screen on my i7 Linux x86_64 machine. 2) syntax highlighting of function names (i.e. valgrindFunc syntax) is also incorrect for c++ function names (it works fine for C function names). :syntime command points to the reasons for the slowness: :syntime on :redraw! :syntime report TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN 40.711692 10 0 20.504.071169 valgrindSrc \((\)\@<=[^)]*:\d\+\()\)\@= 0.009537 36 26 0.0023900.000265 valgrindBin \((\(with\|\)in \)\@<=\S\+\()\)\@= 0.003999 44 44 0.0002480.91 valgrindLine \(^==\d\+== \)\@<= 0.003142 44 22 0.0010000.71 valgrindPidChunk \(^==\)\@<= 0.002684 32 22 0.0010050.84 valgrindFunc \(: \)\@<=\w\+ 0.000842 20 20 0.0002860.42 valgrindMsg\S.*$ 0.000803 20 12 0.0002760.40 valgrindLoc \s\+\(by\|at\|Address\).*$ ...snip... Attached patch fix-slow-valgrind.vim-7.4.580.patch fixes the slow rendering. Rendering feels instantaneous after patch and syntime reports: TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN 0.006443 48 26 0.0024440.000134 valgrindPidChunk \(^==\)\@<= 0.005536 48 48 0.0004810.000115 valgrindLine \(^==\d\+== \)\@<= 0.001445 20 12 0.0005840.72 valgrindRegion ^==\z1==\( \|.*\)$ 0.001436 20 12 0.0006600.72 valgrindLoc \s\+\(by\|at\|Address\).*$ 0.001280 20 20 0.0006610.64 valgrindMsg\S.*$ Now regarding the second problem (incorrect syntax highlighting of C++ function names), I have not been able to fix it yet. I would have though that using something like this should work: syn match valgrindFunc ": \zs\h[a-zA-Z0-9_:\[\]()<>&*+\-, ]*\ze([^)]*)" contained But it does not work. It's broken for function names longer than exactly 3000 characters which happens in the attached valgrind2.log. Syntax highlighting stops after exactly 3000 characters in the function name. De-mangled function names with C++ templates can be very long, so 3000 characters is not unusual. Is there a 3000 characters limit in the regexp engine or in syntax highlighting engine? I could not find any such limit in the source code. Regards Dominique -- -- You received this message from the "vim_dev" maillist. 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. ==30198== Memcheck, a memory error detector ==30198== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==30198== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==30198== Command: ./xxx ==30198== ==30198== Invalid read of size 4 ==30198==at 0x6951490: std::locale::locale(std::locale const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==30198==by 0x62176B: boost::filesystem::path::codecvt() (in /home/azg/code/yyy/build_debug/xxx) ==30198==by 0x647044: boost::log::v2s_mt_posix::sinks::text_file_backend::set_file_name_pattern_internal(boost::filesystem::path const&) (in /home/azg/code/yyy/build_debug/xxx) ==30198==by 0x64813A: boost::log::v2s_mt_posix::sinks::text_file_backend::construct(boost::filesystem::path const&, std::_Ios_Openmode, unsigned long, boost::log::v2s_mt_posix::aux::light_function const&, bool) (in /home/azg/code/yyy/build_debug/xxx) ==30198==by 0x56D4BF: void boost::log::v2s_mt_posix::sinks::text_file_backend::construct >, 0l> >, boost::log::v2s_mt_posix::expressions::attribute_actor >, 2l> >, boost::phoenix::actor, 0l> > >, 2l> >, boost::log::v2s_mt_posix::expressions::attribute_actor >, 2l> > const>, boost::parameter::aux::arg_list, boost::parameter::aux::arg_list, boost::phoenix::actor, 0l> > >, 2l> > const>, boost::parameter::aux::empty_arg_list> > > >(boost::parameter::aux::arg_list >, 0l> >, boost::log::v2s_mt_posix::expressions::attribute_actor >, 2l> >, boost::phoenix::actor, 0l> > >, 2l> >, boost::log::v2s_mt_posix::expressions::attribute_actor >, 2l> > const>, boost::parameter::aux::arg_list, boost::parameter::aux::arg_list, boost::phoenix::actor, 0l> > >, 2l> > const>, boost::parameter::aux::empty_arg_list> > > const&) (text_file_backend.hpp:511) ==30198==by 0x563E36: boost::log::v2s_mt_posix::sinks::text_file_backend::text_file_backend
Re: [patch] syntax highlighting very slow with valgrind syntax
Hi Dominique! On Do, 15 Jan 2015, Dominique Pellé wrote: > Is there a 3000 characters limit in the regexp engine or in syntax > highlighting engine? I could not find any such limit in the source code. Could that be the synmaxcol setting? Best, Christian -- Alles auf der Welt läßt sich finden, wenn man nur das Suchen sich nicht verdrießen läßt. -- Philemon -- -- You received this message from the "vim_dev" maillist. 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] adding src/testdir/test_vartabstop_breakindent.{in,ok}
On Mi, 05 Nov 2014, Christian Brabandt wrote:
> I'll include the update for now at the usual place:
> https://github.com/chrisbra/vim-mq-patches/blob/master/var_tabstops
Updated the patch for v7.4.579
(attached and available at above URL).
Best,
Christian
--
Was aber ist deine Pflicht? Die Forderung des Tages.
-- Goethe, Maximen und Reflektionen, Nr. 31
--
--
You received this message from the "vim_dev" maillist.
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.
diff --git a/runtime/doc/change.txt b/runtime/doc/change.txt
--- a/runtime/doc/change.txt
+++ b/runtime/doc/change.txt
@@ -903,6 +903,11 @@ 4.4 Changing tabs *change-tabs*
{not in Vi}
Not available when |+ex_extra| feature was disabled at
compile time.
+ If the |+vartabs| feature is enabled then a list of
+ tab widths separated by commas may be used in place of
+ a single tabstop. Each value in the list represents
+ the width of one tabstop, except the final value which
+ applies to all following tabstops.
*retab-example*
Example for using autocommands and ":retab" to edit a file which is stored
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -6620,6 +6620,10 @@ A jump table for the options with a shor
set.
NOTE: This option is set to 0 when 'compatible' is set.
+ If Vim is compiled with the |+vartabs| feature then the value of
+ 'softtabstop' will be ignored if |'varsofttabstop'| is set to
+ anything other than an empty string.
+
*'spell'* *'nospell'*
'spell' boolean (default off)
local to window
@@ -7167,6 +7171,10 @@ A jump table for the options with a shor
though. Otherwise aligned comments will be wrong when 'tabstop' is
changed.
+ If Vim is compiled with the |+vartabs| feature then the value of
+ 'tabstop' will be ignored if |'vartabstop'| is set to anything other
+ than an empty string.
+
*'tagbsearch'* *'tbs'* *'notagbsearch'* *'notbs'*
'tagbsearch' 'tbs' boolean (default on)
global
@@ -7806,6 +7814,44 @@ A jump table for the options with a shor
written to disk (see |crash-recovery|). Also used for the
|CursorHold| autocommand event.
+ *'varsofttabstop'* *'vsts'*
+'varsofttabstop' 'vsts' string (default "")
+ local to buffer
+ {only available when compiled with the |+vartabs|
+ feature}
+ {not in Vi}
+ A list of the number of spaces that a counts for while editing,
+ such as inserting a or using . It "feels" like variable-
+ width s are being inserted, while in fact a mixture of spaces
+ and s is used. Tab widths are separated with commas, with the
+ final value applying to all subsequent tabs.
+
+ For example, when editing assembly language files where statements
+ start in the 8th column and comments in the 40th, it may be useful
+ to use the following: >
+ :set varsofttabstop=8,32,8
+< This will set soft tabstops at the 8th and 40th columns, and at every
+ 8th column thereafter.
+
+ Note that the value of |'softtabstop'| will be ignored while
+ 'varsofttabstop' is set.
+
+ *'vartabstop'* *'vts'*
+'vartabstop' 'vts' string (default "")
+ local to buffer
+ {only available when compiled with the |+vartabs|
+ feature}
+ {not in Vi}
+ A list of the number of spaces that a in the file counts for,
+ separated by commas. Each value corresponds to one tab, with the
+ final value applying to all subsequent tabs. For example: >
+ :set vartabstop=4,20,10,8
+< This will make the first tab 4 spaces wide, the second 20 spaces,
+ the third 10 spaces, and all following tabs 8 spaces.
+
+ Note that the value of |'tabstop'| will be ignored while 'vartabstop'
+ is set.
+
*'verbose'* *'vbs'*
'verbose' 'vbs' number (default 0)
global
diff --git a/runtime/doc/tags b/runtime/doc/tags
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -1065,6 +1065,8 @@
'updatetime' options.txt /*'updatetime'*
'ur' options.txt /*'ur'*
'ut' options.txt /*'ut'*
+'varsofttabstop' options.txt /*'varsofttabstop'*
+'vartabstop' options.txt /*'vartabstop'*
'vb' options.txt /*'vb'*
'vbs' options.txt /*'vbs'*
'vdir' options.txt /*'vdir'*
@@ -1079,6 +1081,8 @@
'virtualedit' options.txt /*'virtualedit'*
'visualbell' options.txt /*'visualbell'*
'vop' options.txt /*'vop'*
+'vsts' options.txt /*'vsts'*
+'vts' options.txt /*'vts'*
'w1200' vi_diff.txt /*'w1200'*
'w300' vi_diff.txt /*'w300'*
'w9600' vi_diff.txt /*'w9600'*
@@ -1262,6 +1266,7 @@
+title various.txt /*+title*
+toolbar various.txt /*+toolbar*
+user_commands various.txt /*+user_commands*
++vartabs various.txt /*+vartabs*
+vertsplit variou
Re: Patch 7.4.576
Roland Eggner wrote:
> On 2015-01-14 Wednesday at 17:52 +0100 Bram Moolenaar wrote:
> > Patch 7.4.576
> > Problem:Redrawing problem with 'relativenumber' and 'linebreak'.
> > Solution: Temporarily reset 'linebreak' and restore it in more places.
> > (Christian Brabandt)
>
> This hunk intentionally dropped from Christians 2 patches
> (he merged them in a single patch lastly)?
>
> --- vim-7.4.576/src/normal.c
> +++ vim-7.4.529-linebreak_bug/src/normal.c
> @@ -2162,6 +2162,9 @@ do_pending_operator(cap, old_col, gui_ya
> #ifdef FEAT_VIRTUALEDIT
> virtual_op = MAYBE;
> #endif
> +#ifdef FEAT_LINEBREAK
> +curwin->w_p_lbr = FALSE;
> +#endif
> if (!gui_yank)
> {
> /*
>
> There were two todo entries regarding this issue. The second entry
> done, too?
>
> Patch to fix wrong formatting if 'linebreak' is set. (Christian
> Brabandt, 2014 Nov 12)
It's possible I included an older patch instead of a newer version of
that patch. Christian, please check.
> Thanks to you and Christian!
> Bugfixes whithin a few days, or even within a few hours frequently, this
> is really an excellent support :)
And at a bargain price! :-)
--
>From "know your smileys":
|-PReaction to unusually ugly C code
/// 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///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.576
Hi Roland!
On Do, 15 Jan 2015, Roland Eggner wrote:
> Hi Bram!
>
>
> On 2015-01-14 Wednesday at 17:52 +0100 Bram Moolenaar wrote:
> > Patch 7.4.576
> > Problem:Redrawing problem with 'relativenumber' and 'linebreak'.
> > Solution: Temporarily reset 'linebreak' and restore it in more places.
> > (Christian Brabandt)
>
> This hunk intentionally dropped from Christians 2 patches
> (he merged them in a single patch lastly)?
>
> --- vim-7.4.576/src/normal.c
> +++ vim-7.4.529-linebreak_bug/src/normal.c
> @@ -2162,6 +2162,9 @@ do_pending_operator(cap, old_col, gui_ya
> #ifdef FEAT_VIRTUALEDIT
> virtual_op = MAYBE;
> #endif
> +#ifdef FEAT_LINEBREAK
> +curwin->w_p_lbr = FALSE;
> +#endif
> if (!gui_yank)
> {
> /*
I think this is okay. curwin->w_p_lbr is reset a further lines down and
that should be okay I think.
> There were two todo entries regarding this issue. The second entry done, too?
>
> Patch to fix wrong formatting if 'linebreak' is set. (Christian Brabandt, 2014
> Nov 12)
Which was the second entry?
> Thanks to you and Christian!
> Bugfixes whithin a few days, or even within a few hours frequently, this
> is really an excellent support :)
My pleasure. It's fun hacking Vim to make it better.
Best,
Christian
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Issue 312 in vim: word wrapping messed up when entering Insert mode with 'c' or 's'
Comment #4 on issue 312 by gilad.ar...@gmail.com: word wrapping messed up when entering Insert mode with 'c' or 's' https://code.google.com/p/vim/issues/detail?id=312 Verified with 7.4.580, problem is gone. Thanks! -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 313 in vim: pedit changes cursor position when BufReadPre autocmd defined
Comment #6 on issue 313 by fritzoph...@gmail.com: pedit changes cursor position when BufReadPre autocmd defined https://code.google.com/p/vim/issues/detail?id=313 I discovered today that although the cursor position is thankfully fixed by the patch, there is still an error message that pops up if my buffer is modified. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim truncating line inserted by clicking middle mouse button on Linux
Thank you very much for your quick and detailed answer. Indeed I've got a mapping jk --> Esc. So most of the findings are explained very well. The only thing I still don't get is why the issue can't be seen in gvim. Regards, P. Mattern -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.576
Hi Christian! On 2015-01-15 Thursday at 23:02 +0100 Christian Brabandt wrote: > On Do, 15 Jan 2015, Roland Eggner wrote: > > On 2015-01-14 Wednesday at 17:52 +0100 Bram Moolenaar wrote: > > > Patch 7.4.576 > > > Problem:Redrawing problem with 'relativenumber' and 'linebreak'. > > > Solution: Temporarily reset 'linebreak' and restore it in more places. > > > (Christian Brabandt) > > > > … … > > > There were two todo entries regarding this issue. The second entry done, > > too? > > > > Patch to fix wrong formatting if 'linebreak' is set. (Christian Brabandt, > > 2014 > > Nov 12) > > Which was the second entry? The first entry, already deleted: Patch to fix relative numbers. (Christian Brabandt, 2014 Nov 17) Update Nov 26. The second entry which I believe is covered by 7.4.576: cited 12 lines above. -- Roland Eggner -- -- You received this message from the "vim_dev" maillist. 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. pgpffN6C6XQTW.pgp Description: PGP signature
Re: Issue 313 in vim: pedit changes cursor position when BufReadPre autocmd defined
Comment #7 on issue 313 by vega.ja...@gmail.com: pedit changes cursor position when BufReadPre autocmd defined https://code.google.com/p/vim/issues/detail?id=313 The error is expected since you're trying to :edit a modified buffer. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the "vim_dev" maillist. 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: Ctrl_L behave like Ctrl_P while pum_visible.
On Tuesday, January 6, 2015 at 6:15:50 PM UTC-8, h_east wrote: > Hi list, > > 2015/1/7(Wed) 4:09:31 UTC+9 h_east: > > Nice. Perhaps I think that We need a little more modification such an > > attached a patch url. > > https://gist.github.com/h-east/be555467ddfc3dfb8d54 > > I updated Gist. (Add line#19) > > Best regards, > Hirohito Higashi (a.k.a h_east) Any movement on this? Would love to see at the very least, Christian's patch merged in soon if possible. Cheers, Amadeus -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 313 in vim: pedit changes cursor position when BufReadPre autocmd defined
Comment #8 on issue 313 by fritzoph...@gmail.com: pedit changes cursor position when BufReadPre autocmd defined https://code.google.com/p/vim/issues/detail?id=313 Except the buffer is already loaded so it is more like a split. AFAIK there is no way to open a preview window on the current buffer without triggering the error. and you're always opening a split so it won't be abandoning it. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim truncating line inserted by clicking middle mouse button on Linux
Hi, Peter Mattern schrieb am 15.01.2015 um 23:15: > Thank you very much for your quick and detailed answer. > > Indeed I've got a mapping jk --> Esc. So most of the findings are > explained very well. > The only thing I still don't get is why the issue can't be seen in gvim. I don't do much work with vim, and even less in a terminal, so my answer might be totally wrong. But IIRC pasting with the middle mouse button in a terminal is handled by the terminal itself. It feeds the pasted text to the currently running program as a series of keystrokes and (in this case) Vim has no way to distinguish between those simulated keystrokes and your real input. I think this is one of the reasons behind the 'paste' option (see ":help 'paste'). You might also want to check if :set mouse=a helps. This tells Vim to use the mouse in all modes (except during the hit-enter prompt), but I don't know if it works for all terminals. You can more on this at ":help mouse-using". OTOH Gvim completely handles the mouse itself, so it sees the middle mouse click and translates it to a paste action. Depending on how the paste action is implemented mappings may or may not be disabled during its course. Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.576
Am 2015-01-16 00:33, schrieb Roland Eggner: The first entry, already deleted: Patch to fix relative numbers. (Christian Brabandt, 2014 Nov 17) Update Nov 26. That one is not fixed yet (and has not been merged). It is fixed by the patch attached at that message: https://groups.google.com/d/msg/vim_dev/qORtSGBSnkc/qVfo4-GKS9EJ (That message was about 2 bugs. The first one was the formatting when linebreak is set (fixed by 7.4.576) and the second one was that the relative numbering wasn't updated). The second entry which I believe is covered by 7.4.576: cited 12 lines above. Yes that right. Best, Christian -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
