vim | 31 Oct 00:37 2014

Issue 277 in vim: wrong virtcol("']") if last yanked character is non-ASCII

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 277 by Ludwi... <at> gmx.de: wrong virtcol("']") if last yanked  
character is non-ASCII
https://code.google.com/p/vim/issues/detail?id=277

Assume you have a buffer with exactly two lines. The first line containing  
exactly one character, e.g. U+2502 (│), the second line containing exactly  
one character, e.g. U+0041 (a):

line 1: │
line 2: a

What steps will reproduce the problem?
1. Place the cursor at line 1, virtcol 1
2. Start visual mode and yank one character and echo the virtcol of the  
last yanked part, i.e. type:
vy:echo virtcol("']")
The answer will be 2, although line 1 has no second virt-column.

For the ASCII-character you get a different answer: Doing the same thing  
with line 2, virtcol 1
vy:echo virtcol("']")
will give as answer 1.

What is the expected output? What do you see instead?
Expected output: in both cases "1", because there is only one virtual  
column in every line. Instead I get virtcol 2 in the first line.
(Continue reading)

ramelo1 | 30 Oct 16:23 2014
Picon

[Bug] <at> {register} ends in the wrong line

Hello VIM developers,

Please have a look:

vim -u NONE
-open a file with more than 1 line (or just-  2iaaa<CR><ESC>gg)
:let  <at> q = ':norm l^M'         "the ^M is <C-v><Enter>
 <at> q

-The result should be moving one character to the right, but instead it ends in the second line. The behavior
is as expected when I record the same sequence using qq.

Thanks!
Ramel

-- 
--

-- 
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+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Marco Hinz | 30 Oct 14:15 2014
Picon

[patch] Put ~ markers into their own highlight group

Hi,

this might be yet another controversial patch, but it's asked for on IRC
all the time.

The problem is that the ~ markers (end of buffer) and parts of
'listchars' both use the same highlight group: NonText.

Now people wish to use different colors for this, thus this patch
introduces a new highlight group, EndOfBuffer, which uses the same
colors as NonText by default.

The first patch contains the actual changes and the second one merely
adds 'hi link EndOfBuffer NonText' to the default colorschemes.

Opinions?

Regards

Marco

-- 
Github: http://github.com/mhinz | Twitter: http://twitter.com/_mhinz_

-- 
--

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

(Continue reading)

cs86661 | 30 Oct 07:35 2014
Picon

[Bug Report] setlocal undolevels will get "-123456" ?!

1. vi -u NONE --noplugin

2. verbose set undolevels undoreload (both are global values)
> undolevels=1000
> undoreload=10000

3. verbose setlocal undolevels undoreload
> undolevels=-123456
> undoreload=10000

-- 
--

-- 
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+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

vim | 29 Oct 14:40 2014

Issue 276 in vim: opening file with .gz extension

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 276 by santosh.... <at> gmail.com: opening file with .gz extension
https://code.google.com/p/vim/issues/detail?id=276

The default behaviour of vim when opening a file with ".gz" extension, is  
to decompress and then re-compress it again when saving it. In a situation  
when the file has a  ".gz" extension, BUT IT IS NOT GZIPPED, vim gives  
error in the first part of decompression. But the 2nd part of  
re-compression goes ahead as it is, which has an unwanted side-effect that  
the original file gets compressed. Although not a bug, it would be better  
if the behaviour was more consistent and vim didn't try to re-compress the  
file if it was not able to decompress it originally.

What steps will reproduce the problem?
1. Create a file txt-file (no compression) with ".gz" extension
$ echo -e "one\ntwo" > vimtmp.gz

2. open the file with vim, it spits the following error msg:

--
"vimtmp.gz" 2L, 8C
Error detected while processing function gzip#read:
line   44:
Error: Could not read uncompressed file
Press ENTER or type command to continue
--

(Continue reading)

James McCoy | 29 Oct 02:37 2014

[patch] Use a [count] for do/dp as the [bufspec] for :diffget/:diffput

Needing to fallback to :diffget/:diffput instead of do/dp when dealing
with a 3-way diff has always bothered me.  I've been having to do that
more lately, so the attached patch turns a supplied [count] for do/dp
into the [bufspec] for :diffget/:diffput.

Obviously, it's not as expressive as being able to use the full bufspec,
but, at least for me, I always know the buffer number, so providing the
count is much quicker.

Cheers,
--

-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan <at> jamessan.com>
Attachment (diffput-count.diff): text/x-diff, 3291 bytes
Christian Brabandt | 27 Oct 21:05 2014

[patch] allow to vimgrep current buffer

Bram,
here is a patch, that allows to use
:vimgrep /foobar/
to search only the current buffer. You might want to argue this is 
already possible just use '%' as the filename, but that does not work, 
if the current buffer does not have a name yet. Then vimgrep complains 
about not being able to access an unknown file, although it wouldn't 
have to load the file, since it is already in memory, so it should be 
possible to do so, without writing temporary files.

