Gap between scrollbar and window border when compiled with Visual Studio 2012
Hi, Does anyone know why when compiled with visual studio 2012, the vim gui has gap between the scrollbars and the window borders. Here's the screenshot of vim compiled with visual studio 2010 http://imgur.com/lI05rgq And here is when compiled with visual studio 2012 http://imgur.com/iLeVis1 Both are compiled with the same source code, same configuration, same platform (x64). -- -- 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/groups/opt_out.
Issue 149 in vim: Bug in history management with multiple file buffers
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 149 by gu...@ascomp.ch: Bug in history management with multiple file buffers http://code.google.com/p/vim/issues/detail?id=149 What steps will reproduce the problem? Suppose I have 2 files A and B open in my vim using multiple file buffers 1. I open file A 2. I make a change in A 3. I save the change made to file A 4. Then I open the file buffer for B using bp. 5. Then if I go to the terminal by pressing Ctrl+Z 6. I go back to my file B by pressing fg in the terminal. 7. Then afterwards I go back to the buffer associated with file A 8. If I do undo the history of file A is not there. What is the expected output? What do you see instead? When I do undo I would want the history of file A to be still there What version of the product are you using? On what operating system? vim 7.3 Patches Included: 1-763, 765-831 OpenSuse 12.3 Please provide any additional information below. -- 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/groups/opt_out.
Main help display issue
Hi all, 1. command vim -nNX -u NONE 2. :h 3. :on 4. :se cole=2 lbr 5. :sy on Now you can see a misaligned paragraph starting on line 36 First tought this was a tab vs space issue as you can see with :se list but 'cole is somehow also involved as setting it to 0 removes the misalignment Cheers Dimitar --- GPG Key: 2048R/160C6FA8 2012-10-11 Dimitar Dimitrov (kurkale6ka) mitk...@yahoo.fr -- -- 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/groups/opt_out.
Re: Issue 149 in vim: Bug in history management with multiple file buffers
Comment #1 on issue 149 by fritzoph...@gmail.com: Bug in history management with multiple file buffers http://code.google.com/p/vim/issues/detail?id=149 This is expected behavior. By default Vim discards undo history when you abandon a buffer. You have a few options: 1. Set the 'hidden' option so Vim doesn't abandon the buffer. 2. Set the 'undofile' option so Vim saves the undo information in a file (also lets you quit Vim and relaunch Vim and keep the undo info). 3. Open a new window or tab for file B instead of switching buffers in the same window. -- 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/groups/opt_out.
Re: Breaking undo in Insert mode
On Thursday, July 4, 2013 4:44:26 AM UTC-5, Bram Moolenaar wrote: Perhaps we can somehow detect that CTRL-R = had the side effect of changing the text and then split undo. When it only returns the text to be inserted, there is no need to split undo. Even though it won't fix it all the way, I think this is a good idea. It will make things a lot better at least. Then we can do this obviously simplified example without breaking undo: inoremap Space C-R=\LTSpaceCR -- -- 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/groups/opt_out.
Re: Breaking undo in Insert mode
On Thu, Jul 11, 2013 at 10:36 AM, Ben Fritz fritzophre...@gmail.com wrote: On Thursday, July 4, 2013 4:44:26 AM UTC-5, Bram Moolenaar wrote: Perhaps we can somehow detect that CTRL-R = had the side effect of changing the text and then split undo. When it only returns the text to be inserted, there is no need to split undo. Even though it won't fix it all the way, I think this is a good idea. It will make things a lot better at least. Then we can do this obviously simplified example without breaking undo: inoremap Space C-R=\LTSpaceCR Wasn't this supposedly fixed? 7.3.1290 (after 7.3.1253) CTRL-R = in Insert mode starts new insert -- -- 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/groups/opt_out.
Re: Breaking undo in Insert mode
On Thu, July 11, 2013 17:36, Ben Fritz wrote: On Thursday, July 4, 2013 4:44:26 AM UTC-5, Bram Moolenaar wrote: Perhaps we can somehow detect that CTRL-R = had the side effect of changing the text and then split undo. When it only returns the text to be inserted, there is no need to split undo. Even though it won't fix it all the way, I think this is a good idea. It will make things a lot better at least. Then we can do this obviously simplified example without breaking undo: inoremap Space C-R=\LTSpaceCR Wouldn't in this example CTRL-R= also change the text and therefore break undo here as well? regards, 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/groups/opt_out.
Re: Breaking undo in Insert mode
On Thu, July 11, 2013 17:41, Benjamin Fritz wrote: On Thu, Jul 11, 2013 at 10:36 AM, Ben Fritz fritzophre...@gmail.com wrote: On Thursday, July 4, 2013 4:44:26 AM UTC-5, Bram Moolenaar wrote: Perhaps we can somehow detect that CTRL-R = had the side effect of changing the text and then split undo. When it only returns the text to be inserted, there is no need to split undo. Even though it won't fix it all the way, I think this is a good idea. It will make things a lot better at least. Then we can do this obviously simplified example without breaking undo: inoremap Space C-R=\LTSpaceCR Wasn't this supposedly fixed? 7.3.1290 (after 7.3.1253) CTRL-R = in Insert mode starts new insert No, that fixes the problem that ctrl-r = in insert mode changes the position of the '[ mark. regards, 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/groups/opt_out.
Patch 7.3.787 performance
Hi, I noticed in the vim 7.4a beta (I believe it is the patch 7.3.787 but I'm not entirely sure), it looks like relative line number performance has greatly decreased. If I open a file with just 100 lines, scrolling via rnu is quite choppy, and if I turn it off, it's very fast again. This worked before the RNU patch. I also have row and column highlighting off. -- -- 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/groups/opt_out.
Re: Breaking undo in Insert mode
On Thursday, July 11, 2013 10:45:16 AM UTC-5, Christian Brabandt wrote: On Thu, July 11, 2013 17:36, Ben Fritz wrote: On Thursday, July 4, 2013 4:44:26 AM UTC-5, Bram Moolenaar wrote: Perhaps we can somehow detect that CTRL-R = had the side effect of changing the text and then split undo. When it only returns the text to be inserted, there is no need to split undo. Even though it won't fix it all the way, I think this is a good idea. It will make things a lot better at least. Then we can do this obviously simplified example without breaking undo: inoremap Space C-R=\LTSpaceCR Wouldn't in this example CTRL-R= also change the text and therefore break undo here as well? It doesn't change the text directly, it only returns a value. Actually this mapping seems to work now that I try it again. I'm not sure what I did differently when it didn't work the first time I tried. Something is making me unable to use delimitMate, because even if set the option that makes the Space mapping simply return a space, the undo sequence breaks on every space insertion. This is closer to what is actually going on in delimitMate, but I still can't reproduce the issue. I will try again later to get a smaller example: function! Space() return \Space endfun inoremap flarbityflarb C-]C-R=Space()CR imap Space C-]flarbityflarb -- -- 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/groups/opt_out.
Re: Patch 7.3.787 performance
On Do, 11 Jul 2013, Travis wrote: I noticed in the vim 7.4a beta (I believe it is the patch 7.3.787 but I'm not entirely sure), it looks like relative line number performance has greatly decreased. If I open a file with just 100 lines, scrolling via rnu is quite choppy, and if I turn it off, it's very fast again. This worked before the RNU patch. I also have row and column highlighting off. Recently, there was another patch, modifying the behaviour of 7.3.787. So please try with vim 7.4 beta and try different settings of :set rnu and :set nu Mit freundlichen Grüßen Christian -- Mädchen - das sind diejenigen, die rückwärts tanzen. -- Bob Hope -- -- 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/groups/opt_out.
[patch] let sign placement default to current buffer
Bram,
this small patch makes sign placement easier by defaulting to use the
current buffer instead of yielding an error.
Mit freundlichen Grüßen
Christian
--
Morgens am Frühstückstisch. Er kratzt mit dem Löffel das Eigelb von
seinem Hemd und sagt: Oh Mann, ich sehe aus wie ein Schwein!
Sie: Stimmt! Und bekleckert hast du dich auch!
--
--
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/groups/opt_out.
diff --git a/runtime/doc/sign.txt b/runtime/doc/sign.txt
--- a/runtime/doc/sign.txt
+++ b/runtime/doc/sign.txt
@@ -134,8 +134,9 @@
to be done several times and making changes may not work as
expected).
-:sign place {id} line={lnum} name={name} buffer={nr}
- Same, but use buffer {nr}.
+:sign place {id} line={lnum} name={name} [buffer={nr}]
+ Same, but use buffer {nr}. If the buffer argument is not
+ given, place the sign in the current buffer.
:sign place {id} name={name} file={fname}
Change the placed sign {id} in file {fname} to use the defined
@@ -143,8 +144,9 @@
This can be used to change the displayed sign without moving
it (e.g., when the debugger has stopped at a breakpoint).
-:sign place {id} name={name} buffer={nr}
- Same, but use buffer {nr}.
+:sign place {id} name={name} [buffer={nr}]
+ Same, but use buffer {nr}. If the buffer argument is not
+ given, place the sign in the current buffer.
REMOVING SIGNS *:sign-unplace* *E159*
@@ -194,7 +196,8 @@
If the file isn't displayed in window and the current file can
not be |abandon|ed this fails.
-:sign jump {id} buffer={nr}
- Same, but use buffer {nr}.
+:sign jump {id} [buffer={nr}]
+ Same, but use buffer {nr}. If the buffer argument is not
+ given, place the sign in the current buffer.
vim:tw=78:ts=8:ft=help:norl:
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -7129,8 +7129,8 @@
}
else
{
- EMSG(_(e_invarg));
- return;
+ buf = curwin-w_buffer;
+ break;
}
arg = skipwhite(arg);
}
Re: Vim 7.4a ready for beta testing (test96 FAILED)
Raf wrote: Bram Moolenaar wrote: Announcing: Vim (Vi IMproved) version 7.4a BETA This is the first BETA release of Vim 7.4. Please check that the distribution is OK. I haven't done one for a long time. Report anything that isn't right. That includes a crash but also a typo in the documentation or a missing file. mid-2010 macbookpro macosx-10.6.8 gcc-4.2.1 obtained vim-7.4a.002 via hg (same result via ftp). configure \ --disable-darwin \ --with-x \ --enable-gui=motif \ --enable-multibyte \ --with-mac-arch=current \ --with-features=huge \ --disable-acl Test results: test96 FAILED TEST FAILURE diff -u test96.ok test96.failed --- test96.ok 2013-07-08 10:12:36.0 +1000 +++ test96.failed 2013-07-08 10:15:31.0 +1000 @@ -4,6 +4,8 @@ - quickfix claims that the file name displayed is: test://bar.txt Test B: - number of window open: 2 +Test B: + - number of window open: 2 Test C: - 'buftype' of the location list window: quickfix - buffer displayed in the 2nd window: test://quux.txt i.e. the Test B section of the file is repeated. That's strange. Please check that your version of src/testdir/test96.in is the same as https://code.google.com/p/vim/source/browse/src/testdir/test96.in it's the same. MD5 (/usr/local/src/vim74/src/testdir/test96.in) = 3222973df5598f7ff3297d3cf9b5ecd9 i've tried with three separate copies of 7.4a.010: hg (https://vim.googlecode.com/hg/) test96 fails hg (https://code.google.com/p/vim) test96 fails ftp (ftp.vim.org) test96 passes how wierd is that? the two hg versions are the same but there are some differences between them and the ftp version. the differences are that the ftp version has older versions of: Makefile runtime/compiler/checkstyle.vim runtime/compiler/javac.vim runtime/compiler/php.vim runtime/compiler/se.vim runtime/compiler/tcl.vim runtime/compiler/tidy.vim runtime/compiler/xmllint.vim runtime/doc/diff.txt runtime/doc/options.txt runtime/doc/todo.txt runtime/doc/uganda.txt runtime/doc/version7.txt runtime/plugin/tohtml.vim runtime/synmenu.vim runtime/syntax/2html.vim runtime/syntax/help.vim src/po/nl.po src/po/pl.UTF-8.po src/po/pl.cp1250.po src/po/pl.po src/po/ru.cp1251.po src/po/ru.po i don't know if that helps. the actual diff can be found at http://raf.org/tmp/vim74a.010-ftp-v-code.google.com-p-vim.diff if it's of any use. it's odd that yesterday the ftp version of 7.4a.002 failed but today the ftp version of 7.4a.010 passed. i just tested the ftp version again at every patchlevel up to 010 and they all worked. the hg version still fails though. bizarre. If you can't reproduce a problem you had earlier, it's likely that something else matters. Can you run the test under valgrind? There is a line in src/testdir/Makefile you can uncomment. The test is about location lists, the runtime files should not matter. If they do, it might be that things shift around in memory and trigger the problem somehow. the hg version still produced the error just now. i uncommented the VALGRIND definition in src/tesdir/Makefile and uncommented the LEAK_CFLAGS = -DEXITFREE line in src/Makefile and recompiled vim and reran the tests and test96 passed this time. here's the valgrind report for test96: ==8976== Memcheck, a memory error detector ==8976== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==8976== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==8976== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test96.in ==8976== Parent PID: 3970 ==8976== --8976-- ../vim: --8976-- dSYM directory is missing; consider using --dsymutil=yes ==8976== Warning: ignored attempt to set SIGUSR2 handler in sigaction(); ==8976== the SIGUSR2 signal is used internally by Valgrind What compiler are you using? This looks like OSX. But I thought there was no valgrind for that. Runnint with valgrind also shifts things around. Although you would be really lucky if the wrong accesses happen to fall in valid memory areas. -- How come wrong numbers are never busy? /// 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
Re: [patch] use correct python3 config directory when sys.abiflags is empty
Tim Harder wrote:
I've attached a patch to fix an issue where the wrong python3 config
directory is used when a system's sys.abiflags are empty.
Hmm, but when adding vi_cv_var_python3_abiflags when it's not empty,
might as well do:
config_dir=config-${vi_cv_var_python3_version}${vi_cv_var_python3_abiflags}
Anything against that?
That should work fine. I was somewhat puzzled why the conditional was used
anyway.
I can only imagine a check for vi_cv_var_python3_version, when it's
empty the dash should not be added. But apparently it's never empty.
--
We apologise again for the fault in the subtitles. Those responsible for
sacking the people who have just been sacked have been sacked.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// 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/groups/opt_out.
bd closes gvim instead of the specific buffer
Hi, Wondering if anyone could help me debug why bd would close gvim even if multiple buffers are open. I does not close the specific buffer. I have the following plugins installed: solarized nerdtree taglist_46 thanks. -- -- 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/groups/opt_out.
Re: bd closes gvim instead of the specific buffer
On Fri, July 12, 2013 01:10, Sumonto Ghosh wrote: Hi, Wondering if anyone could help me debug why bd would close gvim even if multiple buffers are open. I does not close the specific buffer. I have the following plugins installed: solarized nerdtree taglist_46 Well, please be a little more specific. What did you do, what happened, what did you expect? How do you reproduce it? regards, 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/groups/opt_out.
