Vim crashes when completing arguments to an user defined command in the cmdline window

[Yegappan Lakshmanan]

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 ''
-

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 .
Now Vim crashes with the following traceback:

Program received signal SIGSEGV, Segmentation fault.
0x00072c00 in call_user_expand_func (user_expand_func=0x4b774
, 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
, 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
, 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
-~--~~~~--~~--~--~---

Re: Bug? Session loading may scroll up needlessly high

[Andy Wokula]

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
-~--~~~~--~~--~--~---

Re: Bug? Session loading may scroll up needlessly high

[Tony Mechelynck]

Andy Wokula wrote:
> 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).
> 

Hm. I have both a vimrc and a viminfo (no gvimrc though), and I am on Linux. I 
wonder what causes the behaviour I see.

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.
-- 
hundred-and-one symptoms of being an internet addict:
242. You turn down a better-paying job because it doesn't come with
  a free e-mail account.


--~--~-~--~~~---~--~~
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

[Ben Schmidt]

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 .
>>
>> 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  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 
 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: Bug? Session loading may scroll up needlessly high

[Andy Wokula]

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: Weird font issue

[Adri Verhoef]

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}  {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: Multiple windows and tabs on the same buffer

[Ben Schmidt]

Tony Mechelynck wrote:
> albiejvr wrote:
>> Nathaniel Whiteinge wrote:
>>> If I have a multiple windows open all viewing different parts of the
>>> same buffer, then open a new tab on that buffer, the cursor position
>>> is reset to the first line in all the windows in that first tab. Is
>>> this normal?
>>>   
>> What command are you using to open the new tab on your buffer? 
>>
>> When I use
>>
>> :tabedit %
>>
>> it positions the cursor at the same position in the file as in the 
>> window where I executed the command from.
>>
>> If I instead use
>>
>> :tabnew
>> :e filename.txt
>>
>> the cursor seems to be automatically positioned at the highest (furthest 
>> down the file) line number that I have the buffer already open at.
>>
>> There is probably some setting to determine the cursor position in a 
>> newly-opened file, but I don't know it.
> 
> With the autocommand defined at lines 66sqq of $VIMRUNTIME/vimrc_example.vim, 
> ":e filename.txt" places the cursor wherever it was when you latest edited 
> that file:
> 
>" When editing a file, always jump to the last known cursor position.
>" Don't do it when the position is invalid or when inside an event handler
>" (happens when dropping a file on gvim).
>autocmd BufReadPost *
>  \ if line("'\"") > 0 && line("'\"") <= line("$") |
>  \   exe "normal! g`\"" |
>  \ endif

The OP's problem was not where the cursor was placed in the newly opened tab, 
but 
that the cursor moved in his already open tab. That is my experience also, and 
I'm 
sure it would be very annoying. The problem only occurs if you open the new tab 
page editing a file in your current tab page using a single command (e.g. 
:tabedit 
% or :tabedit and giving a filename of a currently displayed file). After the 
new 
tab has appeared, with the cursor positioned as expected, do a gt (or a few) to 
return to your original tab and you will find all the windows editing that file 
have scrolled to line 1. This is surely a bug. CCing vim_dev.

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
-~--~~~~--~~--~--~---

[Alpha/Gcc] compiler warning for Vim 7.1.230

[Adri Verhoef]

Compilation of Vim 7.1.230 on an Alpha processor with Gcc yielded:

gui_motif.c: In function 'find_replace_dialog_create':
gui_motif.c:3816: warning: cast to pointer from integer of different size

Installation went fine.
The warning may not be exclusively tied to Vim 7.1.230, I skipped a few
versions before this one.

Adri

--~--~-~--~~~---~--~~
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]

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 .
> 
> 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

[Mikolaj Machowski]

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 .

m.


--~--~-~--~~~---~--~~
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

[Szabolcs]

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 , 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: .nb files are Mathematica notebooks

[Bram Moolenaar]

Szabolcs wrote:

> Currently only *.m files are recognized as mma filetype
> (Mathematica).  *.nb files can also be safely linked to the mma file
> type, as Mathematica notebooks just contain one big Mathematica
> expression.
> 
> Of course one does not normally edit raw notebook files with a text
> editor, but syntax colouring is useful for reading them.

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?

-- 
"Software is like sex... it's better when it's free."
-- Linus Torvalds, initiator of the free Linux OS
Makes me wonder what FSF stands for...?

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

--~--~-~--~~~---~--~~
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

[Tony Mechelynck]

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
-~--~~~~--~~--~--~---

vim_dev@googlegroups.com

[Yegappan Lakshmanan]

On Jan 17, 2008 2:20 AM, Richard Hartmann <[EMAIL PROTECTED]> wrote:
> 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
>

3) It is in the todo list:

-   Add COLUMN NUMBERS to ":" commands ":line1,line2[col1,col2]cmd".  Block
can be selected with CTRL-V.  Allow '$' (end of line) for col2.
7   CTRL-V :s should substitute only in the block, not to whole lines. (David
Young is working on this)
7   Filtering a block should only apply to the block, not to the whole lines.
When the number of lines is increased, add lines. When decreased, pad with
spaces or delete? Use ":`<,`>" on the command line.
6   ":left" and ":right" should work in Visual block mode.
7   Substitute in a block of text.  Use {line}.{column} notation in an Ex
range, e.g.: ":1.3,$.5s" means to substitute from line 1 column 3 to the
last line column 5.
8   Add put command that replaces the text under it.  Esp. for blockwise
Visual mode.

This will be a useful feature to add compared to the support for parallel
editing of the same file.

- Yegappan

--~--~-~--~~~---~--~~
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.

[Dominique Pelle]

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
-~--~~~~--~~--~--~---

Re: Patch 7.1.230

[Richard Hartmann]

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.

[Richard Hartmann]

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: .nb files are Mathematica notebooks

[thomas]

> (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
-~--~~~~--~~--~--~---

vim_dev@googlegroups.com

[Richard Hartmann]

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
-~--~~~~--~~--~--~---