Best,
Christian
-- 
Man erzürnt sich immer mehr gegen einen, für den man erst den Zorn
einige Zeit aufheben muß - und genade ihm dann Gott!
		-- Jean Paul

-- 
--

-- 
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+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Attachment (vimgrep_curbuf.diff): text/x-diff, 3900 bytes
h_east | 27 Oct 15:54 2014
Picon

[patch] When specify a negative number to 'topline' by winrestview(), display becomes strange.

Hi list!

How to reproduce:
- start vim
  $ vim -N -u NONE -c "se nu"

- Input below.
  ia<Esc>
  :call winrestview({'topline': -3})

Expected behavior:
- Display this. (Display does not change)
  1 a

Actual behavior:
- Displayed below. (Invalid line number!)
 -3 a
 -2 a
 -1 a
  0 a
  1 a

I attached a patch.
Please check this.

--
Best regards,
Hirohito Higashi

--

-- 
(Continue reading)

Michael Henry | 27 Oct 12:08 2014

Documentation patch: :global [cmd] can have a range

Bram,

Here is a small documentation patch that indicates the [cmd]
associated with the :global command may contain a range.  Tim
Chase pointed out a couple of pre-existing examples in the
documentation, so I've linked to them from :global, which required
adding one extra tag in usr_25.txt.

diff -r 8bb4ca7fba40 runtime/doc/repeat.txt
--- a/runtime/doc/repeat.txt    Wed Oct 22 22:09:01 2014 +0200
+++ b/runtime/doc/repeat.txt    Mon Oct 27 07:04:58 2014 -0400
 <at>  <at>  -64,6 +64,8  <at>  <at> 

 For the definition of a pattern, see |pattern|.

+NOTE [cmd] may contain a range as well; see |collapse| and
|edit-paragraph-join|.
+
 The global commands work by first scanning through the [range] lines and
 marking each line where a match occurs (for a multi-line pattern, only the
 start of the match matters).
diff -r 8bb4ca7fba40 runtime/doc/usr_25.txt
--- a/runtime/doc/usr_25.txt    Wed Oct 22 22:09:01 2014 +0200
+++ b/runtime/doc/usr_25.txt    Mon Oct 27 07:04:58 2014 -0400
 <at>  <at>  -402,7 +402,7  <at>  <at> 
     :map <Down> gj

 
-TURNING A PARAGRAPH INTO ONE LINE
+TURNING A PARAGRAPH INTO ONE LINE               *edit-paragraph-join*
(Continue reading)

Roland Eggner | 26 Oct 21:58 2014
Picon

[patch] vartabstops: (a) readded src/testdir/test_vartabs.{in,ok} (b) fixed diff hunk erroneously applied due to context change in 7.4.456

Hi all!

When options breakindent, wrap and vartabstop are used all together, there are 
erroneous indentation offsets of continuation lines, as if 
breakindentopt=shift:N would specify nonzero values of N depending on number of 
tab characters at start of line, even if vartabstop is set to a single number, 
e.g. “set vartabstop=4”.

Otherwise the patch works for me as advertised.

Many thanks to Christian and all the other contributors for this patch, 
vartabstop is a very useful feature!

vim -u NONE -U NONE -c ':language en_US.utf8| set columns=80| version| quit'
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 23 2014 19:38:34)
Included patches: 1-488
Extra patches: variable tabstops
Modified by Gentoo-7.4.488-≤odvx1 <at> systomanalyson.not_s/o/e/g>
Compiled by <odvx1 <at> systomanalyson.not_s/o/e/g>
Huge version without GUI.  Features included (+) or not (-):
+acl             -farsi           -mouse_sgr       +tag_old_static
-arabic          +file_in_path    -mouse_sysmouse  -tag_any_white
+autocmd         +find_in_path    -mouse_urxvt     -tcl
-balloon_eval    +float           -mouse_xterm     +terminfo
-browse          +folding         +multi_byte      +termresponse
++builtin_terms  -footer          +multi_lang      +textobjects
+byte_offset     +fork()          -mzscheme        +title
+cindent         +gettext         -netbeans_intg   -toolbar
-clientserver    -hangul_input    +path_extra      +user_commands
-clipboard       +iconv           +perl            +vartabs
(Continue reading)

vim | 26 Oct 00:25 2014

Issue 275 in vim: set clipboard=autoselect,on windows os, it is not by default

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 275 by Go.Zu... <at> gmail.com: set clipboard=autoselect,on windows  
os, it is not by default
https://code.google.com/p/vim/issues/detail?id=275

What steps will reproduce the problem?
1. On windows OS, vim in normal mode, to change the next text line:

a_golf_ball - > - > - > - > |___________| -

to:

             - > - > - > - > |a_golf_ball| -

using 9 keystrokes:

ver *R<C-R>*<Esc>

2.On Windows, by default, these keystrokes does nothing.

3.But under the X11, with vim using the default settings, changing the line  
works !

What is the expected output?

To change the line.

(Continue reading)


Gmane