On 31/10/07 17:43 +0100, Vladimir Marek wrote:
>
>============================ os_unix.c:6652 ============================
>    /* file names are separated with Space */
>    if (shell_style == STYLE_ECHO)
>    {
> buffer[len] = '\n';  /* make sure the buffer ends in NL */
> p = buffer;
> for (i = 0; *p != '\n'; ++i) /* count number of entries */
> {
>     while (*p != ' ' && *p != '\n')
>  ++p;
>     p = skipwhite(p);  /* skip to next entry */
> }
>    }
>========================================================================
>
>and since the string was "/a/b/c 'd" it's separated to two files -
>/a/b/c and 'd
>
>If I'm right with my investigation, I feel that the result is wrong. If
>there is really file called "/a/b/c 'd" expand should return "/a/b/c 'd"
>as one string.
>
>Thanks
>

This kind of glob depends on your 'shell' option, try 'csh' instead
whose glob command is better than the 'echo' of POSIX sh.

Or maybe you are interested in the patch I post to dev sometime ago.

--
Dasn


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

[ ... ]

> This kind of glob depends on your 'shell' option, try 'csh' instead
> whose glob command is better than the 'echo' of POSIX sh.
>
> Or maybe you are interested in the patch I post to dev sometime ago.

I see now. The final goal is function which would tell me what files are
in given directory. That's why I started to use glob. To be as correct
as possible I started to write my wrapper function. So far it is:

