Hello Tony,
Tony Mechelynck schrieb:
On 30/10/12 07:32, Jürgen Krämer wrote:
Jürgen Krämer wrote:
Christian Brabandt wrote:
[...]
It is for a German layout usually. But I can't reproduce it. And
possibly also compiler or architecture (32/64bit) dependent.
yesterday, with the example
I think the fact that this behavior is not evident in the original (release)
version of gvim (7.3.046) demonstrates that this is a bug.
--
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
Dear Vim Dev,
I recently found that v with count remembers the previous visual area.
I found that it is not always true, which seems strange to me (is this
a feature or a bug?). For example if I do v{motion}y, then 1v, as
should, selects the same are in the current position. But if I do
On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:
Dear Vim Dev,
I recently found that v with count remembers the previous visual area.
I found that it is not always true, which seems strange to me (is this
a feature or a bug?). For example if I do v{motion}y, then 1v, as
should,
On 10:15 Wed 31 Oct , Ingo Karkat wrote:
On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:
Dear Vim Dev,
I recently found that v with count remembers the previous visual area.
I found that it is not always true, which seems strange to me (is this
a feature or a bug?). For
On 31-Oct-2012 10:24:48 +0100, Marcin Szamotulski wrote:
On 10:15 Wed 31 Oct , Ingo Karkat wrote:
On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:
Dear Vim Dev,
I recently found that v with count remembers the previous visual area.
I found that it is not always true, which
On 10:40 Wed 31 Oct , Ingo Karkat wrote:
On 31-Oct-2012 10:24:48 +0100, Marcin Szamotulski wrote:
On 10:15 Wed 31 Oct , Ingo Karkat wrote:
On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:
Dear Vim Dev,
I recently found that v with count remembers the previous visual
On 31/10/12 07:27, Jürgen Krämer wrote:
Hello Tony,
Tony Mechelynck schrieb:
On 30/10/12 07:32, Jürgen Krämer wrote:
Jürgen Krämer wrote:
Christian Brabandt wrote:
[...]
It is for a German layout usually. But I can't reproduce it. And
possibly also compiler or architecture (32/64bit)
On 31/10/12 08:04, Axel wrote:
I think the fact that this behavior is not evident in the original (release)
version of gvim (7.3.046) demonstrates that this is a bug.
It should be possible (but a lot of work) to determine a last good and
a first bad version by binary search (dichotomy) and
Following Tony's approach I tried to verify the behavior with Cream's 7.3.709
but I couldn't; gvim.exe behaves correctly. The Cream version however is a
32-bit application, where mine is a 64-bit version compiled with MinGW.
@Jürgen
For which platform did you compile/download your version of
On Wednesday, October 31, 2012 5:48:51 AM UTC-5, Axel wrote:
Following Tony's approach I tried to verify the behavior with Cream's 7.3.709
but I couldn't; gvim.exe behaves correctly. The Cream version however is a
32-bit application, where mine is a 64-bit version compiled with MinGW.
On 31/10/12 15:38, Ben Fritz wrote:
On Wednesday, October 31, 2012 5:48:51 AM UTC-5, Axel wrote:
Following Tony's approach I tried to verify the behavior with Cream's 7.3.709
but I couldn't; gvim.exe behaves correctly. The Cream version however is a
32-bit application, where mine is a 64-bit
On Wed, Oct 31, 2012 at 6:31 AM, Tony Mechelynck
antoine.mechely...@gmail.com wrote:
the W32 versions of gvim at
http://sourceforge.net/projects/cream/files/Vim/ — where the last
version seems mislabeled: it says 6.3.709 on the list of versions
but it offers gvim-7-3-709.exe and
g?gvg? is really nice, I'll give it a try. I tested it over digraphs,
and it works.
You can also use
:C-uEsc
. Unlike g? workaround it alters neither undo nor command history.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are
Great input, ZyX! For me, it even works without the C-u, just :Esc. Though
this looks like a bug to me: I would understand that a no-op command like
:C-uechoCR would be treated as a modification, but an aborted command
definitely does not count as a modification; it also isn't added to the
I was building vim with python support today, and I noticed that it
gives a linker error if multibyte support isn't also enabled. Is that
unexpected, or is the usual model to include features and all their
dependencies?
--
You received this message from the vim_dev maillist.
Do not top-post!
I notice many keywords in runtime/syntax/vim.vim are split across
multiple lines. For example, I assume all the lines beginning with
syn keyword vimCommand could logically be assumed to be a single
(very long) command. Is that accurate?
If this is correct, I'm curious if there's some pattern to
Kartik Agaram wrote:
I notice many keywords in runtime/syntax/vim.vim are split across
multiple lines. For example, I assume all the lines beginning with
syn keyword vimCommand could logically be assumed to be a single
(very long) command. Is that accurate?
If this is correct, I'm curious if
18 matches
Mail list logo
