Re: (possibly known) bug with visual block and searchreplace
On Jan 16, 2008 2:39 PM, Jürgen Krämer [EMAIL PROTECTED] wrote: this is intended and documented behaviour. It's first mentioned below Have a look at the footnotes of this table (especially footnote (1)). Argh, I totally missed that. Sorry for sending this mail in the first place :/ I could not find the actual rationale for this behaviour, though. Not that I am trying to argue it, I am just interested in why this is. Possible explanations would be 1) a good reason that has escaped me 2) a known caveat that is not urgent to handle as Dr Chip has a script, anyway The behaviour you want can be achieved with an additional script by Dr. Chip. You can download it from the following url Thanks a lot :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: .nb files are Mathematica notebooks
(Mathematica). *.nb files can also be safely linked to the mma file type, as Mathematica notebooks just contain one big Mathematica expression. You can define such a link easily yourself. See :h ftdetect Of course one does not normally edit raw notebook files with a text editor I think so too. The extension seems rather unique though. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.230
On Jan 15, 2008 11:17 PM, Charles E Campbell Jr [EMAIL PROTECTED] wrote: This one I figured I might be able to check on -- I mean, how often would garlic show up in the lawbooks? As opposed to something like assault. Anyway, doing a search at Indiana University's virtual law library yielded no hits. Many of those were modified to make them more obscure, thus 'funnier'. One of them is that, in Germany, you are not allowed to start a car when someone is lying under it. The actual law says that you need to ensure that no one can be harmed by you operating the vehicle before you drive it. This includes lights, brakes and, of course, human obstacles. The first version is 'funny', the latter is not, it is just basic common sense. Along the same lines, it might be that you are not allowed to enter any of those three crowded places while stinking so bad as to annoy others. Then someone just picked the most obscure example he could come up with while drunk and went with that. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Set mouse=a causes Vim to hang in screen.
On Jan 15, 2008 8:26 PM, Gautam Iyer [EMAIL PROTECTED] wrote: Ok. Tested. Vim-7.1.229 still hangs on Scientific Linux 5: What are your screen settings? Perhaps they have an influence? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Set mouse=a causes Vim to hang in screen.
On Jan 15, 2008 8:26 PM, Gautam Iyer [EMAIL PROTECTED] wrote: Then vim -u /tmp/vimrc -X hangs when run under screen. It does not display anything, or respond to terminal input (including Ctrl-C). When killed (SIGTERM), it draws the intro screen and prints a message saying Received TERM signal, exiting. I can't reproduce that. A couple of questions/suggestions: When it hangs, does it take 100% of the CPU (endless loop) or is the vim process blocked (0% of CPU). You can check the CPU usage with the top command. You can also try to run vim with strace (useful in case it blocks in a system call?): $ strace vim 2 trace.log ... then look at trace.log You can also try to attach with gdb to the running process. You will first need to build vim with DEBUG information (-g -O0). Just put the following line in vim7/src/Makefile: CFLAGS = -g -O0 Then recompile vim and run it. When vim hangs, attach to the process with gdb as follows: $ gdb /usr/local/bin/vim process_id (replace /usr/local/bin/vim with actual location of your vim program and replace process_id with the process ID of vim). Then in gdb, type bt command to get a stack trace. It should help to debug. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug? Session loading may scroll up needlessly high
Session loading may scroll up needlessly high The cursor line is always scrolled to the top of the window (plus 'scrolloff' if set), regardless of whether there are additional lines (and how many of them) after it. Reproducible: Always Steps to reproduce: 1. Edit (or view) a file which is longer than the window size. 2. G -- Note that the cursor is at the bottom of the window space. This is normal. 3. :mks! 4. :qa 5. vim -S Actual result: The cursor line (which is the last line of the file) is now near the top of the window, with a lot of ~ lines (lines after the end of file) below it. Expected result: The bottom line of the file should be at the bottom of the window (as it was at step 2), with no ~ lines showing. Additional info: Happens identically in GUI and Console modes. 'sessionoptions' is at its default value. Workaround: Use gg^O in each window after restarting, where ^O is obtained by hitting ctrl-v ctrl-o This must be done _manually_; :windo normal gg^O will change the current file in all windows. Using: openSUSE Linux 10.3 VIM - Vi IMproved 7.1 (2007 May 12, compiled Jan 17 2008 02:10:07) Included patches: 1-231 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): [...] It happened the same way at earlier patchlevels. I just thought I'd report it. Best regards, Tony. -- Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long? -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: .nb files are Mathematica notebooks
On Jan 17, 8:35 pm, Bram Moolenaar [EMAIL PROTECTED] wrote: I also see *.nb files listed as Nota Bene text files. I don't know what Nota Bene is, but perhaps the file contents can be checked to be something that looks like Mathematica? According to http://filext.com/file-extension/nb, Nota Bene is a word processor and bibliographic manager. Mathematica notebooks always begin with a comment, i.e. (* (without the quotes). I am not sure whether there may be any whitespace before the (*, but none of the notebooks I checked (created by versions 3.0, 5.2 and 6.0) had any. So perhaps any *.nb file whose first two characters are (* could be linked to the mma file type? Szabolcs --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Mikolaj Machowski wrote: Dnia Thursday 17 of January 2008, Bram Moolenaar napisał: Hello Vim users, I have added two items to vote on: - add collaborative editing: changes made to a file show up in another Vim in a second - add flexible tab stops, can be used for tables I'd like to see something simpler(?): better command line completion of built-in commands. You can script user defined commands as you wish to perform all magic but completion of many built-in commands is really dumb. For example I am working lately with Tab Separated Values. When I try to insert Tab into regular expression of vimgrep Vim constantly tries to resolve it to file name. I have to resort to C-VC-I. m. To search for a hard tab, use \t in the pattern. Currently, :command can have at most one -complete= parameter. I suspect this unicity also applies to builtin commands. Best regards, Tony. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Dnia Thursday 17 of January 2008, Bram Moolenaar napisał: Hello Vim users, I have added two items to vote on: - add collaborative editing: changes made to a file show up in another Vim in a second - add flexible tab stops, can be used for tables I'd like to see something simpler(?): better command line completion of built-in commands. You can script user defined commands as you wish to perform all magic but completion of many built-in commands is really dumb. For example I am working lately with Tab Separated Values. When I try to insert Tab into regular expression of vimgrep Vim constantly tries to resolve it to file name. I have to resort to C-VC-I. m. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Tony Mechelynck wrote: Mikolaj Machowski wrote: Dnia Thursday 17 of January 2008, Bram Moolenaar napisał: Hello Vim users, I have added two items to vote on: - add collaborative editing: changes made to a file show up in another Vim in a second - add flexible tab stops, can be used for tables I'd like to see something simpler(?): better command line completion of built-in commands. You can script user defined commands as you wish to perform all magic but completion of many built-in commands is really dumb. For example I am working lately with Tab Separated Values. When I try to insert Tab into regular expression of vimgrep Vim constantly tries to resolve it to file name. I have to resort to C-VC-I. m. To search for a hard tab, use \t in the pattern. Currently, :command can have at most one -complete= parameter. I suspect this unicity also applies to builtin commands. And maybe I'm just dumb, but isn't auto-complete on a regular expression a bit of a silly idea?! If it's so obvious from what you've already typed what it should be completed to, you probably already have enough typed there to do the search... Inserting Tab as ^I isn't auto-complete, but lack thereof, and \t, as Tony points out, is a better way of doing that anyway, even though it involves pressing an extra key. Another way of getting around it would be to use a different key to Tab for your autocomplete (if there's a key you need to enter less often)! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Weird font issue
On Fri, Dec 21, 2007 at 15:36:03 +, Jeff Lanzarotta wrote:
Thanks.
I was messing around with my vimrc file and inadvertently added 'set
digraph'...
I have now turned that feature off...
James Vega [EMAIL PROTECTED] wrote: On Fri, Dec 21, 2007 at 06:12:24AM
-0800, Jeff Lanzarotta wrote:
When I am in insert mode and I do:
'a' then backspace, 'a' then backspace, 'a' then backspace, repeatively,
the character 'a' is replaced with 'å'.
This is happening because you have the 'digraph' option enabled. When
this option is enabled, you can input unicode characters by typing
{char1} {char2} instead of using {char1}{char2}. This is
described at :help 'digraphs'.
James
--
Jeff Lanzarotta, your quoting mechanism cripples the text portion of the
message that you quoted. It said: {char1} BS {char2} instead of ...
and now it reads {char1} {char2} instead of
Adri
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug? Session loading may scroll up needlessly high
Tony Mechelynck schrieb: Session loading may scroll up needlessly high The cursor line is always scrolled to the top of the window (plus 'scrolloff' if set), regardless of whether there are additional lines (and how many of them) after it. Reproducible: Always Steps to reproduce: 1. Edit (or view) a file which is longer than the window size. 2. G -- Note that the cursor is at the bottom of the window space. This is normal. 3. :mks! 4. :qa 5. vim -S Actual result: The cursor line (which is the last line of the file) is now near the top of the window, with a lot of ~ lines (lines after the end of file) below it. Expected result: The bottom line of the file should be at the bottom of the window (as it was at step 2), with no ~ lines showing. Additional info: Happens identically in GUI and Console modes. 'sessionoptions' is at its default value. Workaround: Use gg^O in each window after restarting, where ^O is obtained by hitting ctrl-v ctrl-o This must be done _manually_; :windo normal gg^O will change the current file in all windows. Using: openSUSE Linux 10.3 VIM - Vi IMproved 7.1 (2007 May 12, compiled Jan 17 2008 02:10:07) Included patches: 1-231 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): [...] It happened the same way at earlier patchlevels. I just thought I'd report it. Best regards, Tony. I cannot reproduce the problem with gVim 7.1.203 on Win32 (Big version with GUI). I checked with gvim -u NONE -U NONE -i NONE -N for :mks!, and gvim -u NONE -U NONE -i NONE -N -S to load the session. I tested three different files (a 1370, 135, 40 lines). After step 5, the cursor is always at the bottom (as expected). -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug? Session loading may scroll up needlessly high
Tony Mechelynck schrieb: Tony Mechelynck schrieb: Session loading may scroll up needlessly high The cursor line is always scrolled to the top of the window (plus 'scrolloff' if set), regardless of whether there are additional lines (and how many of them) after it. Reproducible: Always Steps to reproduce: 1. Edit (or view) a file which is longer than the window size. 2. G -- Note that the cursor is at the bottom of the window space. This is normal. 3. :mks! 4. :qa 5. vim -S Actual result: The cursor line (which is the last line of the file) is now near the top of the window, with a lot of ~ lines (lines after the end of file) below it. Expected result: The bottom line of the file should be at the bottom of the window (as it was at step 2), with no ~ lines showing. I'm posting my Session.vim, which is not for the minimum testcase, as http://users.skynet.be/antoine.mechelynck/vim/Session.vim Best regards, Tony. I can reproduce it with your Session.vim (ah, it enables rolodex mode) -- by creating dummy folders and files, changing some options that produced errors: guifont, printfont, tabline. After another :mks! and restart with -S, the problem still persists ... -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Vim crashes when completing arguments to an user defined command in the cmdline window
Hi all, I am observing that Vim crashes when trying to complete the arguments to an user defined command in the cmdline window. I see this with Vim 7.1.180. To reproduce this crash, use the following sample code: crash.vim - function! s:Myfunc(ArgLead, CmdLine, CursorPos) return [apple, orange, grapes] endfunction command! -nargs=1 -complete=customlist,s:Myfunc Crashvim :echo 'args' - After sourcing the above file, open the cmdline window using q:'. In the cmdline window, enter the Crashvim command and then try to complete the arguments to the command by pressing Tab. Now Vim crashes with the following traceback: Program received signal SIGSEGV, Segmentation fault. 0x00072c00 in call_user_expand_func (user_expand_func=0x4b774 call_func_retlist, xp=0x1cc924, num_file=0xffbee138, file=0xffbee134) at ex_getln.c:4669 4669keep = ccline.cmdbuff[ccline.cmdlen]; (cisco-6.1.0-gdb) bt #0 0x00072c00 in call_user_expand_func (user_expand_func=0x4b774 call_func_retlist, xp=0x1cc924, num_file=0xffbee138, file=0xffbee134) at ex_getln.c:4669 #1 0x000735d4 in ExpandFromContext (xp=0x1cc924, pat=0x392f70 ^, num_file=0xffbee138, file=0xffbee134, options=-4267724) at ex_getln.c:4758 #2 0x00073b3c in expand_cmdline (xp=0x1cc924, str=0x37b310 Crashvim , col=3747696, matchcount=0xffbee138, matches=0xffbee134) at ex_getln.c:4228 #3 0x0002a804 in ins_compl_next (allow_get_expansion=1, count=0, insert_match=1) at edit.c:4010 #4 0x0002b368 in ins_complete (c=22) at edit.c:4585 #5 0x00030df8 in edit (cmdchar=1912832, startln=1911808, count=1) at edit.c:1338 #6 0x000e5310 in op_change (oap=0xffbee5f8) at ops.c:2598 #7 0x000dc548 in do_pending_operator (cap=0xffbee548, old_col=0, gui_yank=0) at normal.c:1909 #8 0x000dd88c in normal_cmd (oap=0xffbee5f8, toplevel=1) at normal.c:1174 #9 0x0009c5c0 in main_loop (cmdwin=1, noexmode=0) at main.c:1181 #10 0x00078e6c in getcmdline (firstc=58, count=1, indent=0) at ex_getln.c:6052 #11 0x00067e84 in do_cmdline (cmdline=0x0, getline=0x79bd0 getexline, cookie=0x0, flags=0) at ex_docmd.c:995 #12 0x000d9344 in nv_colon (cap=0xffbeedf8) at normal.c:5175 #13 0x000dd808 in normal_cmd (oap=0xffbeeea8, toplevel=1) at normal.c:1148 #14 0x0009c5c0 in main_loop (cmdwin=0, noexmode=0) at main.c:1181 #15 0x000a0764 in main (argc=1911808, argv=0x1) at main.c:940 Is anyone else able to reproduce this crash? - Yegappan --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