Unfortunately, it does not catch hidden files on windows :(

fu! Glob(pattern)
	 try
		 if !has('unix')
			 " Windows ... Can anything else fall here which is not apropriate ?
			 let l:res=glob(a:pattern)
			 break

		 if match(&shell, '\(^\|/\)t\?csh$') >= 0
			 " We do have (t)csh
			 let l:res=glob(a:pattern)
			 break
		 endif

                 if executable('csh') > 0 || executable('tcsh') > 0
			 " We can reach (t)csh, so use it for a while
                         let l:newsh='csh'
                         if ( executable('csh') == 0 )
                                 let l:newsh='tcsh'
                         endif

                         let l:sh=&shell

                         try
                                 exe "set shell=".l:newsh
                                 let l:res=glob(a:pattern)
                         finally
				 " Don't clobber the &shell variable
                                 exe "set shell=".l:sh
                         endtry
			 break
		 endif

                 if match(&shell, '\(^\|/\)bash$') >= 0
			 " Bash way of getting all the files (works for bash 2 newer)
                         let l:pat=substitute(a:pattern,
'\([^[:alnum:]\*\?/_-]\)', '\\\1', "g")
                         let l:res=system("shopt -s nullglob; for a in ".l:pat.";
do echo \"$a\"; done")
			 break
                 endif

		 if executable('python')
			 " Python is common these days (Perl default glob implementation sucks)
			 let l:res=system ('python', "import glob\nfor i in
glob.glob('".escape(a:pattern,"'\\")."'):\n print i")
			 break
		 endif

		 " Fallback to default
                 let l:res=glob(a:pattern)
         endtry
         return split (l:res, "\n")
endf

I tested it on linux, solaris 8, solaris 10 and windows.

Thank you for your input

--
	 Vlad

Its true that today world is Internet world,every thing is globelised,differences go away
WE gave you our service on your pay demand,if you want to advertise your product,website,yourself profile or any thing you want,we advertise you in whole world,just contact us and try our sevice

Hello,

   Given below is information (uname -a, cat /proc/cpuinfo, vim
   version) on two machines named crash_machine and recover_machine.

   Bug:  On recover_machine, vim refuses to read a swp file created
         on crash_machine.

   crash_machine>uname -a

   Linux 2.6.18-1.2257.fc5 #1 SMP Fri Dec 15 16:07:14 EST 2006 x86_64
   x86_64 x86_64 GNU/Linux

   crash_machine>cat /proc/cpuinfo
   processor       : 0
   vendor_id       : GenuineIntel
   cpu family      : 15
   model           : 4
   model name      : Intel(R) Xeon(TM) CPU 3.20GHz
   stepping        : 3
   cpu MHz         : 3200.194
   cache size      : 2048 KB
   physical id     : 0
   siblings        : 2
   core id         : 0
   cpu cores       : 1
   fpu             : yes
   fpu_exception   : yes
   cpuid level     : 5
   wp              : yes
   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
                     pge mca cmov pat pse36 clflush dts acpi mmx fxsr
                     sse sse2 ss ht tm syscall lm constant_tsc pni
                     monitor ds_cpl cid cx16 xtpr
   bogomips        : 6403.81
   clflush size    : 64
   cache_alignment : 128
   address sizes   : 36 bits physical, 48 bits virtual
   power management:
   processor       : 1
   vendor_id       : GenuineIntel
   cpu family      : 15
   model           : 4
   model name      : Intel(R) Xeon(TM) CPU 3.20GHz
   stepping        : 3
   cpu MHz         : 3200.194
   cache size      : 2048 KB
   physical id     : 0
   siblings        : 2
   core id         : 0
   cpu cores       : 1
   fpu             : yes
   fpu_exception   : yes
   cpuid level     : 5
   wp              : yes
   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
                     pge mca cmov pat pse36 clflush dts acpi mmx fxsr
                     sse sse2 ss ht tm syscall lm constant_tsc pni
                     monitor ds_cpl cid cx16 xtpr
   bogomips        : 6399.39
   clflush size    : 64
   cache_alignment : 128
   address sizes   : 36 bits physical, 48 bits virtual
   power management:

   crash_machine> vim --version
   VIM - Vi IMproved 7.0 (2006 May 7, compiled Jul 25 2006 10:55:29)
   Included patches: 1-4, 7-17, 19-26, 29-31, 33-42
   Modified by <bugzilla@...>
   Compiled by <bugzilla@...>
   Huge version without GUI.  Features included (+) or not (

   recover_machine>uname -a

   Linux 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:46 EST 2006 i686
   i686 i386 GNU/Linux

   recover_machine>cat /proc/cpuinfo

   processor       : 0
   vendor_id       : GenuineIntel
   cpu family      : 15
   model           : 4
   model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
   stepping        : 3
   cpu MHz         : 2992.859
   cache size      : 2048 KB
   physical id     : 0
   siblings        : 1
   core id         : 0
   cpu cores       : 1
   fdiv_bug        : no
   hlt_bug         : no
   f00f_bug        : no
   coma_bug        : no
   fpu             : yes
   fpu_exception   : yes
   cpuid level     : 5
   wp              : yes
   flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge
                     mca cmov pat pse36 clflush dts acpi mmx fxsr sse
                     sse2 ss ht tm pbe lm constant_tsc up pni monitor
                     ds_cpl est cid cx16 xtpr
   bogomips        : 5989.43

   recover_machine> vim
   VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 28 2006 23:02:04)
   Included patches: 1, 3-4, 7-9, 11, 13-17, 19-26, 29-31, 34-44, 47,
                     50-56, 58-64, 66-73, 75, 77-92, 94-107, 109
   Modified by <bugzilla@...>
   Compiled by <bugzilla@...>
   Huge version without GUI.  Features included (+) or not (-):

   Thanks,

   --Suresh


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Its true that today world is Internet world,every thing is globelised,differences go away
WE gave you our service on your pay demand,if you want to advertise your product,website,yourself profile or any thing you want,we advertise you in whole world,just contact us and try our sevice

To reproduce:

vim -u NONE -U NONE
:set ignorecase infercase
ia<CR><CR><C-X><C-L><C-X><C-L>

After the first <C-X><C-L>, we have
1. "a"
2. ""
3. "a"

the 2nd <C-X><C-L> tries to complete the string on line 2.  This
results in a place where we try to allocate 0 space to hold an empty
string (at edit.c:2151).

The fix is as easy as the explanation; we just add a new condition
that results in skipping case inference for an empty string.

2114c2114
<     if (p_ic && curbuf->b_p_inf)
---
>     if (p_ic && curbuf->b_p_inf && len > 0)

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

It's possible to craft a malformed .swp file that causes vim to crash
in a way that completely locks up a terminal.

Here's what was on my screen when it occurred:


E325: ATTENTION
Found a swap file by the name ".Accounting.pm.swp"
           owned by: root   dated: Sat Nov  3 04:36:39 2007
          file name: /usr/local/bin/Accounting.pm
           modified: no
          user name: root   host name: ***
         process ID: 5936
While opening file "Accounting.pm"
              dated: Sat Nov  3 03:57:44 2007

(1) Another program may be editing the same file.
     If this is the case, be careful not to end up with two
     different instances of the same file when making changes.
     Quit, or continue with caution.

(2) An edit session for this file crashed.
     If this is the case, use ":recover" or "vim -r Accounting.pm"
     to recover the changes (see ":help recovery").
     If you did this already, delete the swap file ".Accounting.pm.swp"
     to avoid this message.

Swap file ".Accounting.pm.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort, (D)elete it:

"Accounting.pm" 2059L, 113828C
Using swap file ".Accounting.pm.swp"
Original file "/usr/local/bin/src/Accounting/lib/Accounting.pm"
*** glibc detected *** double free or corruption (!prev): 0x0926fd60 ***
                                                                         Recovery
completed. You should check if everything is OK.
(You might want to write out this file under another name
and run diff with the original file to check for changes)
Delete the .swp file afterwards.

Vim: Caught deadly signal ABRT

(at this point - the terminal is completely locked up - ^C etc all
have no effect.  kill also has no effect.  kill-9 from another session
ended it OK)

------------------------
Here's some version info
------------------------

                  VIM - Vi IMproved

                    version 6.3.82
               by Bram Moolenaar et al.
          Modified by <bugzilla@...>
     Vim is open source and freely distributable

            Help poor children in Uganda!
    type  :help iccf<Enter>       for information

    type  :q<Enter>               to exit
    type  :help<Enter>  or  <F1>  for on-line help
    type  :help version6<Enter>   for version info

------------------------
Here's some version info
------------------------

I think vim is used for lots of things, including at least editing
crontab files (after copy stuff to /tmp) - thus - a malicious local
user could place crafted .swp files in /tmp (or elsewhere that they
might have access to) to "crash" (DoS) anyone elses future VIM
sessions.  Depending on the error - it might be possible to exploit
this to run arbitrary code elevated to the vim users permissions (the
error reports as *either* "double free" (hard to exploit) or
"corruption" (probably a buffer overflow - easy to exploit))

Kind Regards,
Chris Drake



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hello,

Vim presently associates *.phtml files with PHP/FI (a.k.a. PHP 2) syntax
highlighting, although realistically I doubt anybody uses it[1][2].
Instead, the "php" filetype handles PHP versions 3 and above.

Increasingly, however, I believe the ".phtml" extension is used by PHP
5-based web applications.  For example, apps based on the Zend Framework
typically use it for the "view" part of front controller MVC.

I have the following suggestion:

    1. Remove syntax/phtml.vim.

    2. Change *.phtml association in filetype.vim to associate with php
       filetype instead.

    3. Amend synmenu.vim so there's only one PHP menu item, just called
       "PHP".  This might also be a good time to update "Cold Fusion" to
       "ColdFusion" (no space in name).

Many Thanks,

Dave

[1] It was released in 1995, the same time we were all being wowed by
      Netscape Navigator 1.1!  :o)  PHP 3 superseded it in 1997.
[2]
http://www.nexen.net/chiffres_cles/phpversion/17377-php_statistics_for_july_2007\
.php#versions

--
                                  Save the whales.  Collect the whole set.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Out of courtesy I've emailed Lutz Eymers (last known phtml.vim
maintainer) and Peter Hodge (syntax/php.vim) with a pointer to this
message.  However the mail to Lutz failed ("mailbox disabled for this
recipient").

Regards,

Dave

--
                                  Save the whales.  Collect the whole set.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Chris Drake wrote:
> Hi,
>
> It's possible to craft a malformed .swp file that causes vim to crash
> in a way that completely locks up a terminal.
>
> Here's what was on my screen when it occurred:
>
>
> E325: ATTENTION
> Found a swap file by the name ".Accounting.pm.swp"
>           owned by: root   dated: Sat Nov  3 04:36:39 2007
>          file name: /usr/local/bin/Accounting.pm
>           modified: no
>          user name: root   host name: ***
>         process ID: 5936
> While opening file "Accounting.pm"
>              dated: Sat Nov  3 03:57:44 2007
>
> (1) Another program may be editing the same file.
>     If this is the case, be careful not to end up with two
>     different instances of the same file when making changes.
>     Quit, or continue with caution.
>
> (2) An edit session for this file crashed.
>     If this is the case, use ":recover" or "vim -r Accounting.pm"
>     to recover the changes (see ":help recovery").
>     If you did this already, delete the swap file ".Accounting.pm.swp"
>     to avoid this message.
>
> Swap file ".Accounting.pm.swp" already exists!
> [O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort, (D)elete it:
>
> "Accounting.pm" 2059L, 113828C
> Using swap file ".Accounting.pm.swp"
> Original file "/usr/local/bin/src/Accounting/lib/Accounting.pm"
> *** glibc detected *** double free or corruption (!prev): 0x0926fd60 ***
>                                                                        
Recovery completed. You should check if everything is OK.
> (You might want to write out this file under another name
> and run diff with the original file to check for changes)
> Delete the .swp file afterwards.
>
> Vim: Caught deadly signal ABRT
>
> (at this point - the terminal is completely locked up - ^C etc all
> have no effect.  kill also has no effect.  kill-9 from another session
> ended it OK)
>
> ------------------------
> Here's some version info
> ------------------------
>
>                  VIM - Vi IMproved
>
>                    version 6.3.82
>               by Bram Moolenaar et al.
>          Modified by <bugzilla@...>
>     Vim is open source and freely distributable
>
>            Help poor children in Uganda!
>    type  :help iccf<Enter>       for information
>
>    type  :q<Enter>               to exit
>    type  :help<Enter>  or  <F1>  for on-line help
>    type  :help version6<Enter>   for version info
>
> ------------------------
> Here's some version info
> ------------------------
>
> I think vim is used for lots of things, including at least editing
> crontab files (after copy stuff to /tmp) - thus - a malicious local
> user could place crafted .swp files in /tmp (or elsewhere that they
> might have access to) to "crash" (DoS) anyone elses future VIM
> sessions.  Depending on the error - it might be possible to exploit
> this to run arbitrary code elevated to the vim users permissions (the
> error reports as *either* "double free" (hard to exploit) or
> "corruption" (probably a buffer overflow - easy to exploit))
>
> Kind Regards,
> Chris Drake

I seem to semember that something like that was fixed long ago, but my memory
is hazy. Could you reproduce it with some "decently recent" version?

You might want to peruse the lists of patches:

http://ftp.vim.org/pub/vim/patches/6.3/README
http://ftp.vim.org/pub/vim/patches/6.4/README
http://ftp.vim.org/pub/vim/patches/7.0/README
http://ftp.vim.org/pub/vim/patches/7.1/README

FYI, 6.3.082 dates from 5 June 2005. Lots of water went under the bridge since
then. The current version is 7.1.147.


Best regards,
Tony.
--
Impartial, adj.:
	 Unable to perceive any promise of personal advantage from
espousing either side of a controversy or adopting either of two
conflicting opinions.
		 -- Ambrose Bierce, "The Devil's Dictionary"


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi Tony,

Sorry - busy - if I get a free moment, I might have a try.  I did save
the files concerned.

If it helps any - I managed to recover my file by transferring the
file + .swp to an older server, which worked fine.  version 6.3.81 is on
the oldie.

Kind Regards,
Chris Drake


Sunday, November 4, 2007, 1:34:01 AM, you wrote:


TM> Chris Drake wrote:
>> Hi,
>>
>> It's possible to craft a malformed .swp file that causes vim to crash
>> in a way that completely locks up a terminal.
>>
>> Here's what was on my screen when it occurred:
>>
>>
>> E325: ATTENTION
>> Found a swap file by the name ".Accounting.pm.swp"
>>           owned by: root   dated: Sat Nov  3 04:36:39 2007
>>          file name: /usr/local/bin/Accounting.pm
>>           modified: no
>>          user name: root   host name: ***
>>         process ID: 5936
>> While opening file "Accounting.pm"
>>              dated: Sat Nov  3 03:57:44 2007
>>
>> (1) Another program may be editing the same file.
>>     If this is the case, be careful not to end up with two
>>     different instances of the same file when making changes.
>>     Quit, or continue with caution.
>>
>> (2) An edit session for this file crashed.
>>     If this is the case, use ":recover" or "vim -r Accounting.pm"
>>     to recover the changes (see ":help recovery").
>>     If you did this already, delete the swap file ".Accounting.pm.swp"
>>     to avoid this message.
>>
>> Swap file ".Accounting.pm.swp" already exists!
>> [O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort, (D)elete it:
>>
>> "Accounting.pm" 2059L, 113828C
>> Using swap file ".Accounting.pm.swp"
>> Original file "/usr/local/bin/src/Accounting/lib/Accounting.pm"
>> *** glibc detected *** double free or corruption (!prev): 0x0926fd60 ***
>>
>> Recovery completed. You should check if everything is OK.
>> (You might want to write out this file under another name
>> and run diff with the original file to check for changes)
>> Delete the .swp file afterwards.
>>
>> Vim: Caught deadly signal ABRT
>>
>> (at this point - the terminal is completely locked up - ^C etc all
>> have no effect.  kill also has no effect.  kill-9 from another session
>> ended it OK)
>>
>> ------------------------
>> Here's some version info
>> ------------------------
>>
>>                  VIM - Vi IMproved
>>
>>                    version 6.3.82
>>               by Bram Moolenaar et al.
>>          Modified by <bugzilla@...>
>>     Vim is open source and freely distributable
>>
>>            Help poor children in Uganda!
>>    type  :help iccf<Enter>       for information
>>
>>    type  :q<Enter>               to exit
>>    type  :help<Enter>  or  <F1>  for on-line help
>>    type  :help version6<Enter>   for version info
>>
>> ------------------------
>> Here's some version info
>> ------------------------
>>
>> I think vim is used for lots of things, including at least editing
>> crontab files (after copy stuff to /tmp) - thus - a malicious local
>> user could place crafted .swp files in /tmp (or elsewhere that they
>> might have access to) to "crash" (DoS) anyone elses future VIM
>> sessions.  Depending on the error - it might be possible to exploit
>> this to run arbitrary code elevated to the vim users permissions (the
>> error reports as *either* "double free" (hard to exploit) or
>> "corruption" (probably a buffer overflow - easy to exploit))
>>
>> Kind Regards,
>> Chris Drake

TM> I seem to semember that something like that was fixed long ago, but my
memory
TM> is hazy. Could you reproduce it with some "decently recent" version?

TM> You might want to peruse the lists of patches:

TM> http://ftp.vim.org/pub/vim/patches/6.3/README
TM> http://ftp.vim.org/pub/vim/patches/6.4/README
TM> http://ftp.vim.org/pub/vim/patches/7.0/README
TM> http://ftp.vim.org/pub/vim/patches/7.1/README

TM> FYI, 6.3.082 dates from 5 June 2005. Lots of water went under the bridge
since
TM> then. The current version is 7.1.147.


TM> Best regards,
TM> Tony.




--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi Chris

Vim-6.3.81 in which you reported the bug is quite old. My guess is that
the bug is likely to have been fixed in a more recent version of vim, with
all latest patches.  However, if you still have the offending .swp file (and
if it's ok to share it), it might be interesting to send it, to double
check that
the bug does not happen in latest vim.

-- Dominique

On 11/4/07, Chris Drake <christopher@...> wrote:
>
> Hi Tony,
>
> Sorry - busy - if I get a free moment, I might have a try.  I did save
> the files concerned.
>
> If it helps any - I managed to recover my file by transferring the
> file + .swp to an older server, which worked fine.  version 6.3.81 is on
> the oldie.
>
> Kind Regards,
> Chris Drake
>
>
> Sunday, November 4, 2007, 1:34:01 AM, you wrote:
>
>
> TM> Chris Drake wrote:
> >> Hi,
> >>
> >> It's possible to craft a malformed .swp file that causes vim to crash
> >> in a way that completely locks up a terminal.
> >>
> >> Here's what was on my screen when it occurred:

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.1.148
Problem:    Some types are not found by configure.
Solution:   Test for the sys/types.h header file. (Sean Boudreau)
Files:     src/configure.in, src/auto/configure


*** ../vim-7.1.147/src/configure.in Thu Jun 28 13:02:22 2007
--- src/configure.in Sat Oct 27 15:52:16 2007
***************
*** 2026,2032 ****
   fi

   AC_CHECK_HEADERS(stdarg.h stdlib.h string.h sys/select.h sys/utsname.h \
!  termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h termio.h \
  	 iconv.h langinfo.h unistd.h stropts.h errno.h \
  	 sys/resource.h sys/systeminfo.h locale.h \
  	 sys/stream.h sys/ptem.h termios.h libc.h sys/statfs.h \
--- 2026,2032 ----
   fi

   AC_CHECK_HEADERS(stdarg.h stdlib.h string.h sys/select.h sys/utsname.h \
!  termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h sys/types.h termio.h \
  	 iconv.h langinfo.h unistd.h stropts.h errno.h \
  	 sys/resource.h sys/systeminfo.h locale.h \
  	 sys/stream.h sys/ptem.h termios.h libc.h sys/statfs.h \
*** ../vim-7.1.147/src/auto/configure Thu Jun 28 13:02:22 2007
--- src/auto/configure Sun Nov  4 15:34:14 2007
***************
*** 10265,10272 ****



   for ac_header in stdarg.h stdlib.h string.h sys/select.h sys/utsname.h \
!  termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h termio.h \
  	 iconv.h langinfo.h unistd.h stropts.h errno.h \
  	 sys/resource.h sys/systeminfo.h locale.h \
  	 sys/stream.h sys/ptem.h termios.h libc.h sys/statfs.h \
--- 10265,10273 ----



+
   for ac_header in stdarg.h stdlib.h string.h sys/select.h sys/utsname.h \
!  termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h sys/types.h termio.h \
  	 iconv.h langinfo.h unistd.h stropts.h errno.h \
  	 sys/resource.h sys/systeminfo.h locale.h \
  	 sys/stream.h sys/ptem.h termios.h libc.h sys/statfs.h \
*** ../vim-7.1.147/src/version.c Tue Oct 30 17:36:31 2007
--- src/version.c Sun Nov  4 15:34:26 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     148,
   /**/

--
If your nose runs, and your feet smell, you might be upside down.

  /// Bram Moolenaar -- Bram@... -- 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
-~----------~----~----~----~------~----~------~--~---

Hi,

I'd like to request a feature in Vim which would be useful not very often but
is very important I think.

Usually I don't lose information in Vim. You can undo things, you can restore
the file from a backup etc. There is only one situation which led me to
information loss several times. This situation happens when I have a file with
modifications opened in Vim and then I also change this file by accident
outside of Vim. In this case Vim shows a message box with 2 buttons: reload
file or don't reload file. Several times I pressed "reload file" by accident.
And my changes in Vim were lost! Undo didn't work after that.

I don't know if it's difficult to implement but it would be great if undo
worked after such reload. And this would be useful not only for "by accident"
cases - I could also press "reload" just to see what those external changes are
and then undo if I don't need them.

P.S. Persistent undo would be great too. :)


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Chris Drake wrote:

> It's possible to craft a malformed .swp file that causes vim to crash
> in a way that completely locks up a terminal.

I can't do much without such a .swp file.  To be able to reproduce the
problem I would need both the original file and the .swp file that has
the problem.

Your text suggests that you know how to make a .swp file that causes the
problem.  Please share that with me.  Don't send to the list if you
think this may help malicious people to misuse the info.

6.3.82 is quite old, it's very well possible that the problem got fixed
in the mean time.  Can you reproduce the problem with Vim 7.1?  The swap
file should be compatible.

> Vim: Caught deadly signal ABRT
>
> (at this point - the terminal is completely locked up - ^C etc all
> have no effect.  kill also has no effect.  kill-9 from another session
> ended it OK)

You may need to reset the terminal (in xterm that's done by pressing
CTRL and the middle mouse button, select "Do Full reset").  Sometimes
typing "reset<CR>reset<CR>" works.  Vim switches off echo, so you may
not see what you type.

> ------------------------
> Here's some version info
> ------------------------
>
> I think vim is used for lots of things, including at least editing
> crontab files (after copy stuff to /tmp) - thus - a malicious local
> user could place crafted .swp files in /tmp (or elsewhere that they
> might have access to) to "crash" (DoS) anyone elses future VIM
> sessions.  Depending on the error - it might be possible to exploit
> this to run arbitrary code elevated to the vim users permissions (the
> error reports as *either* "double free" (hard to exploit) or
> "corruption" (probably a buffer overflow - easy to exploit))

I think that would be really hard to do, but it can't be ruled out.

--
hundred-and-one symptoms of being an internet addict:
88. Every single time you press the 'Get mail' button...it does get new mail.

  /// Bram Moolenaar -- Bram@... -- 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
-~----------~----~----~----~------~----~------~--~---

Matthew Wozniski wrote:

> To reproduce:
>
> vim -u NONE -U NONE
> :set ignorecase infercase
> ia<CR><CR><C-X><C-L><C-X><C-L>
>
> After the first <C-X><C-L>, we have
> 1. "a"
> 2. ""
> 3. "a"
>
> the 2nd <C-X><C-L> tries to complete the string on line 2.  This
> results in a place where we try to allocate 0 space to hold an empty
> string (at edit.c:2151).
>
> The fix is as easy as the explanation; we just add a new condition
> that results in skipping case inference for an empty string.
>
> 2114c2114
> <     if (p_ic && curbuf->b_p_inf)
> ---
> >     if (p_ic && curbuf->b_p_inf && len > 0)

Thanks for the clear explanation.  And this looks like the right way to
fix this.

--
hundred-and-one symptoms of being an internet addict:
85. Choice between paying Compuserve bill and paying for kids education
     is a no brainer -- although a bit painful for your kids.

  /// Bram Moolenaar -- Bram@... -- 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
-~----------~----~----~----~------~----~------~--~---

Alexei Alexandrov schrieb:
> Hi,
>
> I'd like to request a feature in Vim which would be useful not very often but
> is very important I think.
>
> Usually I don't lose information in Vim. You can undo things, you can restore
> the file from a backup etc. There is only one situation which led me to
> information loss several times. This situation happens when I have a file with
> modifications opened in Vim and then I also change this file by accident
> outside of Vim. In this case Vim shows a message box with 2 buttons: reload
> file or don't reload file. Several times I pressed "reload file" by accident.
> And my changes in Vim were lost! Undo didn't work after that.
>
> I don't know if it's difficult to implement but it would be great if undo
> worked after such reload. And this would be useful not only for "by accident"
> cases - I could also press "reload" just to see what those external changes
are
> and then undo if I don't need them.
>
> P.S. Persistent undo would be great too. :)

You can try a workaround with
     :h DiffOrig
     :h FileChangedShell

au FileChangedShell * call DiffSync()

func! DiffSync()
     " :DiffOrig
     vert new
     set buftype=nofile
     read #
     0delete _
     diffthis
     wincmd p
     diffthis

     wincmd p
     %diffput
     close

     diffoff
endfunc

Diffing against the changed file on disk adds the changes to the undo
history.

When writing the file you'll get a
     WARNING: The file has been changed since reading it!!!
of course -- the function does not reload the file.

As  :h FileChangedShell  states:
| NOTE: The commands must not change the current
| buffer, jump to another buffer or delete a
| buffer.  *E246*

Trying the function I didn't get any errors though.

--
Andy


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Dave Hodder wrote:

> Vim presently associates *.phtml files with PHP/FI (a.k.a. PHP 2) syntax
> highlighting, although realistically I doubt anybody uses it[1][2].
> Instead, the "php" filetype handles PHP versions 3 and above.
>
> Increasingly, however, I believe the ".phtml" extension is used by PHP
> 5-based web applications.  For example, apps based on the Zend Framework
> typically use it for the "view" part of front controller MVC.
>
> I have the following suggestion:
>
>    1. Remove syntax/phtml.vim.
>
>    2. Change *.phtml association in filetype.vim to associate with php
>       filetype instead.
>
>    3. Amend synmenu.vim so there's only one PHP menu item, just called
>       "PHP".  This might also be a good time to update "Cold Fusion" to
>       "ColdFusion" (no space in name).
>
> Many Thanks,
>
> Dave
>
> [1] It was released in 1995, the same time we were all being wowed by
>      Netscape Navigator 1.1!  :o)  PHP 3 superseded it in 1997.
> [2]
>
http://www.nexen.net/chiffres_cles/phpversion/17377-php_statistics_for_july_2007\
.php#versions


I don't know about the use of PHP in .phtml files.  I thought they were
always called *.php.  Opinions?

I don't delete an existing syntax file unless it is completely useless.

--
hundred-and-one symptoms of being an internet addict:
91. It's Saturday afternoon in the middle of May and you
     are on computer.

  /// Bram Moolenaar -- Bram@... -- 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
-~----------~----~----~----~------~----~------~--~---

Suresh Govindachar wrote:

>   Given below is information (uname -a, cat /proc/cpuinfo, vim
>   version) on two machines named crash_machine and recover_machine.
>
>   Bug:  On recover_machine, vim refuses to read a swp file created
>         on crash_machine.
>
>   crash_machine>uname -a
>
>   Linux 2.6.18-1.2257.fc5 #1 SMP Fri Dec 15 16:07:14 EST 2006 x86_64
>   x86_64 x86_64 GNU/Linux

[...]

>   recover_machine>uname -a
>
>   Linux 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:46 EST 2006 i686
>   i686 i386 GNU/Linux

One machine is 32 bit, the other 64 bit.  That is different enough for
Vim not to be able to read the .swp file.  For performance reasons Vim
stores "int" and "long" values directly in the .swp file.  Thus byte
order and sizeof() matters.

You might be able to compile a 32 bit Vim on the 64 bit machine and read
the .swp files on both machines.

--
From "know your smileys":
  ;-0 Can't find shift key
  ,-9 Kann Umschalttaste nicht finden

  /// Bram Moolenaar -- Bram@... -- 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
-~----------~----~----~----~------~----~------~--~---

Alexei Alexandrov wrote:

> I'd like to request a feature in Vim which would be useful not very often but
> is very important I think.
>
> Usually I don't lose information in Vim. You can undo things, you can restore
> the file from a backup etc. There is only one situation which led me to
> information loss several times. This situation happens when I have a file with
> modifications opened in Vim and then I also change this file by accident
> outside of Vim. In this case Vim shows a message box with 2 buttons: reload
> file or don't reload file. Several times I pressed "reload file" by accident.
> And my changes in Vim were lost! Undo didn't work after that.
>
> I don't know if it's difficult to implement but it would be great if undo
> worked after such reload. And this would be useful not only for "by accident"
> cases - I could also press "reload" just to see what those external changes
are
> and then undo if I don't need them.

I'll put it in the todo list.  However, don't expect it soon.  I think
the only right way to implement it is to do a diff between the buffer
text and the file that is to be loaded.  The difference would then be
stored as a change in the undo buffer.

> P.S. Persistent undo would be great too. :)

That's already in the todo list.

--
From "know your smileys":
  :~) A man with a tape recorder up his nose

  /// Bram Moolenaar -- Bram@... -- 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
-~----------~----~----~----~------~----~------~--~---

Bram Moolenaar schrieb:
>
> Alexei Alexandrov wrote:
>
>> I'd like to request a feature in Vim which would be useful not very often but
>> is very important I think.
>>
>> Usually I don't lose information in Vim. You can undo things, you can restore
>> the file from a backup etc. There is only one situation which led me to
>> information loss several times. This situation happens when I have a file
with
>> modifications opened in Vim and then I also change this file by accident
>> outside of Vim. In this case Vim shows a message box with 2 buttons: reload
>> file or don't reload file. Several times I pressed "reload file" by accident.
>> And my changes in Vim were lost! Undo didn't work after that.
>>
>> I don't know if it's difficult to implement but it would be great if undo
>> worked after such reload. And this would be useful not only for "by accident"
>> cases - I could also press "reload" just to see what those external changes
are
>> and then undo if I don't need them.
>
> I'll put it in the todo list.  However, don't expect it soon.  I think
> the only right way to implement it is to do a diff between the buffer
> text and the file that is to be loaded.  The difference would then be
> stored as a change in the undo buffer.

Already there (todo.txt from 2007 Oct 30) as well:

8   See ":e" as a change operation, find the changes and add them to the
     undo info.  Needed for when an external tool changes the file.

>> P.S. Persistent undo would be great too. :)
>
> That's already in the todo list.

--
Andy

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

[CCing vim_dev; apologies for my continued disorganised postings!]

OK, folks,

After reading feedback, etc., here is a revised patch. It's just the
documentation
that is different from the previous patch.

In the end, given that a number of things can be done without v:operator, as
Andy
demonstrated, and that Yankring is a pretty specific example, I thought perhaps
the best thing would be to put a brief example analogous to the v:prevcount
example which is right nextdoor in the docs.

If you still think a lengthier example is better, though, Bram, I'm happy to
revise the patch again. I thought this, or a scaled-down count-ignorant version
might be a more useful lengthy example (compared to the function name thing I
suggested before):

	 :" Defines a motion/text-object <C> which allows you to operate on
	 :" the {count}th column of a tab-delimited table, or the column
	 :" the cursor is currently in if no count is given.
	 :onoremap C <Esc>:call OperateColumn()<CR>
	 :function! OperateColumn()
	 :  let c = v:prevcount
	 :  if c == 0
	 :    call search('^\|\t\zs','bc',line("."))
	 :  else
	 :    call cursor(line("."),1)
	 :    while search('\v(\zs[^\t]*(\t|$)){'.c.'}','c',line(".")) == 0
	 :      call setline(line("."),getline(line("."))."\t")
	 :    endwhile
	 :  endif
	 :  call feedkeys('"'.v:register.v:operator)
	 :  if strpart(getline(line('.')),col('.')-1,1) == "\t"
	 :    call feedkeys(":\<CR>")
	 :  else
	 :    call feedkeys(search('\t','n',line(".")) == 0 ? "$" : "t\t")
	 :  endif
	 :endfun

Ben.







--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Index: runtime/doc/eval.txt
===================================================================
--- runtime/doc/eval.txt (revision 621)
+++ runtime/doc/eval.txt (working copy)
@@ -1401,10 +1401,20 @@
 		 This is the screen column number, like with |virtcol()|.  The
 		 value is zero when there was no mouse button click.

+ 			 *v:operator* *operator-variable*
+v:operator The last operator given in Normal mode. This is a single
+  character except for commands starting with <g> or <z>,
+  in which case it is two characters. Best used alongside
+  |v:prevcount| and |v:register|. Useful if you want to cancel
+  Operator-pending mode and then use the operator. >
+ 	 :omap O <Esc>:call MyMotion(v:operator)<CR>
+<  Read-only.
+
 					 *v:prevcount* *prevcount-variable*
  v:prevcount The count given for the last but one Normal mode command.
 		 This is the v:count value of the previous command.  Useful if
-  you want to cancel Visual mode and then use the count. >
+  you want to cancel Visual or Operator-pending mode and then
+  use the count. >
 			 :vmap % <Esc>:call MyFilter(v:prevcount)<CR>
  <  Read-only.

Index: src/vim.h
===================================================================
--- src/vim.h (revision 607)
+++ src/vim.h (working copy)
@@ -1688,7 +1688,8 @@
  #define VV_MOUSE_WIN 49
  #define VV_MOUSE_LNUM   50
  #define VV_MOUSE_COL 51
-#define VV_LEN  52 /* number of v: vars */
+#define VV_OP  52
+#define VV_LEN  53 /* number of v: vars */

  #ifdef FEAT_CLIPBOARD

Index: src/eval.c
===================================================================
--- src/eval.c (revision 607)
+++ src/eval.c (working copy)
@@ -345,6 +345,7 @@
      {VV_NAME("mouse_win",  VAR_NUMBER), 0},
      {VV_NAME("mouse_lnum",  VAR_NUMBER), 0},
      {VV_NAME("mouse_col",  VAR_NUMBER), 0},
+    {VV_NAME("operator",  VAR_STRING), VV_RO},
  };

  /* shorthand */
