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

Re: A few more bugs fixed in Windows install.exe [Patch]

Expand Messages
  • Jonathon Merz
    ... Hoo boy, I ll get this right one of these days :) Forgot that in there to make it work with my still quirky paths, though I think I finally have my paths
    Message 1 of 6 , Jun 1, 2001
      Walter Briscoe wrote:

      > In article <3B166462.8030508@...> of Thu, 31 May 2001 10:33:54
      > in !vim-dev, Jonathon Merz <jmerz42@...> writes
      >
      >>No new features here, but several bug fixes. This patch is against the
      >>dosinst.c included with 6.0ah, and is (I think) completely up to date with
      >>everyone's fixes. Aside from what was in my last patch, this includes Walter
      >>Briscoe's fix for correctly finding shell folders in all versions of windows
      >>and Daniel Einspanjer's fix for registering OLE when Vim's path includes
      >>directories with spaces. I have also fixed a small problem causing shortcut
      >>creation to quit on a false error condition when compiled under MingW or
      >>Cygwin, and threw in a small fix for OLE registration on Cygwin caused by
      >>Cygwin not getting along with Windows-style paths.
      >>
      >>At the moment, I have it building and running on WinNT 4 using MSVC, Borland C
      >>5.5, MingW, and Cygwin. Anyone who can test it out on other operating
      >>systems, testing is much appreciated. Thanks again to everyone finding and
      >>fixing bugs.
      >>
      >>-Jon
      >>
      >>[ A MIME application / gzip part was included here. ]
      >>
      >>
      >
      > The patch does not work due to the following code:
      > --- 56,121 ----
      > /* ---------------------------------------- */
      >
      > #include "version.h"
      > + /* TEMP -- */
      > + #undef VIM_VERSION_NODOT
      > + #define VIM_VERSION_NODOT "vim60"
      > + /* -- TEMP */


      Hoo boy, I'll get this right one of these days :) Forgot that in there to
      make it work with my still quirky paths, though I think I finally have my
      paths straightened out so that Vim works for me "as usual". I've attached
      another patch, off of the pristine 6.0ah sources for dosinst.c that includes
      this and also includes a few other good coding changes that Walter suggested
      to me.


      > The vim shortcuts give me a 25 line screen rather than the 50 which is
      > my usual habit. They run vim.exe directly. I think they should do so via
      > %COMSPEC% or run vim.bat.

      Ok, there are a few ways to handle that. %COMSPEC% would open vim to whatever
      size you have set as the default for your command shell. My question there is
      whether %COMSPEC% is guaranteed to be defined. Another option (and I think
      this is required to make the vim.bat method work) is to have a line:

      set lines=xx

      in your vimrc file. This should work for console vim as well as gvim
      regardless of how it is started. I would tend towards this option since it
      only relies on vim, rather than relying on environment variables. Let me know
      what you think.

      > dosinst.c has become seriously complicated and I think might usefully be
      > given a specification document. For example, is the following a bug:
      > 1) install with shortcuts
      > 2) install without shortcuts.
      > Shortcuts remain in place!


      I don't think I understand the bug. Could you elaborate on it?

      Thanks and hope it works better this time.

      -Jon
    • Bram Moolenaar
      ... I think that the only vim or gvim that can be found in the path will be the batch files that have been installed. Otherwise we are back to the problems of
      Message 2 of 6 , Jun 1, 2001
        Jon Merz wrote:

        > > The vim shortcuts give me a 25 line screen rather than the 50 which is
        > > my usual habit. They run vim.exe directly. I think they should do so via
        > > %COMSPEC% or run vim.bat.
        >
        > Ok, there are a few ways to handle that. %COMSPEC% would open vim to
        > whatever size you have set as the default for your command shell. My
        > question there is whether %COMSPEC% is guaranteed to be defined. Another
        > option (and I think this is required to make the vim.bat method work) is to
        > have a line:
        >
        > set lines=xx
        >
        > in your vimrc file. This should work for console vim as well as gvim
        > regardless of how it is started. I would tend towards this option since it
        > only relies on vim, rather than relying on environment variables. Let me
        > know what you think.

        I think that the only vim or gvim that can be found in the path will be the
        batch files that have been installed. Otherwise we are back to the problems
        of how to find the executables.

        Those batch files would be in a fixed place (default is the Windows directory,
        where every application dumps his .dll files). When installing a new version,
        ideally only the path in these batch files need to change. Thus once the
        start menu entries have been made and the icon has been installed on the
        desktop, a new version doesn't have to do this again. That avoids ending up
        with a whole row of Vim commands in the start menu or adding yet another vim
        to the desktop.

        --
        hundred-and-one symptoms of being an internet addict:
        77. The phone company asks you to test drive their new PBX system

        /// 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 ///
      • Walter Briscoe
        In article of Fri, 1 Jun 2001 19:54:15 in !vim-dev, Bram Moolenaar writes ... I think we MAY
        Message 3 of 6 , Jun 4, 2001
          In article <200106011754.f51HsFE11235@...> of Fri, 1 Jun 2001 19:54:15 in
          !vim-dev, Bram Moolenaar <Bram@...> writes
          >
          >Jon Merz wrote:
          >
          >> > The vim shortcuts give me a 25 line screen rather than the 50 which is
          >> > my usual habit. They run vim.exe directly. I think they should do so via
          >> > %COMSPEC% or run vim.bat.
          >>
          >> Ok, there are a few ways to handle that. %COMSPEC% would open vim to
          >> whatever size you have set as the default for your command shell. My
          >> question there is whether %COMSPEC% is guaranteed to be defined. Another
          >> option (and I think this is required to make the vim.bat method work) is to
          >> have a line:
          >>
          >> set lines=xx
          >>
          >> in your vimrc file. This should work for console vim as well as gvim
          >> regardless of how it is started. I would tend towards this option since it
          >> only relies on vim, rather than relying on environment variables. Let me
          >> know what you think.
          >
          >I think that the only vim or gvim that can be found in the path will be the
          >batch files that have been installed. Otherwise we are back to the problems
          >of how to find the executables.
          I think we MAY have a different view of how the microSoft "operating system" processes
          the PATH environment variable. This is my understanding. Traditionally - in DOS 5 -
          the OS acted as if the following pseudo-code applied:
          for %ext in (COM EXE BAT) do if exist .\name.%ext use it
          for %ext in (COM EXE BAT) do for %dir in (%PATH%) do if exist %dir\name.%ext use it
          dosinst.c contains code which mimics that logic.

          In W9X and NTX, the logic is more like
          if PATHEXT is unset or OS is W9X, set PATHEXT=COM;EXE;BAT
          set RUNPATH=.;%PATH%
          for %dir in (%RUNPATH%) do for %ext in (%PATHEXT%) do if exist %dir\name.%ext use it

          The logic in dosinst.c is safe. It is more restrictive than necessary on
          modern systems.
          >
          >Those batch files would be in a fixed place (default is the Windows directory,
          >where every application dumps his .dll files). When installing a new version,
          >ideally only the path in these batch files need to change. Thus once the
          >start menu entries have been made and the icon has been installed on the
          >desktop, a new version doesn't have to do this again. That avoids ending up
          >with a whole row of Vim commands in the start menu or adding yet another vim
          >to the desktop.
          >
          I will check that with respect to 6.0ai and fix if needed.
          --
          Walter Briscoe
        • Walter Briscoe
          In article of Fri, 1 Jun 2001 11:25:36 in !vim-dev, Jonathon Merz writes [snip] ... If To err is
          Message 4 of 6 , Jun 4, 2001
            In article <3B17C200.6070005@...> of Fri, 1 Jun 2001 11:25:36
            in !vim-dev, Jonathon Merz <jmerz42@...> writes
            [snip]
            >Hoo boy, I'll get this right one of these days :) Forgot that in there to
            >make it work with my still quirky paths, though I think I finally have my
            >paths straightened out so that Vim works for me "as usual". I've attached
            >another patch, off of the pristine 6.0ah sources for dosinst.c that includes
            >this and also includes a few other good coding changes that Walter suggested
            >to me.
            If "To err is human,...", I am also typically human. This review process
            is very effective.

            >
            >
            >> The vim shortcuts give me a 25 line screen rather than the 50 which is
            >> my usual habit. They run vim.exe directly. I think they should do so via
            >> %COMSPEC% or run vim.bat.
            >
            >Ok, there are a few ways to handle that. %COMSPEC% would open vim to whatever
            >size you have set as the default for your command shell. My question there is
            >whether %COMSPEC% is guaranteed to be defined. Another option (and I think
            >this is required to make the vim.bat method work) is to have a line:
            >
            >set lines=xx
            >
            >in your vimrc file. This should work for console vim as well as gvim
            >regardless of how it is started. I would tend towards this option since it
            >only relies on vim, rather than relying on environment variables. Let me know
            >what you think.
            I was hoping there was a workaround in that. I put set lines=50 in my
            _vimrc and started vim via the shortcut. It started with set lines?=42
            and would not switch to full screen mode. (The 25 line start would not
            switch either. I feel sure it did last week.)

            >
            >> dosinst.c has become seriously complicated and I think might usefully be
            >> given a specification document. For example, is the following a bug:
            >> 1) install with shortcuts
            >> 2) install without shortcuts.
            >> Shortcuts remain in place!
            >
            >
            >I don't think I understand the bug. Could you elaborate on it?
            I meant something like
            1) install 6.0ah with shortcuts
            2) install 6.0ai without shortcuts.
            Shortcuts to 6.0ah remain in place!

            --
            Walter Briscoe
          Your message has been successfully submitted and would be delivered to recipients shortly.