Build failure OS X 10.8.4 for 7.4a.28

Hello, Just pulled 7.4a28, after having successfully build 7.4a.24. Build failed with this at the end: Undefined symbols for architecture x86_64: _find_win_for_buf, referenced from: _RBAppend in if_python.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit

Re: Build failure OS X 10.8.4 for 7.4a.28

On Wed, Jul 17, 2013 at 12:36 PM, Manuel Ortega mannyvim...@gmail.comwrote: Hello, Just pulled 7.4a28, after having successfully build 7.4a.24. Build failed with this at the end: Undefined symbols for architecture x86_64: _find_win_for_buf, referenced from: _RBAppend

Re: Vim-7.4 no longer recognizes some mail files by file name

On Mon, Jul 29, 2013 at 8:36 PM, Gary Johnson garyj...@spocom.com wrote: I just noticed this today with 7.4b but the behavior is the same with 7.4a.9. It works correctly with 7.3.882. The problem is that when I open a temporary file created by mutt with the name /tmp/muttV1LGjR, the latest

Re: Vim-7.4 no longer recognizes some mail files by file name

On Tue, Jul 30, 2013 at 12:05 PM, Manuel Ortega mannyvim...@gmail.comwrote: On Mon, Jul 29, 2013 at 8:36 PM, Gary Johnson garyj...@spocom.com wrote: This should be detected by both of the following patterns in $VIMRUNTIME/filetype.vim: mutt[[:alnum:]_-]\{6\} mutt[[:alnum:]._-]\{6

Terrible bug wrt g~ and undo.

There is a horrendous bug wrt the 'g~' operator. I've found it on OSX 10.8.4. Doesn't matter whether it's MacVim 7.4b or Vim 7.4b.18. To reproduce: Make a new file with three lines: - a b - (The middle line is empty, and there's no trailing whitespace after a

Two bugs in vim.vim syntax file

There are at least two bugs in vim syntax highlighting. It occurs when one leaves out optional spaces in a List or Dictionary. For example: let foo = ['one','two','three'] shows distractingly bizarre highlighting. The second and third elements have only their first letter colored, and that

Re: Two bugs in vim.vim syntax file

Sorry, forgot to include this info: I'm on OSX 10.8.4, with Vim 7.4.005. The bug also appear in MacVim 7.4. -Manny -- -- 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

Re: Two bugs in vim.vim syntax file

On Mon, Aug 19, 2013 at 9:21 AM, Charles Campbell charles.e.campb...@nasa.gov wrote The problem is discriminating between marks and strings. My solution has been to reduce the number of items detected as marks and to favor strings. Please try

I wish I had known this earlier; please put it in the docs!

Dear Bram, While perusing $VIMRUNTIME/syntax/vim.vim, I noticed that many of the attributes to the command :command can be abbreviated. Namely: instance: -n[args] -com[plete] -ra[nge] -cou[nt] -re[gister] -ban[g] I didn't ever know this before. No wonder! As far as I can

Re: I wish I had known this earlier; please put it in the docs!

On Mon, Aug 19, 2013 at 3:53 PM, Manuel Ortega mannyvim...@gmail.comwrote: Dear Bram, While perusing $VIMRUNTIME/syntax/vim.vim, I noticed that many of the attributes to the command :command can be abbreviated. Namely: instance: -n[args] -com[plete] -ra[nge] -cou[nt

Small addition to syntax/vim.vim

As noted in an earlier thread, I discovered that most attributes to :command can be abbreviated. I discovered this only by accident, looking in syntax/vim.vim. Turns out, in that syntax file (a) there is no support for the attribute -buffer (for buflocal commands), and (b) trial and error

Re: Small addition to syntax/vim.vim

On Wed, Aug 21, 2013 at 1:50 PM, Charles Campbell charles.e.campb...@nasa.gov wrote: Bram Moolenaar wrote: So Dr. Chip, please add this attribute to the syntax file. And Bram, please note this in the docs about -buffer too. This is not really intended to work that way. It happens that

Re: [PATCH] Disable Pattern not found message unless verbose 0

## Reason It is quite annoying when you use auto-completion plugins like YouCompleteMe or neocomplete. ## Related Discussion: - https://github.com/Valloric/YouCompleteMe/issues/642#issuecomment-27711342 -

Re: [patch][docfix] maparg()'s {dict} now returns also nowait

+ nowait Do not wait another longer mappings +(|:map-nowait|). This isn't quite English. Perhaps Do not wait to see whether the user is entering a longer {lhs} before triggering the map? -- -- You received this message from the vim_dev

Re: [patch] uppercase marks don't work after bwiping a buffer

On Mo, 09 Dez 2013, Bram Moolenaar wrote: Christian Brabandt wrote: I use an uppercase mark to access a blowfish encrypted file. I therefore :bwipe that buffer when I'm done with this file. Unfortunately, I can't use the uppercase mark again, to reload that file, Vim throws E92

Re: [patch] uppercase marks don't work after bwiping a buffer

Now, since lowercase marks are associated with the *buffer* and not the *file*, I would in fact expect :bwipe to zap those. Huh? Lowercase marks are associated with *files*. In the .viminfo file, where the lowercase marks are, each one is associated with a pathname, i.e., a file. (It's just

Re: [patch] uppercase marks don't work after bwiping a buffer

Now, since lowercase marks are associated with the *buffer* and not the *file*, I would in fact expect :bwipe to zap those. Huh? Lowercase marks are associated with *files*. In the .viminfo file, where the lowercase marks are, each one is associated with a pathname, i.e., a file.

Re: [patch] uppercase marks don't work after bwiping a buffer

On Wed, Dec 11, 2013 at 5:55 PM, Ben Fritz fritzophre...@gmail.com wrote: On Wednesday, December 11, 2013 4:00:22 PM UTC-6, Manuel Ortega wrote: Now, since lowercase marks are associated with the *buffer* and not the *file*, I would in fact expect :bwipe to zap those. Huh? Lowercase

Re: [patch] uppercase marks don't work after bwiping a buffer

On Thursday, December 12, 2013 1:10:07 PM UTC-6, Manuel Ortega wrote: I never said it would make 'b magically jump to my profile if I'm currently looking at something that isn't my profile. I said lowercase marks are associated with files. And each lowercase mark a-z is a mark

TextChanged[I] still missing in parts of docs

The autocommand events TextChanged* do not appear in the short list of autocommand events that begins on line 201 of autocmd.txt. -Manny -- -- 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

Re: TextChanged[I] still missing in parts of docs

On Mon, Dec 16, 2013 at 1:15 AM, Manuel Ortega mannyvim...@gmail.comwrote: The autocommand events TextChanged* do not appear in the short list of autocommand events that begins on line 201 of autocmd.txt. -Manny Never mind, my bad. I was using MacVim, which is several patches behind

Re: when searching for files, upward search with a relative path no longer works in vim7.4

On Thu, Dec 19, 2013 at 6:31 PM, Aaron Bohannon a...@google.com wrote: To reproduce (on standard *nix installation): (1) start vim in your home directory (2) :cd .vim (3) :echo findfile('.vimrc', expand('$USER') . ';') In vim 7.3, you get something like /home/$USER/.vimrc. In vim 7.4,

Re: Suggestion: Every primitive vim operation should have a callable descriptive name

On Sat, Jan 11, 2014 at 11:36 PM, Mosh moshah...@gmail.com wrote: All builtin vim operations should be named for 2 reasons: 1. if you map a key, then the original command binding is unavailable: example: :map [ 0.. Now how do I call [c in diff mode; [c doesn't have a name.

Re: [patch] doc/gui.txt: small complements

Part of your addition contains a typo. It should be these commands, not this commands. -Manny -- -- 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

Re: security context with undo file

I get a similar warning over and over when I ran make test after building 7.4.241. That is, I get that warning inside the running of the tests, and test82 fails. I tried reconfiguring with --disable-smack, but that didn't change anything. This is on a GNU/Linux virtual host. I am not seeing

Re: security context with undo file

On Wed, Apr 2, 2014 at 3:20 PM, Manuel Ortega mannyvim...@gmail.com wrote: I get a similar warning over and over when I ran make test after building 7.4.241. That is, I get that warning inside the running of the tests, and test82 fails. I tried reconfiguring with --disable-smack

Re: security context with undo file

The culprit is 7.4.238. Patch 7.4.244 seems to have fixed it; thanks! -Manny -- -- 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

Re: _dd doesn't reset v:register

On Sat, Apr 19, 2014 at 9:47 AM, Andrew andrey.ra...@gmail.com wrote: Given a text file with the following two lines: first line second line If you now go to the second line and yank it, then go to the first line and type in _ddp What I'd expect to happen is: second

Re: [Bug] Meta key mappings do not work in recording or :normal command

On Sun, May 11, 2014 at 4:16 PM, Jacob Niehus jacob.nie...@gmail.comwrote: Hello, I have found that meta key mappings do not work properly when used in a recording/macro or the :normal command. This happens in both terminal and GUI Vim so I don't think it's a key code issue. Steps to

Re: Vim 7.4 Relative line number bug?

On Sun, May 11, 2014 at 2:43 PM, Robert Arkwright rarkwri...@gmail.comwrote: I may have discovered a bug with relative line numbers in Vim 7.4. To reproduce: * Launch Vim with default configuration (no ~/.vimrc or ~/.vim directory). * Immediately enter insert mode (i). * Enter ten lines of

Re: Filtering under folds

On Wed, May 21, 2014 at 2:58 PM, Teemu Ikonen tpiko...@gmail.com wrote: Filtering a line which is currently folded results in the whole fold being filtered. For example, take a 2-line file like below with set foldmethod=marker: one {{{1 two Issuing the command ':2!echo foo', when the fold

Re: MacVim builds against a custom Python Framework, but eventually the default Python.Framework is what gets linked?!

On Thu, May 22, 2014 at 5:13 PM, Muhittin Bilginer muhittin.bilgi...@gmail.com wrote: Hi, I have been desperately trying to build MacVim against a custom Python framework with no luck so far. I have tried many things, at the end MacVim builds with no errors, but when I check the linking of

Re: Buffer position not preserved when resizing window (7.4.307)

On Sun, May 25, 2014 at 9:17 AM, Bram Moolenaar b...@moolenaar.net wrote: Ron Aaron wrote: To repro the issue: gvim -u NONE somefile :sp 50G Now switch to the second window C-WW And resize it: C-W+ Note that the first window will jump back to line 1

Re: runtime/doc/tags under Mercurial control

On Saturday, May 18, 2013 7:15:27 AM UTC-4, Xavier de Gaye wrote: runtime/doc/tags is under Mercurial control: $ hg locate runtime/doc/tags runtime/doc/tags This file is automatically generated during vim build. It is annoying to have it appear sometimes in the output of 'hg

Can the regexpengine and python bonanza be moved to a beta branch?

Dear Bram, Now that there is no longer pressure to quickly cram everything in to avoid patchlevel 1000 and up (too late), shouldn't the regex engine stuff and the flurry of pythoniana be moved into a 7.4beta branch, or vim-experimental branch or something like that? There is just so much build

compiler warning, 7.3.1072

I got a compiler warning on OSX 10.8.3 that I've never seen before. This is while building 7.3.1072. The last vim I built was 7.3.1053 and this warning didn't exist then. gcc -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X_UNIX -no-cpp-precomp -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o

test 86 failure on OSX 10.8.4

Hello, I just pulled and built 7.3.1154. A 'make test' failed, apparently on test 86. I see the following: Test results: test86 NO OUTPUT I've almost never run make test before, and it's never failed for me. Is there something else I need to look at that should be reported here? -Manny --

Re: Highlighting broken with re=2

I can't reproduce on OS X 10.8.4, using MacVim, which is at 7.3.1168. I don't get what matches the .png file; I get the same colors whether re=1 or re=2. I can't test console vim because the file lang.vim only defines gui colors. Therefore, I see no highlighting no matter what. -Manny On

Re: Highlighting broken with re=2

On Wed, Jun 12, 2013 at 5:37 PM, Dominique Pellé dominique.pe...@gmail.comwrote: Bram Moolenaar b...@moolenaar.net wrote: Axel Bender wrote: you may as well elimitate the inverted question mark (I just forgot to replace it in the example - in the base document there are no xs), the

Re: Patch 7.3.1183

On Thu, Jun 13, 2013 at 1:27 PM, Bram Moolenaar b...@moolenaar.net wrote: Patch 7.3.1183 Problem:Python tests 86 and 87 fail. Solution: Add empty files. (ZyX) Files: src/testdir/python_before/before_1.py, src/testdir/python_before/before_2.py ***

Re: Patch 7.3.1183

On Thu, Jun 13, 2013 at 1:46 PM, Bram Moolenaar b...@moolenaar.net wrote: Manuel Ortega wrote: Something's up with hg. I did 'hg pull -u' to get this commit, but those empty files are not actually put into the working dir. 'hg sum' tells me that indeed I did receive 7.3.1183

Re: Can't build v7-3-1189

Buried in that gist file is a line that shows the OP is using a beta version of XCode5, which won't come out until OS X 10.9 comes out. Possibly the OP is building on a beta of OSX10.9 as well. If you look at the issues page of, e.g., the homebrew website (

Re: Incorrect highlighting with re=1 introduced by 7.3.1191

On Fri, Jun 14, 2013 at 5:20 PM, Dominique Pellé dominique.pe...@gmail.comwrote: Hi These 2 commands which only differ by using re=1 or re=2 do not highlight the same text. It's correct with re=2 and incorrect with re=1 (with re=1, the second line is not entirely highlighted, but it

Re: Incorrect highlighting with re=1 introduced by 7.3.1191

On Sat, Jun 15, 2013 at 10:14 AM, Manuel Ortega mannyvim...@gmail.comwrote: On Fri, Jun 14, 2013 at 5:20 PM, Dominique Pellé dominique.pe...@gmail.com wrote: Hi These 2 commands which only differ by using re=1 or re=2 do not highlight the same text. It's correct with re=2 and incorrect

Re: Can't build v7-3-1189

On Fri, Jun 14, 2013 at 5:02 PM, Christian Wellenbrock christian.wellenbr...@gmail.com wrote: On Friday, June 14, 2013 10:35:59 PM UTC+2, Manuel Ortega wrote: Buried in that gist file is a line that shows the OP is using a beta version of XCode5, which won't come out until OS X 10.9 comes

Re: Broken syntax in vim.vim

On Wed, Jun 26, 2013 at 1:09 PM, Charles Campbell charles.e.campb...@nasa.gov wrote: Sounds like nasty stuff. Two problems: 1. There is no isk+=: in syntax/vim.vim v7.3-25 Not here either. 2. My copy of ftplugin/vim.vim, which I don't maintain, also does not have isk+=: in it.

Re: Patch 7.3.1249

On Thu, Jun 27, 2013 at 3:50 PM, Bram Moolenaar b...@moolenaar.net wrote: Andy Wokula wrote: Am 26.06.2013 20:04, schrieb Bram Moolenaar: Patch 7.3.1249 Problem:Modeline not recognized when using Vim instead of vim. Solution: Also accept Vim. Files: src/buffer.c

Re: Regression: After startup, first message output is swallowed.

On Mon, Jul 1, 2013 at 11:45 AM, Ingo Karkat sw...@ingo-karkat.de wrote: Hello Vim developers, I noticed a regression: $ vim -N -u NONE :echo foo The intro message is cleared, the (now empty) UI does not show foo. Expected behavior: The intro message stays visible, the command-line

Re: Regression: After startup, first message output is swallowed.

On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama kazunobu.kuriy...@nifty.com wrote: That said, the vim shipped with MacOS X 10.8.4, the version of which is 7.3 and looks no patch applied, not linked against X11, works well. This suggests that the early patch-levels of 7.3 are free from this

Re: vim stops

1. command /usr/local/bin/vim -nNX -u NONE Bram, I looked at this and didn't remember offhand what the '-X' flag did. No wonder: 'vim --help' has no entry for that flag. But ':h startup-options' *does* say what the flag does. Please update the output of 'vim --help'. I shall now hunt for

add rockspec files to filetype.vim?

Hello, In $VIMRUNTIME/filetype.vim there is no entry for .rockspec files (luarocks). I think all it takes is: Luarocks au BufNewFile,BufRead *.rockspec setf lua -Manny -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are

Re: add rockspec files to filetype.vim?

On Fri, Sep 5, 2014 at 5:45 AM, Bram Moolenaar b...@moolenaar.net wrote: Manuel Ortega wrote In $VIMRUNTIME/filetype.vim there is no entry for .rockspec files (luarocks). I think all it takes is: Luarocks au BufNewFile,BufRead *.rockspec setf lua That's easy to add. I'm

:redir and :!cmd

Unsure if this is a bug or what. Do this in a new console vim instance (console version of MacVim will show it too, though I am NOT reporting a MacVim problem to the wrong list): :redir = foo :!ls -l :redir END :echo foo What I expect is to see the usual ls listing of the current dir contents.

Re: A feature request (kind of Issue report) - GUI setup, left margin, legitimity,

On Sat, Sep 27, 2014 at 4:51 PM, Christian Brabandt cbli...@256bit.org wrote: Hi Mikhail! On Sa, 27 Sep 2014, Mikhail V wrote: Greetings, I am totally new to the discussion groups, so i'm sorry in advance if there are already solutions to my problem. And I was not able to attach

Re: [patch] Cut fold and sign columns at end of buffer

On Mon, Sep 29, 2014 at 2:39 PM, Marco Hinz mh.code...@gmail.com wrote: Well, I suppose there is something to say for both ways. What do the users prefer? I understand that such visual changes are almost always controversial, especially for such a long-lasting editor with its big

Re: [patch] Cut fold and sign columns at end of buffer

On Monday, September 29, 2014 4:55:55 PM UTC-4, Israel Chauca F. wrote: On 9/29/14, 12:09 PM, Bram Moolenaar wrote: Well, I suppose there is something to say for both ways. What do users prefer? I prefer the proposed look. I think that it looks cleaner when the columns end where

Re: [patch] Cut fold and sign columns at end of buffer

On Sat, Oct 4, 2014 at 3:03 PM, Marco Hinz mh.code...@gmail.com wrote: The screenshot attached to the proposal doesn't show the case when all four of the highlight groups have the same background color. In that case, the proposal looks bizarre. In that case it wouldn't look bizarre, but

Re: Suggestion: adding commands for adjusting the window width in the quickref help

On Wed, Oct 22, 2014 at 12:06 PM, Andi Hafner a.haf...@kmu-net.ch wrote: Doing so, I also realized that there is no built in horizontal equivalent to CTRL-W_= (make all windows equal height), i.e. a command to make all windows equal width. Am I right or did I miss something? (I'm speaking

Re: [bug] glob won't list symbolic links that point to non-existing files

On Thu, Feb 19, 2015 at 11:34 AM, Charles Campbell charles.e.campb...@nasa.gov wrote: Hello: Please try the following on a linux system: mkdir PROBLEM cd PROBLEM ln -s file1 file2 Doing ls shows file2 exists (but it points to a non-existing file). Fire up vim: vim -u NONE -N

Test failure on OS X

Sorry if this is a repeat of something already known. On OS X 10.10.1, Vim 7.4.608 will have make test fail: Test results: test_eval FAILED TEST FAILURE make[2]: *** [report] Error 1 make[1]: *** [test] Error 2 make: *** [test] Error 2 The portion of that file that seems to indicate what

Re: Test failure on OS X

On Wed, Jan 28, 2015 at 3:07 AM, Kazunobu Kuriyama kazunobu.kuriy...@nifty.com wrote: Hi, On Jan 28, 2015, at 11:33, Manuel Ortega mannyvim...@gmail.com wrote: Sorry if this is a repeat of something already known. On OS X 10.10.1, Vim 7.4.608 will have make test fail: Test results

vim syntax file

The vim syntax file included in the hg repo was just updated. But by looking at the diffs, it appears that it went from version 7.4-27 backwards to 7.4-19. Is that right? Or is it a typo in the version number? -Manny -- -- You received this message from the vim_dev maillist. Do not

Re: Google Code shuts down

There are a lot of people saying Github is better than Bitbucket for reasons XYZ, therefore we should move to Github. The problem is that moving to Github means Bram and the rest of us have to switch to git. The problem here is not git itself, but the switching. The path of minimum

Re: Preparations for moving to github

On Tue, Mar 24, 2015 at 5:36 PM, Bram Moolenaar b...@moolenaar.net wrote: Since Google Code is going to be shut down we need a new place for the Vim repository. Many users have given their opinion and github appears to be the preferred site. Darn. It would be nice if, when this gets

Re: Preparations for moving to github

On Thu, Mar 26, 2015 at 12:43 AM, Dominique Pellé dominique.pe...@gmail.com wrote: Manuel Ortega mannyvim...@gmail.com wrote: It would be nice if, when this gets finalized, the new repo trims out ancient stuff like 7.0, 7.1, and 7.2. There's no reason for everyone to have to clone all

Re: Preparations for moving to github

On Thu, Mar 26, 2015 at 9:43 AM, Ingo Karkat sw...@ingo-karkat.de wrote: Bram already is a bottleneck in development; please don't make him work harder by adding yet more complexity in repo maintenance! It's quite obvious that almost nobody on this list cares about adding complexity for

Re: Preparations for moving to github

On Fri, Mar 27, 2015 at 9:13 AM, Peter Aronoff telemac...@arpinum.org wrote: On Friday, March 27th, 2015 at 9:11AM, Bram Moolenaar wrote: Kana Natsuno wrote: On Friday, March 27, 2015 at 5:00:19 AM UTC+9, Bram Moolenaar wrote: Isn't there a way to clone only up to some time ago,

Re: Patch 7.4.654

On Thu, Mar 5, 2015 at 1:35 PM, Bram Moolenaar b...@moolenaar.net wrote: Patch 7.4.654 Problem:glob() and globpath() cannot include links to non-existing files. (Charles Campbell) Solution: Add an argument to include all links with glob(). (James McCoy) Also

Re: [bug] glob won't list symbolic links that point to non-existing files

This is just a reminder that whenever this gets patched, the VimL function globpath() also needs to receive the same repair. -Manny -- -- 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

Re: log messages slightly corrupted in new github repo

On Fri, Mar 27, 2015 at 10:16 AM, Bram Moolenaar b...@moolenaar.net wrote: Manuel Ortega wrote: I cloned the new testing repo from github. When I do git log and scroll through the results, I find that multi-line log messages that look fine in the hg repo are a bit mangled

Re: Preparations for moving to github

We can't forget either that a MAJOR part of the Vim plugin ecosystem lives on Github already. I don't know why people keep bringing this up. It's (a) not even clear that it is true, and (b) even if it is true, it strikes me as completely irrelevant to the question of where to host vim. Who

Re: log messages slightly corrupted in new github repo

On Fri, Mar 27, 2015 at 10:16 AM, Bram Moolenaar b...@moolenaar.net wrote: Manuel Ortega wrote: I cloned the new testing repo from github. When I do git log and scroll through the results, I find that multi-line log messages that look fine in the hg repo are a bit mangled

Re: Preparations for moving to github

On Fri, Mar 27, 2015 at 5:06 PM, Bruno Sutic bruno.su...@gmail.com wrote: Indeed, we haven't even seen *that* reason. All we've seen is it makes the vocal git users happy. I don't know why people keep saying the majority of vim users prefer git/github. This has in no way been established.

Re: Preparations for moving to github

On Thu, Mar 26, 2015 at 7:44 PM, James McCoy james...@jamessan.com wrote: On Mar 26, 2015 5:03 PM, John Szakmeister j...@szakmeister.net wrote: On Thu, Mar 26, 2015 at 11:26 AM, James McCoy james...@jamessan.com wrote: [snip] $ git gc --aggressive ... $ du -hs .git . 34M

Re: Bug Report: If gui=bold is not present in hi StatusLine, the status line does not render a background color.

On Mon, Apr 20, 2015 at 10:56 PM, Roland Eggner ed...@systemanalysen.net wrote: Hi Christian! On 2015-04-20 Monday at 10:38 +0200 Christian Brabandt wrote: Am 2015-04-20 09:24, schrieb Bidit Mazumder: If gui=bold is not present in the hi StatusLine of the active color scheme, then the

Re: Bug Report: If gui=bold is not present in hi StatusLine, the status line does not render a background color.

On Mon, Apr 20, 2015 at 3:24 AM, Bidit Mazumder bidit.mazum...@gmail.com wrote: If gui=bold is not present in the hi StatusLine of the active color scheme, then the status line does not render a background color. I don't know if this is a Vim issue or a MacVim issue. It's neither. I can't

recent log messages

The most recent two log messages (for patches, not tags) are messed up. They now look horrible in both `hg log` AND `git log`. In `hg log`, in an 80-column terminal, I see patch 7.4.690 for Problem: Memory access errors when changing indent in Ex mode. redraw when using CTRL-U. (Knil

Re: recent log messages

Assuming this github move is going to be permanent... The new format of commit messages makes the Problem: line really long in some cases. While `hg log` doesn't soft-wrap lines in its display, `git log` does not, which makes its output really hard to read. Bram, I agree that `git log` stinks,

Please fix the overzealous :diffoff command

Doing :h diffoff gives: The :diffoff command resets the relevant options to the values they had when using |:diffsplit|, |:diffpatch| , |:diffthis|. or starting Vim in diff mode. Otherwise they are set to their default value: 'diff' off 'scrollbind'off 'cursorbind'

Re: A bug wrt regexps in either Vim or the docs

On Sun, Jun 14, 2015 at 12:09 AM, James McCoy james...@jamessan.com wrote: On Sat, Jun 13, 2015 at 11:55:12PM -0400, Manuel Ortega wrote: Vim 7.4.738 here, Mac OSX 10.10.3. (Not MacVim, although the below is reproducible there too). Either the \_ regexp construct is broken, or the docs

A bug wrt regexps in either Vim or the docs

Vim 7.4.738 here, Mac OSX 10.10.3. (Not MacVim, although the below is reproducible there too). Either the \_ regexp construct is broken, or the docs are badly misleading. I don't know which. The following problem seems independent of re=1 or re=2. I always use re=1. Open a new, empty vim

Re: Patch 7.4.765

On Fri, Jul 3, 2015 at 1:23 PM, mattn mattn...@gmail.com wrote: - -1 1 - select two lines, and type C-A or C-X. vim will crash. Happens on OS X too. -Manny -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you

Re: Repository cleanup (Was: Preparations for moving to github)

On Thu, Aug 20, 2015 at 4:55 AM, Bram Moolenaar b...@moolenaar.net wrote: Markus Heidelberg wrote: Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg: Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar: I cloned it - it is perfect :) For some reason on

installation suddenly fails on OS X

One of the commits today broke installation on OS X 10.11.1. 'make install' bombs out with the following: --8<-- if test -d /usr/local/share/icons/locolor/16x16/apps -a -w /usr/local/share/icons/locolor/16x16/apps \ -a ! -f

Re: Patch 7.4.754

On Fri, Jul 10, 2015 at 11:48 PM, Urtica dioica gaultheria.shal...@gmail.com wrote: I've had some time to play with this patch. 1. Let's crash Vim. snip 2. Visual areas change from dot repeats. gv can confirm the changed areas. I can confirm each of these two cases on OSX. Perhaps the

Re: On forwarding the GH issues to this list

On Sun, Aug 30, 2015 at 12:50 PM, Ken Takata ktakata65...@gmail.com wrote: Hi Bram, 2015/8/31 Mon 1:35:30 UTC+9 Bram Moolenaar wrote: I don't see a way in GitHub to have some text show up when using the New issue button. There doesn't even seem to be a way to have some kind of issue

Re: Patch 7.4.860

On Tue, Sep 8, 2015 at 2:04 PM, Manuel Ortega <mannyvim...@gmail.com> wrote: > On Tue, Sep 8, 2015 at 1:14 PM, Bram Moolenaar <b...@moolenaar.net> wrote: > >> >> Patch 7.4.860 >> Problem:Filetype detection is outdated. >> Solution: Include all

Re: Patch 7.4.860

On Tue, Sep 8, 2015 at 1:14 PM, Bram Moolenaar wrote: > > Patch 7.4.860 > Problem:Filetype detection is outdated. > Solution: Include all recent and not-so-recent changes. > Files: runtime/filetype.vim > > Somehow the actual patch didn't make it to GitHub. On the

Re: tags problem has followed us from hg

In the case of mercurial, there's no need to make branches or merges in order to solve this problem. Just add the following to $REPO/.hg/hgrc: [hooks] pre-status = hg revert runtime/doc/tags pre-update = hg revert runtime/doc/tags pre-pull = hg revert runtime/doc/tags I'm about to investigate

Re: tags problem has followed us from hg

On Thu, Sep 10, 2015 at 3:33 PM, Markus Heidelberg <markus.heidelb...@web.de > wrote: > Am Donnerstag, 10. September 2015, 14:33:37 schrieb Manuel Ortega: > > In the case of mercurial, there's no need to make branches or merges in > > order to solve this problem. Just add t

Re: tags problem has followed us from hg

On Thu, Sep 10, 2015 at 4:02 PM, Olaf Dabrunz <o...@fctrace.org> wrote: > On 10-Sep-15, Manuel Ortega wrote: > > In the case of mercurial, there's no need to make branches or merges in > order to solve this problem. Just add the following to > > $REPO/.hg/hgrc: > &

Re: Patch 7.4.949

On Thu, Dec 3, 2015 at 2:14 PM, Bram Moolenaar wrote: > > Kenichi Ito wrote: > > > After this patch, test_listlbr_utf8 fails on travis-ci. > > https://travis-ci.org/vim/vim/builds/94633493 > > > > 54,56c54,56 > > < ¶ > > < a b c¶ > > < a b c¶ > > --- > > > ¶ > >

make test incorrectly claims my terminal is not 80 x 24

I just built 7.4.1055. Then I did 'make test'. I get the following nonsense: test1 FAILED - terminal size must be 80x24 or larger My terminal is 80x25. Also, I didn't get this message one or two days ago, even though my terminal size hasn't been modified. This is on Mac OS X 10.11.2, using

Re: make test incorrectly claims my terminal is not 80 x 24

On Wed, Jan 6, 2016 at 3:12 PM, Manuel Ortega <mannyvim...@gmail.com> wrote: > I just built 7.4.1055. Then I did 'make test'. I get the following > nonsense: > > test1 FAILED - terminal size must be 80x24 or larger > > My terminal is 80x25. Also, I didn't get this messa

Re: Updating runtime files without version control

What's wrong with making :RuntimeUpdate just make the appropriate rsync call? That's how I used to keep $VIMRUNTIME up to date way back when. OS X, at least, comes with rsync built in. -Manny -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below

Re: [vim] Completion introduces incorrect entries (version 922) (#495)

AmaruCoder, If I understand the situation correctly, ZyX is saying that two things are combining to create the behavior you observe. One is that somewhere between Vim 7.4.712 and Vim 7.4.922 the English spell files acquired the non-ASCII apostrophes. Two is that whatever font you're using is

Re: [vim] Completion introduces incorrect entries (version 922) (#495)

On Sunday, November 22, 2015 at 8:12:46 PM UTC-5, Nikolai Aleksandrovich Pavlov wrote: > These do not look like incorrect entries. They look like they are using > unicode apostroph and used font does not have the necessary glyph. I would > say that entries with ’ (U+2019, RIGHT SINGLE QUOTATION

Re: is causing display artifacts in the GUI

On Sun, Jun 12, 2016 at 12:31 PM, Manuel Ortega <mannyvim...@gmail.com> wrote: > This is on Mac OS X 10.11.5, with the very latest Vim. I can reproduce > with both MacVim and the "regular" X11 gVim. > > Setting causes some strange display artifacts in the GUI, > w

is causing display artifacts in the GUI

This is on Mac OS X 10.11.5, with the very latest Vim. I can reproduce with both MacVim and the "regular" X11 gVim. Setting causes some strange display artifacts in the GUI, when one uses "!" to run a shell cmd. A bizarre suffix is appended to the filename that replaces "%". To reproduce, in

Re: is causing display artifacts in the GUI

On Wed, Jun 15, 2016 at 10:02 AM, Manuel Ortega <mannyvim...@gmail.com> wrote: > On Wed, Jun 15, 2016 at 5:48 AM, Kazunobu Kuriyama < > kazunobu.kuriy...@gmail.com> wrote: > >> I couldn't reproduce the bug with Athena, GTK+ 2, GTK+ 3 GUIs, but did >> with MacVim

  1   2   3   >