@@ -17260,6 +17261,35 @@
  }

  /*
+ * Set v:operator if needed.
+ */
+    void
+set_op_var(optype)
+    int  optype;
+{
+    /* This will either be two operator characters, or one and a NUL. */
+    char_u opchars[2];
+
+    if (optype == OP_NOP)
+    {
+ set_vim_var_string(VV_OP, NULL, 0);
+ return;
+    }
+
+    opchars[0] = get_op_char(optype);
+    if (opchars[0] == 'g' || opchars[0] == 'z')
+ opchars[1] = get_extra_op_char(optype);
+    else
+ opchars[1] = 0;
+
+    /* Avoid free/alloc when the value is already right. */
+    if (vimvars[VV_OP].vv_str == NULL ||
+     vimvars[VV_OP].vv_str[0] != opchars[0] ||
+     vimvars[VV_OP].vv_str[1] != opchars[1])
+ set_vim_var_string(VV_OP, opchars, opchars[1]==0?1:2);
+}
+
+/*
   * Get or set v:exception.  If "oldval" == NULL, return the current value.
   * Otherwise, restore the value to "oldval" and return NULL.
   * Must always be called in pairs to save and restore v:exception!  Does not
Index: src/normal.c
===================================================================
--- src/normal.c (revision 607)
+++ src/normal.c (working copy)
@@ -7173,6 +7173,7 @@
 	 {
 	     cap->oap->start = curwin->w_cursor;
 	     cap->oap->op_type = OP_DELETE;
+     set_op_var(OP_DELETE);
 	     cap->count1 = 1;
 	     nv_dollar(cap);
 	     finish_op = TRUE;
@@ -8212,6 +8213,7 @@
      {
 	 cap->oap->start = curwin->w_cursor;
 	 cap->oap->op_type = op_type;
+ set_op_var(op_type);
      }
  }

On 11/4/07, Bram Moolenaar <Bram@...> wrote:
>
> I'll put it in the todo list.  However, don't expect it soon.  I think
> the only right way to implement it is to do a diff between the buffer
> text and the file that is to be loaded.  The difference would then be
> stored as a change in the undo buffer.

Yes, this would be the most correct way. It is also not very easy to
implement perhaps?

>
> > P.S. Persistent undo would be great too. :)
>
> That's already in the todo list.
>
I know actually - this is why the smile is there. Just making sure you
know people need this feature :)

--
Alexei Alexandrov

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hello,

   The following is a post by Brian Dessent on the MinGW-Users
   mailing list.  People thinking about vim and consoles/ptys on
   Windows might find it interesting.

   --Suresh

   >> http://msdn2.microsoft.com/en-us/library/ms740141.aspx
   >
   > So how do I do a 'select' on stdin of the parent and the
   > stdout of the child?

   [following is from Brian Dessent on the MinGW-Users list]

   I'm not sure I quite understand the context here.  If you just
   want to spawn a child process and read its stdout (or write its
   stdin) over a pipe, then you can just use the standard popen:
   <http://msdn2.microsoft.com/en-us/library/96ayss4b(VS.80).aspx>.
   This is somewhat of an abstraction from the Win32 calls, so if you
   want to see how to do it directly with Win32 then have a look at:
   <http://msdn2.microsoft.com/en-us/library/ms682499.aspx>.

   But if I'm understanding correctly that's not what you want -- you
   have multiple read inputs that you need to multiplex?  In that
   case you will probably need to use WaitForMultipleObjects(), which
   is somewhat of an analog to the POSIX select():
   <http://msdn2.microsoft.com/en-us/library/ms687025.aspx>.
   Note however that the list of types of objects that WFMO can
   accept does not include files or pipes:

       * Change notification
       * Console input
       * Event
       * Memory resource notification
       * Mutex
       * Process
       * Semaphore
       * Thread
       * Waitable timer

   (also note that "Console input" means direct input from a console,
   i.e.  the user typed something.  Consoles are sort of like the
   Win32 equivalent of ptys, but they are not "pseudo" -- they
   represent an actual console, i.e. what you see when you click on
   "Command Prompt" in the start menu.  If you have a child spawned
   with stdin/stdout redirected then GetStdHandle returns a pipe
   handle, so you can't use the console API on them in that case.  I
   suppose if you really wanted to be tricky you could achieve
   something like a pty by creating a new console with its window
   hidden off-screen, launching your child attached to that console,
   and then using the Win32 console API to read and write to it.
   This is, incidently, what the Console project
   <http://sourceforge.net/projects/console/> does to provide a
   prettier interface (multiple tabs, sane copy/paste, better font
   selection, etc) for Win32 consoles while still having the programs
   being run think they are attached to a real console, instead of a
   pipe.)

   In order to select on files and pipes, you have to use
   asynchronous (aka overlapped) I/O, which is kind of like what
   POSIX calls non-blocking I/O:
   <http://msdn2.microsoft.com/en-us/library/ms686358.aspx>.
   MSDN has an example of doing this with named pipes:
   <http://msdn2.microsoft.com/en-us/library/aa365603.aspx>.
   Note that Win32 named pipes are more like what POSIX calls fifos.
   Win32 anonymous pipes are the kind that are usually used for
   redirection and follow pretty closely to what POSIX calls a pipe.



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Alexei Alexandrov wrote:

> On 11/4/07, Bram Moolenaar <Bram@...> wrote:
> >
> > I'll put it in the todo list.  However, don't expect it soon.  I think
> > the only right way to implement it is to do a diff between the buffer
> > text and the file that is to be loaded.  The difference would then be
> > stored as a change in the undo buffer.
>
> Yes, this would be the most correct way. It is also not very easy to
> implement perhaps?

It probably needs to depend on an external diff program.  That's both a
bit unreliable (esp. on MS-Windows where executing external programs is
not simple) and can be slow.

I once looked into including diff code into Vim, but could only find
code that is relatively complicated.  If someone knows a nice,
well-behaving, small diff algorithm implementation in C that would help
a lot.

--
From "know your smileys":
  O:-) Saint

  /// Bram Moolenaar -- Bram@... -- 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
-~----------~----~----~----~------~----~------~--~---

On 11/5/07, Bram Moolenaar <Bram@...> wrote:
> I once looked into including diff code into Vim, but could only find
> code that is relatively complicated.  If someone knows a nice,
> well-behaving, small diff algorithm implementation in C that would help
> a lot.

It's a bit messy from first glance, but I was able to find some
MIT-licensed diff code in C:
http://www.ioplex.com/~miallen/libmba/dl/src/diff.c

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

can someone provide steps that can be followed if i want to start
building VIM on my machine? I have gutsy ubuntu.
please provide more than just:

apt-get source vim
apt-get source vim-dev

because that fails the configure! i would like instructions, after
which you can go

./configure
./make

and have the thing running....
or is that too much to ask? not sure...


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Nov 05, 2007 at 05:33:25PM -0800, MrTomer wrote:
> can someone provide steps that can be followed if i want to start
> building VIM on my machine? I have gutsy ubuntu.
> please provide more than just:
>
> apt-get source vim
> apt-get source vim-dev
>
> because that fails the configure! i would like instructions, after
> which you can go
>
> ./configure
> ./make
>
> and have the thing running....
> or is that too much to ask? not sure...

As posted by me 2 days ago, with one minor correction:

On an Ubuntu system, or any Debian-based system, it's very easy.

# Install all required development packages/build dependencies:
$ sudo apt-get build-dep vim-full

# Change to some directory we don't mind mucking up:
$ cd /tmp

# Download the vim source:
$ apt-get source vim-full

# Move to the patches directory
$ cd vim-7.1/upstream/patches

# Get the latest patches
$ python get_patches.py

# Move to the toplevel directory containing the debian subdirectory
$ cd ../..

# The system I was on already had these packages, but I don't think they get
# pulled in automatically by the apt-get build-dep, so you might need this:
$ sudo apt-get install build-essential fakeroot

# Then, actually build with
$ dpkg-buildpackage -rfakeroot -uc -b

# That command will take a while and will pop out one .deb for each variant.
Then, you can just
$ sudo dpkg -i /tmp/vim-full_7.1*.deb

Obviously replacing vim-full with whatever your preferred variant is.

Also, this doesn't belong on vim-dev, it belongs on vim-use.  vim-dev is for
submitting and discussing bug reports and patches.  I'm setting the reply-to
address accordingly.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---