Loading ...
Sorry, an error occurred while loading the content.

Vim version 6.0aw BETA available

Expand Messages
  • Bram Moolenaar
    This might be the last BETA for Vim 6.0. I m planning the 6.0 release in less than a week from now. I m not going to change much, only important problems and
    Message 1 of 7 , Sep 16 1:19 PM
    • 0 Attachment
      This might be the last BETA for Vim 6.0. I'm planning the 6.0 release
      in less than a week from now. I'm not going to change much, only
      important problems and things I know won't cause trouble.

      Last call for updating message and menu translations!!!

      All recently reported problems have been fixed, except for an obscure
      one with --remote-send.

      I have added the 'imdisable' option to work around the XIM problems on
      SGI/Irix. Please verify that there are no problems when 'imdisable' is
      at it's default value. We were unable to add a real fix, so this hack
      had to be added to make Vim work for most people.


      Changes
      -------

      Made ACL support work on SGI.

      Added Chinese message translations and menu translations. (Wang Jun)

      New syntax files:
      ratpoison Ratpoison config/command (Doug Kearns)
      lynx Lynx config (Doug Kearns)


      Fixes
      -----

      When 'virtualedit' is set:
      - Using "A" with a blockwise selection didn't work after the end of the line.
      - "P" in virtual space didn't work.
      - "p" at the last position in a TAB used spaces while this wasn't required.

      MS-Windows: In the install program, add a title argument to the "start"
      command when "cmd.exe" has been detected. Should fix the problem that
      uninstalling a previous version doesn't work.

      When 'scrolloff' is non-zero and "$" is in 'cpoptions', using "s" while the
      last line of the file is the first line on screen, the text wasn't displayed.

      When running "autoconf", delete the configure cache to force starting cleanly
      when configure is run again.

      Removed the curly braces from the argument to XSetLocaleModifiers() again,
      this was a misinterpretation of the manpage.

      When changing the Normal colors for cterm, the value of 'background' was
      changed even when the GUI was used.

      Athena and Motif: When adding a tooltip to a normal menu item, Vim would
      crash.

      The warning for a missing vimrun.exe was always given on startup, but some
      people just editing a file don't need to be bothered by it. Only show it when
      vimrun would be used.

      When debugging commands that were preceded with ":silent", debug mode didn't
      display the typed command.

      Using "]c" in diff mode could cause a "ml_get" error. It didn't consistently
      beep, now it beeps when not moving the cursor.

      After using ":diffthis" the topline could be halfway a fold, causing display
      problems.

      Gvimext: Don't call LoadLibrary() in DllMain(), it may cause a crash. Use
      thread-safe increment and decrement for reference counters. (Muraoka Taro)

      When using "%" in a multibyte text it could get confused by trailbytes that
      match. (Muraoka Taro)

      Termcap entry for RiscOS was wrong, using 7 and 8 in octal codes.

      Athena: The title of a dialog window and the file selector window were not
      set. (David Harrison)

      The "htmlLink" highlight group specified colors, which gives problems when
      using a color scheme. Added the "Underlined" highlight group for this.

      The indent.vim file contained line continuation, that doesn't work when
      in compatible mode.

      When using ":bufdo" it would stop at the first unlisted buffer.

      When closing the command line window with a mapped ":quit" it would execute
      the line under the cursor.

      The file explorer plugin didn't sort on time correctly. (Bernd Strohhaecker)

      After using ":insert" or ":change" the '[ mark would be one line too low.

      Macintosh: Prototype was missing for mch_has_exp_wildcard(). (Axel Kielhorn)

      'imactivate' was compiled in for Athena and Motif while it only works for GTK.

      Handling dropped files was nearly identical between Win16 and Win32, but the
      function was defined twice. Moved it to gui_w48.c.

      Sun Workshop: Changing directory to the directory of an edited file caused
      other file names to become invalid. The balloon evaluation didn't work.
      Made the toolbar commands work silently.

      Win32: The $VIMRUNTIME/procset.ps file had CR-LF line endings, should be LF.

      The "sjiscorr" program was always compiled, and since it's then newer than
      ja.sjis.po that file would always be produced. Avoid that by only generating
      ja.sjis.po when it's older than ja.po.

      When looking for the file name after a match with 'include' one character was
      skipped. Same for 'define'.

      PostScript printing: Under some locales floating point numbers used a comma
      instead of a decimal point, which doesn't work. (Mike Williams)

      Win32 printing: When the bold version of the printer font is wider, the title
      would wrap. Align the text to the baseline.

      Win32 and DJGPP: When editing a file with a short name in a directory, and
      editing the same file but using the long name, would end up with two buffers
      on the same file.

      When moving the cursor to just below the currently displayed text, the cursor
      could be in the first column instead of on the right character.

      runtime/doc/tags.html was used both for tags.txt and the converted tags file.
      Renamed tags.txt to tagsrch.txt.

      "gf" on a filename that starts with "../" only worked when the file being
      edited is in the current directory. An include file search didn't work
      properly for files starting with "../" or ".". Now search both relative to
      the file and to the current directory.

      When setting 'scrollbind' with a ":windo" command, the relative positions were
      not kept.

      Remote server:
      - Using foreground() doesn't always work for MS-Windows, the OS forbids an
      application to move itself to the foreground. Added remote_foreground() to
      have the client do it. On Unix it also works, for portability.
      - "gvim --remote main.c" which executes itself didn't set the server name.
      - When "--remote-send" failed, was trying to execute locally. That doesn't
      make sense, now Vim exits.
      - "vim --servername foo --remote main.c" which executes itself didn't handle
      received remote commands. The X display was closed and opened again when
      setting the terminal.

      When 'printheader', 'titlestring', 'iconstring', 'rulerformat' or 'statusline'
      contained "%{" but no following "}" memory was corrupted and a crash could
      happen.

      Syntax highlighting: When using a combination of keepend and extend could
      unexpectedly end a region.

      GTK: When folds are present, dragging the scrollbar thumb didn't work.

      ":0append" and then inserting two lines did not redraw the blank lines that
      were scrolled back down.

      When using insert mode completion in a narrow window, the message caused a
      scroll up. Now shorten the message if it doesn't fit and avoid writing the
      ruler over the message.

      When working in an xterm, selecting a wrapped line with the shift key and
      pasting it inserted line breaks. The trick to tell the terminal that the line
      wraps didn't work.

      XIM still didn't work correctly on some systems, especially SGI/IRIX. Added
      the 'imdisable' option, which is set by default for that system.

      Fixed two small problems for compiling with Borland. (Dan Sharp)



      Epilogue
      --------

      WARNING: This is still an unstable version. Most functionality should work
      fine, but in some cases it might crash or even destroy your work.

      If you run into something that doesn't work, please try to figure out why,
      try to solve it and send me a patch. If you can't do that, at least let me
      know exactly how to reproduce the problem.

      More info about the new 6.0 features with ":help version6". Or look here:
      http://vim.sf.net/whyvim.php.

      If you don't like the syntax of a command, the name of an option or how the
      new features work, let's discuss this in the vim-dev maillist.


      You can find Vim 6.0 here: ftp://ftp.vim.org/pub/vim/unreleased/
      More information about downloading: http://vim.sf.net/download.php

      Unix:
      unix/vim-6.0aw.tar.bz2 sources + runtime files, bzip2 compressed
      unix/vim-6.0aw-rt1.tar.gz runtime files part 1
      unix/vim-6.0aw-rt2.tar.gz runtime files part 2
      unix/vim-6.0aw-src1.tar.gz sources part 1
      unix/vim-6.0aw-src2.tar.gz sources part 2
      unix/vim-6.0av-6.0aw.diff.gz diff between 6.0av and 6.0aw

      Various:
      extra/vim-6.0aw-extra.tar.gz extra files
      extra/vim-6.0aw-lang.tar.gz multi-language files
      extra/vim-6.0av-6.0aw-extra.diff.gz extra diff
      extra/vim-6.0av-6.0aw-lang.diff.gz multi-lang diff
      doc/vim60awhtml.zip help files converted to HTML

      MS-Windows:
      pc/gvim60aw.exe self-installing, includes runtime files
      pc/vim60awrt.zip runtime files
      pc/vim60awlang.zip extra files for translated messages and menus
      pc/gvim60aw.zip GUI binary for Windows 95/98/NT/2000
      pc/gvim60awole.zip GUI binary with OLE support
      pc/gvim60aw_s.zip GUI binary for Windows 3.1
      pc/vim60awd16.zip 16 bits real mode - works on any system
      pc/vim60awd32.zip 32 bits protected mode - needs 386 and DPMI
      pc/vim60aww32.zip console version for Windows NT/2000/XP
      pc/vim60awsrc.zip sources for PC (with CR-LF)

      Amiga:
      amiga/vim60awrt.tgz runtime files
      amiga/vim60awbin.tgz binaries
      amiga/vim60awsrc.tgz sources packed for Amiga

      OS/2:
      os2/vim60awrt.zip runtime files
      os2/vim60awos2.zip binaries


      Happy Vimming!

      --
      panic("Foooooooood fight!");
      -- In the kernel source aha1542.c, after detecting a bad segment list

      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
      ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
    • Johannes Zellner
      On Sun, Sep 16, 2001 at 10:19:17PM +0200, Bram Moolenaar wrote: [...] ... [...] ;-) having ~/.vim/after/syntax/c.vim: ~/.vim/after/syntax/c.vim syn match
      Message 2 of 7 , Sep 16 2:31 PM
      • 0 Attachment
        On Sun, Sep 16, 2001 at 10:19:17PM +0200, Bram Moolenaar wrote:
        [...]
        > WARNING: This is still an unstable version. Most functionality should work
        > fine, but in some cases it might crash or even destroy your work.
        [...]

        ;-)

        having ~/.vim/after/syntax/c.vim:

        " ~/.vim/after/syntax/c.vim
        syn match cTodo contained '![a-zA-Z]\+'
        syn keyword cTodo contained joze
        syn keyword cTodo contained NOTE

        # vim -u NONE -U NONE -c "syn on" ~/.vim/after/syntax/c.vim

        Program received signal SIGSEGV, Segmentation fault.
        [Switching to Thread 1024 (LWP 16014)]
        0x08142f27 in check_state_ends () at syntax.c:2326
        2326 if (SYN_ITEMS(syn_buf)[cur_si->si_idx].sp_type
        == SPTYPE_START
        (gdb) where
        #0 0x08142f27 in check_state_ends () at syntax.c:2326
        #1 0x0814299f in syn_current_attr (syncing=0, displaying=1) at
        syntax.c:2141
        #2 0x08141e3c in get_syntax_attr (col=38) at syntax.c:1676
        #3 0x08131cde in win_line (wp=0x8202d70, lnum=7, startrow=6, endrow=61)
        at screen.c:3289
        #4 0x0812ee26 in win_update (wp=0x8202d70) at screen.c:1607
        #5 0x0812d376 in update_screen (type=40) at screen.c:504
        #6 0x080ce8b3 in main_loop (cmdwin=0) at main.c:1899
        #7 0x080ce6fc in main (argc=0, argv=0xbffff16c) at main.c:1808
        #8 0x402a264f in __libc_start_main () from /lib/libc.so.6
        (gdb)


        --
        Johannes
      • Moore, Paul
        From: Bram Moolenaar [mailto:Bram@moolenaar.net] ... Looks like this has fixed the problem. Interestingly, the Lucida Console header now looks non-bold. On
        Message 3 of 7 , Sep 17 2:26 AM
        • 0 Attachment
          From: Bram Moolenaar [mailto:Bram@...]
          > Win32 printing: When the bold version of the printer font is
          > wider, the title would wrap. Align the text to the baseline.

          Looks like this has fixed the problem. Interestingly, the Lucida Console
          header now looks non-bold. On further investigation, it seems to me that it
          *is* bold, but the effect is so subtle that you can't really see the
          distinction. The "bold" version looks bold because of the spacing (which
          we've just suppressed!!) This is some sort of design fault in the font, I
          guess (oddly, on screen, the distinction between bold & non-bold is very
          clear).

          Anyway, it looks like the problem is fixed - although I'll probably switch
          to using Courier New for printing now, because all my tests have convinced
          me it looks better :-)

          Paul.
        • Mike Williams
          ... I would guess not. We have corrupted the intended printing conditions the font designer used for a good appearence. In that situation I am not surprised
          Message 4 of 7 , Sep 17 3:32 AM
          • 0 Attachment
            On 17 Sep 2001, at 10:26, Moore, Paul wrote:

            > From: Bram Moolenaar [mailto:Bram@...]
            > > Win32 printing: When the bold version of the printer font is
            > > wider, the title would wrap. Align the text to the baseline.
            >
            > Looks like this has fixed the problem. Interestingly, the Lucida Console
            > header now looks non-bold. On further investigation, it seems to me that it
            > *is* bold, but the effect is so subtle that you can't really see the
            > distinction. The "bold" version looks bold because of the spacing (which
            > we've just suppressed!!) This is some sort of design fault in the font, I
            > guess (oddly, on screen, the distinction between bold & non-bold is very
            > clear).

            I would guess not. We have corrupted the intended printing
            conditions the font designer used for a good appearence. In that
            situation I am not surprised it does not look as good. Also just
            going by the name Lucida Console would imply that this is meant more
            as a monitor font (i.e. for low res display <= 96dpi) and not a
            printing font (i.e. a high res device >= 300dpi).

            Rarely a monitor font (such as ones used in web browsers) looks good
            in print. But this is a major digression.

            (Adobe have some fixed pitch Lucida PS fonts that look good in print.
            However, they want beer tokens in exchange for them :( .)

            > Anyway, it looks like the problem is fixed - although I'll probably switch
            > to using Courier New for printing now, because all my tests have convinced
            > me it looks better :-)

            In general Courier New is lighter weight (i.e. not as black) and has
            a greater leading (distance between lines) than plain ol' Courier,
            even though the character X-height (that is the height of capital
            letters for example) is smaller. Still, at the end of the day it all
            comes down to personal preference.

            TTFN

            Mike.
          • Bram Moolenaar
            ... I can t reproduce it, but I can guess what the problem is. Please check if this fixes it: ... *************** ... break; if (had_extend) + {
            Message 5 of 7 , Sep 17 3:42 AM
            • 0 Attachment
              Johannes Zellner wrote:

              > having ~/.vim/after/syntax/c.vim:
              >
              > " ~/.vim/after/syntax/c.vim
              > syn match cTodo contained '![a-zA-Z]\+'
              > syn keyword cTodo contained joze
              > syn keyword cTodo contained NOTE
              >
              > # vim -u NONE -U NONE -c "syn on" ~/.vim/after/syntax/c.vim
              >
              > Program received signal SIGSEGV, Segmentation fault.
              > [Switching to Thread 1024 (LWP 16014)]
              > 0x08142f27 in check_state_ends () at syntax.c:2326
              > 2326 if (SYN_ITEMS(syn_buf)[cur_si->si_idx].sp_type
              > == SPTYPE_START
              > (gdb) where
              > #0 0x08142f27 in check_state_ends () at syntax.c:2326

              I can't reproduce it, but I can guess what the problem is. Please check
              if this fixes it:

              *** syntax.c~ Sat Sep 15 17:15:20 2001
              --- syntax.c Mon Sep 17 12:31:48 2001
              ***************
              *** 2310,2316 ****
              --- 2310,2320 ----
              break;

              if (had_extend)
              + {
              syn_update_ends(FALSE);
              + if (current_state.ga_len == 0)
              + break;
              + }

              cur_si = &CUR_STATE(current_state.ga_len - 1);


              --
              hundred-and-one symptoms of being an internet addict:
              224. You set up your own Web page. You set up a Web page for each
              of your kids... and your pets.

              /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
              ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
              \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
            • Johannes Zellner
              ... [...] yes. That seems to work. Thanks! -- Johannes
              Message 6 of 7 , Sep 17 4:04 AM
              • 0 Attachment
                On Mon, Sep 17, 2001 at 12:42:14PM +0200, Bram Moolenaar wrote:
                >
                > Johannes Zellner wrote:
                >
                > > having ~/.vim/after/syntax/c.vim:
                > >
                > > " ~/.vim/after/syntax/c.vim
                > > syn match cTodo contained '![a-zA-Z]\+'
                > > syn keyword cTodo contained joze
                > > syn keyword cTodo contained NOTE
                > >
                > > # vim -u NONE -U NONE -c "syn on" ~/.vim/after/syntax/c.vim
                > >
                > > Program received signal SIGSEGV, Segmentation fault.
                > > [Switching to Thread 1024 (LWP 16014)]
                > > 0x08142f27 in check_state_ends () at syntax.c:2326
                > > 2326 if (SYN_ITEMS(syn_buf)[cur_si->si_idx].sp_type
                > > == SPTYPE_START
                > > (gdb) where
                > > #0 0x08142f27 in check_state_ends () at syntax.c:2326
                >
                > I can't reproduce it, but I can guess what the problem is. Please check
                > if this fixes it:
                [...]

                yes. That seems to work. Thanks!

                --
                Johannes
              • Nikolai 'pcp' Weibull
                wrote a indent/yacc.vim seems the first message went straight to Bram...(pressed r instead of L i spose = )... try it out please... -- /* Name: Nikolai
                Message 7 of 7 , Sep 18 11:36 AM
                • 0 Attachment
                  wrote a indent/yacc.vim
                  seems the first message went straight to Bram...(pressed 'r' instead of
                  'L' i spose =\)...
                  try it out please...

                  --
                  /* Name: Nikolai 'pcp' Weibull -- Age: 21 -- Born in: Chicago, IL USA *
                  * Where @: Gothenburg, Sweden -- Homepage: http://www.pcppopper.org/ *
                  * Email: da.box@..., pcp@... -- System: GeForce2 MX 32 *
                  * Celeron 667at950, Fujitsu 20.49gb UDMA-66, ASUS CUV4X, 256mb PC133 *
                  * main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);} */
                Your message has been successfully submitted and would be delivered to recipients shortly.