Re: [PATCH] fix man page viewing with man-db
2010/11/29 Bram Moolenaar b...@moolenaar.net: Pádraig wrote: Ensure vim is not recursively invoked (man-db does this) when doing ctrl-[ on a man page reference Shouldn't that be ctrl-] ? -- 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
Re: [BUG] Being provided some equal recursive structures, equality operator never stops comparison
On Mon, Aug 23, 2010 at 4:45 PM, ZyX wrote:
Ответ на сообщение «Re: [BUG] Being provided some equal recursive structures,
equality operator never stops comparison»,
присланное в 17:34:55 23 августа 2010, Понедельник,
отправитель Adrien Axioplase Piérard:
But in vim, you cannot use assignment in eval statemnts.
You almost can. You can if you don't mind setting them local to a
particular buffer or window, at least.
:echo eval(setbufvar(bufnr(''), 'x', 42))
0
:echo b:x
42
~Matt
--
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
Re: Plans for Mercurial branches?
On Tue, Aug 17, 2010 at 5:26 PM, Bram Moolenaar wrote: Björn Winckler wrote: I for one would be very happy if the next version (vim74?) used this scheme (i.e. where all new work happens on the default branch). In my opinion the default branch should contain the stable version. Most users would sync there once in a while to update their Vim. Most users don't get their vim from source control at all - they get it from binaries or source provided by their distro. Developers would want to get the bleeding edge version, and we can assume the can follow the instructions to sync to a different branch. I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. Keep in mind that in most opensource projects work that way - I don't think I've ever checked out code where the starting branch wasn't the main development branch. If you want an older version, it's easy to check out an old tag. With CVS or SVN, you'd always get the latest HEAD, there's no reason for Hg to be any different. Just my $0.02 ~Matt -- 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
Re: Vim 7.3f ready for beta testing
2010/8/14 Dominique Pellé dominique.pe...@gmail.com: * I did set mouse=a. I can use the mouse to position the cursor and mouse also works fine with Netrw (clicking on directories opens them...). However, I cannot use the mouse to resize Vim's windows (nothing happens when I click the statusline and try to drag it). That would be expected behavior if ttymouse=xterm instead of xterm2 (as far as I can tell, the original xterm mouse protocol had no drag-and-drop support). Does :set ttymouse=xterm2 fix it? ~Matt -- 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
Re: added completion to the :setfiletype command.
On Wed, Jul 28, 2010 at 9:20 AM, Ingo Karkat sw...@ingo-karkat.de wrote: Sorry, I haven't tried your patch yet, only reviewed it. I'd like to point out the naming peculiarities for ftplugins (:help ftplugin-name), which I think require additional filtering of the retrieved *.vim names: | The generic names for the filetype plugins are: | | ftplugin/filetype.vim | ftplugin/filetype_name.vim | ftplugin/filetype/name.vim Yeah, I was about to point this out. Really, since the goal is to get a list of all possible filetype, we should include any directory in ftplugin, and we should remove everything after an _ from the filenames. I definitely don't think we should just filter out files with an _ in the name. ~Matt -- 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
Re: Should 2html generate valid CSS by default?
On Wed, Jul 28, 2010 at 9:24 PM, Benjamin Fritz fritzophre...@gmail.com wrote: On Wed, Jul 28, 2010 at 3:39 PM, Bram Moolenaar b...@moolenaar.net wrote: The documentation clearly says: By default, HTML optimized for old browsers is generated. If you prefer using cascading style sheets (CSS1) for the attributes (resulting in considerably shorter and valid HTML 4 file), use: :let g:html_use_css = 1 We can change that to default to using CSS when the variable isn't set and tell users to use this to disable that: :let g:html_use_css = 0 Any problems with that? Well...it would be inconsistent with the other options, which will remain enabled even if you :let them to zero. If I change this one, I will want to change all options to work the same way. Each would do as one might expect when :let to either zero or 1, with a default behavior noted in the :help when they are not defined at all. I think that the best choice is just to keep the same option name and change the behavior when it hasn't been set. So, if the user sets html_use_css to 0 in their vimrc, they won't get CSS, and if they have set it to 1 or haven't set it at all, they'll get CSS. I can't see any good reason for adding a second variable, it seems like it would only complicate things. I definitely *wouldn't* write it to always be set to 1 by default - that's too hard to override for users who aren't intimately familiar with the order in which different vim initializations happen. I'd just have the plugin do this when it runs: if !exists(g:html_use_css) let html_use_css = 1 endif That way, if the user has set it to anything in his vimrc, the plugin never needs to do anything. If he sets it in his gvimrc instead, he just overwrites the default that the plugin set. ~Matt -- 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
Re: Tr : Re : Minor problems...
On Tue, Jul 27, 2010 at 9:17 AM, Dimitar DIMITROV wrote: I tried with Vim 7.3b and the problem is gone when cursorline is on but I still find it strange that vertical bars and stars would appear when highlighting the text. It may be relevant for other filetypes but I don't think it is for help files. Here is what I get when copying: 1.txt| About the manuals |usr_02.txt| The first steps in Vim |usr_03.txt| Moving around |usr_04.txt| Making small changes |usr_05.txt| Set your settings |usr I'm not such a fan of that either. Is there some option to make copying copy exactly what's shown on the screen, without including concealed text? I actually can't think of a time when I'd want to copy the concealed text, for any use case I've thought of so far for conceal... ~Matt -- 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
Re: Tr : Re : Minor problems...
On Tue, Jul 27, 2010 at 12:12 PM, Matt Wozniski wrote: On Tue, Jul 27, 2010 at 9:17 AM, Dimitar DIMITROV wrote: I tried with Vim 7.3b and the problem is gone when cursorline is on but I still find it strange that vertical bars and stars would appear when highlighting the text. It may be relevant for other filetypes but I don't think it is for help files. Here is what I get when copying: 1.txt| About the manuals |usr_02.txt| The first steps in Vim |usr_03.txt| Moving around |usr_04.txt| Making small changes |usr_05.txt| Set your settings |usr I'm not such a fan of that either. Is there some option to make copying copy exactly what's shown on the screen, without including concealed text? I actually can't think of a time when I'd want to copy the concealed text, for any use case I've thought of so far for conceal... That was stupid - I managed to completely ignore the case of copying some text from one part of the current buffer to another part, I was only thinking about copying between buffers or between applications. Still, I think that an option controlling whether or not concealed text is included in the copy would be a good thing. ~Matt -- 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
BUG: echo_string incorrectly detects a structure as recursive
To reproduce:
:echo repeat([{'a':'1'}], 2)
[{'a': '1'}, {...}]
expected output: [{'a': '1'}, {'a': '1'}]
:echo repeat([[0]], 2)
[[0], [...]]
expected output: [[0], [0]]
This seems to be caused by echo_string deciding that the data
structure is recursive, despite the fact that it definitely shouldn't
be.
~Matt
--
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
Re: [patch] Disallow changing 'fenc' in modeline
On Fri, Jul 23, 2010 at 2:06 PM, Nikolai Weibull n...@bitwi.se wrote: On Fri, Jul 23, 2010 at 19:33, James Vega james...@jamessan.com wrote: On Fri, Jul 23, 2010 at 1:25 PM, Nikolai Weibull n...@bitwi.se wrote: Sort of like a modeline? Sort of, except modelines can be at the top or the bottom of the file And one could easily scan from the beginning or end of the file, sort of like we already do for a modeline. and are processed after the buffer has been loaded. Which I already noted should be processed before the buffer has been loaded, at least for options that affect the fundamental processing of the buffer, for example, 'fileencoding'. This would have to be part of the process of loading the buffer, Not necessarily. which is why the places that do allow it require the information to be at the top of the file. meta/ may actually appear anywhere in the document, if places is referring to HTML processors (which of course don’t have to respect it). Look, I never suggested that this was going to be easy, but there’s no point in making it harder (by adding some separate control sequence). Ruby already looks for the 'fileencoding' option in a Vim modeline when trying to determine the encoding of a file. Doing it *properly* (eg, for all supported encodings) would definitely be difficult, but I can envision a quick hack that works for single-byte encodings: 0) Start handling a :e command 1) remember what 'fenc' was set to before any modelines were handled 2) handle modelines 3) if fenc has changed, implicitly do an :e ++enc=fenc (and whatever other flags) (goto 0) I think that should work fine as long as the modeline is a valid modeline in both encodings, which should be true for all single-byte encodings and utf-8, but won't hold for utf-16, utf-32, etc... Any thoughts? If I'm not missing anything, it should be possible to make vim handle the simplest (and most useful, since they can't be unambiguously detected automatically) case without breaking things any worse than they are for more complicated cases. ~Matt -- 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
Re: Vim 7.3a ready for beta testing
Please bottom post on this list... I'm reformatting... On Wed, Jul 21, 2010 at 6:05 AM, mikeyao yaoweiz...@gmail.com wrote: On Jul 21, 5:38 pm, Bram Moolenaar b...@moolenaar.net wrote: Mikeyao (?) wrote: Why not javascript interface ? The code has developed. http://www.vim.org/scripts/script.php?script_id=2375 I haven't actually heard from someone using it. Also, I have no idea why someone would want to write plugins in Javascript. Perhaps because it's the only language someone knows? Vim support many languages interface and I just found new lua interface added in 7.3. I think most programmers know javascript and like it, it's going to mainstream. Many web developers using vim, they know javascript well. I haven't tried the JS interface patch, but I definitely would like to see a javascript interface. I don't know Lua, TCL or Ruby (though I intend to learn the latter one day), I don't like to use Perl or Python for anything more than a few dozen lines, and I hate Scheme almost as much as Lisp. Javascript is a powerful, easy to learn, multi-paradigm language that was designed for embedding, so I think it's a perfect fit for a Vim interface - and I personally would be more likely to use it than any of the other interfaces. ~Matt -- 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
Re: Color code my Vi Editor
On Wed, Jul 21, 2010 at 10:11 AM, duffman wrote: Hi, I tried to look up information online on this but wasn't able to find anything that worked. I used Vi at my old job and loved the editing features it provided. I've moved to a new place now and I am the only developer here. I logged into a SunOS Unix box (bash shell) and while things work my vi editor looks very bland (no colors schemes and bw) which makes reading and writing code difficult. When I looked up info I found that I have to put the color coding information into my .vimrc file in my home directory. I am in a corporation and under my home /home/myName I don't have a .vimrc file. I found a sample one online that I copied but it didn't have any effect on my vi editor. I also tried syntax on commands by vi said it wasn't recognized by vi. Can anyone please help make my vi editor colorful? Many thanks! On a Solaris box, it's relatively unlikely that `vi' runs vim. You can check by doing :version - that will either fail entirely (meaning you're not running vim) or show a bunch of information including -syntax (meaning you are using a vim binary, but that syntax highlighting support wasn't compiled in). Either way, the solution will be to find a better package or compile vim from source. ~Matt -- 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
Re: Patch to allow ctermfg or bg values as #rrggbb
On Wed, Jul 14, 2010 at 4:57 PM, Bram Moolenaar wrote: Matt Wozniski wrote: [about a patch to support #rrggbb in a terminal] Where can I find the latest version of this patch? I only see one that is two years old. As Benjamin Haskell noted, I decided to shoot for a vimscript implementation instead of a patch implementation, and wound up with CSApprox instead. You've already committed 9cf38f, which was the last thing that was really missing in making CSApprox perfect, and it turns out it's much easier to do all of the nasty magic that needs to be done in a script than in code, and the result is much more flexible. The down side is that it's a bit slow (as Dominique pointed out), but I have a version in my sandbox that should hopefully help a bit with that. 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
Re: Memory leak
On Thu, Jul 8, 2010 at 6:55 PM, Tony Mechelynck wrote: If you want to usefully contribute memory leak reports, please use the latest version, either the latest stable version (currently 7.2.445) or the bleeding-edge development version (7.3a, available only over Mercurial, not as a bz2 archive). ... On Debian, you should be able to use apt-get to get the dependencies of the vim-x11 package (or of whatever it is called on that distro). Indeed. apt-get build-dep vim-gnome ~Matt -- 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
Re: Bug: Making « sc» abbreviation is not possibl e
On Thu, Jul 1, 2010 at 10:55 AM, ZyX wrote: Ответ на сообщение Re: Bug: Making sc abbreviation is not possible, присланное в 00:10:21 01 июля 2010, Четверг, отправитель Bram Moolenaar: Most likely has something to do with keyword characters, since 'iskeyword' has a different value in help files. Yes, James Vega already pointed me that I should have in iskeyword option in order to be able to make this abbreviation. Now I understand that it is not a bug, but I think that error message should be more verbose, like: Exxx: Invalid abbreviation: sc and *Exxx* tag before the line There are three types of abbreviations. I second this - in this case, we do have enough information to know exactly why it's an invalid argument, and - unlike most times when E474 is thrown - it's not always immediately obvious to even trained eyes what the error is, since it depends on buffer-local options. An error message just for this case would be a Good Thing. ~Matt -- 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
Re: [patch] redraw bug with 'foldcolumn' and 'conceallevel'
On Tue, Jun 15, 2010 at 9:08 AM, Vince Negri wrote: From: Dominique Pellé [mailto:dominique.pe...@gmail.com] Thinking about it further, this second attached patch also fixes the fold column redraw bug with less redraws than patch in previous email. However, unlike previous patch, it does not fix the redraw glitches with moving commands ) ]] CTRL-F (etc) so they require specific fixes. I think this patch is the right way to go about it, as we shouldn't be redrawing unnecessarily (esp since Vim is often run over remote connections.) That does mean that explicit fixes need to be added for a number of movement commands, but I'd rather sort them out as they are discovered. Dominque, you so far have a list of these movement commands needing treatment: ) ]] PageUp PageDown CTRL-F CTRL-B CTRL-U CTRL-E (when cursor is on the top line, causing scrolling) CTRL-Y (when cursor is on the bottom line, causing scrolling) CTRL-O CTRL-I [count]go [count]g; :[range] :go [count] I haven't tested the patch, but I'd bet that [count]z- [count]z+ [count]zCR [count]zt etc will need fixups, and might be easy to miss since their no-count behavior doesn't move the cursor. ~Matt -- 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
Re: Patch 7.2.442
On Sun, Jun 6, 2010 at 4:26 PM, Bram Moolenaar wrote: James Vega wrote: On Sat, Jun 05, 2010 at 10:37:39PM +0200, Patrick Texier wrote: Le Sat, 05 Jun 2010 16:16:06 +0200, Bram Moolenaar a écrit dans le message 201006051416.o55eg6to002...@masaka.moolenaar.net : Patch 7.2.442 (after 7.2.201) Using Linux/GCC 3.2/GTK 1, I can't compile this patch. I think that gtk_selection_clear_targets is not available with GTK 1. It isn't and I don't see equivalent functionality in GTK 1's API. One possibility is to keep the old code for builds using GTK 1, which would resurface the buggy interaction with OpenOffice.org for anyone still building against GTK 1. Although, OpenOffice.org requires GTK 2, so you probably won't run into that problem. Personally, I'd prefer to remove all the GTK 1 code from Vim since GTK 1 isn't supported by its upstream anymore and has been deprecated for years. As it is, parts of Vim will need to be changed for compatibility with GTK 3 when that comes out, and supporting three different GTK versions just seems like overkill, in my opinion. gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) You're using a Linux distribution that was released 8 years ago, a year and a half after the last release of GTK 1. I'm surprised this is the first new release of a piece of software that hasn't worked. What do others think about removing support for GTK 1? It makes sense, any system where you would try to build Vim 7.3 should be able to install GTK 2 libraries. It will clean up the Vim source code. I'm a fan of the idea. I work on systems with the Motif gvim and the GTK 2 gvim, but I don't think I've ever worked on a system with a GTK1 gvim. The number of #ifdef's in the GUI code is ridiculous, so I strongly support anything that will make life easier for Bram and other contributors. ~Matt -- 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
Re: inoremap esc bug?
On Tue, May 25, 2010 at 4:53 PM, Bee beeyaw...@gmail.com wrote:
On May 25, 1:19 pm, Tony Mechelynck antoine.mechely...@gmail.com
wrote:
On 25/05/10 18:03, Bee wrote:
Is this a bug? Seems inoremap is not working here.
I recommend
:set timeout timeoutlen=5000 ttimeoutlen=100
(or similar), where
- both times are in milliseconds
- 'timeoutlen' should be longer than the longest time between keystrokes
when you're hesitating about which key to type next in a multikey {lhs}
for a mapping
- 'ttimeoutlen' should be shorter than the shortest time between
keystrokes at your fastest typing speed but longer than the (longest)
time between successive bytes sent to you by the keyboard for a single key.
When bytes arrive with a shorter interval between them than
'ttimeoutlen' milliseconds, Vim will then accept them as a multibyte
keycode (if found in the current termcap) in preference to a mapping.
See the corresponding help topics for details.
Hi Tony
I tried what you suggested and it had no effect, tried other values,
still get the A, B, C, D.
Also tried with:
vim -N -i NONE -u NONE
Still getting:
The arrow keys up, down, right, left produce A, B, C, D respectively.
Yes, this is a known vim bug that has been reported multiple times -
at least once by me.
~Matt
--
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
Re: Patch to make link.sh output a bit less scary.
On Tue, May 18, 2010 at 11:04 AM, Cesar Romani wrote: On 18/05/2010 04:24 a.m., Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. I'd use unlinking instead of delinking. I'd say Not linking in libXt or Removing libXt from libraries or Going to link without libXt. ~Matt -- 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
Re: Keyboard input handling
On Tue, May 4, 2010 at 8:14 PM, Tom Sorensen wrote: On Tue, May 4, 2010 at 7:14 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: Over the past 7 years, I have been a member of the #vim channel on Freenode. Almost every week we get somebody in the channel who wonders such things as how to map Ctrl-Shift-T differently from Ctrl-T. We explain that isn't possible. Even in Gvim. Actually, he's understating it. We usually get at least two people a week. Several people a day isn't too uncommon. A lot of this is because vim has already used pretty much every non-shifted key on the keyboard -- you're left with either replacing default functionality (which I don't like suggesting) or using Leader based combinations (which I'm fine with, to a certain extent, but many others are not). I'd be certain that the average is at least 2 or 3 people a day - many of the IRC regulars have seen this question get asked multiple times in one day, and we're not on for 24 hours - usually more like 2 or 3. And let's not forget how often it comes up on the mailing list - A quick search over the last ~1 year shows the below list of threads that all amount to you can't map that in vim. I emphatically agree that vim's keyboard handling is one of the ugliest parts of the editor; something definitely needs to be done to bring vim back up on par with other GUI tools. ~Matt Mapping Shift-space: how to tell if its possible? How to imap C-= ? CTRL+W under MS Windows map a-h on win32 (Win XP) gvim 7.2 in french layout work incorrectly accent grave in french(France) keyboard layout is not printing. win32 (Win XP) Platform why nmapA-0 not work? map a-h on win32 (Win XP) gvim 7.2 in french layout work incorrectly What is Alt-T supposed to do by default? Mapping ctrl-; (ctrl semicolon) mapping problems How to map Ctrl+/ ? mapping alt-keys add mapping to auto-fill Binding Ctrl+Tab and Ctrl+Shift+Tab difficulties with Vim and PuTTY. Bugging me for a long time Can't :imap S-space How to map Alt+key when using vim in putty How to get Alt-[ in putty terminal How to map ctrl-del to delete word? how to map tab and c-i independently How to map key shift+ctrl+N? I can't remap Shift-F4 key Insert Mode Mappings on a Mac map! C-= C-ogt and map! C-- C-ogT Don't work map command, ctrl-v and .vimrc map C-J C-Wj not operate...help.. mapping control+0-1 or backtick Maping Ctrl-Shift-s problems Mapping shift-space Mappings to shift-keys within terminal mode Mappings for tab navigation don't work Tab and C-i will clash in mappings unable to map ctrl-1 Unable to map Ctrl+Shift+Z Strange behavior with Key Maps -- 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
Re: Keyboard input handling
On Wed, May 5, 2010 at 11:20 AM, Ben Fritz wrote: On May 4, 6:14 pm, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: Vim's keyboard input system revolves centrally around a queue of bytes. This worked well when all the world was serial terminals. In this new world of GUIs this model doesn't work so well. I advocate changing it to a queue of keypress events. I know next to nothing about the termcap/terminfo/etc. code or what is involved in such a change, and do not have the time currently to start delving into Vim's C code (sometime soon, I keep telling myself) but I would certainly be willing to test on Windows XP and Vista, even to the point of learning how to compile my own Vim on these systems so that I can try out the patches. I have a Ubuntu system at home but don't get many chances to use it; I image we'll have a plethora of testers on such systems though. I've got access to xterm on HP-UX, AIX, and Solaris 9 and 10 - nothing too exotic, but I can help test there - and in Linux with fbiterm, which is pretty exotic as far as terminal emulators go these days. ~Matt -- 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
Re: [PATCH] Set the buffer to be modified after recovery (was: Save recovered file with ZZ?)
On Mon, Apr 26, 2010 at 11:14 AM, Tom Sorensen wrote: It was written by Matt Wozniski, not James. The issues I had with it were that it would not perform correctly on both Windows and Linux. As I recall (based on my log searches) it would do nothing the first time you edited the file, but execute the second time. Some issue with the BufWinEnter's executing out of the defined order. That was what I found last June, and I stopped messing with it shortly after. I've also found it to not work quite right on Solaris - the only platform it seemed to work well enough on was Linux. I'd be interested to find out if the feedkeys-based approach works more reliably. ~Matt -- 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 Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: Regular expression: **
On Mon, Apr 12, 2010 at 10:36 AM, Tom Link micat...@gmail.com wrote: I believe this is a special case, that is mentioned at :h /star Thanks. I missed that paragraph. Regards, Tom O_o I never knew that one, either. Huh. ~Matt -- 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 To unsubscribe, reply using remove me as the subject.
Re: [SPAM:XXXXXXXX] Re: [patch] Jump list not updated in certain circumstances
On Mon, Apr 12, 2010 at 5:45 PM, Lech Lorens wrote: On 11-Apr-2010 Bram Moolenaar wrote: Lech Lorens wrote: While 10G does add to the jump list, :10 does not. I believe that both the methods of moving from line to line should be consistent with regard to the jump list. This patch removes this inconsistency by making :10 update the jump list. Additionally, this patch fixes the problem described by Jean Johner in 5e8c1aa3-6f97-4d1e-ab09-c7e79a990...@q15g2000yqj.googlegroups.com (the current position is not added to the jump list when in insert mode C-End is pressed). An analogical situation takes place when C-Home is pressed in insert mode. This has also been taken care of. Did you verify that is compatible with vi? Some of these inconsistencies are traditional. Sometimes it's useful to offer two ways to do the same thing, so that users and scripts can have the option of setting the jump or not. I tried verifying it with vi which I got from http://ex-vi.sourceforge.net/. Either I am missing something or the original vi does not include a jump list implementation. Regarding making it possible not to change the jump list - I think the difference between 10G and :10 might indeed be desirable. In this case, however, do you think it would be a good idea to mention the difference in documentation? I attached a patch with a proposed modification. I cast my vote for the behavior change instead... vim has had :keepjumps for a long time; I'd expect that scripters are going to favor :keepjumps 10 over this undocumented feature. In general, I don't think it's a good idea to keep vi compatibility when vim has an indisputably better way to do the job. ~Matt -- 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 To unsubscribe, reply using remove me as the subject.
Re: bug: Vim trys to set color -1
On Wed, Mar 17, 2010 at 9:51 AM, graywh gra...@gmail.com wrote: I found a bug where Vim tries to set foreground/background color -1. I noticed the issue when running Vim inside Tmux and using :CSApproxSnapshot. Tmux doesn't handle the escape sequences (\E[3-1m and \E[4-1m) the same as Xterm does. Godlygeek seems to think Vim is trying to reset the colors back to the terminal default. Anyway, I'm hoping someone else can help fix this or make sense of the problem. This problem can be reproduced without CSApprox by just doing :hi Normal ctermbg=NONE or :hi Normal ctermfg=NONE These commands result in a call to term_fg_color or term_bg_color from syntax.c with an argument of -1. I'm not sure what exactly the fix should be, though. Maybe this? The below seems to work from quick tests, using ^[[39m and ^[[49m as the color-reset for xterm-alikes. ~Matt --- src/term.c.orig 2010-03-17 11:33:36.289769000 -0400 +++ src/term.c 2010-03-17 11:35:31.71950 -0400 @@ -2756,7 +2756,8 @@ /* Special handling of 16 colors, because termcap can't handle it */ /* Also accept \e[3%dm for TERMINFO, it is sometimes used */ /* Also accept CSI instead of Esc[ */ -if (n = 8 t_colors = 16 +/* Also handle -1 specially as a reset to default */ +if (((n = 8 t_colors = 16) || n == -1) ((s[0] == ESC s[1] == '[') || (s[0] == CSI (i = 1) == 1)) s[i] != NUL (STRCMP(s + i + 1, %p1%dm) == 0 @@ -2770,9 +2771,9 @@ %s%s%%dm, #endif i == 2 ? IF_EB(\033[, ESC_STR [) : \233, - s[i] == '3' ? (n = 16 ? 38;5; : 9) - : (n = 16 ? 48;5; : 10)); - OUT_STR(tgoto(buf, 0, n = 16 ? n : n - 8)); + s[i] == '3' ? (n == -1 ? 3 : n = 16 ? 38;5; : 9) + : (n == -1 ? 4 : n = 16 ? 48;5; : 10)); + OUT_STR(tgoto(buf, 0, n == -1 ? 9 : n = 16 ? n : n - 8)); } else OUT_STR(tgoto((char *)s, 0, n)); -- 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
Re: 2010 new features
On Fri, Mar 12, 2010 at 6:19 AM, Tom Link micat...@gmail.com wrote: Maybe it /would/ make GVim more attractive if it had, let's say, a more modern toolbar. Maybe MS Office like ribbons would help to improve vim's popularity. I've been told that a future version of OpenOffice will have similar gui elements. Hence, they have to be useful. That's true, OpenOffice is a paragon of usability! ~Matt -- 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
Re: VIM-7.2.394 multibyte related problem?
2010/3/10 Dominique Pellé dominique.pe...@gmail.com: SungHyun Nam wrote: Hello, With the attached files (vimrc and mb.txt), if I open the mb.txt and just type A, gvim -u vimrc -U NONE --noplugin mb.txt A, Now, I should saw (X = cursor): ,X But, I saw , X It occurs on 3 different versions of gvim, win32/cygwin-gtk2/linux-gtk2. I included cygwin-gtk2 version info below. Thanks, namsh :ver VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Mar 11 2010 08:56:42) Included patches: 1-394 I can reproduce it too with at least Vim-7.2.394 or Vim-7.2.245 in the gnome-terminal and in xterm, as well as with gVim GTK 2 on Linux. But I can only reproduce it with some values of 'colums'. I can for example reproduce it with 50, 51, 77, 78, 79, 80, 81, or 82 columns. But I can't reproduce it with for example 52, 75, 76, 83 or 84 columns. So to be able to reproduce it, you may have to add set columns=80 to the vimrc sample file: $ cat vimrc set columns=80 tw=0 nowrap listchars+=extends:,precedes: sidescroll=1 fencs=utf-8 Aha, I can reproduce after dropping the number of columns to 80, in all 3 environments that I had previously tested. That was the missing element. Is this something related to a doublewide character being scrolled offscreen by one cell? ~Matt -- 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
Re: Impossible to resize windows with mouse when command line opened
On Sat, Feb 27, 2010 at 2:39 PM, Jean Johner jean.joh...@cea.fr wrote: On Feb 27, 1:54 pm, Bram Moolenaar b...@moolenaar.net wrote: If I understand you correctly, that's the selection mechanism that lets you copy text from the screen to the command you are typing. Hello Bram, What I wanted to say is that the present behaviour is not intuitive in my opinion. Take the case of the Linux distribution with the default .vimrc After you have typed gvim file1 :sp file2 q: you get two status lines: file1 at the bottom and file2 in the middle. When you put the mouse on the status line file1, you see a vertical double-sided arrow which indicates that you can use the mouse to change the dimension of the window. And in fact it does. When you put the mouse on the status line file2, you see the same arrow so that you are tempted to do the same, but this time it does not work (for good reasons) and you select text instead. I think that will be felt to be a bug by new users (like me). Two possibilities in my opinion: 1/ When you put the mouse on status line file2, a cross appears instead of an arrow, indicating that the mouse is not active there. If the user tries to drag, nothing happens. Selection of text in the status line is forbidden in that case. 2/ If you really want to allow selection in the status line file2 (which in my opinion is not useful since it is not possible in status line file1), then it would be better to show the standard oblique one- sided arrow when you put the mouse on status line file2. 3) Or, don't allow any windows to be resized when the command-line window is open. I'd prefer symmetry. Though I still don't follow why both can't be resizable, I'd rather no windows be resizable than only some of them. I have another problem in the case of Windows distribution with the default _vimrc. After having typed the same commands as above, I could not find a way to copy the text selected by dragging the mouse in file1 or file2 to the command line window. Center-click does work neither CTRL-C/CTRL-V. :help modeless-selection ~Matt -- 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
Clicking the mouse doesn't change the jump list?
Is it intentional that moving the cursor by clicking the mouse doesn't modify the jumplist? It seems strange that you can't jump back to where you were before clicking with `` for instance. You can get around it with a mapping like noremap LeftMouse m'LeftMouse but that seems like it shouldn't be necessary... ~Matt -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: [patch] has(win64) returns 0 in 64-bit Vim
On Tue, Jan 5, 2010 at 8:52 AM, Sergey Khorev wrote: Hi, has(win64) returns 0 even for x64 version of Vim. It seems we need to define WIN64 for this to work. Something like that: *** ../vim72.323/src/Make_mvc.mak Wed Dec 23 09:36:54 2009 --- src/Make_mvc.mak Tue Jan 5 16:46:26 2010 *** *** 314,319 --- 314,323 # end of choices ### + !if ($(CPU) == AMD64) || ($(CPU) == IA64) + CFLAGS=$(CFLAGS) -DWIN64 + !endif + !ifdef OS OS_TYPE = winnt DEL_TREE = rmdir /s /q -- Sergey Khorev http://sites.google.com/site/khorser Can anybody think of a good tagline I can steal? Isn't that only checking the type of CPU that the vim binary was built with, instead of whether it was built as an x64 binary? Or does defining WIN64 cause an x64 binary to be built instead? I'm not sure what has(win64) should be returning based only on reading the help, but I'd imagine it should either be a) whether the vim binary itself is a 64 bit binary, or b) whether the OS that the binary is running on is a 64-bit version of windows. The latter seems more useful, but I'm not sure just from the help. If I'm right, though, it would have to be a runtime test; nothing at compile time could do the trick. ~Matt -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: [patch] has(win64) returns 0 in 64-bit Vim
On Tue, Jan 5, 2010 at 2:17 PM, Sergey Khorev wrote: Well, Isn't that only checking the type of CPU that the vim binary was built with, instead of whether it was built as an x64 binary? Or does defining WIN64 cause an x64 binary to be built instead? CPU in makefile defines target CPU. -DWIN64 passed to compiler does nothing besides pointing out to source code we are targeting x64 or IA64. OK, then. I'm not sure what has(win64) should be returning based only on reading the help, but I'd imagine it should either be a) whether the vim binary itself is a 64 bit binary, or b) whether the OS that the binary is running on is a 64-bit version of windows. The latter seems more useful, but I'm not sure just from the help. If I'm right, though, it would have to be a runtime test; nothing at compile time could do the trick. Source code clearly states it was meant as a compile-time check: #ifdef WIN64 win64, #endif Honestly, I'm not sure what's the point in knowledge what OS version we are running. I can conceive of a plugin that dynamically loads a DLL - or another program - that requires a 64-bit windows, which would need to know that the host OS supports it. In this case, you'd want to know that the OS is 64 bit, even if the vim binary is 32-bit. But as I said, I can see the argument either way. It should obviously be consistent with whatever win16 and win32 do, so if they're compile-time architecture checks, all is fine. ~Matt -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: remote_foreground() doesn't work exactly on GTK (on KDE)
On Thu, Dec 17, 2009 at 10:59 AM, ron wrote: Hi, Peter - Thanks, that is a help. I'm using KDE though, so maybe some DCOP incantation or similar would be what I need? wmctrl is window manager agnostic - its basic features should work in just about every window manager. So, while you might be able to do some dcop magic instead, there's no reason you couldn't use wmctrl. ~Matt -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: Vim on Cygwin removes write permission when writing file not owned by current user on Samba share
On Wed, Sep 23, 2009 at 11:02 AM, Nikolai Weibull wrote: With set backupcopy=auto Vim on Cygwin 1.7 removes write permission when writing a file not owned by the current user on a Samba share. I realize that this can be a Cygwin (1.7) problem, so I’m mainly asking whether anyone else has stumbled upon this problem. I'd try reproducing it with a native windows build, and then taking it to the cygwin list if it doesn't reproduce. Especially given that security on shared drives has historically required a lot of little tweaks in Cygwin every time a new corner case is found... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Memory is used up when I replace \t0\n to \n
On Thu, Sep 10, 2009 at 4:13 AM, John Beckett wrote: Aleafs wrote: :1,$ s/\t0\n/\n/g Note that :% is a shortcut for :1,$ In a substitute, \n means two different things: - In the pattern, it refers to a newline. - In the replacement, it refers to a null byte (8 zero bits). You can see this at ':help :s' by following the first two links. In a replacement, '\r' inserts a newline. Yes, it's strange, and no, I didn't try to work out why this issue caused the problem you report. My guess: Vim is really, really bad at handling extremely long lines, and if the goal was to delete the last column of a text file (I'm assuming every line ended with \t0) then this command told vim to turn the file into one 700kb long line. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fwd: inquiry regarding vim patch to support python3 interface
On Thu, Sep 3, 2009 at 7:13 AM, Bram Moolenaar wrote: Perhaps we should use :py3, with the requirement that white space follows. It's not perfect, but probably the best compromise. Is :py_3 better? Looks strange. - When Vim was compiled with Python 2.x :py3 gives an error - When Vim was compiled with Python 3.x :python gives an error - When Vim was compiled with both 2.x and 3.x both commands work +1 for :py3 being the best compromise. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: the 'Vim: Reading from stdin...' message
On Fri, Aug 14, 2009 at 6:25 PM, Britton Kerin wrote: I dislike this message. Also the one about the number of files to edit. These make it hard (or impossible, when doing things like 'view -M -') to make vim completely silent for use for interactive stages in shell scripts and the like. An option to make vim totally silent would be nice. Hardly *impossible* - just use a temp file instead. For instance, in most shells, you could easily replace echo hello | view -M - with view -M (echo hello) to prevent that message. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
On Wed, Aug 12, 2009 at 4:42 AM, Dimitar DIMITROV wrote: Hi, I just wanted to support all the complainers. Even if the standard plugins do not slow Vim down, some of them are useless. tohtml for instance produces code which is not compliant with any modern standards. It is a shame to have it bundled. You've probably missed html_use_css - :let it to 1 to get some decent CSS-y HTML, instead of the how-the-internet-worked-in-1994 html generated by default. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Windows vista alt key mapping
On Sat, Aug 8, 2009 at 4:49 AM, Ian00 wrote: This looks like a bug that I've worked around. I've noticed in windows vista that mapping alt keys doesn't work in ~/.vimrc. Mapping after vim loads works fine, and creating a separate file with the mappings and then sourcing it from an autocommand works: autocmd VimEnter * source ~/.vimbugfix For reference, alt a-z in insert mode gives: áâãäåæçèéêëìíîïðñòóôõö÷øùú I get the same result with default settings, and no vimrc or gvimrc. - Ian Kelling Hm. Don't have a windows machine to test with at the moment, care to do some debugging? What does set enc? fenc? fencs? print out if you put it in _vimrc? If you run that line manually? If you put the maps in _vimrc, what shows up for them in the output of the :map command? My wild guess is that the encoding when the vimrc is being sourced doesn't match the encoding you get once vim is started, and that's causing vim to map one set of byte sequences for A-x in vimrc and another set once vim has started. If I'm right, you might be able to fix it using either a scriptencoding in the vimrc (but probably not), or by setting encoding in your vimrc. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: adding modes
On Mon, Jul 13, 2009 at 7:31 PM, Tony Mechelynck wrote: On 14/07/09 01:08, James Vega wrote: On Tue, Jul 14, 2009 at 12:46:37AM +0200, Tony Mechelynck wrote: On 13/07/09 18:08, Ingo Karkat wrote: The default window navigation commands are a bit tedious, I mapped CTRL-JKHL to go to the window in that direction: nnoremapC-j C-wj etc. Ctrl-L is the redraw key, very useful when something goes half wrong, and so forth. I find that doing :syn sync fromstart is usually a better fix.C-l only fixes the issue sometimes and in the cases it doesn't, :syn sync fromstart would be necessary anyway. I don't mean that. :syn sync fromstart is for times when redrawing wouldn't be useful but syntax highlighting has to be recomputed from higher than it was (much higther, sometimes). Ctrl-L is for when Vim forgot to redraw the screen and it isn't displaying what it thinks it is. You could always do :redraw! instead of C-L though - but, who wants that? I'm also against remapping CTRL + h/j/k/l The other two key combos being masked areC-h andC-j which don't override anything. They're simply alternatives for other keys. Yes, but remapping them *would* affect those keys. If, for example, your terminal sent ^H for BS then pressing BS would suddenly move one window left - which I suppose is as sane as moving one character left, it's default behavior - but it does still change things. Not sure if there's any setup where pressing a Return key (as distinct from Enter) on the keyboard actually sends a ^J but I bet there's one out there somewhere. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: adding modes
On Mon, Jul 13, 2009 at 6:17 PM, Tony Mechelynck wrote: On 13/07/09 18:00, Raúl Núñez de Arenas Coronado wrote: Usually Vim is called modal because it can be in insert mode or normal mode. I don't consider things like that. I prefer to consider Vim as a command-driven application, one of the commands insert text, other allows for visual selections, other runs ex commands etc. It's all about commands, just that. If insert text is just one command until you leave Insert mode... well, I won't deny that to part of the Vim C code it is that, but thinking that, when I enter a new file, I'll be partway inside one long command for I don't know how long until, after having hit Esc (which is part of that long command but signals it end) I'll finally hit :wqEnter (a second command) to quit Vim... well, that's just impractical for a flesh-and-blood person who can hardly conceive that the long job of typing all the data in one file is the same kind of stuff as :wq and that he used exactly two commands during that long session. (And when I hit F3 in Insert mode, which is imapped to C-O:wa|wvCR , to me it isn't ending one command, doing two other commands, and starting a fourth one, it's just one action to save the file, and that is part of Insert mode. Maybe that's how you choose to look at it, but it *is* ending insert mode, executing some commands, and starting a new insert command. :help ins-special-special explains this, and it's painfully obvious when you try to type, say, i)Left(Esc. and get (() instead of ()() I have to agree with Raúl in his interpretation - insert mode is really only a mode in the sense of a mode being a place that has its own mappings and keybindings, but in all other senses - for instance, what counts as beginning and ending a command, or repeating a command, or counting how many changes have been made, or any number of other metrics - it's only a command. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: path completion case sensitivity on unix
On Fri, Jul 3, 2009 at 2:28 PM, Thomas Rowe wrote: Path completion on Windows and Unix are different regarding case sensitivity. Given file './Blah' on Windows, vim command ':e btab' will expand out to ':e Blah'. On Linux it does not expand, even though bash does as I have 'set completion-ignore-case on' in my ~/.inputrc. I would much prefer case insensitive completion on Linux. Ideally vim would honor .inputrc settings. I'd like to offer a patch but the learning curve for the vim source seems rather steep. Any chance of getting this implemented? Or can someone offer some pointers on how to do it myself? Vim couldn't possibly obey settings in .inputrc, since it doesn't use readline. As for case-insensitive completion, see this: http://groups.google.com/group/vim_dev/browse_thread/thread/d85208b0b888c5a2/7215a4c95e7637e1 ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch to try out: :unsilent
Oops, accidentally sent this to Bram off-list. Bram Moolenaar wrote: Matt Wozniski wrote: Bram Moolenaar wrote: Any comments on adding the :unsilent command modifier? Maybe we could add a :msgonly modifier that behaves like :silent but does add to the message history? The message history is to store displayed messages. If a message isn't displayed then it should not be in the history. If you want to log some things to see what your plugin is doing you can use a global List and append to that. It just seems that it would be nicer if each plugin didn't need to roll its own ad-hoc logging solution. When something goes wrong, a lot of experienced vim users will instinctively check :messages to see if an error managed to slip by them unnoticed, so the message history seems like an intuitive place to do logging. It not only would save plugin authors the need to roll their own logging solution, but would save plugin users from having to learn which plugins do provide their own logging, and learning how to view the log for each. It's not something I feel terribly strongly about one way or the other, but I definitely think that extending the message history from it's current definition to A list of messages that can give you insight about what happened recently would be more useful. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim 7.2 compiles fine on MSYS but it doesn't execute
On Sun, Jun 7, 2009 at 10:07 PM, Cesar Romani wrote: Thanks a lot for your help. Actually when I press backspace, it behaves like the cursor left and when I press escape the characters left behind are deleted. CTRL-h cannot delete either, neither :fixdel can fix the backspace. But When I create a .vimrc file with null content in my home directory, the backspace works, strange! That's actually the expected behavior; see :help compatible-default and :help cpo-v The upshot is that when you don't have a vimrc, vim defaults to vi compatibility, and Backspaced characters remain visible on the screen in Insert mode, and when you do have a vimrc you no longer get the somewhat irritating vi-compatible behavior; instead the characters are erased from the screen right away. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Screen not redrawing in console Vim after z=
2009/5/28 Raúl Núñez de Arenas Coronado: Hi all :) I don't know if this is my fault, my terminal's fault or a Vim bug. It happens both in my distro's Vim and my self compiled Vim (which is newer). Latest version showing this problem is 7.2.184, tested under a terminal virtual and a Linux console. I can reproduce the problem in gvim (both GTK2 and lesstif), although in gvim the screen is redrawn automatically after a few seconds... don't know why, didn't seem to be tied to the value of 'updatetime' or 'timeoutlen'... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: comma in $HOME bug?
On Tue, May 5, 2009 at 12:50 PM, Michael Hordijk wrote: Vim doesn't seem to handle a comma in $HOME at all. In this case, $HOME = /u/hordijk,spin strace shows that Vim seems to be doing some odd parsing around the comma: stat64(/u/hordijk/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) stat64(spin/.vim/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) Anybody else experience a similar issue, or I am the only one with a comma in their homedir? :) Vim uses a comma separated list of directories to search for runtime files. Your home directory is added to that list, but appears as two elements instead of one, because of the comma in it. I doubt there's any way to get around this. You *might* be able to hack things to make it work, but it would be ugly. In general, I would think that comma is one of those strange characters that you shouldn't embed in $HOME, like : and ; ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
On Fri, May 1, 2009 at 2:42 PM, Gary Johnson wrote: On 2009-05-01, Bram Moolenaar wrote: Pankaj Garg wrote: On Apr 30, 9:30 am, Ben Fritz wrote: On Apr 29, 11:42 am, Bram Moolenaar wrote: The name 'guidecolumn' starts with gui, which is confusing, since it also works in a terminal. 'margincolumn' perhaps? I agree. If a user uses :help guiC-D for example, they would NOT be expecting 'guidecolumn' to show up! As for the name, I don't see 'guidecolumn' as being a problem. I doubt that anyone would confuse it with a GUI command. There are lots of English words having the same initial letters but unrelated meanings. :help comm^D shows some examples of this. I see two problems with 'margincolumn'. The first is that highlighting the right margin is but one application for this feature. The second is that 'margincolumn' implies to me that its location automatically tracks the right margin (i.e., 'textwidth' or 'wrapmargin') which it currently doesn't. While that tracking feature may be added following the discussions in this thread, the highlighting will be of the right margin only for a particular value of 'margincolumn'. I agree. I think that 'guidecolumn' is a much better name. Whenever people show up in freenode's #vim asking about this feature, the first phrase they use for it is guide column or guide line, presumably this is because that's what other editors call it. Differing because of the aesthetics of having an option whose first 3 letters make it appear with gui options when completing from the help is just going to make things much harder for people looking for a guide column option, not significantly easier for those trying to figure out which of the gui* options they want. Also, I agree with Gary - it's not inconceivable that someone might want two guides at different spots representing different things, which would mean that the margincolumn name is much more misleading. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
On Wed, Apr 15, 2009 at 1:18 AM, Dennis Benzinger dennis.benzin...@gmx.net wrote: Hi! Am 14.04.2009 23:18, _Lone schrieb: To set 'guidecolumn' you can do :set guidecolumn=N where N is the column. If N is 0 then guidecolumn is turned off. It is highly unlikely that a user would want the guidecolumn at column 0 but the syntax seems odd so let me know if you think there can be a better way to do this. [...] Why don't you use -1 (or every negative number) to turn off the guide column? Or use = 0 for off and 1 for the first column... which is more consistent with how commands like gC-g and such show things... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] Foldmethod for the quickfix window
On 4/13/09, Gary Johnson wrote: On 2009-04-14, Lech Lorens wrote: The attached patch changes the default 'foldmethod' for the quickfix window to manual. I'm a little concerned about applying such fine tuning of individual window behavior to the source code. If there is a general rule in vim for the option values that windows inherit when they are created, I think we should use that general rule unless there is a compelling reason to do otherwise. As you say, this could also be fixed with a ftplugin/qf.vim script, which would be a more consistent method of applying such filetype-specific adjustments. Well... I'm not sure I agree. The quickfix, location list, and command-line windows are already very distinct from any other windows you can create. They behave differently, they have special commands that open and close them, they have key bindings that only apply in that one type of window. It seems reasonable that the code for these types of windows should be as centralized as possible - doing it all in vimscript would be a noble goal, but is certainly beyond the abilities that are currently available in vimscript, and barring that, I think that all of their special-case behavior should be held in the source code. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] Foldmethod for the quickfix window
On 4/13/09, Tony Mechelynck wrote: On 14/04/09 00:50, Matt Wozniski wrote: On 4/13/09, Gary Johnson wrote: On 2009-04-14, Lech Lorens wrote: The attached patch changes the default 'foldmethod' for the quickfix window to manual. I'm a little concerned about applying such fine tuning of individual window behavior to the source code. If there is a general rule in vim for the option values that windows inherit when they are created, I think we should use that general rule unless there is a compelling reason to do otherwise. Well... I'm not sure I agree. The quickfix, location list, and command-line windows are already very distinct from any other windows you can create. They behave differently, they have special commands that open and close them, they have key bindings that only apply in that one type of window. It seems reasonable that the code for these types of windows should be as centralized as possible - doing it all in vimscript would be a noble goal, but is certainly beyond the abilities that are currently available in vimscript, and barring that, I think that all of their special-case behavior should be held in the source code. Why do you think it's impossible to define quickfix folding in vimscript? IMHO, a reasonable folding scheme would be to fold qf lines together if they refer to errors/matches in the same source file. I don't think that would be hard to implement in vimscript, with a well-crafted expression folding method. No, you misinterpreted what I said. It's definitely possible to define the *folding* behavior for quickfix windows in vimscript, but it's not possible to create a window that behaves like a quickfix window in vimscript without using the quickfix commands. For instance, there's no way to emulate what :make does in vimscript without duplicating all of the 'errorformat' logic that's currently in C. As for the command-line window, that's even simpler: I believe it deserves no folding at all. Again, I wasn't talking specifically about folding, I was talking about all the behavior for a command-line window. You can't use vimscript to create a window that the cursor can't leave, other than by going through the special-casing in C for a command-line window. Also, moving everything to C code means harder to debug, Yep harder to change, Yep and practically impossible to customize. Well... no. This would only change the default foldmethod, an autocmd could still change the behavior from the default to match the user's preferences. And, a default of no folding with possible user-supplied vimscript to make it possible to fold related lines together is probably better than defaulting to folding related things. I'm in favour of having the maximum possible in vimscript, and only move to C code what cannot be done in vimscript, or only at an unacceptable performance loss. I'm in favor of keeping all of the logic for the special window types in one place. I agree that it would be better if that place could be vimscript, but it can't. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] configure: $x_includes used even if not set
On Fri, Apr 10, 2009 at 6:43 PM, Tony Mechelynck wrote: Couldn't you run test just once? Maybe something more or less like if test -n $x_includes -a $x_includes != NONE Just my sense of aesthetics, I'm not on a Mac. Usually, yes - but lore tells of shells where test isn't POSIX compatible, where -a and -o don't behave predictably but and || do... *shrug* ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] configure: $x_includes used even if not set
On Fri, Apr 10, 2009 at 10:53 PM, Tony Mechelynck wrote: On 11/04/09 04:16, Matt Wozniski wrote: On Fri, Apr 10, 2009 at 6:43 PM, Tony Mechelynck wrote: Couldn't you run test just once? Maybe something more or less like if test -n $x_includes -a $x_includes != NONE Just my sense of aesthetics, I'm not on a Mac. Usually, yes - but lore tells of shells where test isn't POSIX compatible, where -a and -o don't behave predictably but and || do... Hm. What about the shells available on the Mac, and in particular on Mac OS X ? Changing the configure script would change things wherever ./configure is used. And, besides, it looks prettier is hardly a reason to accept behavior that might be broken somewhere. If we can agree that test ... -a ... and test ... test ... are functionally equivalent, but that the latter might work somewhere the former doesn't, it's pretty clear that we should use the latter. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Why won't @: work?
On Fri, Apr 3, 2009 at 11:51 AM, fREW Schmidt wrote: It looks kosher, leading me to believe it may be some funky mapping/abbrv you have in place. Do you experience the same problem when you start with vim -u NONE If it does, then you'd have to track down which mapping is impeding your success. If it doesn't work when started with a blank config file, it might help to have the output of Ok, I figured out what the problem is, but it's a drag because I like the setting to much to not use it: Swap ; and : Convenient. nnoremap ; : nnoremap : ; vnoremap ; : vnoremap : ; So I can't do @: because it tries to do @; but if I do @; nothing happens at all... Vim sees @: properly, but puts a remappable : into the typeahead, which is remapped to ; and causes the rest of the command line to be interpreted as a normal-mode command... looking at the code, this is because nv_at() calls do_execreg(), which calls put_in_typebuf(), which sticks a bunch of remappable things into the typeahead. It seems to me that the automatically inserted : and \n shouldn't be remappable... Bram? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Suggestion: Redefine \Uxxxxx in double-quoted strings
Bram Moolenaar wrote: Tony Mechelynck wrote: Vim is now capable of displaying any Unicode codepoint for which the installed 'guifont' has a glyph, even outside the BMP (i.e., even above U+), but there's no easy way to represent those high codepoints by Unicode value in strings: I mean, \u and \U still accept no more than four hex digits. I propose to keep \u at its present meaning, but extend \U to allow additional hex digits (either up to a total of 8 hex digits, in line with ^VU as opposed to ^Vu in Insert mode, or at least up to the value \U10, above which the Unicode Consortium has decided that there never shall be a valid Unicode codepoint at any future time. It does cause problems for something like \U12345 which would now be the character 0x1234 followed by the character 5. After the change it would become one character 0x12345. I don't see a convenient alternative though. Anyone? Well, I don't know about *convenient*, but one option would be to continue allowing \u to use 1-to-4 hex digits, and require that \U use exactly 8 (or exactly 6, if we only support up to \U10) hex digits. On the one hand, it will break just about every existing place where someone used \U instead of \u. On the other hand, the fix is trivial, and it gives an actual reason for supporting both \u and \U. I think it's better than the alternative you propose, since changing the definition from 1-to-4 hex digits to 1-to-8 hex digits will cause things to fail in non-obvious ways, and changing the defiintion to exactly 8 hex digits should usually cause a more obvious failure that we could assign a helpful error number to. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: doc suggestion
On Sat, Apr 4, 2009 at 3:17 PM, Yakov Lerner wrote: If vimscript functions had remark Added in vim7.1.129, it would be useful. For example, if you want to know how portable the script is. Probably not exactly what you're looking for, but I keep copies of vim 6.4.10 and 7.0.0 around just so that I can look at older runtimefiles and docs and test scripts in older vims. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Font handling issues/suggestions/bugs
On Thu, Apr 2, 2009 at 2:57 AM, George V. Reilly wrote: On Wed, Apr 1, 2009 at 11:23 PM, Ron Aaron wrote: I am currently working on three OSes at the same time: Win32, Linux and Mac OS/X - and I am using the same vimrc settings on all three. Mostly the same, anyway. One area which causes problems is font handling. All three systems (GTK2 on Linux) have very similar font handling, but not similar enough to be easy to make work on all at once. :help setting-guifont illustrates this problem. Why not use the same fontspec on Win32, GTK and Mac OS/X? I propose that the spec: set guifont=Luxi_Mono:h13 be the 'canonical' font format for these systems; then only GTK2 support needs to be modified. If the font isn't found, then substitute spaces for the underscores and try again. It would make cross-platform vimrc files much easier to maintain. But :h13 is only supported for win32, right? And what about the X11-motif gui, the photon gui, the athena gui? Further, it would be helpful to have a getfontsize() function to parallel getfontname(). It would return the current font size being used. Currently, the getfontname() will not also return font size if e.g. set gfn=Courier is set (then Courier is returned, not Courier:h12 or whatever). Also: getfontname() doesn't always work (Mac OS/X, anyway). After my gvim has started, getfontname() returns an empty string. It would also be really nice to allow a per-window font. That is, make 'gfn' a window-specific setting. That might not be too hard, but I don't know if Bram will agree to it. If you had Courier:h12 in one window and Monaco:h15 in another, how would you reconcile the two grids? This wouldn't even be possible without changing the fact that vim's GUIs really just provide a kind of terminal emulator to run vim functionality in. On a related note, it would be nice if it were possible to supply a set of alternatives to guifont, as in CSS. GVim would work its way down the list until it found one that was present on the system; e.g., :set guifont=Consolas:h12,Monaco:h12,Andale_Mono:h13,Lucida_Console,Courier:h13 That exact example should work, shouldn't it? And then maybe the Vim-supplied fallback value of guifont could be changed to something pleasanter, especially on Windows, to, say Consolas,Lucida Console,Terminal. Might be a reasonable change for the default systemwide vimrc? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[PATCH] Let synIDattr() query guifg/bg/sp without +gui
Currently, in a vim that isn't built with +gui, it's possible to set the
gui, guifg, guibg, and guisp attributes for a highlight group, but not
to retrieve those settings - the command is accepted with no error, but
the settings are silently ignored. This is unfortunate, since scripts
might want to query what colors would be being used if a gui were
running. One example is CSApprox.vim, which needs to know what colors
would be being used in the gui in order to pick and set the closest
available terminal colors.
This patch allows synIDattr() to report the gui, guifg, guibg, and guisp
attributes even when vim isn't compiled with +gui. It should be
uncontroversial; it only changes some #ifdef's around so that things
that were only stored when +gui before are now stored when either +gui
or +eval. In my testing, it makes CSApprox work perfectly in gui-less
vim versions.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
commit e458c019b0ff0515259aebca8e04ce06b9a2646c
Author: Matt Wozniski m...@drexel.edu
Date: Fri Mar 27 02:15:31 2009 -0400
Let synIDattr() query guifg/bg/sp without +gui
diff --git a/src/eval.c b/src/eval.c
index 98979b1..ce50aef 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -16629,9 +16629,7 @@ f_synIDattr(argvars, rettv)
mode = get_tv_string_buf(argvars[2], modebuf);
modec = TOLOWER_ASC(mode[0]);
if (modec != 't' modec != 'c'
-#ifdef FEAT_GUI
modec != 'g'
-#endif
)
modec = 0; /* replace invalid with current */
}
diff --git a/src/syntax.c b/src/syntax.c
index 4b4b0bb..e4d0089 100644
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -48,6 +48,13 @@ struct hl_group
#endif
char_u *sg_font_name; /* GUI font or fontset name */
int sg_gui_attr;/* Screen attr for GUI mode */
+#else
+# ifdef FEAT_EVAL
+int sg_gui; /* gui= highlighting attributes */
+char_u *sg_gui_fg_name;/* GUI foreground color name */
+char_u *sg_gui_bg_name;/* GUI background color name */
+char_u *sg_gui_sp_name;/* GUI special color name */
+# endif
#endif
int sg_link; /* link to this highlight group ID */
int sg_set; /* combination of SG_* flags */
@@ -6203,7 +6210,7 @@ syn_get_foldlevel(wp, lnum)
* The #ifdefs are needed to reduce the amount of static data. Helps to make
* the 16 bit DOS (museum) version compile.
*/
-#ifdef FEAT_GUI
+#if defined(FEAT_GUI) || defined(FEAT_EVAL)
# define CENT(a, b) b
#else
# define CENT(a, b) a
@@ -6923,7 +6930,7 @@ do_highlight(line, forceit, init)
HL_TABLE()[idx].sg_cterm_bold = FALSE;
}
}
-#ifdef FEAT_GUI
+#if defined(FEAT_GUI) || defined(FEAT_EVAL)
else
{
if (!init || !(HL_TABLE()[idx].sg_set SG_GUI))
@@ -7221,6 +7228,20 @@ do_highlight(line, forceit, init)
# endif
}
}
+#else
+# ifdef FEAT_EVAL /* Store the fg color name for synIDattr() */
+ if (!init || !(HL_TABLE()[idx].sg_set SG_GUI))
+ {
+ if (!init)
+ HL_TABLE()[idx].sg_set |= SG_GUI;
+
+ vim_free(HL_TABLE()[idx].sg_gui_fg_name);
+ if (STRCMP(arg, NONE))
+ HL_TABLE()[idx].sg_gui_fg_name = vim_strsave(arg);
+ else
+ HL_TABLE()[idx].sg_gui_fg_name = NULL;
+ }
+# endif
#endif
}
else if (STRCMP(key, GUIBG) == 0)
@@ -7253,6 +7274,20 @@ do_highlight(line, forceit, init)
# endif
}
}
+#else
+# ifdef FEAT_EVAL /* Store the bg color name for synIDattr() */
+ if (!init || !(HL_TABLE()[idx].sg_set SG_GUI))
+ {
+ if (!init)
+ HL_TABLE()[idx].sg_set |= SG_GUI;
+
+ vim_free(HL_TABLE()[idx].sg_gui_bg_name);
+ if (STRCMP(arg, NONE))
+ HL_TABLE()[idx].sg_gui_bg_name = vim_strsave(arg);
+ else
+ HL_TABLE()[idx].sg_gui_bg_name = NULL;
+ }
+# endif
#endif
}
else if (STRCMP(key, GUISP) == 0)
@@ -7274,6 +7309,20 @@ do_highlight(line, forceit, init)
HL_TABLE()[idx].sg_gui_sp_name = NULL;
}
}
+#else
+# ifdef FEAT_EVAL /* Store the sp color name for synIDattr() */
+ if (!init || !(HL_TABLE()[idx].sg_set SG_GUI))
+ {
+ if (!init)
+ HL_TABLE()[idx].sg_set |= SG_GUI;
+
+ vim_free(HL_TABLE()[idx].sg_gui_sp_name);
+ if (STRCMP(arg, NONE))
+ HL_TABLE()[idx].sg_gui_sp_name = vim_strsave(arg);
+ else
+ HL_TABLE()[idx].sg_gui_sp_name = NULL;
+ }
+# endif
#endif
}
else if (STRCMP(key, START) == 0 || STRCMP(key, STOP) == 0)
@@ -7503,17 +7552,19 @@ highlight_clear(idx)
HL_TABLE()[idx].sg_cterm_fg = 0;
HL_TABLE()[idx].sg_cterm_bg = 0;
HL_TABLE()[idx].sg_cterm_attr = 0;
-#ifdef FEAT_GUI /* in non-GUI fonts are simply ignored */
+#if defined(FEAT_GUI) || defined(FEAT_EVAL)
HL_TABLE()[idx].sg_gui = 0;
-HL_TABLE()[idx].sg_gui_fg = INVALCOLOR;
vim_free(HL_TABLE()[idx].sg_gui_fg_name);
HL_TABLE()[idx].sg_gui_fg_name = NULL;
-HL_TABLE()[idx].sg_gui_bg = INVALCOLOR;
vim_free(HL_TABLE()[idx
Re: [wish] different statusline format for noncurrent statusline
On Tue, Mar 17, 2009 at 4:19 PM, Bram Moolenaar b...@moolenaar.net wrote: Yakov Lerner wrote: We have separae highlighting, StatusLineNC, for non-current. I wish I had different *format*, too, for noncurrent statusline. I do not think differnt format for non-current statusline is supported. Is it possible to put this request in todo. Thanks. I'll add it in the todo list. Don't expect this soon though. Still in bug fixing mode... Perhaps an 'actual_curwin' like 'actual_curbuf'? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [RFC] Default 'encoding' to UTF-8
On Fri, Mar 13, 2009 at 12:01 PM, Mike Williams wrote: Matt Wozniski wrote: This sounds like a very good idea to me. I don't know of any other programs that allow you to change encoding used internally, and we would be in good company if we chose to always use a unicode encoding internally: Java uses UTF-16 internally, and I believe python does as well. Is there any time when it would be desirable to use a non-unicode 'encoding' (assuming, of course, that +multi_byte is available)? I can't think of any. Yes, editing very large (say a few 100MB) data files that in a single byte encoding. For my day job I regularly enjoy having to spelunk my way around large files containing a mix of readable ASCII and binary data. Using a Unicode encoding could make this prohibitive. Yes, this is essentially a raw file edit mode, perhaps that should be an option - or would it be part of setting binary mode? How would using Unicode for 'enc' in any way affect this? Sure, you'd want to use a single-byte 'fenc', but no one is suggesting that the 'fenc' option should be removed. If there is a reason why editing binary files should be affected at all by what encoding the editor uses for storing the buffer text internally, I don't see it and you'll need to elaborate. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Sun, Mar 8, 2009 at 5:40 AM, Corinna Vinschen wrote: On Mar 7 20:35, Matt Wozniski wrote: On Sat, Mar 7, 2009 at 12:35 PM, Tony Mechelynck wrote: That's if you want Vim for Cygwin. You can also use Cygwin to compile (cross-compile, if you want) versions of Vim which don't need Cygwin to run, as explained on my Windows HowTo Hm. Support for using cygwin's gcc to do cross-compile builds is soon to be dropped. Maybe we should remove the option to do this from Make_cyg.mak? Or, at least add a note to the README noting that the option is deprecated and soon to be removed? You seem to be getting something wrong. When 1.7 gets released, gcc will not support the -mno-cygwin option anymore, but the distro will get a mingw cross-compiler nevertheless. You just have to use the cross-compiler i686-pc-mingw32 explicitely. No, I understood that, and was just failing to make myself clear in the email. The reason I brought this up was to suggest that either Make_cyg.mak be removed entirely, or that it be changed to use a cross-compiler explicitly rather than use the -mno-cygwin switch. If this were to be changed, we'd want to do it now, rather than after Cygwin 1.7's official release. In retrospect, I wasn't terribly clear at all, so sorry for the confusion. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
EOL for Cygwin - Win32 cross compiles
On Sat, Mar 7, 2009 at 12:35 PM, Tony Mechelynck wrote: That's if you want Vim for Cygwin. You can also use Cygwin to compile (cross-compile, if you want) versions of Vim which don't need Cygwin to run, as explained on my Windows HowTo Hm. Support for using cygwin's gcc to do cross-compile builds is soon to be dropped. Maybe we should remove the option to do this from Make_cyg.mak? Or, at least add a note to the README noting that the option is deprecated and soon to be removed? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Sat, Mar 7, 2009 at 9:05 PM, Tony Mechelynck wrote: On 08/03/09 02:35, Matt Wozniski wrote: On Sat, Mar 7, 2009 at 12:35 PM, Tony Mechelynck wrote: That's if you want Vim for Cygwin. You can also use Cygwin to compile (cross-compile, if you want) versions of Vim which don't need Cygwin to run, as explained on my Windows HowTo Hm. Support for using cygwin's gcc to do cross-compile builds is soon to be dropped. Maybe we should remove the option to do this from Make_cyg.mak? Or, at least add a note to the README noting that the option is deprecated and soon to be removed? The only interest of Make_cyg.mak is to compile Vim binaries which don't need Cygwin to run No, it allows for compiling either mingw OR cygwin binaries (at the moment). And, if you've ever tried to run a ./configure script on cygwin, you'll understand why that's still useful... using the -mno-cygwin option of the Cygwin gcc compiler and the appropriate corresponding option of the linker. This option will be removed when Cygwin migrates to Cygwin 1.7 / gcc 4. See http://www.cygwin.com/ml/cygwin/2008-09/msg00291.html . Removing the option has been planned for some time - it has never really worked correctly, it provides no significant advantages over simply using mingw to compile, and it has historically been very confusing to users. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Sat, Mar 7, 2009 at 9:32 PM, Tony Mechelynck wrote: On 08/03/09 03:15, Matt Wozniski wrote: On Sat, Mar 7, 2009 at 9:05 PM, Tony Mechelynck wrote: using the -mno-cygwin option of the Cygwin gcc compiler and the appropriate corresponding option of the linker. This option will be removed when Cygwin migrates to Cygwin 1.7 / gcc 4. See http://www.cygwin.com/ml/cygwin/2008-09/msg00291.html . Removing the option has been planned for some time - it has never really worked correctly, it provides no significant advantages over simply using mingw to compile, and it has historically been very confusing to users. If removing the option has always been confusing to users, then why can't they leave it in? No, *having* the option has always been confusing to users. Regularly people ask for help on the cygwin mailing lists for programs compiled with the -mno-cygwin flag, not realizing that adding that flag meant that they made a program that wasn't linked against cygwin1.dll and couldn't use any cygwin capabilities. It's pretty confusing to install through cygwin's setup.exe cygwin's gcc, invoke a magical flag to cygwin's compiler, and create a product that's explicitly only supported by mingw and not by cygwin. The _option_ to compile native-Windows programs using Cygwin gcc _is_ a useful thing, I can't imagine on what grounds someone would think the opposite. I never said it wasn't useful, just that it has never worked properly and has no significant advantages over simply compiling with mingw. Compiling native windows programs with Debian's gcc would also be useful, but you're not likely to find a great deal of support for adding a -mno-debian switch to Debian's gcc for that purpose. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Sat, Mar 7, 2009 at 10:29 PM, Tony Mechelynck wrote: On 08/03/09 03:49, Matt Wozniski wrote: On Sat, Mar 7, 2009 at 9:32 PM, Tony Mechelynck wrote: [...] The _option_ to compile native-Windows programs using Cygwin gcc _is_ a useful thing, I can't imagine on what grounds someone would think the opposite. I never said it wasn't useful, just that it has never worked properly and has no significant advantages over simply compiling with mingw. Compiling native windows programs with Debian's gcc would also be useful, but you're not likely to find a great deal of support for adding a -mno-debian switch to Debian's gcc for that purpose. I'm not asking that much. Debian usually doesn't run under Windows, after all. Cygwin, OTOH, does, which makes it more obvious why it would be useful to use it as a true Unix-like environment, with all the power that that implies, to compile true Windows applications, even if it must then be understood that such true Windows applications won't run in the environment where they were compiled. There's nothing stopping you from setting up your own cross toolchain, which is really what mingw is for, anyway. In fact, this is the more portable (and more unix-y) way to go - you can compile Windows programs on Debian or Cygwin using a cross-compile toolchain, without the need for a half-baked never-fully-implemented magical compiler switch. I never used MinGW (except insofar as the -mno-cygwin compiler is a MinGW-for-Cygwin compiler) but from what I heard when I still had Windows it didn't sound as convincing as Cygwin. Huh? They do different things. Cygwin provides a POSIX emulation layer through cygwin1.dll, mingw provides mappings from POSIX concepts to Windows concepts to try to make it possible to cross-compile POSIX applications. What's there to be convinced about? Either one is the right tool for the job, or the other is. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Sat, Mar 7, 2009 at 9:21 PM, Steve Hall wrote: On Sun, 2009-03-08 at 03:05 +0100, Tony Mechelynck wrote: The only interest of Make_cyg.mak is to compile Vim binaries which don't need Cygwin to run, using the -mno-cygwin option of the Cygwin gcc compiler and the appropriate corresponding option of the linker. If Cygwin drops the option, then you should not use Make_cyg.mak but switch (for instance) to MinGW and Make_ming.mak. The option will be dropped. Do these now fully support all gVim's features? I seem to recall several years ago when I moved away from BCC that not all the usual perl, python, tcl, mzscheme, ruby, ole, etc. features were. Well, the mingw compiler clearly supports them, and must be able to find and link the libraries, if you're able to build with these options using Make_cyg.mak - so, if Make_mingw.mak doesn't support these options, then it's only a matter of fixing up the Makefile (and possibly the README). ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
PATCH: Change colors for Motif/Athena balloonexpr tooltip
Motif and Athena recognize the 'ToolTip' highlight group, and will
change the fonts and colors of the balloons popped up over toolbar
entries. However, the colors aren't used for the balloons popped up as
a result of a balloonexpr.
This patch fixes that issue.
~Matt
diff --git a/runtime/doc/debugger.txt b/runtime/doc/debugger.txt
index 3b599ad..28a7b9c 100644
--- a/runtime/doc/debugger.txt
+++ b/runtime/doc/debugger.txt
@@ -92,7 +92,9 @@ could be used for displaying other information as well.
The Balloon Evaluation has some settable parameters too. For Motif the font
list and colors can be set via X resources (XmNballoonEvalFontList,
-XmNballoonEvalBackground, and XmNballoonEvalForeground).
+XmNballoonEvalBackground, and XmNballoonEvalForeground). For Motif and
+Athena, you can set the foreground color, background color, and font to be
+used by changing the ToolTip highlight group.
The 'balloondelay' option sets the delay before an attempt is made to show a
balloon.
The 'ballooneval' option needs to be set to switch it on.
diff --git a/src/gui_beval.c b/src/gui_beval.c
index 7adde4e..c3d1d66 100644
--- a/src/gui_beval.c
+++ b/src/gui_beval.c
@@ -1292,6 +1292,24 @@ drawBalloon(beval)
NULL);
#endif
+ /* Set tooltip colors */
+ {
+ Arg args[2];
+
+#ifdef FEAT_GUI_MOTIF
+ args[0].name = XmNbackground;
+ args[0].value = gui.tooltip_bg_pixel;
+ args[1].name = XmNforeground;
+ args[1].value = gui.tooltip_fg_pixel;
+#else /* Athena */
+ args[0].name = XtNbackground;
+ args[0].value = gui.tooltip_bg_pixel;
+ args[1].name = XtNforeground;
+ args[1].value = gui.tooltip_fg_pixel;
+#endif
+ XtSetValues(beval-balloonLabel, args[0], XtNumber(args));
+ }
+
XtPopup(beval-balloonShell, XtGrabNone);
beval-showState = ShS_SHOWING;
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: if {expr1}
On 2/17/09, Larson, DavidX S wrote:
Hello all,
I was working on my script when I ran across this unexpected behavior
with the if statement. The doc says:
:if {expr1} *:if* *:endif* *:en* *E171* *E579* *E580*
:en[dif]Execute the commands until the next matching :else
or :endif if {expr1} evaluates to non-zero.
I thought that meant that if {expr1} evaluated to anything other than
zero (such as a string) then the if statement passes, but it
doesn't. It's simple enough to reproduce:
It does - but a string, evaluated in a numeric context, evaluates to
zero, unless the string can be interpretted as a number.
:echo abcd / 1
0
:echo 256 / 1
256
:echo 0x10 / 1
16
:echo 010 / 1
8
:echo atoehu / 1
0
if atoehu
echom pass
else
echom fail
endif
Always echo's: fail.
Right. Because atoehu, as a Number, is 0.
Is the bug in the doc, vim, or in my head? I have version 7.2.106.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: [PATCH] more-prompt: add 'f' for scrolling back a screen
On Tue, Feb 17, 2009 at 9:19 PM, Markus Heidelberg wrote: Bram Moolenaar, 18.02.2009: Markus Heidelberg wrote: After reaching the end of the more prompt, hitting SPACE jumps out of it. Add 'f' to avoid this problem and for consistency with 'b' in scroll down a screen. This also changes the help message to contain f instead of SPACE, I'm not sure about this. This change also adds a missing leading Space for fr.po and no.po and missing trailing spaces for most of the other languages. I think the message should remain using SPACE, since that is the traditional way of going forward. OK. I agree with this, leave the message as is. I'm actually not sure if adding f to go a screen down is helpful. For me at least it is. f is more universal, I'm used to use f in less/man and Ctrl-F in Vim. And as mentioned above, that SPACE closes the more prompt: I don't want to accidentally press the key once to often and get bounced out of the pager, which can especially happen when scrolling fast. I don't think this is user-friendly and with supporting f it could be avoided. It definitely is helpful, both for symmetry with other vim commands (C-f and C-b in normal mode, for instance), and for symmetry with other programs. Less to learn is always a nice thing. And, given that space leaves the more prompt (and no one will want that to change), this does provide a nice alternative. I'm definitely in favor of this change. Also, my SPACE key makes more noise :) :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Race condition in vim_tempname() on Windows
src/fileio.c : vim_tempname() contains these lines: if (GetTempFileName(szTempFile, buf4, 0, itmp) == 0) return NULL; /* GetTempFileName() will create the file, we don't want that */ (void)DeleteFile(itmp); Is this really right? Is there any reason to call DeleteFile() here? On a quick glance, it seems that everyone who gets a name back is just doing an mch_open(tempname, w) on it, which doesn't care whether or not the file exists already. I ask because this seems to be causing a race condition: GetTempFileName() checks if a file exists, finds a name that doesn't exist, creates it, and returns the name back to the caller. It creates it so that future calls to GetTempFileName() won't choose the same file, since it now exists. But, deleting it before being done with it introduces a race condition: vim calls GetTempFileName(), then DeleteFile(), then another process calls GetTempFileName(), and now vim has the path to a file that didn't exist when it asked for a unique, non-existant file, but exists now, and is no longer safe for vim to use. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Tue, Feb 10, 2009 at 9:48 PM, Charles E. Campbell, Jr. wrote: Matt Wozniski wrote: But let's not forget that they have significant disadvantages, too... Vimballs made with new versions of the plugin don't work on older vims. There's been one problem with that -- 7.0 vimball doesn't handle the later vimball versions. 7.1 and has been compatible; newer vimballs have largely fixed small problems, not introduced incompatibilities. I could swear an incompatibility was introduced when fnameescape() came along... but that might have just been for using newer versions of the plugin with older vims, not with extracting vimballs made with the newer version on older vims. If so, scratch that point off my list. Vimball was done by request, consequently it didn't have much feedback before it went into 7.0. Considering that those writing and distributing scripts are much more likely to be at the bleeding edge than the users who download those scripts, they're quite likely to wind up distributing something that many of their users can't use. It's also not possible to include binary files in a vimball, or fines with different encodings, or even files with different line endings. I think that I could get vimball to handle binary files, which would mean that zip files could be embedded. However, most plugins don't need binary files (those with icons for signs would be an exception). Or even those that would like to include screenshots, or compiled data files... I don't doubt that vimball could be made to support things like this, I just think it would be more effort than trying to come up with a wrapper around zips that adds the features we need. IMHO, this makes them significantly less useful than zip files, since we could add those 3 nice features (automatic :helptags, extracted to first writable directory, uninstallable) to zip files without having to tolerate the disadvantages that vimball doesn't seem to be able to overcome... Really, it seems that depending on an unzip program being on the computer is far better than implementing our own barely-featured interface-unstable self-extracting-archive-that-wants-to-be-a-zipfile. I think that an effort to nicely encapsulate the platform differences and such of handling zipfiles, or possibly even one day writing a vimscript unzipper, would be a better use of our resources than continuing to maintain vimball. And putting these vim-specific features into zip files would be real popular with the rest of the zip community, I'm sure. At the very least, it'd be bloat for most such users. Then some other applications would want to chime in with their own application specific features. Well, of course I didn't mean that we should add the features to the zip format. Rather, I meant we should do something more like XPI - create a zip file, rename it to .vba, and let vim handle it specially. The change would be transparent to users, and give more useful features to developers, without having to reinvent the wheel. It'd be better to have a plugin that acted as a wrapper around zip to support the additional features that vimball provides. Probably could be a modification to the current zip handling plugin. The same sort of mods could be done with tar and the tar handling plugin, too. I'll consider doing it (after taxes and fafsas). Right. For the near term, supporting unzipping using a pure-vimscript solution isn't terribly likely, but it's definitely possible OOTB in vims built with +python, for example. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Wed, Feb 11, 2009 at 11:06 AM, Tom Link micat...@gmail.com wrote: Right. For the near term, supporting unzipping using a pure-vimscript solution isn't terribly likely, but it's definitely possible OOTB in vims built with +python, for example. IMHO reliance on compiled-in +python support would make things even more complicate that relying on unzip being installed -- which maybe could be even shipped with vim? BTW the zip plugin work quite well, even when using bash under windows. I was suggesting just the opposite - that we shouldn't *rely* on +python, but that if python were available we wouldn't have to rely on an external unzip. Which may or may not be worthwhile - I guess it depends on which supported platforms don't include an 'unzip' (win 9x? Amiga?) and whether most binaries on those platforms have +python (probably not, so the entire exercise might well be pointless). I was just pointing out a possibility that might be worth considering. :-) BTW maybe a vba (zip-based or not) could include some sort of manifest file that includes not only a file list but also dependencies on other plugins? These manifests could be saved in, eg, ~/vimfiles/vimballs/ manifests/ and be used for downloading the dependencies and for removing vimfiles (AFAIK the uninstall info is currently saved in a single file, which could cause minor conflicts when syncing vimfiles directories between several computers). Just a thought. Sounds like a reasonable suggestion to me. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Wed, Feb 11, 2009 at 7:29 PM, Tony Mechelynck wrote: On 11/02/09 16:23, Matt Wozniski wrote: [...] Well, of course I didn't mean that we should add the features to the zip format. Rather, I meant we should do something more like XPI - create a zip file, rename it to .vba, and let vim handle it specially. The change would be transparent to users, and give more useful features to developers, without having to reinvent the wheel. [...] For backward compatibility, *.vba shouldn't be a zipfile under another name (which .xpi and .jar are, but these extensions were never used for something else before). *.vba.gz (keeping the .vba as-is and compressing them for transport, the way .tar.gz relates to plain .tar) would be easy to implement; if you want something more complicated than this, I believe a new extension would be necessary. Yes, I realized that after sending that email off - I was thinking about it providing backwards compatibility in the sense that the install process for a zip-based vimball and a vimscript-based vimball could be made largely the same, but at the time of writing it didn't even occur to me that the old vimball install scripts would mangle it. Oops. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Tue, Feb 10, 2009 at 4:35 PM, Charles Campbell wrote: James Vega wrote: I'm still curious what purpose vimballs serve over a standard archive format like zip or tar.gz. From a distribution perspective, all they've done is made my work harder when trying to include vim scripts in a package for a Linux distribution. * they automatically enable help for any enclosed help files * files go where they need to; they're not dependent on the user changing to the appropriate directory first. * one may uninstall the files extracted by a vimball (:RmVimball vimballname) * the vimball itself requires no addtional tools beyond vim itself (compression/decompression is another matter) But let's not forget that they have significant disadvantages, too... Vimballs made with new versions of the plugin don't work on older vims. Considering that those writing and distributing scripts are much more likely to be at the bleeding edge than the users who download those scripts, they're quite likely to wind up distributing something that many of their users can't use. It's also not possible to include binary files in a vimball, or fines with different encodings, or even files with different line endings. IMHO, this makes them significantly less useful than zip files, since we could add those 3 nice features (automatic :helptags, extracted to first writable directory, uninstallable) to zip files without having to tolerate the disadvantages that vimball doesn't seem to be able to overcome... Really, it seems that depending on an unzip program being on the computer is far better than implementing our own barely-featured interface-unstable self-extracting-archive-that-wants-to-be-a-zipfile. I think that an effort to nicely encapsulate the platform differences and such of handling zipfiles, or possibly even one day writing a vimscript unzipper, would be a better use of our resources than continuing to maintain vimball. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Mon, Feb 9, 2009 at 5:56 PM, Andy Wokula wrote: Here is another way to get the option names, it's basically :set C-A snip The output is almost sorted and includes all and termcap as the first two entries. Wow. That is quite clever, I definitely wouldn't have thought of that. Nicely done. For the termcap options, you'd also want to do a :set t_C-a for getting each of the termcap options... Though I don't see any easy way to use this to get the :set-termcap stuff... Ie, :set M-x=foo Any ideas on that one? I don't have time to play with it ATM, but I'm definitely curious about it. :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Sun, Feb 8, 2009 at 11:40 PM, Garrett Whelan whaled...@gmail.com wrote: I would like to be able to access all the variables at a given time in Vim without necessarily knowing what they are. Basically everything you would see if you typed :let and :set. So in increasing order of difficulty There's no easy way to get all options, afaik. All variables, though, isn't too tough: you can treat the scopes as a dictionary keyed by names of values in that scope. So, for example: for [var, val] in items(g:) echo Global variable \ . var . \ is \ . val \ The type might change, so we unlet it before it's assigned again unlet val endfor Is there a way to redirect the output from :let and :set? It would be pretty simple to parse that up, but I can't figure it out. Yes. :help :redir - but, again, probably not what you want to do. Is there a way to call functions in the Vim code from VimL? Browsing through the source I see list_hashtable_vars seems to have the info I need. Is there a way to access the actual C data structures from VimL? If I could read the various hashtables myself I could do what I needed. No... those would be awfully strange features for a scripting language... I suspect there's no way to do any of this, but I thought I'd ask before I took a more...cumbersome route. Oh, also what is this declaration structure: KR style C. Vim's old. Back when ANSI C was still not so popular. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: description of CTRL-W = in index.txt
Bram Moolenaar wrote: Chris Littell wrote: In the help file index.txt, the description for CTRL-W = should mention that it also makes window widths equal. Right now it looks like there is no command to do this until you see the detailed description. I'll make it: make all windows the same height width How about: make all windows the same size ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
PATCH: URLs can't be found in 'path'
:help 'path' says
- When using |netrw.vim| URLs can be used. For example, adding
http://www.vim.org; will make :find index.html work.
This, however, does not actually work (and hasn't since vim 6.4.10, at
least). Attached patch fixes.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
diff --git a/src/misc2.c b/src/misc2.c
index 76fe2ec..1598b10 100644
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -4696,7 +4696,9 @@ vim_findfile(search_ctx_arg)
stackp-ffs_filearray_cur = i + 1;
ff_push(search_ctx, stackp);
-simplify_filename(file_path);
+if (!path_with_url(file_path)) {
+simplify_filename(file_path);
+}
if (mch_dirname(ff_expand_buffer, MAXPATHL)
== OK)
{
Re: Is vim really fully unicoded?
On Tue, Jan 6, 2009 at 6:10 PM, Tony Mechelynck wrote:
On 06/01/09 12:31, anhnmncb wrote:
Hi, list, as title, if so, why can't many functions
still handle correctly with unicode? For example the func:
getline('.')[col('.')-1]
Can't return a charactor outside the range of ascii.
because string[index] returns a byte value, not a character value: see
:help expr8.
*Nod*
If the character at the cursor is U+007F, you'll get
the first byte (in the range 0xC0-0xFD, or in practice in the range
0xC0-0xF4) of its UTF-8 representation.
No, you could get some byte of some entirely different character. Ie,
on a line with two 2-byte characters, getline('.')[col('.')-1] on the
second character would return the 2nd byte of the first character.
The _character_ at the cursor is obtained as follows:
let i0 = byteidx(getline('.'), virtcol('.') - 1)
let i1 = byteidx(getline('.'), virtcol('.'))
let character = strpart(getline('.'), i0, i1 - 10)
Using virtcol() there seems broken... what if you're in the middle of
a tab, for example, with virtualedit=all?
:echo join(split(áéíóú, '\zs')[1:3], '')
is how I would do it... but, is there any real reason why indexing
into a string *should* be byte oriented instead of character oriented,
apart from backwards compatibility? It seems drastically less easy to
use the thing that more people want to use more of the time; and in
fact some of the snippets in the vim help (like the example given at
:help expr-8) won't work on multibyte lines given the way that string
indexing works now. It seems like a place where the cost of losing
backwards compatibility might be outweighed by the cost of keeping
things the way they are...
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Is vim really fully unicoded?
On 1/6/09, Tony Mechelynck wrote:
On 07/01/09 00:39, Matt Wozniski wrote:
On Tue, Jan 6, 2009 at 6:10 PM, Tony Mechelynck wrote:
On 06/01/09 12:31, anhnmncb wrote:
Hi, list, as title, if so, why can't many functions
still handle correctly with unicode? For example the func:
getline('.')[col('.')-1]
Can't return a charactor outside the range of ascii.
because string[index] returns a byte value, not a character value: see
:help expr8.
*Nod*
If the character at the cursor is U+007F, you'll get
the first byte (in the range 0xC0-0xFD, or in practice in the range
0xC0-0xF4) of its UTF-8 representation.
No, you could get some byte of some entirely different character. Ie,
on a line with two 2-byte characters, getline('.')[col('.')-1] on the
second character would return the 2nd byte of the first character.
col() gives a one-based byte ordinal. [] takes a zero-based argument. I
stand by what I said.
Ooh, you're right - I forgot col() returned a byte index, and not the
column as its name would imply...
The _character_ at the cursor is obtained as follows:
let i0 = byteidx(getline('.'), virtcol('.') - 1)
let i1 = byteidx(getline('.'), virtcol('.'))
let character = strpart(getline('.'), i0, i1 - 10)
Using virtcol() there seems broken... what if you're in the middle of
a tab, for example, with virtualedit=all?
:echo join(split(áéíóú, '\zs')[1:3], '')
OK, I didn't think of virtual editing, nor even, it seems, of
multi-column characters such as tabs and fullwidth CJK. However, [1:3]
wouldn't work because the idea is that we're in a script, we don't know
that we're in the 1st, 2nd or 3rd column, just that we want whatever is
at the cursor. I might do it with
function CursorChar()
normal yl
return @@
endfunction
echo matchstr(getline('.'), '\%' . col('.') . 'c.')
does the same thing without clobbering the unnamed register...
slightly more elegant, imho.
is how I would do it... but, is there any real reason why indexing
into a string *should* be byte oriented instead of character oriented,
apart from backwards compatibility? It seems drastically less easy to
use the thing that more people want to use more of the time; and in
fact some of the snippets in the vim help (like the example given at
:help expr-8) won't work on multibyte lines given the way that string
indexing works now. It seems like a place where the cost of losing
backwards compatibility might be outweighed by the cost of keeping
things the way they are...
Changing an existing construct from byte-oriented to
multibyte-character-oriented would probably break a lot of existing
scripts. I don't believe Bram would ever accept that.
But sometimes, breaking things is required to make progress. The fact
that we're having a conversation with both of us suggesting (fairly
complicated) things that haven't worked is a perfect proof for the
fact that the current system is counterintuitive and hard to use...
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Is vim really fully unicoded?
On 1/6/09, Tony Mechelynck wrote:
On 1/6/09, Matt Wozniski wrote:
echo matchstr(getline('.'), '\%' . col('.') . 'c.')
Again, col('.') is a byte index, not a column. What about virtcol('.')
instead?
Nope. \%15c is also a byte index, not a column (which is also
counter-intuitive, and brings us back to the problem - that however
well documented it is, even experienced vimscript programmers get this
stuff wrong regularly.)
Changing an existing construct from byte-oriented to
multibyte-character-oriented would probably break a lot of existing
scripts. I don't believe Bram would ever accept that.
But sometimes, breaking things is required to make progress. The fact
that we're having a conversation with both of us suggesting (fairly
complicated) things that haven't worked is a perfect proof for the
fact that the current system is counterintuitive and hard to use...
That's no reason for breaking what does work. I don't mind
counterintuitive as long as it's documented.
See above. If no one can remember how to use it, or the workarounds
to make it work are worth more trouble to the author than the trouble
of not having it work on multibyte input, I'd say that it _doesn't_
work as is.
In fact, I'd argue that having string indexing be byte-oriented after
multibyte was added was a regression that broke things that did work:
before, getline('.')[col('.')-1] was a valid way to get the character
under the cursor, and afterwards it was not. Changing this behavior
would probably break very few scripts, since I doubt most scripters
are defensive about doing it correctly, and would mean that all the
broken code that already exists, and even the code that was written
before proper multibyte support was added (I believe it was added
after vimscript, right?), would continue to work *unless* it was
written intentionally to work around this issue. And I think that
authors who knew enough to work around this would, by and large, be
happy to see it fixed. I think that the advantages of having new
scripts work the way that they should, instead of the way that they
do, would greatly outweigh the disadvantages of breaking scripts
depending on the broken behavior. But, Bram's opinion is the final
answer, so we'll see if he weighs in.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Race condition during file saving
On Sat, Jan 3, 2009 at 11:27 PM, Adam Osuchowski wrote: Cases like mbox files are not so rare. There are many examples of simultaneously access to single file, but problem exists even without concurrent modification. A simple example: editing config file for some daemon. When vim truncates this file and program read it at the same time (because, for example, it will be restarted by cron, other administrator or even by itself) it will be problematic situation. The same matter is if a program will be run from cron or other program (for example, procmail from sendmail). Recover option in vim does not help here. Do you suggest turn off all processes during editing config files? Vim is used on multiuser and multiprocess systems, so limiting the working users or simultaneously processes to single one is misunderstanding. Why do you disrespect problem, especially if there is solution in the form of proper use of rename(2) syscall, which I mentioned about? rename(2) doesn't do everything needed. What if the file being written is a symlink, or a hard link? rename() would break the link, which probably isn't what you want an editor to do... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Files in ftdetect dirs are not searched
On Wed, Dec 31, 2008 at 8:11 AM, Tony Mechelynck wrote: On 31/12/08 07:48, Matt Wozniski wrote: On Tue, Dec 30, 2008 at 1:14 PM, Daniel Schierbeck wrote: I hope there's a simple workaround. Sorry I couldn't come up with the solution earlier on IRC, but after some sleep, I think I see what's going wrong here. 10 to 1 says you're using a 'nix distro that installs a default system-wide vimrc, and that system-wide vimrc does 'filetype on', meaning that $VIMRUNTIME/filetype.vim gets loaded before your ~/.vimrc ever adds your runtimepaths onto the default runtimepath, and only the ftdetect directories in the default runtimepath are used. I'm not really sure what to do about that, though... You could use :filetype off :filetype on after changing your 'runtimepath', which would first unset the filetype-detection autocommands, and then re-source filetype.vim to set them again with the new 'runtimepath' (invoking your ftdetect/*.vim scripts). Yes, then that seems like the best solution. I hadn't thought that :filetype off | filetype on would reload filetype.vim, but now that I think about it it makes sense. So, that's the solution, then. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Files in ftdetect dirs are not searched
On Tue, Dec 30, 2008 at 1:14 PM, Daniel Schierbeck wrote: I have added several directories to my runtimepath, each corresponding to a git repository. For example, I have a directory ~/Projects/vim- rack that contains ftdetect/rack.vim and syntax/rack.vim. I'm able to manually :set filetype=rack (i.e. the syntax/rack.vim file is picked up), but the ftdetect file does not work. It works fine if I create a symlink at ~/.vim/ftdetect/rack.vim. It seems there's a bug in the way ftdetect files are sourced. This feeling is amplified by the fact that I can insert syntax errors into ~/Projects/vim-rack/ftdetect/rack.vim without Vim complaining on startup. I hope there's a simple workaround. Sorry I couldn't come up with the solution earlier on IRC, but after some sleep, I think I see what's going wrong here. 10 to 1 says you're using a 'nix distro that installs a default system-wide vimrc, and that system-wide vimrc does 'filetype on', meaning that $VIMRUNTIME/filetype.vim gets loaded before your ~/.vimrc ever adds your runtimepaths onto the default runtimepath, and only the ftdetect directories in the default runtimepath are used. I'm not really sure what to do about that, though. You could remove the system-wide vimrc entirely, and move anything done in it to your ~/.vimrc after your change to runtimepath... but this seems ugly as it affects other users. You could alias vim=vim --cmd 'set rtp^=yourdir' in your shell rc, but that also seems horrifically ugly. You could redo the runtime! ftdetect/*.vim, but that would make any autocmds from *other* directories in the runtimepath be re-added... I think the nicest thing to do would be to save the existing value of the 'runtimepath' option, overwrite it with *just* the directories you want added, do the runtime! ftdetect/*.vim, reset 'runtimepath' back to its old value, and then add the new paths to that option in the right spots... but that seems like a whole lot of work for this. Anyone see any better solutions? It's a shame there are no autocmds for an option being set... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim SEGV
On Sat, Dec 27, 2008 at 3:15 AM, Dominique Pelle wrote: 2008/12/27 Matt Wozniski wrote: I found a SEGV that I can reproduce reliably, but can't seem to track down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind, and SEGVs under gdb. The steps that I'm using to reproduce this are complicated, and possibly very specific to the version of the runtime files and such that I'm using, but I'm hoping that a log of the backtrace + valgrind log can help someone to track it down. From the stack trace, a pointer is dereferenced, and points to some invalid (freed) memory, as a result of a previous memory reallocation in hash_may_resize(). Yeah. Looks to me like something got moved, the old memory got freed, and a pointer was held to the old location instead of the new one... I tried to reproduce it but I could not. Yeah, I'm not surprised... the fact that it seems tied to a hash table resizing makes me think that it's very much tied to the number of plugins I have loaded, the number of variables I have defined, and a whole bunch of other, less obvious factors Which command(s) do you use to step to line 300? at the :debug prompt, just pressing sCR and then CR repeatedly until I hit 300. Also which version of Vim are you using? I'm asking because the line numbers in the valgrind stack trace are not consistent with the latest eval.c of vim-7.2.75. Sorry, yeah - 7.2.049, the latest from the debian git repo: git://git.debian.org/git/pkg-vim/vim.git (plus an rsync'ed runtime updated last night). Maybe compiling with -O0 can help to get better debug information (if not already done?). It already is compiled with make CFLAGS='-g -O0'. Thanks for looking into this... I still haven't managed to spot the bug on my own. If you spot any variables you'd like to investigate or some such, let me know and I can try some breakpoints, since I can reproduce it... :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: usr_4[34].txt cosmetics
On Fri, Dec 26, 2008 at 6:49 AM, Florian Rehnisch wrote: Hi folks, it is said, that translators are the best profreaders. ;-) Sometimes, I make annotations. Let's see what I have: # type: Plain text #: usr_43.txt:61 # FIXME: ticks around maplocalleader, not dquotes, for it's an option msgid Likewise, the mapping for \\\c\ will disappear when editing another buffer. The \:map buffer\ command creates a mapping that is local to the current buffer. This works with any mapping command: \:map!\, \:vmap\, etc. The |LocalLeader| in the mapping is replaced with the value of \maplocalleader\. I disagree with this - maplocalleader isn't an option, it's a variable. 'options' should be quoted in the vim help, and variables should be double quoted. # type: Plain text #: usr_44.txt:501 #, no-wrap # FIXME shouldn't that be C++ syntax msgid The \:runtime!\ command searches 'runtimepath' for all \syntax/c.vim\ files.\n This makes the C syntax be defined like for C files. If you have replaced this one the\n c.vim syntax file, or added items with an extra file, these will be loaded as\n well.\n After loading the C syntax items the specific C++ items can be defined.\n For example, add keywords that are not used in C: \n No, I think this one is right as well. Though it could probably be phrased slightly better, I believe it's trying to say that All C syntax items will be defined like for C files. I'd suggest this patch as a clarification: diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..e37bfd5 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -492,10 +492,10 @@ one for C by using the following command: :runtime! syntax/c.vim -The :runtime! command searches 'runtimepath' for all syntax/c.vim files. -This makes the C syntax be defined like for C files. If you have replaced the -c.vim syntax file, or added items with an extra file, these will be loaded as -well. +The :runtime! command searches 'runtimepath' for all syntax/c.vim files +and loads them each. This makes every C syntax item be loaded just like they +would for C files. If you have replaced the c.vim syntax file, or added items +with an extra file, these will be loaded as well. After loading the C syntax items the specific C++ items can be defined. For example, add keywords that are not used in C: # type: Plain text #: usr_44.txt:513 #, no-wrap # FIXME s,It,A script, msgid Now consider the Perl language. It consists of two distinct parts: a\n documentation section in POD format, and a program written in Perl itself.\n The POD section starts with \=head\ and ends with \=cut\.\n You want to define the POD syntax in one file, and use it from the Perl\n syntax file. The \:syntax include\ command reads in a syntax file and stores\n the elements it defined in a syntax cluster. For Perl, the statements are as\n follows: \n I agree here. diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..7aa324a 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -503,9 +503,10 @@ For example, add keywords that are not used in C: This works just like in any other syntax file. -Now consider the Perl language. It consists of two distinct parts: a -documentation section in POD format, and a program written in Perl itself. -The POD section starts with =head and ends with =cut. +Now consider the Pere language. There are two distinct types of files that +need Perl syntax highlighting: a documentation section in POD format, and +a program written in Perl itself. The POD section starts with =head and +ends with =cut. You want to define the POD syntax in one file, and use it from the Perl syntax file. The :syntax include command reads in a syntax file and stores the elements it defined in a syntax cluster. For Perl, the statements are as # type: Plain text #: usr_44.txt:668 # FIXME comma after b:current_syntax msgid Choose a good, descriptive name for your syntax file. Use lowercase letters and digits. Don't make it too long, it is used in many places: The name of the syntax file \name.vim\, 'filetype', b:current_syntax the start of each syntax group (nameType, nameStatement, nameString, etc). Yep. diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..d6609f9 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -663,7 +663,7 @@ as an example will save you a lot of time. Choose a good, descriptive name for your syntax file. Use lowercase letters and digits. Don't make it too long, it is used in many places: The name of -the syntax file name.vim, 'filetype', b:current_syntax the start of each +the syntax file name.vim, 'filetype', b:current_syntax, the start of each syntax group (nameType, nameStatement, nameString, etc). Start with a check for b:current_syntax. If it is defined, some other Thanks and merry
Vim SEGV
I found a SEGV that I can reproduce reliably, but can't seem to track down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind, and SEGVs under gdb. The steps that I'm using to reproduce this are complicated, and possibly very specific to the version of the runtime files and such that I'm using, but I'm hoping that a log of the backtrace + valgrind log can help someone to track it down. GDB shows: Program received signal SIGSEGV, Segmentation fault. 0xb8063424 in __kernel_vsyscall () (gdb) bt #0 0xb8063424 in __kernel_vsyscall () #1 0xb7885956 in kill () from /lib/i686/cmov/libc.so.6 #2 0x08137c79 in may_core_dump () at os_unix.c:3070 #3 0x08137c10 in mch_exit (r=1) at os_unix.c:3035 #4 0x080db39c in getout (exitval=1) at main.c:1344 #5 0x08100ea0 in preserve_exit () at misc1.c:8371 #6 0x0813617c in deathtrap (sigarg=11) at os_unix.c:1057 #7 signal handler called #8 0x08079b32 in deref_func_name (name=0x90546a5 netrw#Explore(0,0,0+0,''), lenp=0xbf87d4ec) at eval.c:7833 #9 0x0808b2e5 in trans_function_name (pp=0xbf87d574, skip=0, flags=1, fdp=0xbf87d554) at eval.c:20395 #10 0x0807389e in ex_call (eap=0xbf87d608) at eval.c:3271 #11 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87da44, sourcing=1, cstack=0xbf87d740, fgetline=0, cookie=0x0) at ex_docmd.c:2622 #12 0x0809e834 in do_cmdline (cmdline=0x9126bb0 call netrw#Explore(0,0,0+0,''), getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #13 0x080a6562 in do_ucmd (eap=0xbf87db78) at ex_docmd.c:5989 #14 0x080a0d32 in do_one_cmd (cmdlinep=0xbf87dfb4, sourcing=1, cstack=0xbf87dcb0, fgetline=0, cookie=0x0) at ex_docmd.c:2613 #15 0x0809e834 in do_cmdline (cmdline=0x91165c6 E, getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #16 0x0809e0f1 in do_cmdline_cmd (cmd=0x91165c6 E) at ex_docmd.c:702 #17 0x080997f0 in ex_debug (eap=0xbf87e0c8) at ex_cmds2.c:301 #18 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87e504, sourcing=0, cstack=0xbf87e200, fgetline=0x80b4047 getexline, cookie=0x0) at ex_docmd.c:2622 #19 0x0809e834 in do_cmdline (cmdline=0x0, getline=0x80b4047 getexline, cookie=0x0, flags=0) at ex_docmd.c:1096 #20 0x081188af in nv_colon (cap=0xbf87e5f0) at normal.c:5233 #21 0x08111f9b in normal_cmd (oap=0xbf87e690, toplevel=1) at normal.c:1200 #22 0x080db0e3 in main_loop (cmdwin=0, noexmode=0) at main.c:1183 #23 0x080dac41 in main (argc=1, argv=0xbf87e894) at main.c:942 Valgrind gives: 1 errors in context 1 of 1: Invalid read of size 4 at 0x8088402: find_var_in_ht (eval.c:18815) by 0x8088277: find_var (eval.c:18769) by 0x8079B16: deref_func_name (eval.c:7831) by 0x808B2E4: trans_function_name (eval.c:20395) by 0x807389D: ex_call (eval.c:3271) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x80A6561: do_ucmd (ex_docmd.c:5989) by 0x80A0D31: do_one_cmd (ex_docmd.c:2613) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x809E0F0: do_cmdline_cmd (ex_docmd.c:702) by 0x80997EF: ex_debug (ex_cmds2.c:301) Address 0x4d9ebbc is 916 bytes inside a block of size 2,048 free'd at 0x4022B8A: free (vg_replace_malloc.c:323) by 0x81037B6: vim_free (misc2.c:1625) by 0x80D7F8C: hash_may_resize (hashtab.c:467) by 0x80D7C5C: hash_add_item (hashtab.c:254) by 0x80D7BD4: hash_add (hashtab.c:227) by 0x8088E54: set_var (eval.c:19189) by 0x8072C7F: set_var_lval (eval.c:2787) by 0x80721B1: ex_let_one (eval.c:2403) by 0x80711B2: ex_let_vars (eval.c:1858) by 0x8071163: ex_let (eval.c:1823) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) I can give any more information anyone might need. I've been reproducing this by doing :debug Explore, stepping to line 300, then quitting from debug mode - but I would not be at all shocked if that doesn't work for others. I'll keep trying to track it down, but Dominique seems to really have a knack for finding these sorts of problems, so maybe he can shorten the bug-hunting time. :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: 2html.vim support for dynamic folding
On Thu, Dec 18, 2008 at 8:01 AM, Markus Heidelberg wrote: When typing ^Vu and the codes above in terminal Vim, I always get these squares, i.e. the characters cannot be displayed, in vim -g it works. Is this a font issue? Yes; your font just must be missing those glyphs. Also, Konqueror displays the squares, but Firefox and Opera get it right. Again, just the font being used. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug: E685, SEGV - a:000 garbage collected too early?
function! ReturnArgs(...)
return a:000
endfunction
Seems to work fine?
echo ReturnArgs(1, 2, 3)
SEGV
echo string(ReturnArgs(1, 2, 3))
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
E685 Internal Error
echo MakeArgsDict(1, 2, 3)
SEGV
echo string(MakeArgsDict(1, 2, 3))
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug: E685, SEGV - a:000 garbage collected too early?
On Mon, Dec 15, 2008 at 2:42 PM, Dominique Pelle wrote:
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
I can reproduce that with vim-7.2.69 on Linux.
Following patch seems to fix it, but I'm not sure whether
that's the correct fix or whether it's only a workaround:
That's slightly better, since it no longer seems to crash, but it's
still wrong. With that patch applied, combining those two functions -
eg,
:echo MakeArgsDict(ReturnArgs(1, 2, 3))
gives the completely nonsensical result
{'args': [[...]]}
when the correct result should be
{'args': [1, 2, 3]}
Still haven't looked at the source, though, so I can't suggest a
better patch yet.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug: E685, SEGV - a:000 garbage collected too early?
On Mon, Dec 15, 2008 at 4:49 PM, Matt Wozniski wrote:
On Mon, Dec 15, 2008 at 2:42 PM, Dominique Pelle wrote:
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
I can reproduce that with vim-7.2.69 on Linux.
Following patch seems to fix it, but I'm not sure whether
that's the correct fix or whether it's only a workaround:
That's slightly better, since it no longer seems to crash, but it's
still wrong. With that patch applied, combining those two functions -
eg,
:echo MakeArgsDict(ReturnArgs(1, 2, 3))
gives the completely nonsensical result
{'args': [[...]]}
when the correct result should be
{'args': [1, 2, 3]}
Still haven't looked at the source, though, so I can't suggest a
better patch yet.
Better still,
:echo string(MakeArgsDict(ReturnArgs(1, 2, 3)))
gives
E724: variable nested too deep for displaying
{'args': }
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Bug? xterm-function-keys broken
For the life of me, I can't seem to get vim to recognize, eg, xHome and Home as separate keycodes. For instance... vim -u NONE -N :set Home? xHome? t_kh Home ^[[1~ t_kh Home ^[[1~ :set Home= :set xHome? E518: Unknown option: xHome? Is this intentional behavior? What's the point of having both Home and xHome if you can't use them to set two different key sequences that are both recognized as Home? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug? xterm-function-keys broken
John Beckett wrote: Matt Wozniski wrote: For the life of me, I can't seem to get vim to recognize, eg, xHome and Home as separate keycodes. Perhaps the following is an explanation: :help version7 /xHome Previously Home and xHome could be mapped separately. This had the disadvantage that all mappings (with modifiers) had to be duplicated, since you can't be sure what the keyboard generates. Now all xHome are internally translated to Home, both for the keys and for mappings. Also for xEnd, xF1, etc. Yes, I saw that, but I'm pretty sure that only refers to mapping with :map, and not setting the terminal byte sequence they correspond to with :set. I can't see a use for doing :map F1 foo and:map xF1 bar, but that's exactly because they should be two separate byte sequences that mean that the same key was pressed. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug? xterm-function-keys broken
Bram Moolenaar wrote: Matt Wozniski wrote: For the life of me, I can't seem to get vim to recognize, eg, xHome and Home as separate keycodes. For instance... That's a bug. This patch should fix it: Yes, that seems to fix it for me, xterm on Linux. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug in :set-termcap
At :help :set-termcap, an example shows the command
:set M-b=^[b
This command does not work as expected when 'encoding' is set to
something multibyte. The reason seems to be that vim recognizes the
input bytes 0x1B 0x62 as a metafied 'b', and then stuffs 0xE2 into its
internal text buffers - a byte which is not reasonable unicode. As a
result, vim continues waiting for more bytes to finish the
(unintentional) sequence, until it gives up, decides that the sequence
is invalid multibyte, and just returns the first byte as a character.
The attached patch fixes this by stuffing the multibyte bytes
corresponding to the given codepoint into the input buffer instead.
I'm not sure if there's a better way to handle changing the size of
MAX_KEY_CODE_LEN in src/keymap.h, but Bram will know for sure.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
diff --git a/src/keymap.h b/src/keymap.h
index 39837e5..99f38e6 100644
--- a/src/keymap.h
+++ b/src/keymap.h
@@ -479,6 +479,13 @@ enum key_extra
*
* K_SPECIAL KS_MODIFIER bitmask K_SPECIAL KS_EXTRA KT_LEFTDRAG.
*
- * This is a total of 6 tokens, and is currently the longest one possible.
+ * This is a total of 6 tokens, and is currently the longest one possible. In
+ * a multibyte encoding, it is also possible that a keycode representing a wide
+ * string taking up multiple bytes will need to be interpreted. In this case,
+ * the maximum becomes the maximum number of bytes to a character.
*/
-#define MAX_KEY_CODE_LEN6
+#ifdef FEAT_MBYTE
+# define MAX_KEY_CODE_LEN(MB_MAXBYTES)
+#else
+# define MAX_KEY_CODE_LEN6
+#endif
diff --git a/src/term.c b/src/term.c
index f795144..a991127 100644
--- a/src/term.c
+++ b/src/term.c
@@ -4919,8 +4919,20 @@ check_termcode(max_offset, buf, buflen)
/* Finally, add the special key code to our string */
key_name[0] = KEY2TERMCAP0(key);
key_name[1] = KEY2TERMCAP1(key);
- if (key_name[0] == KS_KEY)
- string[new_slen++] = key_name[1]; /* from :set M-b=xx */
+ if (key_name[0] == KS_KEY) {
+#ifdef FEAT_MBYTE
+ if (has_mbyte) {
+ char_u buf[MB_MAXBYTES];
+ int numbytes;
+ numbytes = (*mb_char2bytes)(key_name[1], buf);
+ buf[numbytes] = NUL;
+ STRCPY(string, buf);
+ new_slen += numbytes;
+ }
+ else
+#endif
+ string[new_slen++] = key_name[1]; /* from :set M-b=xx */
+ }
else
{
string[new_slen++] = K_SPECIAL;
Re: Patch: disallow encoding in modeline.
On Tue, Dec 9, 2008 at 3:40 AM, Patrick Texier wrote: Attached patch disallows 'encoding' in a modeline but not in secure mode. Looks like a good idea to me, especially since the vim help explicitly says that 'encoding' should either be set in ~/.vimrc or not at all... In fact, I think it shouldn't be usable in a modeline even if not in secure mode... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On Mon, Nov 17, 2008 at 6:02 PM, Dominique Pelle wrote: 2008/11/17 Dominique Pelle: Hi I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). Steps to reproduce: ... Observe that after pasting test in step 8/, Vim either crashes with: Vim: Caught deadly signal ABRT Vim: preserving files... .. or sometimes Vim just misbehaves (hangs or not longer accepts all keystrokes for example). Sometimes the text is not inserted at all when pasting the second time at step 8/. Running the same test with Valgrind, I see errors 100% of the times but so far I did not find how to fix them: ... Does anybody else see that bug too? I see that: - vim 'small' is not affected by the bug - vim 'normal' has the bug. Tweaking feature.h manually, I got 2 version of them, which only differ by the FEAT_XCLIPBOARD feature: - the one with FEAT_XCLIPBOARD is affected by the bug - the one without FEAT_XCLIPBOARD is not affected by the bug. So +xterm_clipboard is the feature that is triggering the bug. I'm not having any luck at all reproducing this, with 7.2.025 and +xterm_clipboard... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed overlapping memcpy() in if_xcmdsrv.c
On Sat, Nov 8, 2008 at 11:18 PM, Tony Mechelynck wrote: Configure is supposed to check whether one of the system provided string-move operations handle overlap. Here's what I see in the logs and files produced by configure on my system: snip So I suppose mch_memmove should be used everywhere for moves of byte strings (overlapping or not), and it will be resolved by bcopy, memmove, memcpy or the owncoded function according to what configure has found. You're right up til this point, but mch_memmove() should only be used where the bytes are overlapping, since it's so much less efficient than just a normal memcpy() and that loss is only justified when its extra feature is being used. memmove() should never be used in the vim sources. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Has remove() always thrown an error if idx is beyond the end of list?
On Tue, Oct 21, 2008 at 4:29 PM, Tony Mechelynck wrote: On 21/10/08 13:53, Nikolai Weibull wrote: Here's a patch: Please apply your patches to the latest version of the file. In eval.txt dated 2008 Sep 14, line, 4482 to 4489 are ... within the help for remote_send(); IOW your pointer is 14 lines too short. Isn't this a non-issue? The line numbers aren't right for the latest eval.txt, but the patch still applies fine. What's the problem? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: core dump with vim 1:7.1-138+1ubuntu3
On Mon, Oct 13, 2008 at 8:37 PM, John Little wrote: On Oct 14, 12:13 pm, frankjas wrote: I have been encountering an intermittent coredump ... I rebuilt vim from source with symbols after I stumbled on a reproduceable test case today... Brilliant. follows. It looks like the field uh_next_alt is being corrupted. Often in the backtrace it also contains the value 0x11. I can write up the exact steps to reproduce this error for anyone interested/capable of debugging this error. Yes, please. An early step will be to try it with an up to date version of vim, which is at 7.2.025, some hundreds of fixes after 7.1.138. Regards, John https://bugs.launchpad.net/ubuntu/+source/vim/+bug/219546 In short, Ubuntu Hardy shipped with a seriously buggy version - any vim version between 7.1.127 and 7.1.146 suffers from double-frees leading to crashes. Your best bet is to rebuild from source, either from the package source with the latest 7.1 patches, or from the up-to-date 7.2 sources, or to install the Ubuntu Intrepid vim. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
BUG: Unicode characters in commands
On Sun, Sep 28, 2008 at 4:35 PM, Tony Mechelynck wrote: On Sun, Sep 28, 2008 at 9:40 AM, John Hughes wrote: I am trying to write a command that substitutes some Ascii characters with a Unicode character. The following substitution works when entered directly: :%s/\.\.\./…/eg However, when defined as a command, it does not work: :com Ellipsis %s/\.\.\./…/eg The command :Ellipsis converts ... into â80feX¦ Why is this? Is there any way of using Unicode characters in substitute commands? I'm using gvim 7.2.21, huge build with Gnome2 GUI and 'encoding' set to UTF-8. Just like the OP, I see the following: - Typing the :s command at the command-line works OK. - Defining that :s command as a user-command text, then running that user command, replaces every set of three dots by â80feX¦ (5 characters including two invalid UTF-8 sequences, 7 bytes viz. C3 A2 80 FE 58 C2 A6). - Recalling that command definition with :command Ellipsis displays the ellipsis character as an ellipsis. - The ellipsis is U+2026, in UTF-8 0xE2 0x80 0xA6. Notice that 80 and A6 appear (though not consecutively) as part of the replace-text actually used, and that E2 is C3 A2 which also appears. This makes me suspect that Vim is applying a spurious Latin1-to-UTF8 conversion to what is already UTF-8 (with something wrong, maybe buffer-overflow, happening in the middle). Another possibility would be using a character length instead of a byte length, or vice-versa, at some point in the user-command execution. I can confirm this. It looks to me like it's not a spurious Latin1-UTF8 conversion, but an internally-escaped string that's not un-escaped before being used. Sourcediving, it seems that mb_unescape() is called to escape any multibyte characters when displaying the command, but that mb_unescape() is never called before the command is passed to do_cmdline() to be executed. That seems to explain why it's displayed properly but executed incorrectly. I don't completely follow all of the string escaping being done here, though, so Bram knows for sure. I've cross-posted to the vim-dev list accordingly. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug in exception handling with :return
These two functions ought to behave identically, but don't... For some reason, the :catch never gets triggered for the Broken one. function! Working() try let y = x return y catch /^Vim\%((\a\+)\)\=:E121/ Handle 'Undefined variable' errors return 42 endtry endfunction function! Broken() try return x catch /^Vim\%((\a\+)\)\=:E121/ Handle 'Undefined variable' errors return 42 endtry endfunction ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
