On 04-Jun-2014 16:54 +0200, Павлов Николай Александрович wrote:
On 04-Jun-2014 16:54, Павлов Николай Александрович wrote:>
>
> On June 4, 2014 6:44:34 PM GMT+03:00, "Павлов Николай
> Александрович" wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>
>
>
>> On June 4, 2014 3:48:42 PM
On Thursday, June 5, 2014 2:23:25 PM UTC+12, Bohr Shaw wrote:
> With this mapping `nnoremap F f*,` and the cursor on `b` in the text
> `foo*bar`, after pressing `F`, the cursor wouldn't be moved to `*`.
I expect this; the "f*" fails, there's a beep, and the rest of the mapping is
not executed.
With this mapping `nnoremap F f*,` and the cursor on `b` in the text `foo*bar`,
after pressing `F`, the cursor wouldn't be moved to `*`.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit
Comment #1 on issue 227 by burningg...@gmail.com: Pane looses focus of
current line on resizing.
http://code.google.com/p/vim/issues/detail?id=227
After checking the current changelogs, this was fixed with: 7.4.309
Sorry, please close.
--
You received this message because this project is co
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 227 by burningg...@gmail.com: Pane looses focus of current line
on resizing.
http://code.google.com/p/vim/issues/detail?id=227
What steps will reproduce the problem?
1. Open multiple split panes with :split.
2. Have texts i
Jean-François Bignolles wrote:
> Le lundi 2 juin 2014 16:43:42 UTC+2, Bram Moolenaar a écrit :
> >
> > I notice you use string concatenation:
> >
> > +#define RUNTIME_AFTER RUNTIME_USER "/after"
> >
> > Older C compilers do not support this. I'm not sure which ones, it is
> > not used yet i
Yasuhiro Matsumoto wrote:
> Hi list. Try this.
>
> vim -u NONE
> :tabnew
> :e foo
> :autocmd BufLeave bdelete!
> :e bar
> :tabnew
> :e baz
> :autocmd BufLeave bdelete!
> :e xxx
>
> Maybe, vim crash with ":e bar" or ":e xxx". Because it call win_close() and
> refer the pointer. Below is a pat
Yukihiro Nakadaira wrote:
> substitute() with zero width pattern breaks multi-byte character.
>
> Steps to reproduce:
> $ vim -u NONE
> :set encoding=3Dutf-8
> :echo substitute("\u00e1", '\zs', 'x', 'g')
> xxx
>
> Please check the following patch.
Thanks!
--
hundred-and-one symptoms
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On June 4, 2014 6:44:34 PM GMT+03:00, "Павлов Николай Александрович"
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>
>
>On June 4, 2014 3:48:42 PM GMT+03:00, Ingo Karkat
> wrote:
>>On 04-Jun-2014 13:34 +0200, Axel Bender wrote:
>>
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On June 4, 2014 3:48:42 PM GMT+03:00, Ingo Karkat wrote:
>On 04-Jun-2014 13:34 +0200, Axel Bender wrote:
>
>> I'd already be happy if virtcol() would take into account the length
>of the showbreak string. I'm otherwise prepared to work with UTF-8
On Wed, Jun 4, 2014 at 9:21 PM, Christ van Willegen
wrote:
> Hi,
>
> On Wed, Jun 4, 2014 at 1:47 PM, Yukihiro Nakadaira
> wrote:
> > substitute() with zero width pattern breaks multi-byte character.
> >
> > Please check the following patch.
> >
> > diff -r bed71c37618c src/eval.c
> > --- a/src/e
On Thu, May 29, 2014 at 5:52 PM, Dhruva Sagar wrote:
> But surely this should be supported natively, doesn't sound like it would
> require huge change, would anyone be able to throw some light into why this
> is the case ?
A made a toy patch about 4 years ago for this[1], based on the
completio
Hi,
On Wed, Jun 4, 2014 at 1:47 PM, Yukihiro Nakadaira
wrote:
> substitute() with zero width pattern breaks multi-byte character.
>
> Please check the following patch.
>
> diff -r bed71c37618c src/eval.c
> --- a/src/eval.cThu May 29 14:36:29 2014 +0200
> +++ b/src/eval.cWed Jun 04 20:44:4
On 04-Jun-2014 13:34 +0200, Axel Bender wrote:
> I'd already be happy if virtcol() would take into account the length of the
> showbreak string. I'm otherwise prepared to work with UTF-8 characters...
Character widths are not directly related to this, but that little
incorrectness in your otherw
substitute() with zero width pattern breaks multi-byte character.
Steps to reproduce:
$ vim -u NONE
:set encoding=utf-8
:echo substitute("\u00e1", '\zs', 'x', 'g')
xxx
Please check the following patch.
diff -r bed71c37618c src/eval.c
--- a/src/eval.cThu May 29 14:36:29 2014 +0200
++
I'd already be happy if virtcol() would take into account the length of the
showbreak string. I'm otherwise prepared to work with UTF-8 characters...
I consider this a flaw (well maybe a bug?) that should be fixed.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! T
16 matches
Mail list logo