Re: Patch 8.2.3615
On Friday, December 10, 2021 at 10:07:25 PM UTC+13 cbl...@256bit.org wrote: > > Patch 8.2.3615 has been amended a bit by Patch 8.2.3754 so please check > latest version if this is still problematic for you. > Yes, after 8.2.3754 the problem ended. I was unlucky in that my vim update cadence stepped in between those patches. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/e4f30c3b-b6a2-4fd3-9631-e4457a741f8fn%40googlegroups.com.
Re: Patch 8.2.3615
This change was an unexpected problem for me. Until I stumbled on this thread I'd no idea is was due to a change in vim. gq started unindenting the yaml subset files I'm working with: doc: Lorem ipsum dolor sit amet, consectetur adipiscing elit The doc tags often have to be reformatted. Turning off cindent is a fix, but the files have source code in some elements and these are affected. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/646d4a85-cea1-447b-917b-fef4ee81142fn%40googlegroups.com.
Re: Escape sequences printed to the console when starting Gvim 8.1
After reading here, I went back to the 18.04 install, and updated vim to the latest, and the problem does not occur now. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/5b5103db-2265-4651-b298-a4f08119b965n%40googlegroups.com.
Re: Escape sequences printed to the console when starting Gvim 8.1
I installed Ubuntu 18.04 and reproduced the problem. Until seeing your post, I thought it was a gnome-terminal problem, because it does not occur for me with xterm, though I didn't try hard. xterm tends to be the least buggy emulator IME, perhaps because it has a rigorous test environment. A workaround is to start the gui early, by putting a "gui" command in .vimrc. Back in 2018 there were a few folks using similar workarounds. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2e6fa593-bd6a-48e4-91a5-1254bf2a42b3n%40googlegroups.com.
Re: Escape sequences printed to the console when starting Gvim 8.1
> - Ubuntu 18.04 with your Vim 8.1 -- has the issue > I wonder why you need Vim 8.1. At https://launchpad.net/~jonathonf/+archive/ubuntu/vim I see only vim 8.2 for 18.04. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/0a66aa81-f186-4b7a-a41f-f81766d10712n%40googlegroups.com.
Re: GTimeVal warning
toothpik >is anyone else getting these when they build? Yes, see the discussion at https://github.com/vim/vim/issues/4987 Some part of GTK2 being deprecated by another. There's nothing this project can do about it, other than giving up on GTK2. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/e0e56864-9f29-4d04-b05e-a70affcdf1afo%40googlegroups.com.
Re: [vim/vim] after restart X server vim boots slows (#6199)
I just had a go at reproducing your problem, on a KDE session that had been running for several days, though with many suspensions. After killing the X server with ctrl-alt-backspace, the kwin_x11 process went to 100% CPU (on one core), and KDE didn't shut down properly. Trying to log back in, the display got stuck on the splash screen. I conclude that in 20.04, killing an X server with KDE is buggy. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/b3bf3f13-bf93-4ea9-838e-92219e1c80f2o%40googlegroups.com.
Re: gvim startup time on Kubuntu 20.04 increased
I stumbled on what amounts to a solution for me. The default GTK3 theme in Kubuntu is called "Breeze", as is the default KDE and GTK2 theme. Changing the theme to a non-Breeze one reduces the "starting GUI" delay to about 200 ms, depending on the theme. This is much less noticeable. IMO it's crazy that Vim, despite sourcing over 60 scripts, can start in less than 100 ms, and the GUI can need much longer than that. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/349a399d-db44-4299-94b6-86064554f38c%40googlegroups.com.
gvim startup time on Kubuntu 20.04 increased
I upgraded from Kubuntu 19.10 to 20.04. gvim now has an annoying ~600 ms delay on starting, which --startuptime says occurs at "starting GUI". On 19.10 the delay is ~140 ms.This applies to all the recent versions of gvim I've tried up to 8.2.683, with --clean, -u NONE -U NONE, even running the exact same executable: gvim built on 20.04 running on 19.10 does not have the delay, gvim built on 19.10 running on 20.04 does. Applying set go= in .vimrc doesn't help. After installing vim-gtk3 from the respective repositories, some 8.1 version, the delay does not occur booted to a live iso of Ubuntu 20.04, nor Xubuntu 20.04. It does booted to the Kubuntu live iso. These findings also apply to running the vim built on Kubuntu 20.04, booted from the isos, except that the delay on Xubuntu is only 80 ms. So this seems to be a KDE plasma problem. Does anyone with KDE plasma 5.18.4, or 5.18, on another distro see this? What might be the cause of this? Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/223fc8ad-d764-4f99-a2d1-1b1fe9def5cf%40googlegroups.com.
Re: [vim/vim] In bash syntax you can't escape a backquote in a double-quoted string. (#5991)
This is a regression, the syntax/sh.vim from 2019-06-16 does not show this problem. The maintainer of this syntax script has his own version numbering, and if you want to report problems he usually will first ask that you try the latest script from his web site, which is version 190. It has the problem. The version on github is 189, dated 2019-10-16. Version 188, which I have from the Ubuntu 20.04 repository, does not show the problem. (Neither do versions 125, 133, or 179, which I had lying around.) HTH somebody, and regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2f3dd5a2-a626-4d56-90da-d9852279f7e2%40googlegroups.com.
Re: Error when deleting or yanking while not in insert mode. BadAccess (attempt to access private resource denied)
On Tuesday, April 21, 2020 at 9:35:23 PM UTC+12, Andreas Plesner wrote:
> My school provide a server from which we can run code...
>BadAccess (attempt to access private resource denied)
>Vim: Got X error
>Vim: Finished.
(I'm guessing... the error suggests the X server is running as a different
user from the vim user, or on a different host. You might be able to solve
this by some .Xauthority manipulation, or the brute force use of xhost. I
suggest reading the Xsecurity(7) man page. These aspects of X are unknown
by most, including me, and only a dim memory for most of the rest.)
I can report that I run vim with the change that Christian Brabandt has
suggested to no ill effect, and have done so for many years. I
occasionally get BadWindow X errors when vim puts 256 kiB or more on the
clipboard. (I've never been able to track it down, as it happens
asynchronously.) The one extra change I make is to add the line
g_print("%s", IObuff);
that causes the error message to go to standard output, wherever that may
be. Without the preserve_exit() call the message doesn't otherwise appear
anywhere.
I expect that vim's clipboard support will not work, though. For editing
files on a server, it may be easier to run vim locally, and use netrw to
access the files.
HTH, John Little
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/6ec5e3d2-663a-4df6-b55d-142111b9e5d2%40googlegroups.com.
Re: [vim/vim] :compiler segmentation fault (#5594)
git says 21b9e9773d64de40994f8762173bdd8befa6acf7 is the first bad commit Date: Sun Jan 26 19:26:46 2020 +0100 patch 8.2.0154: reallocating the list of scripts is inefficient Problem:Reallocating the list of scripts is inefficient. Solution: Instead of using a growarray of scriptitem_T, store pointers and allocate each scriptitem_T separately. Also avoids that the growarray pointers change when sourcing a new script. HTH, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/5f7eff38-f8dd-46e8-990c-8e329c15d88c%40googlegroups.com.
Re: [vim/vim] Segfault when calling gettabwinvar() with nonexistent tabnr and winnr > 1000 (#5475)
I reproduced this, and noticed that the stock Ubuntu version did not, so bisected to find the first bad commit is 9c27b1c6d140ca824a78654c1cb70a43a69b4ec6 Date: Sun May 26 18:48:13 2019 +0200 patch 8.1.1400: using global pointer for tab-local popups is clumsy Problem:Using global pointer for tab-local popups is clumsy. Solution: Use the pointer in tabpage_T. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/c081390b-f5b2-47dc-bbf4-e67fe3fcf41f%40googlegroups.com.
Re: version8.txt wrongly says that :wsverb command was added in vim-8.2
On Tuesday, December 31, 2019 at 12:18:01 AM UTC+13, Bram Moolenaar wrote: >Opinions? I agree the info is useful; I noticed because I didn't find the 8.2.00* patch details. Just as there is presently version4.txt, 5, 6, 7, I suggest version7.4.txt, version8.0.txt, version8.1.txt and version8.2.txt, since support for 8.3 filenames is no longer needed. Separating the discussion about each significant release from the list of patches would be sensible too. I imagine that would make maintaining them easier. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/f4861bc1-ca07-4bae-b93d-54d8f128bb11%40googlegroups.com.
Re: version8.txt wrongly says that :wsverb command was added in vim-8.2
Just noticed that :help patches gives version8.txt, which lists all the patch descriptions since 7.4.1, 6,600 of them, but stops at 8.1.2424; there's no list for the 50 or so 8.2 patches. Now, version8.txt has become unwieldy; at 1.6 MB it's by far the largest file in the repo, and github grumbles about it: (Sorry about that, but we can’t show files that are this big right now.) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/5e64a916-5346-484c-a643-832925bc6508%40googlegroups.com.
Re: [vim/vim] gvim spamming console from which it was started (#3628)
On Monday, December 9, 2019 at 2:58:29 AM UTC+13, Juan Lanus wrote: ... Bit of a necro, out of the blue a year later... Anyway, I remember these nuisances, but they've been gone for me for some time, GTK2 or GTK3. I'm on Ubuntu 19.10. Maybe it's been fixed in GTK (if so I'd be surprised), or the debian or Ubuntu packagers patched it. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/cb0c6819-8f1c-4c03-8aec-4d1f9d6ea294%40googlegroups.com.
Bug of vim script
a: is a scope, like g: or s:, for arguments of the function. For example: function WithArgs(first, second) echo a:first a:second echo a:1 a:2 endfunction Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/32ea159e-10d0-4559-a3ef-f37dc078d3ee%40googlegroups.com.
Re: [vim/vim] inoremap /inoremap do not disable mouse cursor movements (#4900)
On Saturday, September 7, 2019 at 2:43:21 PM UTC+12, yuri@FreeBSD wrote: I suppose you are using ssh? Yes. I think it's all over by the time vim on the remote system gets the input. Vim is receiving up or down arrow sequences when you use the scroll wheel, and there's nothing vim can do about it. I suggest that your terminal emulator on the local system is where you need to make a change. If you use xterm you could use xinput to disable the scroll wheel altogether, but some emulators ignore that; my konsole does. There may be a way with Gnu screen or tmux. Or conceivably, no idea if this would work, enable X forwarding with ssh, run a vim with +X11 and use set mouse=a in vim, then map the scroll events to . Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/5842b05b-f650-49f4-b068-8b3e61c3e7ea%40googlegroups.com.
Re: [vim/vim] Fix: 'visualbell' doesn't work (#1789)
FWIW I've used a 100 ms bell sound via a libcanberra call for many years, and have had to make the same hack to misc1.c. The reason given in the comments for the one per second limit is that some systems or terminals stall while playing a beep, so repeating some action or motion by holding a key down can cause a hang while a key buffer-full of beeps play. I wonder if any such systems are still used or supported. With libcanberra repeating a sound just restarts it and sounds play asynchronously anyway. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/090e421f-e300-495a-8ebe-5a6e61c7b321%40googlegroups.com.
Re: Using text properties to show rendered documents
On Sunday, June 9, 2019 at 3:20:23 AM UTC+12, Paul Jolly wrote: > > Why not just use :self markdown. and a markdown syntax file? > > Apologies, I'm probably missing something obvious here; but what is > the :self command? The obvious typo, surely :setf markdown? regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/b67f5deb-d4f7-43fc-bb4d-5cc179176db1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How about sound?
Since others have posted code, here's mine. In gui_gtk_x11.c: At file scope: #ifdef CANBERRA # include static ca_context *canberra = 0; #endif In gui_mch_beep: #ifdef CANBERRA int ca_error; if (!canberra) // static, initialize on first use ca_context_create (&canberra); ca_error = ca_context_play (canberra, 0, CA_PROP_EVENT_ID, "bell", CA_PROP_EVENT_DESCRIPTION, "vim beep", CA_PROP_CANBERRA_CACHE_CONTROL, "volatile", NULL); if (ca_error) fprintf(stderr, "%d error, %s\n", ca_error, ca_strerror(ca_error)); #else ... But also, in misc1.c, in vim_beep: #ifdef CANBERRA // john I use a 100 ms beep, which plays asynchronously anyway // so let's use 50 instead of 500 if (!did_init || ELAPSED_FUNC(start_tv) > 50) #else if (!did_init || ELAPSED_FUNC(start_tv) > 500) #endif Because libcanberra plays the sound in another thread, or something like that, it doesn't block, and it handles playing multiple sounds. My keyboard repeat rate is 50 Hz, and if I hold down the escape key I get 10 sounds a second, because the sound is 100 ms (thanks to audacity). Having a very fast (that is, a short attack stage) sound saves me a good fraction of second every time. Thinking while typing, please excuse me... The sound themes typically available for the xdg desktop standard have sounds that are one or 2 seconds long, and usually start slowly. For me that wouldn't suit vim. I'd like a general scheme where a different sound could be set for at least each auto command event. Maybe via an ex command, say "play". F.ex. one could make vim like a smartphone with key sounds on with InsertCharPre. But I'd like other events, too, with fine-grained control possible for errors and every circumstance where vim presently issues a beep. Python can play sounds, so I suppose I could make a call to python in auto commands. Maybe all we need is an event for the bell, and for errors, maybe passing or setting up some context via v:event. (It was a struggle for me to get all the packages I needed to get my python to use GSound; documentation I found was not quite up to date. ) So, my conclusion is that there could be an event for all the circumstances where vim presently may beep, and the relevant item at :h 'belloff' could be set in v:event. If an error has occurred then v:errmsg gives information. Then some heroic plugin author can put together the python bits and pieces with an appropriate sound theme. The large majority who want nothing to do with sound can continue in their silence, or maybe flash their RGB, or send a command to an odour generator ;). Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/06c490a5-53be-444c-8b9b-9edc033a7629%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How about sound?
On Wednesday, June 5, 2019 at 1:08:03 AM UTC+12, Bram Moolenaar wrote: > I have been wondering if it would help if Vim could play a sound. I'm a fan. More bandwidth from vim to me is always good. But people wanting to turn off beeps from vim are very vocal, those wanting to turn them on are not. I got used to relying on beeps using vi on dumb terminals for many years, and using vim with GTK with random DEs getting any kind of beep with vim proved very hit or miss, and losing the beep after some kind of upgrade happened a lot. So I learned about libcanberra, and my vim gives me a 100 ms cowbell. It's only about 15 lines of C. Managing (choosing, distributing) the sound files would be a far larger task than the code I imagine. I've no idea about libcanberra on MS Windows. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/12df3782-b1ac-4e84-97a1-d3bbe3a3e41e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Makefile changes (#4376)
I suggest making your changes in your own git branch. My workflow is git checkout master git pull git checkout john git merge master I find this cleaner and more flexible than git stash. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/cc5a0e3a-86a2-438f-9212-2a146a2947b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
make -j reconfig fails, indent.o now depends on auto/osdef.h
I use make -j with vim to compile several files simultaneously. Using make -j8 reconfig gave me In file included from indent.c:14: vim.h:272:11: fatal error: auto/osdef.h: No such file or directory # include "auto/osdef.h" /* bring missing declarations in */ ^~ Running make -j subsequently had no trouble, nor did make reconfig. It seems that indent.o should now depend on osdef.h; running make depend regenerated that part of src/Makefile with that dependency for indent.o, and the problem resolved. Perhaps make depend should be run on the master. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Vim 8.1 is freezing / buffering all input while another process is watching files and performing brief but I/O heavy work (#3834)
On Tuesday, January 22, 2019 at 1:58:02 AM UTC+13, Nick Janetakis wrote: >... an I/O heavy action ... Vim is frozen ... This sounds much like a Linux I/O scheduler problem, especially as >If I move my source code to the SSD, I don't notice this hanging / buffering >effect These can be inexplicably hardware dependent; identical OS and software on another machine can be problem free. Totally frustrating because it seems not much attention was paid to it by the Linux devs for years. For example, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381300 Typically, deadline is used for SSDs and cfq for hard discs. What does cat /sys/block/sdb/queue/scheduler say? If it says something like noop deadline [cfq] You might try echo deadline | sudo tee -a /sys/block/sdb/queue/scheduler Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [BUG] Peculiar bug with session restoration, please repro
On Sunday, January 13, 2019 at 11:53:04 AM UTC+13, Jason Franklin wrote: > Again, while working with sessions, I found a peculiar bug. > Now... move the cursor up and down with j/k, and you'll see that > cursorline highlighting doesn't follow the cursor as expected. I reproduced this in Kubuntu 18.10 in a konsole, and also gvim with GTK2, but only after getting the latest source, so I thought, I can bisect this. The first bad commit is patch 8.1.0726: redrawing specifically for conceal feature Problem:Redrawing specifically for conceal feature. Solution: Use generic redrawing methods. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Syntax highlighting infelicity for bash (#3773)
On Monday, January 7, 2019 at 8:55:21 AM UTC+13, 38spl wrote:
> the following is valid bash(1) code to trim the last character of a string:
>
> string="${string::$((${#string}-1))}"
>
> The characters in bold above are highlighted as if they are syntax errors.
>From :help sh.vim:
One may specify a global default by instantiating one of the following
variables in your <.vimrc>:
...
bash:
let g:is_bash = 1
...
If there's no "#! ..." line, and the user hasn't availed himself/herself of
a default sh.vim syntax setting as just shown, then syntax/sh.vim will assume
the Bourne shell syntax.
If I add a shebang line, #/bin/bash, or I let g:is_bash = 1 in my .vimrc, that
line of code is highlighted without indicating an error.
So, in your vim, what does this say:
:echo b:is_bash
if it says E121: Undefined variable: b:is_bash then the code has not been
recognized as bash.
Note that setting is_bash doesn't have an effect immediately, only after a
reload or otherwise re-executing the syntax script, by, say, turning syntax off
and on.
Regards, John Little
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gVim: diacritic renders on wrong character with particular font at size 11 or above (#3754)
On Thursday, January 3, 2019 at 9:34:53 PM UTC+13, Tony Mechelynck wrote: > GTK2 or GTK3? The results could be different. If you can, try compiling Vim > with the other version of GTK. I did that (built a GTK3 vim). No change. The incorrectly rendered fonts had the same placement of the dot. > FWIW, :set gfn=Bistream\ Vera\ Sans\ Mono\ 8 gives me correctly placed > composing characters in gvim with GTK2. (That's very small.) With that font in vim the dot is under the c but at the right of the cell. I suggest checking a larger size of that font. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gVim: diacritic renders on wrong character with particular font at size 11 or above (#3754)
On Friday, January 4, 2019 at 9:39:40 AM UTC+13, Kazunobu Kuriyama wrote:
>
> The number 90 means that the spacing of the font in question is dual. If the
> spacing were mono, the number would be 100.
$ fc-query -f "%{spacing}\n"
/usr/share/fonts/truetype/liberation/LiberationMono-Regular.ttf
100
Regards, John Little
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gVim: diacritic renders on wrong character with particular font at size 11 or above (#3754)
On Wednesday, January 2, 2019 at 12:14:41 PM UTC+13, MathSquared wrote: > I'm experiencing a very peculiar issue with the sequence of characters > U+010D, U+0323 (č, combining dot below). I tried entering those, reproduced the problem (luckily) and thought I'd report that. But then it got confusing... Using the text "loč̣rem ipsum" I see this with "Liberation Mono", a distributed (I think) font on my Kubuntu 18.10, gvim 8.1.655 with GTK2. With that font in Libreoffice Writer, the dot appears correctly. I tried sizes up to 72 point, with the same result. Trying some common fonts at random, with "Monospace", "Deja Vu Sans Mono", and "Courier", the dot is in the correct place. As well as "Liberation Mono", with "Latin Modern Mono" and "FreeMono" the dot is under the previous character o. The same text in Kate, the Kubuntu default editor, puts the dot under the next character (the r above), in all the fonts I tried. So does Konsole, but xterm renders it correctly. gedit, the GNOME editor, also shows the dot correctly in all the fonts I tried. Weird. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
gcc 8 -Wcast-function-type warnings
Posting this in case somebody else falls down the same rabbit hole I did. I've compiled vim with gcc -Wextra for many years, uncommenting a line in the distributed Makefile to enable this and a few other strict warnings. Yesterday upon getting the latest source and compiling I got lots, 44, of -Wcast-function-type warnings. The warnings are sort of valid; in the case I looked at there's a mismatch of the number of parameters in a function pointer, but the missing one is not used anyway. One of the cases is in GTK code, which we're unlikely to get changed, so I suppose we should just ignore these warnings. Other projects are doing this. So, if one wants to use -Wextra, I suggest adding -Wno-cast-function-type as well. Maybe the comment line in the Makefile could be changed. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Hard-coded 2 pixel border in GTK gVim (#3575)
On Tuesday, October 30, 2018 at 2:05:04 PM UTC+13, Kazunobu Kuriyama wrote: > Vim on xterm has the 2px-width border Not on my xterm on KDE. ovk's mod now makes gvim consistent with vim in an xterm, and vim in a konsole, when I use the same font as gvim. > Personally, I think any UI should follow a UI guideline written... It seems to me that the guideline you refer to is very old, and has long been superseded in modern DEs, which support configurability of these elements, or minimises them. > Therefore, it's okay for me that Windows Gvim has no border around the text > area if that fits recent Windows design. Why should we, however, import that > design into UNIX-like systems at the cost of inconsistency between Vim and > Gvim on a single platform? If consistency between vim and gvim is a goal, all that hard-coding of sizes and widths needs to be removed so that the user's themes and styles and so on are allowed to work. The present code guarantees inconsistency, at least on my screen. Of course, it can't be as easy as that, and I am by no means even slightly proficient with this stuff. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Hard-coded 2 pixel border in GTK gVim (#3575)
On Monday, October 29, 2018 at 2:14:04 PM UTC+13, ovk wrote: > The current GTK gVim has hard-coded 2 pixel border ... Thank you for pointing this out. I begrudge every pixel, and much prefer setting this to zero, now that I've tried it. The scrollbar width being hard-coded to 15 or 16 has always annoyed me, so I've been reducing this in my builds of gvim for a long time. Fixing this border width glitch fits well with the thinner scrollbar. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
linebreak, showbreak, and visual block yank problem
I noticed a problem today when editing a paragraph that was wrapped to several lines on screen. To reproduce, use a file with a line with normal prose text that wraps to several screen lines, say x.txt, then vim -u NONE -c "set linebreak showbreak=>" x.txt Move to the end of the long line, start a block selection with ctrl-V, press y to yank it. The yanked text will be from an earlier part of the line, not the text in the block selection. The offset increases with the amount of space showing on the right of the text, space that without the 'linebreak' option would not be blank. It doesn't happen with v for a character selection. I bisected my .vimrc to find the settings triggering the problem, then used git bisect to find the problem was introduced with v7.4.576: Date: Wed Jan 14 17:52:30 2015 +0100 updated for version 7.4.576 Problem:Redrawing problem with 'relativenumber' and 'linebreak'. Solution: Temporarily reset 'linebreak' and restore it in more places. (Christian Brabandt) I could give a more detailed example, but Google groups might wrap it into a confusing mess. I suppose that using a block selection for part of a line that is wrapped with 'linebreak' is marginally useful so this problem is very minor. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Can't build from source on latest Fedora 28 (#3398)
On Saturday, September 1, 2018 at 5:00:34 PM UTC+12, Gennadiy Zlobin wrote: ... > checking for iconv_open()... yes; with -liconv At this point there is a libiconv.something, and it does have iconv_open() in it. (My debian-derived ubuntu does not, so fails this test; the libraries it tests with are -ltinfo -lnsl -lselinux -liconv. ) Configure only tries to link here. ... > configure:13799: checking size of int > configure:13804: gcc -o conftest -g -O2 -L/usr/local/lib conftest.c -lm > -ltinfo -lelf -lselinux -liconv >&5 > configure:13804: $? = 0 Now it links again with -liconv sucessfully, but on running > configure:13804: ./conftest > ./conftest: error while loading shared libraries: libiconv.so.2: cannot open > shared object file: No such file or directory > configure:13804: $? = 127 The load of the iconv library fails. Something is wrong with your iconv library; I suggest reinstalling it, or removing it. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] reset tty's termios to expected values on SIGCONT (#3285)
On Monday, August 6, 2018 at 10:21:03 AM UTC+12, joshudson wrote: > vim gets very confused when it gets a TSTOP, TTIN, or STOP signal and later a > CONT signal. I see this in vim 8.1.0239, sending SIGSTOP. The pseudo-terminal is in line mode; typing :!echo causes vim to reset it. Using stty -F /dev/pts/ raw then ctrl-L in vim resets it too. >I remember being able to do this in classic vi from ages ago. This perked my interest, because surely I used to do this a lot every day with actual terminals. I even built vim 6.4 and 5.8 to check them out, but their behaviour is the same (in my KDE with plasma 5, but also in the Linux console). Now :suspend and ctrl-Z work, so now I think that's what I used to do all the time back then. So it's only sending SIGSTOP from somewhere else that gives trouble. Sometimes I get junk back in the shell, f.ex. " xM P. xM#P.", that my shell thinks I've typed. Weird that no-one bothered about it then. There was a related problem fixed in Vim-7.2.130 that was due to a race condition, so maybe 2018 hardware has brought this out. See mch_suspend() in os_unix.c to see the details; maybe vim could use this if it gets a SIGCONT it's not expecting. However, the best approach might be, don't do that. IIUC SIGSTOP can't be caught, blocked, or ignored and if vim has the X selection other processes that ask for it will hang. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Error detected while processing function 39_Highlight_Matching_Pair: in bash file (#3280)
On Sunday, August 5, 2018 at 11:32:10 AM UTC+12, vikkitharan wrote: > Error detected while processing function 39_Highlight_Matching_Pair: > line 78: > E475: Invalid argument: 0 I can't reproduce this, with 8.1.0239. I suspect some other plugin or setting is confusing the matchparen.vim plugin. Does it still occur with vim --clean -N -c 'ru plugin/matchparen.vim' 2.sh If it does, can you tell us what is in the line in matchparen.vim for which the error is reported? My line 78 is blank. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Weird indentation of C labels when a statement block starts on the same line (#3229)
On Thursday, July 19, 2018 at 4:28:00 AM UTC+12, Tony Mechelynck wrote: > > Once upon a time, maybe 40 to 50 years ago, I used to be programming in > COBOL, and if my colleagues and I did use PERFORM statements, GOTOs weren't > shunned either. Nothing wrong with PERFORM, so long as it was just one paragraph or (IMO preferably) one section being performed. > Then came programming theorists... they told us that GOTO statements were evil No theorists were needed for me to learn to wish the fieriest hell upon any who used GOTO in COBOL (with the possible exception of GOTO paragraph-end in COBOL-74 and earlier). I will bear deep scars on my psyche to my grave from the consequences of use of GOTO. If you needed to be told this, I can only be bewildered. A lot of money, billions, and lives, have been lost through use of GOTO. > But they seem to be doing a comeback in C... "goto" in C was much used one day, and one can find it here and there in the vim source. Either for some performance reason, or to simplify code generation, f.ex. with yacc. But today with modern compilers I deny there is any need at all, and they should be loathed as the spawn of Satan they are. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Weird indentation of C labels when a statement block starts on the same line (#3229)
I see your behaviour with vim --clean -c 'set cinoptions+=L' -c 'normal ggVG=' The in-built C indenting doesn't cope with the opening brace on the same line as the label. Neither does 'smartindent'. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Can't find pkg-config during configure (#3192)
On Wednesday, July 11, 2018 at 12:01:27 PM UTC+12, Char Aznable wrote: > Any clue about what's going on here? The problem isn't with pkg-config. but with GTK. You check pkg-config with gtk+-2.0, but configure thinks you want GTK 3; if you really want GTK2 adjust the CONF_OPT_GUI line in the Makefile. I'd first check the return status of pkg-config --exists gtk+-3.0: $ pkg-config --exists gtk+-3.0;echo $? should say "0"; I say that because from my reading of the configure script that would be a way that you'd get a bare "configure:9850: result: no" with no explanation; if the link of a test programme failed, or the run of it failed, there'd be more info in the log. If you get "1" pkg-config thinks you haven't got GTK3, and maybe you need to install some GTK3 development files. Autotools configure scripts are beasts. You could try using CONF_OPT_GUI = --enable-gui=gtk3 --disable-gtktest in the Makefile to skip some of those GTK tests. The version will still gets checked, but it's seems bit redundant in that a version less than 3.0.0 wouldn't be, well, 3. HTH, and regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Vim hangs when showmatch and cpoptions-m are enabled and paste a block containing parens (#3146)
I think these have the same cause as the problem reported by Petr Vorel: https://groups.google.com/forum/?hl=en#!topic/vim_dev/GB0OXwfTsdA If your problems are not avoided by :set t_BE= to turn off "bracketed paste" then I imagine it's different. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] try/catch inconsistent (#3142)
> Observation : gvim shows the "Press enter" line, while vim does not. I get the opposite; gvim does not show the prompt, vim does. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Is it possible to disable vim from opening too large files? (#3120)
On Saturday, June 30, 2018 at 9:41:08 PM UTC+12, xuejipeng wrote: > I performed a misoperation and opened a 6G file with vim, which caused the > server to crash. I wonder if there is a configuration ... I suggest you look at the LargeFile plugin: https://www.vim.org/scripts/script.php?script_id=1506 Using it might solve your problem, but if it doesn't, it's quite simple, you could adapt it to suit your needs in a few lines of vim script. However, I don't know a good way to abort loading the file, perhaps someone here can tell us. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0128
On Sunday, July 1, 2018 at 2:28:04 AM UTC+12, Bram Moolenaar wrote: > Patch 8.1.0128 Just noticed version.c on github doesn't have patch number 128. No effect, other than a little confusion. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Scrolling large documents in GVim flickers (#701)
I'd like to look at this but I can't reproduce anything like it. On Kubuntu 18.04, gvim 8.1.0091 with GTK2, and with a keyboard rate at 50 Hz, and a 3.4 GHz i7, holding down Page Down or ctrl-f gives no flicker, and top says gvim is at 18% of one core, with Xorg 30% and kwin_x11 at 17%, roughly. What font are you using? What locale settings? What video hardware? (I just use the i7's HD 530, to a 1080p screen.) gvim --clean gives me Monospace Regular 10, which appears to be the same as DejaVu Sans Mono Book 10. Perhaps if I use your font and encoding I could reproduce the flicker. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim bug when inserting foo}
I have reproduced this with konsole and xterm, with vim 8.0.1453, 8.1.26, and 8.1.72. It happens for any character that showmatch would respond with, }, ), or ], if there isn't a matching left character, and so vim would do the visual bell if one was typing. Vim get very confused and echoes all characters typed, even escape if typed twice. Except that, if one presses ctrl-c, the display freezes and vim goes CPU bound, with its memory usage bouncing up and down by a few MB, very slowly increasing. The only action I've found that will affect vim is a window resize, or a WINCH signal; sometimes that fills most of the screen with the two characters ^C. It's a bracketed paste problem, :set t_BE= to turn that off stops it happening. It's like the showmatch action is turned back on slightly too soon, and the sequences for the visual bell interfere with the end of the paste and the result is a mess. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gvim --remote-wait spikes high CPU usage (#2975)
FWIW, using ps (and top and htop) I see a similar result as you, on Kubuntu 18.04 and vim 8.1.0026. (I was deceived for a while by KSysGuard, the KDE system monitor, showing only 8%, but I think that KSysGuard is dividing by the cpu count.) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] wasted space of toolbar in openSUSE Leap 15.0 (#2957)
Kazunobu Kuriyama said: >For the record, this issue isn't due to Vim or GTK+ 3, but the icon theme that >doesn't comply with the specs. >...the directory layout of Breeze... Thank you for that explanation. I've been mystified by some icon behaviour in another context with GTK 3. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] a symbol disappears and reappears when the cursor passes over it (#2696)
On Wednesday, March 7, 2018 at 11:39:36 AM UTC+13, lkintact wrote: > Copy this text into the buffer: Тٌам (these are Cyrillic letters with an Arab > symbol above the "а", probably a result of a poor OCR) > Move the cursor from "м" to "Т" and back several times. The Arab symbol > appears and disappears. In my experience these behaviours are because the font doesn't work with vim for those characters. I normally use Liberation Mono, and if I make the font large enough to see the symbol clearly it's fine. But if I change to Latin Modern Mono (a random choice) I get the behaviour you describe; also the "м" loses the right stem sometimes. Your :set all shows guifont= so you haven't chosen a font; if I run gvim -u NONE I get guifont= similarly, but if I run :set guifont=* I see that the font is called "Monospace". That's some generic alias from KDE, Ubuntu, debian or Linux, I don't know, but it also displays "Тٌам" correctly. Vim is picky about the font, and fonts that have characters that extend outside the cell have problems, like the results depending on the direction the cursor moves past the letter. Leftover artifacts is another problem. There's a world of issues, all I know is that I don't know much about that world. So, I suggest finding a better font to use with vim. If you tell us your OS (and GUI if that OS has several) I sure you'll get recommendations. Fonts vary a lot in how much of Unicode they support, you might mention which scripts you need. You can set the guifont in your .gvimrc. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gvim exits with "BadWindow (invalid window parameter)" when highlighting large regions (#1023)
A few findings: 1. > Turning on "Ignore selection" in the clipboard settings has stopped it. Not good, I use it all the time, in vim or out. 2. The failure occurs if the selection is more than 262144 bytes, 2**18. 3. A workaround for me is to take the suggestion in the comment in x_error_handler in os_unix.c: /* Silently continuing might be an alternative... */ and commenting out the preserve_exit() call. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gvim exits with "BadWindow (invalid window parameter)" when highlighting large regions (#1023)
On Thursday, September 8, 2016 at 7:54:00 PM UTC+12, nuko8 wrote: > Accordingly, I'd like to suggest that the issue be viewed more in terms of > interaction between KDE and GTK+ 2 as well as usage of the KDE desktop > environment. I agree with your conclusion, but it is a severe gvim failure. For me, any text file large enough, about 5000 lines, causes gvim to exit if one tries to ggVG. In the vim source directory, eval.c is not big enough, but cat e*.c > x.c makes a file big enough. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gvim exits with "BadWindow (invalid window parameter)" when highlighting large regions (#1023)
I can reproduce this with 7.4.1689, 7.4.2161, and 7.4.2321, all with GTK2 on KDE with plasma 5. I'll have a go later with debug, valgrind and asan. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] SEGV when run gvim in ubuntu 16.04 (#851)
On Tuesday, August 9, 2016 at 8:16:28 AM UTC+12, gschintgen wrote: > Hi, I think my current Ubuntu installation is suffering from the same bug. > I'm on 16.04 (clean install) using the distribution-provided package: version > 7.4.1689-3ubuntu1.1. > Fairly often (but not always) gvim crashes as soon as I launch it. Which distro provided GUI are you running? Ubuntu packages vim with GTK2 and GTK3. IIUC GTK2 is the default, and you get GTK3 at /usr/bin/vim.gtk3 > The error output is the same as given by @tracyone. I suspect that doesn't mean much, the output looks generic. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] SEGV when run gvim in ubuntu 14.04 (#851)
On Wednesday, June 8, 2016 at 6:41:47 PM UTC+12, tracyone wrote: > OS:ubuntu 16.04 x86-64 > I build vim from source by myself,build script is: > ./configure \ > --with-features=huge \ > --with-compiledby="tracyone" \ > --enable-multibyte \ > --enable-gui=gtk3 \ > --enable-gpm \ > --enable-cscope \ > --enable-fontset \ > --enable-sniff \ > --enable-xim \ > --enable-fail-if-missing \ > --enable-pythoninterp=dynamic \ > --enable-fail-if-missing \ > --with-python-config-dir=/usr/lib/python2.7/config-x86_64-linux-gnu \ > --enable-python3interp=dynamic \ > --with-python3-config-dir=/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu > run any command in gvim will lead to SEGV I'm on 16.04, so I had a go compiling with your options, with patches up to 2187. configure said: configure: WARNING: unrecognized options: --enable-sniff I don't understand that, but anyway I compiled with make and vim -g runs ok. I did run sudo apt-get build-dep vim-gtk3 and it pulled down some packages: gir1.2-atspi-2.0 gir1.2-gconf-2.0 gir1.2-gnomekeyring-1.0 icu-devtools libart-2.0-dev libatk-bridge2.0-dev libatspi2.0-dev libavahi-client-dev libavahi-common-dev libavahi-glib-dev libbonobo2-dev libbonoboui2-dev libdbus-1-dev libdrm-dev libegl1-mesa-dev libepoxy-dev libgail-common libgail-dev libgconf2-dev libgmp-dev libgmpxx4ldbl libgnome-keyring-dev libgnome2-dev libgnomecanvas2-dev libgnomeui-dev libgnomevfs2-dev libgnutls-dev libgnutlsxx28 libgtk-3-dev libicu-dev libidl-2-0 libidl-dev libidn11-dev libmirclient-dev libmircommon-dev libmircookie-dev libmircookie2 liborbit2 liborbit2-dev libp11-kit-dev libpopt-dev libprotobuf-dev libprotobuf9v5 libtasn1-6-dev libwayland-dev libx11-xcb-dev libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev libxcb-randr0-dev libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev libxkbcommon-dev libxml2-dev libxshmfence-dev libxtst-dev libxxf86vm-dev nettle-dev orbit2 ruby-dev ruby2.3-dev x11proto-dri2-dev x11proto-gl-dev x11proto-record-dev x11proto-xf86vidmode-dev I've been building fine with GTK2 without that lot. My :ver says Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/ include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/ include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk -3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/mirclient -I/usr/include/mircom mon -I/usr/include/mircookie -I/usr/include/cairo -I/usr/include/pango-1.0 -I/us r/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/includ e/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/glib-2.0 - I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -DCANBERRA -Wall -Wextra -W missing-prototypes -Wunreachable-code -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -D_REENTRANT Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-3 -lgdk-3 -lpango cairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2 .0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -lcanberra (Ignore the canberra stuff, I don't like the GTK bell so have coded in my own. Canberra needs -D_REENTRANT.) HTH, and regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: can't build with gui -- config not finding gtk
On Tuesday, June 21, 2016 at 7:13:46 PM UTC+12, Tony Mechelynck wrote: > On Mon, Jun 20, 2016 at 3:46 AM, John Little wrote: > [...] > > I'm on a debian-derived distro, [...] > > Then you may have one bit of useful information. Which command would > you run using aptitude or apt-get, to make sure that you have all > requirements for building Vim with GTK2? sudo apt-get build-dep vim-gtk Regards, John Little As I said earlier, the > openSUSE repositories include a "zypper-aptitude" package which > installs whatever is needed to mimic the Debian aptitude and apt-get > commands by means of the openSUSE "zypper" package manager. > > Then after making sure that zypper-aptitude is installed, toothpik > could run aptitude or apt-get or whatever Debian users use, with the > same command-line arguments, and it would look for (and install if > missing) any necessary prerequisite for building Vim. > > And after running that, "make reconfig", with the config settings set > by means of environment variables as I showed earlier, would run rerun > configure then immediately recompile all modules needed by whatever > config options were selected. > > > Best regards, > Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: can't build with gui -- config not finding gtk
To mention the obvious just in case, are you running (in the vim src) make reconfig Sometimes that's necessary due to OS updates, without vim changing. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: can't build with gui -- config not finding gtk
On Monday, June 20, 2016 at 12:33:07 PM UTC+12, toothpik wrote: > looking for a module named something like gtk+-2.0.pc > of course I have no such module in any of those directories I'm on a debian-derived distro, so this may not be directly helpful, but for me /usr/lib/x86_64-linux-gnu/pkgconfig/gtk+-2.0.pc is an installed file of package "libgtk2.0-dev". Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: can't build with gui -- config not finding gtk
The GTK check uses the "pkg-config" command. I suggest you look in the generated "configure" script in the auto directory to see what parameters it is being given, then run it yourself, and report the parameters and result here. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] configure fails on gcc 6.0 (#800)
On Friday, May 13, 2016 at 9:47:26 AM UTC+12, Daniel Hodges wrote: > I've been trying to compile on fedora 24 and I'm running into this bug issue: > > src/auto/config.log ... > gcc: error: unrecognized command line option '-qversion'; did you mean > '--version'? > gcc: fatal error: no input files > compilation terminated. > > It seems the error is in src/auto/configure I've just installed gcc 6 on Ubuntu 16.04, and built vim using --enable-rubyinterp with no trouble. My config.log contains the errors you report; it continues: configure:2993: checking whether the C compiler works I conclude that those errors are not your problem. You may have concluded the same, since --enable-rubyinterp has nothing to do with that part of configure's processing. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Lack of integer overflow handling in range() and for
On Friday, April 22, 2016 at 8:13:21 PM UTC+12, Lekare wrote: > When entering something really big, like > > :put =range(300,3) > > Vim quits with message > > Vim: Caught deadly signal SEGV > Vim: Finished. > [1]75479 segmentation fault \vim On my x86-64 with 16 GiB of RAM, that causes vim to gallop through memory at about 2 GiB/s, then linux is in strife, until [ 4382.649514 ] Out of memory: Kill process 2965 (gvim) score 917 or sacrifice child [ 4382.650036 ] killed process 2965 (gvim) total-vm:30326512kB, anon-rss:15751236kB, file-rss:160kB The point I'm trying to make is that if you ask vim to do stuff beyond the resources of the system it's running on, vim will try, and the failure depends on that system. IMO it would be very difficult to code vim to reliably catch all the ways it can fail like this. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] On XFCE, the gvim main window opens without having focus (#689)
On Tuesday, March 15, 2016 at 8:46:16 AM UTC+13, Anthony Papillion wrote: > When gVim starts, the main window does not have focus and must be clicked in > order to begin using it. I struck this problem with xterm some years ago. https://www.kubuntuforums.net/showthread.php?57403-xterm-kde-gtk-focus-glitch&highlight=xterm The cause was an environment variable called DESKTOP_STARTUP_ID, and the terminal programme (xterm) should unset it, according to the "Desktop Entry Specification". I corresponded with the maintainer of xterm and he agreed that it should be unset. Maybe the fix didn't get to XFCE by 14.04, or you are using something else. Anyway, you could check if DESKTOP_STARTUP_ID is set, and unset it in your .profile or .bashrc. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to update with local changes
On Monday, January 18, 2016 at 9:36:17 PM UTC+13, LCD 47 wrote: > On 17 January 2016, John Little wrote: > > Or, would I be better with the cryptic commands above? (I say cryptic > > because '... use "--set-upstream-to". Something like ...' followed by > > commands where --set-upstream-to does not appear.) > > It does, "git br -u" is a shortcut for "git branch --set-upstream-to". I did presume that, but I was hinting that giving the command in full would be appropriate when helping a newbie, and perhaps more vim-like. I suppose I was making subtle point about my newbieness, feeling it relevant to the discussion. Oh dear, I'm becoming unsubtle, sorry. > See "man git-branch", and perhaps the "Tracking Branches" section in the > official Git book: > > http://git-scm.com/book/ch3-5.html#Tracking-Branches > > It's a common problem, and the "cryptic" sequence of commands above > is really all you need to solve it. I think with recent versions of git > you can further shorten > > git co -b local > git br -u origin/master > > to > > git co -b local origin/master A sincere, unsubtle thank you for those pointers. I'll be following them up. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to update with local changes
On Monday, January 18, 2016 at 6:19:55 PM UTC+13, James McCoy wrote: (I much appreciate your response, and would like to forestall any impression otherwise that might be construed from the grumpy terseness of my remarks. My grumpiness laments my own failings with git.) > runtime/doc/tags really shouldn't be part of the repository. It's a > generated file. Bram didn't agree last time this was brought up. It is generated as part of "make install". I can imagine needing it for testing before doing a make install. > That being said, simply deleting the file from disk isn't going to help > because that's just another type of uncommitted modification to a file > that Git is versioning. Yup, learned that one the hard way. > Even if you were to commit the delete, then > you'll just have to merge a conflict (you deleted it and Bram changed > it) any time the tags file is regenerated by Bram. Ditto. > The simplest thing to do would be to reset the tags file to its > versioned state before pulling in the latest changes from Bram. > > $ git checkout runtime/doc/tags I just learned about git checkout recently. This is a nuisance in that I have to do it every time. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to update with local changes
On Sunday, January 17, 2016 at 4:59:10 AM UTC+13, LCD 47 wrote: > The trick is to use "--set-upstream-to". Something like this: > > git clone https://github.com/vim/vim.git > cd vim > git co -b local > git br -u origin/master > > This creates a branch named "local", switches to it, and sets it up > so that when you run "git pull" it merges changes from GitHub. After > that you can just patch and commit your changes to this branch: > > ... edit ... > git ci -am 'Some work done.' > ... edit ... > git ci -am 'Some more work done.' > > "git pull" will then merge changes to upstream master to your > branch, keeping your changes: > > git pull I've following the instructions on vim.org, which says if you have local changes use git fetch followed by git merge. This has been a dog's breakfast at times, with me running various git commands I don't understand (as suggested by cryptic messages) trying to shut git up. runtime/doc/tags usually gives trouble, despite me putting it in .gitignore, and deleting it locally. Today it was: $ git merge CONFLICT (modify/delete): runtime/doc/tags deleted in HEAD and modified in refs/remotes/origin/master. Version refs/remotes/origin/master of runtime/doc/tags left in tree. Automatic merge failed; fix conflicts and then commit the result. $ rm runtime/doc/tags $ git merge error: merge is not possible because you have unmerged files. hint: Fix them up in the work tree, and then use 'git add/rm ' hint: as appropriate to mark resolution and make a commit, or use hint: 'git commit -a'. fatal: Exiting because of an unresolved conflict. $ git commit -a [master 589478d] Merge remote-tracking branch 'refs/remotes/origin/master' How should I make this runtime/doc/tags stuff go away? .gitignore doesn't. Or, would I be better with the cryptic commands above? (I say cryptic because '... use "--set-upstream-to". Something like ...' followed by commands where --set-upstream-to does not appear.) Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to update with local changes
On Sunday, January 17, 2016 at 4:59:10 AM UTC+13, LCD 47 wrote: > The trick is to use "--set-upstream-to". Something like this: > > git clone https://github.com/vim/vim.git > cd vim > git co -b local > git br -u origin/master > > This creates a branch named "local", switches to it, and sets it up > so that when you run "git pull" it merges changes from GitHub. After > that you can just patch and commit your changes to this branch: > > ... edit ... > git ci -am 'Some work done.' > ... edit ... > git ci -am 'Some more work done.' > > "git pull" will then merge changes to upstream master to your > branch, keeping your changes: > > git pull I've following the instructions on vim.org, which says if you have local changes use git fetch followed by git merge. This has been a dog's breakfast at times, with me running various git commands I don't understand (as suggested by cryptic messages) trying to shut git up. runtime/doc/tags usually gives trouble, despite me putting it in .gitignore, and deleting it locally. Today it was: $ git merge CONFLICT (modify/delete): runtime/doc/tags deleted in HEAD and modified in refs/remotes/origin/master. Version refs/remotes/origin/master of runtime/doc/tags left in tree. Automatic merge failed; fix conflicts and then commit the result. $ rm runtime/doc/tags $ git merge error: merge is not possible because you have unmerged files. hint: Fix them up in the work tree, and then use 'git add/rm ' hint: as appropriate to mark resolution and make a commit, or use hint: 'git commit -a'. fatal: Exiting because of an unresolved conflict. $ git commit -a [master 589478d] Merge remote-tracking branch 'refs/remotes/origin/master' How should I make this runtime/doc/tags stuff go away? .gitignore doesn't. Or, would I be better with the cryptic commands above? (I say cryptic because '... use "--set-upstream-to". Something like ...' followed by commands where --set-upstream-to does not appear.) Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.995
Tony I have used git checkout to back out my change, as patch 1038 does it now. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.995
On Sunday, January 3, 2016 at 8:31:34 AM UTC+13, Bram Moolenaar wrote: > > I would propose to follow the source code. A manual can have a mistake. > However, is what we need available in ALL point release of 2.31? Tony > mentions getting the warning for 2.31.6. If we check for 2.31, will it > work with 2.31.0 ? FWIW, IMO it's just a nuisance warning, and the slightly obsessive like me can make it go away. Unless someone with gdk-pixbuf-2.0 2.31.0 pops up and says using the GResource code works, we'd run the risk of breaking someone's build. However, my local ubuntu archive mirror has packages only for 2.30.7, 2.31.3 and 2.32.[12] for ubuntu and debian. 2.30.7 comes with the long term support release (supported till 2019) which does not give the deprecation warning. So, in the debian world only 2.31.3 is widely used. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.995
On Sunday, January 3, 2016 at 2:13:42 AM UTC+13, Tony Mechelynck wrote: > > What does > > > >pkg-config --modversion gdk-pixbuf-2.0 > > > > say on your system, Tony? > > It says 2.31.6 My Ubuntu 15.04 install says 2.31.3, so I think you could do what I did in my post above, change line 2511 of src/configure.in to read $gdk_pixbuf_version_minor -ge 31 ; then and make reconfig. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.995
On Saturday, January 2, 2016 at 7:09:58 PM UTC+13, Tony Mechelynck wrote: > the compiler warning in question is still there at the current patchlevel. What does pkg-config --modversion gdk-pixbuf-2.0 say on your system, Tony? Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.995
> Patch 7.4.995 > Problem:gdk_pixbuf_new_from_inline() is deprecated. I was pleased to see this patch come, the deprecation warning is annoying if one is in the habit of watching out for warnings. However, I still got the warning; my version of gdk-pixbuf-2.0 is 2.31.3, with Ubuntu 15.04. On the reasoning that if I get the warning, then gdk_pixbuf_new_from_inline() is deprecated in my version, I hacked the configure script to check for 2.31 rather than 2.32 and have compiled ok. IIUC the code is only used for icons on the toolbar and for signs, and these work fine at least once. Whether anything should be done about this is debatable, but I thought I'd mention it. Certainly the documentation referred to in the pull request suggests that GResource landed in 2.32, and my gio/gresource.h has lots of GLIB_AVAILABLE_IN_2_32 error macros. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] Cursor disappears when adding/removing vertical splits (#480)
On Wednesday, November 18, 2015 at 8:09:25 AM UTC+13, John Little wrote: > FWIW, I don't see this with KDE 5. > Just had the opportunity to check this with LXDE on Lubuntu, and I still don't see it. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] Crash while mouse-selecting in two-buffer mode (#486)
On Thursday, November 19, 2015 at 10:19:23 PM UTC+13, Kirill Ivashov wrote: > if I click as far right as possible > > Issue title states not "clicking" but "selecting" which means "Hold left > mouse down and move cursor". There's confusion here, or at least I am. There are two "cursors": the mouse cursor and what I'll call the "text cursor" (note this is usually what konsole and vim mean by "cursor"; I have blinking cursor checked on the advanced tab of editing the profile). Do you mean "hold left mouse down and move mouse to the left"? I haven't been able to reproduce any problem, however I move anything. Aha, I just did it. I had to type a lot of text, and do lots of mouse dragging. The handling of the visual highlighting before that didn't inspire confidence, with the wrong parts of the text being highlighted. I suspect your problem may have something to do with "extended coordinates". What does set ttymouse? tell you? Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] Crash while mouse-selecting in two-buffer mode (#486)
I can't reproduce this, though I am seeing incorrect behaviour. > click as right as possible (terminal size should be larger than column size * > column count I don't know what "column size" and "column count" refer to, sorry. Making my konsole 248 columns wide, if I click as far right as possible, nothing happens (vim should move the cursor to the right window). Using ctrl-V indicates that konsole won't tell vim a mouse click beyond column 222. xterm can, it's using a different control sequence for this now. My konsole is KDE Frameworks: 5.9.0, konsole 3.0.1. on Kubuntu Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[vim] Cursor disappears when adding/removing vertical splits (#480)
FWIW, I don't see this with KDE 5. Just speculating, this might be caused by a problem with GTK2 in Gnome 3; I have the impression that the Gnome project does that sort of thing. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: screen clearing doesn't work in xterm
On Sunday, November 8, 2015 at 4:52:26 PM UTC+13, Random832 wrote: > "U+25BD WHITE DOWN-POINTING TRIANGLE" Well done, is all I can say. How do you start an xterm in non-utf8 mode? If I reset my locale to C and start an xterm then vim, vim uses latin1 and only the bd byte is output. IMO, the code should explain why this magic number character is used. Then we'd know how to pick another, maybe. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: screen clearing doesn't work in xterm
Note also that you can add a full reset when vim starts by putting the following in your .vimrc: let &t_ti = "\ec" . &t_ti I haven't tested that much though. It messes with the "alternate screen" handling. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: screen clearing doesn't work in xterm
On Sunday, November 8, 2015 at 12:03:49 PM UTC+13, Random832 wrote: > When running in xterm (a real xterm, not any other terminal reporting > itself as "xterm") with TERM set to xterm, Vim puts the terminal in a > state where the screen clearing commands \e[K and \e[J do not work Are you sure it's vim? If, at a bash prompt in an xterm, I run echo -e '\eV' then the xterm gets in a state like you describe, particularly if I then run vim. Running tput reset fixes it. Does running tput reset before running vim exhibit your trouble? Or even tput reset;vim in case your shell's prompt command has the nasty sequence (mine does a bunch). This implies to me that vim's internal xterm handling is not complete in its reset. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Updates to vhdl.vim
On Tuesday, October 6, 2015 at 2:00:41 AM UTC+13, Daniel Kho wrote: > Somehow the one installed by the package manager seems pretty old. Doing a > ":version" gave the following: > :version > VIM - Vi IMproved 7.3 (2010 Aug 15, compiled May 4 2012 04:25:35) > Included patches: 1-429 That's the version in Ubuntu Precise Pangolin, released in April 2012, aka 12.04. If you're really on precise, you could do-release-upgrade to 14.04. Ubuntu 15.04 has 7.4.488, but compiling your own is so easy, so long as you run sudo apt-get build-dep vim and sudo apt-get install build-essential before trying to compile vim. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: VIM now crashes when opening large file:
On Wednesday, September 9, 2015 at 6:10:24 AM UTC-5, Josh G wrote: > I keep getting crashes now when opening large file (4GB, 9GB). +1 for the LargeFile plugin. Though, vim does everything in memory, if you have less RAM than the size of the file it will be swapping and so slow. > it kept moving really slow. I couldn't really highlight anything quickly Some syntax highlighting can get very slow; what syntax was being used? Also, vim can get slow if lines are very long, say kilobytes. I've had usable performance looking at largeish log files with syntax highlighting by using drastically simple highlighting. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unicode 6.0.0 symbols show with incionsistent width
On Tuesday, July 21, 2015 at 6:54:37 PM UTC+12, Yuri Vic wrote: > Actually on my system (FreeBSD, kde konsole terminal) font doesn't support > this character, and it is shown as an "empty box" glyph. However, when the > cursor is over it, one box turns into two consecutive boxes. And when the > cursor is to the right, space gets added to this symbol and other letters > begin to jump in a strange way. > So I don't think font has anything to do with it. Also vim package doesn't > depend on any unicode packages, last time I looked widths were hard-coded in > vim itself. With konsole I use Liberation Mono too, and running vim in konsole the display is corrupted, though the glyph is sometimes displayed. Setting ambiwith=double improves things a bit, sometimes the display is correct. I would consider this a konsole problem; I get the same trouble at the bash prompt if I run echo "THUMBS UP SIGN (👍)1234" then go back and edit the line; vim is not involved. But it's really a fundamental limitation in vim; it really wants characters in single cells, with some limited hacks for double width characters. I can't see this limitation changing. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unicode 6.0.0 symbols show with incionsistent width
On Tuesday, July 21, 2015 at 9:25:55 AM UTC+12, Yuri Vic wrote: > I came across this symbol: U+1F44D THUMBS UP SIGN (👍) > In vim-7.4.778 it shows with width one or two... And Zyx replied: So this problem has nothing to do with Vim. I agree. Using "Liberation Mono" with a GTK vim the thumbs up is displayed ok. I know the behaviour, in my vim, f.ex. "ㄫ" which I get with vim's nG digraph, writes to four character cells altogether. Scarcely relevant factoid, I used the thumbs up recently in an SM on my Samsung S3 phone, and the recipient on a Sony couldn't render it. Regards, John -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.778
gcc 4.9.2 still gives a warning: ops.c: In function ‘do_addsub’: ops.c:5406:10: warning: ‘startcol’ may be used uninitialized in this function [-Wmaybe-uninitialized] int startcol; ^ AFAICT it's not a problem, but I'm not surprised gcc can't figure that out. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Neovim changes
On Thursday, April 16, 2015 at 1:04:18 AM UTC+12, Christian Brabandt wrote: > syslog.1:Feb 4 21:00:31 debian kernel: [513730.438473] Out of memory: > Kill process 12506 (vim) score 731 or sacrifice child I only mention this for completeness of the discussion, and I realize this is only peripherally related to the point. When the OOM killer is striking, setting a ulimit can cause a quicker, and nicer failure, facilitating debugging sometimes. Generally, I've always had misgivings about the "abort is the best error handler school", as I call it. Seems to show a lack of imagination of what it might be like to be in other shoes. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Wrong dollar sign red color highlighting in shell scripts
On Saturday, March 21, 2015 at 10:52:19 PM UTC+13, Yuri wrote: > In BSD Almquist shell, CR='\r' is literally backslash and r, and > CR=$'\r' is carriage return char. > ) The same syntax works in bash, but this isn't posix syntax. So why > vim flags it then, if it is Bourne shell syntax? I agree now that it's wrong, and the syntax dash uses is weird. It appears that the writer of those parts of the shell syntax highlighting was writing for dash. But this is understandable since the ANSI C quoting style, though it appeared in ksh93, has only recently (2013) been published by the open group, and while I'm not a standards lawyer that publication seems not very official, more de facto. Since the syntax script supports the $'...' style for bash and ksh, it should be easy to do so in posix mode too. Nevertheless, shell script syntax highlighting is almost a Sisyphean task, and I'm very grateful that Dr Chip has done it. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Wrong dollar sign red color highlighting in shell scripts
Yuri said: > > This helped, but there is still some valid shell syntax in BSD > > (Almquist) shell that is highlighted red: > > > CR=$'\r' > > > NL=$'\n' > > dollar sign and enclosing quotation symbols. Christian replied: > That is not valid posix syntax, isn't it? Indeed, that's ksh syntax; with ash it accepts it but includes an extra $ character. The correct syntax with my ash is CR='\r' NL='\n' In this case flagging the $ as an error is useful, with my ash at least. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Wrong dollar sign red color highlighting in shell scripts
On Thursday, March 19, 2015 at 6:58:53 PM UTC+13, Yuri wrote: > OS is FreeBSD, vim-7.4.657, #!/bin/sh is Bourne shell, IIRC arithmetic evaluation $(()) and process execution using $() were not in the original Bourne shell, they are POSIX features (that came first from the Korn shell I think). > adding 'let > g:is_sh=1' into ~/.vimrc didn't change anything I wouldn't expect it to, that's what I had to add to reproduce your problem. However, I think if you add let g:is_posix = 1 as well you'll be good, without adding bash or ksh support. I suspect you've really got an Almquist shell. Note that vim's help in syntax.txt says posix: (using this is the same as setting is_kornshell to 1) let g:is_posix = 1 but my reading of syntax/sh.vim suggests this is no longer quite true. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Wrong dollar sign red color highlighting in shell scripts
On Thursday, March 19, 2015 at 2:46:19 PM UTC+13, Yuri Vic wrote:
> In these Bourne shell statements in .sh file:
>
> val=$((some_variable - 1))
>
> val=$(some_function_or_command)
> val=$(${SOME_VAR} arg1 arg2)
>
> enclosing dollar sign and braces highlighted as red, even though this is a
> valid shell syntax.
I wonder what version OS, vim, and syntax script you have.
I had to force the syntax script to highlight for the Bourne shell (by
let is_bash = 1
in my .vimrc to see the lines highlighted incorrectly. Even using the shebang
#!/bin/sh didn't do it; sh.vim notices that /bin/sh resolves to /bin/dash on my
Debian based distro, and sh.vim sets a POSIX flag. Indeed, my distro only has
POSIX shells AFAICT.
Regards, John Little
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: can't edit ~/.alias - segmentation fault
On Thursday, March 5, 2015 at 4:04:05 PM UTC+13, Ran Regev wrote: > # alias eali > alias eali='vim ~/.alias' > # eali > Vim: Caught deadly signal SEGV > Any idea? The # prompt suggests running as root, where ~ may not be well defined. My linux distro (ubuntu) has a /root for this purpose, perhaps yours doesn't, or $HOME is screwed up. Looks odd anyway. So, do you see this not logged on as root? What's your OS, anyway? Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Font size?
On Friday, February 27, 2015 at 11:44:01 AM UTC+13, John Little wrote: > Though these days gvim is subtracting 1 from the lines I tell it, either with > -geometry or set lines, I don't know why. I just looked into this, and I suspect there's a race condition in the GUI. I had been compiling with profiling on and forgot about it; now with profiling off about a quarter of vim invocations subtract 1 from the line count when my .gvimrc does "syntax on", however 'lines' was set. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Font size?
On Friday, February 27, 2015 at 1:59:22 AM UTC+13, Don wrote: > ...I ... reduce the font size to 8-points Someone else with good eyesight! While it might make more sense to set lines=60, say, in your .vimrc , another way to do it is to use a -geometry argument to gvim. I have alias v='gvim -geometry 80x60' Though these days gvim is subtracting 1 from the lines I tell it, either with -geometry or set lines, I don't know why. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Google summer of code
On Friday, February 13, 2015 at 1:43:05 AM UTC+13, Marius Gedminas wrote: > As a user, I'd like Vim to migrate to GTK+ 3.x please. Not meaning to question or challenge your suggestion at all, is it possible you could say why? (Everything Gnome 3-ish has otherwise been a turn off to me.) Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Strange display of acute accent in a complex character
On Friday, January 30, 2015 at 9:50:13 AM UTC+13, Yuri Vic wrote: > I have the UTF8 representation of this character: Ϊ́ (ce 99 cc 88 cc 81) > kde4, konsole-4.14.2, FreeBSD-10 FWIW, I have konsole 4.13.3, and the accent is being drawn above the diaeresis, outside the character cell, up into the line above, whether in vim or not. Vim won't work well with that. The font has an effect, using Courier New lets the character display correctly in konsole, but not always well in vim in that console, it depends which line was drawn last. To display the character properly with vim, I imagine you'd need a font that draws it all inside the character cell. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.560
On Thursday, December 18, 2014 at 9:01:14 AM UTC+13, Bram Moolenaar wrote: > Patch 7.4.560 ... > Files:src/ops.c I get a compile warning on this with gcc 4.9.2 ops.c: In function ‘read_viminfo_register’: ops.c:5758:21: warning: ‘new_width’ may be used uninitialized in this function [-Wmaybe-uninitialized] y_current->y_width = new_width; ^ ops.c:5757:20: warning: ‘new_type’ may be used uninitialized in this function [-Wmaybe-uninitialized] y_current->y_type = new_type; ^ Looking at the code, the case can't be reached, but a couple of initializers wouldn't hurt, I'd have thought. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Regeression in RE ("\%>")somewhere after 7.4.560
On Sunday, January 18, 2015 at 7:52:46 AM UTC+13, Axel Bender wrote: > 1) Open the attached file "test.txt". > 2) set ts=80 > 3) /\%>80vGesamtausabe > > Contrary to the behavior in 560 (Windows 7, MinGW64), only the term > "Gesamtausgabe" in the second line is marked. I see this in 7.4.580, linux amd64. In fact, the \%>Nv atom looks quite broken, given the line, and vim -u NONE -N: abcdefgh \%>2vc and \%2vd work, but \%>2ve does not. More generally, \%>Nv does not match beyond N + 2, and it used to. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim cursorline problem / terminal bug ?
On Friday, October 17, 2014 8:30:18 AM UTC+13, Arkadiusz Miśkiewicz wrote: > I have a problem with "set cursorline" where cursor line doesn't get > properly drawn. ... > Is anyone beside me being able to reproduce this? > kde 4.14.2 > vim 7.4.461 KDE 4.13.3, Konsole 2.13.2 here, and no problem. Have you checked with vim -u NONE? Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Can't paste into new windows when clipboard is set to unnamedplus
On Saturday, September 13, 2014 12:48:01 AM UTC+12, Jason Pleau wrote: > Hello John. Unfortunately I am not using any clipboard manager. I am using a > barebones window manager (i3 http://i3wm.org), with gnome-settings-daemon (at > home), and xfce4-settingsd (at work). As far as I know, none of them has a > clipboard manager. Clipit is reported to work with i3 (in the i3 FAQ), and clipman works with XFCE. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Can't paste into new windows when clipboard is set to unnamedplus
On Wednesday, September 10, 2014 1:01:53 PM UTC+12, Jason Pleau wrote: > I cannot paste from the system clipboard with vim if it is opened after > I copied my text into the clipboard. I am using set clipboard=unnamedplus. Are you using a clipboard manager? In KDE this is klipper, and with LXDE one can install "parcellite", if I've got that correctly. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: gcc buffer overflow detected on vim startup
On Thursday, September 11, 2014 4:58:15 PM UTC+12, Dominique Pelle wrote: > John Little wrote: > > *** buffer overflow detected ***: vim terminated ... > I'm guessing you're using Ubuntu. Well, my post did say Kubuntu. > Ubuntu modified > their version of gcc to default to -D_FORTITY_SOURCE=2. Thank you. > See "man gcc" on Ubuntu which says: > === BEGIN QUOTE === > > NOTE: In Ubuntu 8.10 and later versions, > -D_FORTIFY_SOURCE=2 is set by default, > and is activated when -O is set to 2 or higher. > If _FORTIFY_SOURCE is set to 1, with compiler ... In my defence, that starts at line 3488 of a 12,222 line man page; no wonder I didn't see it. I looked at the gcc manual from the gcc web site. I've been compiling my own vim since about Ubuntu 8.10, I wonder why I haven't run into this before. Thanks again, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
gcc buffer overflow detected on vim startup
I've been running a debug build of vim for a while, and while diagnosing a
slowness problem noticed that it was much slower than the version I get with my
distro (Kubuntu 14.04, 7.4.52), so I changed my compiler flags to add -O2 and
recompiled.
The resulting executable aborted instantly:
*** buffer overflow detected ***: vim terminated
and splurges out a backtrace and about 300 lines of memory map.
The version of gcc is 4.8.2.
Getting a core dump, I see that gcc is doing a checked strcpy and aborting.
This occurs at my line 874 of eval.c:
STRCPY(p->vv_di.di_key, p->vv_name);
p is pointing at the first element of vimvars:
static struct vimvar
{
char*vv_name; /* name of variable, without v: */
dictitem_T vv_di; /* value and name for key */
charvv_filler[16]; /* space for LONGEST name below!!! */
charvv_flags; /* VV_COMPAT, VV_RO, VV_RO_SBX */
} vimvars[VV_LEN] =
and vv_di is a
struct dictitem_S
{
typval_Tdi_tv; /* type and value of the variable */
char_u di_flags; /* flags (only used for variable) */
char_u di_key[1]; /* key (actually longer!) */
}
This is done to avoid a allocation for di_key. I think gcc is complaining that
di_key has only room for one char, and doesn't realize that we've allowed space
in vv_filler for the data.
Why it should do that with -O2 and not without has me wondering, perhaps the
members of struct vimvar are being reordered?
Anyway, if I add -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 to the compile flags
(gcc is using a default of 2) the abort goes away, but this leaves an uneasy
feeling.
I thought having the last char item of a struct being declared as [1] was valid
C, and I have a vague idea that there's an explicit ok for this sort of thing.
Regards, John Little
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Is there anything about CI (Contentious Integration) in Vim program?
Don't you mean Continuous Integration? My thoughts... vim is built on so many platforms, in a variety of configurations, that full CI of vim would have to be distributed, using volunteered resources; I imagine that would be difficult to organize. I imagine we'd need a lot more tests, including platform specific rendering tests. As it is, there are many who build vim on their own environments who pull frequently, and report problems to this list promptly. Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
