RE: Set mouse=a causes Vim to hang in screen.
-Original Message- From: vim_dev@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gautam Iyer Sent: 12 January 2008 03:47 To: vim_dev@googlegroups.com; [EMAIL PROTECTED] Subject: Re: Set mouse=a causes Vim to hang in screen. On Fri, Jan 11, 2008 at 08:51:56PM -0500, James Vega wrote: The following caused Vim to hang: 1. Create /tmp/vimrc with the following lines: set nocp set mouse=a 2. Run screen, and then do $ vim -u /tmp/vimrc Vim hangs before starting up. But it does finish starting? Nope! Just hangs for ever. However when I kill it (using kill -- Ctrl-C is ignored), it leaves the intro message drawn on the screen. Sounds like you have a $DISPLAY environment variable which is incorrect and Vim is (unsuccessfully) attempting to connect to the X server. Well, the same problem is caused when I do vim -X. Also, env TERM=rxvt vim connects to the X server just fine (in fact, even gvim runs). Can anyone else reproduce this? I tried and I can't reproduce it. This is on Linux RH server v 4, vim 7.1.211. ---Zdenek --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in @{reg} together with [EMAIL PROTECTED]
Andy Wokula schrieb:
Nikolai Weibull schrieb:
On Jan 8, 2008 6:45 PM, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
It might help folks help you if you included the
get_command_mode_range() function.
Ugh, yeah, I'm beginning to have a suspicion as to what the problem is:
function! s:get_command_mode_range(type)
let b = line('[)
let e = line('])
if b e
let range = '.,+' . (e - b)
elseif b == e
let range = '.'
else
let range = '.,+' . (b - e)
endif
call feedkeys(':' . range, 'n')
endfunction
I'm guessing that feedkeys() is the culprit here.
Yes, feedkeys() puts its argument at the end of the input buffer, which
already contains the contents of register a.
I think you have found a limit of g@ -- I wasn't able to find a solution
that keeps the elegance, now an additional _r in the recording is needed
to insert the range.
Try this one (g: for Normal mode only):
nmap g: :set operatorfunc=sidget_command_mode_rangeCRg@
let @a = g:}_rj\r
note: the final ^M causes an additional ^@ to be added to the
register
func! s:get_command_mode_range(type)
let b = line('[)
let e = line('])
if b e
let range = '.,+' . (e - b)
elseif b == e
let range = '.'
else
let range = '.,+' . (b - e)
endif
exe nmap _r :. range
endfunc
Problem:
If we use g@ in the {rhs} of a mapping for g: , we cannot add further
keys there, because Vim has no concept of place holders for the motion
the user has to type. Currently, the first few of the further keys
will be taken as the motion for g@ before continuing.
Ok, I was wrong. Vim *has* inputsave() and inputrestore().
nmap silent g: :set operatorfunc=sidExRangeOpCRg@
let @a = g:}join
final CR to be added
func! s:ExRangeOp(type)
let b = line('[)
let e = line('])
if b e
let range = '.,+' . (e - b)
elseif b == e
let range = '.'
else
let range = '.,+' . (b - e)
endif
call inputsave()
call feedkeys(':'. range. \c-r=''[inputrestore()]\r, 'n')
endfunc
--
Andy
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: [PATCH] Cross-compilation patch to avoid looking for /usr/local at compile time
On Friday 11 January 2008, Bram Moolenaar wrote: Marc Haisenko wrote: What about the main configure.in fixes for cross-compiling patch by me ? Is there anything I need to tweak so you can accept it or is there some reason why you'd say the patch wouldn't be necessary ? When adding a new argument to configure it's always good to document this in the appropriate places. No worry, the patch doesn't add any new arguments. It only allows to use the appropiate autoconf mechanism (well-named environment variables) to pass the results of tests in environments where those tests can't be done (cross-compiling). Is there any file I'd need to document them ? Haven't seen any yet. Don't get me wrong, I wouldn't be mad if you'd declined it, I just want a definitive accepted or declined. I still need to look into this. Configure patches are always tricky. Yes, they are :-) Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in FAQ at http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl
On Jan 3, 2008 3:58 AM, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: There used to be a cron job that periodically converted the text version of the FAQ to the HTML version and uploaded it to the Vim online site. I think that stopped working a few years ago. Would it make sense to try and export the wiki to that site or, at least, add warnings to the FAQ pages that they are not current any more and a pointer to the wiki? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.1.229
Patch 7.1.229
Problem:A fold is closed when it shouldn't when 'foldmethod' is indent
and backspacing a non-white character so that the indent increases.
Solution: Keep the fold open after backspacing a character.
Files: src/edit.c
*** ../vim-7.1.228/src/edit.c Sat Jan 12 18:13:05 2008
--- src/edit.c Mon Jan 14 20:06:43 2008
***
*** 8618,8623
--- 8619,8632
if (vim_strchr(p_cpo, CPO_BACKSPACE) != NULL dollar_vcol == 0)
dollar_vcol = curwin-w_virtcol;
+ #ifdef FEAT_FOLDING
+ /* When deleting a char the cursor line must never be in a closed fold.
+ * E.g., when 'foldmethod' is indent and deleting the first non-white
+ * char before a Tab. */
+ if (did_backspace)
+ foldOpenCursor();
+ #endif
+
return did_backspace;
}
*** ../vim-7.1.228/src/version.cSun Jan 13 21:57:25 2008
--- src/version.c Mon Jan 14 20:08:35 2008
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 229,
/**/
--
ROBIN: (warily) And if you get a question wrong?
ARTHUR: You are cast into the Gorge of Eternal Peril.
ROBIN: Oh ... wacho!
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Set mouse=a causes Vim to hang in screen.
On Mon, Jan 14, 2008 at 05:59:24PM +0100, Vladimir Marek wrote: [...] Can anyone else reproduce this? Nope. Solaris, x86, vim 7.1 Ok. I tried reproducing this on a few other systems too. I can't reproduce it on Fedora, Gentoo and Mac OS X (Leo). But the above causes Vim to hang every time on Scientific Linux release 5.0 (Boron). Would anyone have any idea as to why? I've currently just aliased vim to env TERM=rxvt vim under screen, which causes the problem to go away. So it's not critical... GI -- The 10 Commandments of DOS: 3. Thy hard disk shall never have more than 1024 sectors. You don't need that much space anyway. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch to fix VC8 compiler warnings
On 14/01/2008, Bram Moolenaar [EMAIL PROTECTED] wrote: Mike Williams wrote: Catching up from the weekend patches I had two warnings for my builds. The attached patch fixes them - done against 7.1.228 Thanks. I'm wondering if LONGLONG is always defined when WIN3264 is defined. We don't use LONGLONG yet anywhere. LONGLONG should be defined in all recent versions of the compiler and SDK. Always as a 64-bit signed quantity. Recent = last six years or so. -- /George V. Reilly http://www.georgevreilly.com/blog --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for Unix filename expansion to try out
On Fri, Jan 04, 2008 at 12:17:42 +, Bram Moolenaar wrote: A couple of problems were detected when the Unix shell is used to expand file names containing characters such as a single quote. This applies to completion on the command line and glob(). I made a patch that defines a function to echo each file name separately. Inspired by a patch that Dasn made, but staying on the safe side. The patch for ex_docmd.c changes detecting the end of the file name when doing command line completion. This specifically fixes a file name containing . Please try it out and let me know if there are any new problems. I tried it out and found a problem. This is my directory structure: a'b/ DS=70 DS 70 DS=D66 + S70 There is a directory a'b and it contains three files. The first filename (DS=70) doesn't contain any spaces, the other two do. Now I start Vim. At first, I'm inputting :n a followed by a TAB. The screen will display :n a\'b/, which is correct. Then I type a TAB again and again and again. $ vim :n aTAB :n a\'b/ :n a\'b/TABTABTAB :n a\'b/DS=70 :n a\'b/DS=70 :n a\'b/DS=70 (Nothing happens, only one filename matches) :n a\'b/*6TAB (Nothing happens, no filename matches) :n a\'b/*6*0TAB (Nothing happens, no filename matches) :n a\'b/DS\ 7TAB (Nothing happens, no filename matches) :n a\'b/DS\TAB :n a\'b/DS\* Adri (Vim 7.1 + patches 1-200 plus Bram's Patch for Unix filename expansion) --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for Unix filename expansion to try out
On 14/01/08 21:49 +0100, Adri Verhoef wrote: Please try it out and let me know if there are any new problems. I tried it out and found a problem. This is my directory structure: a'b/ DS=70 DS 70 DS=D66 + S70 There is a directory a'b and it contains three files. The first filename (DS=70) doesn't contain any spaces, the other two do. Now I start Vim. At first, I'm inputting :n a followed by a TAB. The screen will display :n a\'b/, which is correct. Then I type a TAB again and again and again. $ vim :n aTAB :n a\'b/ :n a\'b/TABTABTAB :n a\'b/DS=70 :n a\'b/DS=70 :n a\'b/DS=70 (Nothing happens, only one filename matches) :n a\'b/*6TAB (Nothing happens, no filename matches) :n a\'b/*6*0TAB (Nothing happens, no filename matches) :n a\'b/DS\ 7TAB (Nothing happens, no filename matches) :n a\'b/DS\TAB :n a\'b/DS\* Adri (Vim 7.1 + patches 1-200 plus Bram's Patch for Unix filename expansion) I can't reproduce this with 1-229. Patch 223 has been released, have a try? -- Dasn --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
tar: Read 5120 bytes from - (Re: Porting vim to Astlinux)
On Sun, Dec 16, 2007 at 01:54:08 +, Philip Prindeville wrote: bzcat /home/philipp/trunk/dl/vim-7.1.tar.bz2 | tar -C /home/philipp/trunk/build_i586 -xf - tar: Read 5120 bytes from - Any idea why (re: the short read on tar)? This is not a problem. Tar doesn't complain if you decompress the .bz2 file at first and then tar -xf the decompressed file (.tar). Tar doesn't know the size of the uncompressed file (yet) when it's still compressed because Tar is reading from stdin. Try this: (bzcat ~/.../.../vim-7.1.tar.bz2 ; dd bs=5120 if=/dev/zero count=1 ) | tar tvf - Does it help? Adri ᴠɪᴍ ⒎ ① --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Cross-compilation patch to avoid looking for/usr/local at compile time
Michael Haubenwallner wrote: On Thu, 2008-01-10 at 22:10 +0100, Bram Moolenaar wrote: Philip Prindeville wrote: What I tried to say: excluding /usr/local/[include|lib] is not specific for cross compiling. This should be a separate setting. Then it can also be set for cross compiling. Thank you for the trigger to rework my old patch http://www.mail-archive.com/[EMAIL PROTECTED]/msg02896.html to check gcc if it already uses the wanted local-dir. /haubi/ That would work for me. -Philip --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
