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

Re: New patch to set cursor shape in Cygwin

Expand Messages
  • Tony Mechelynck
    On 28/12/11 08:18, Ben wrote: [...] ... IIUC, to make a gvim for Cygwin you need the Cygwin X11 libraries and development environment, and at least one of
    Message 1 of 6 , Dec 28, 2011
    • 0 Attachment
      On 28/12/11 08:18, Ben wrote:
      [...]
      > I've tried compiling with GUI enabled on both Cygwin and Mac OS X, and
      > I haven't had success. On Cygwin, I got the message "no GUI support"
      > during configuration, while on Mac OS X, compilation of gui_mac.c
      > failed with some strange looking errors. However, I'm pretty sure
      > Cygwin vim executables can't be run in both console and GUI mode (at
      > least I've never seen that), and all the modules to which I've added
      > code already include preprocessor tests for various GUI defines, so I
      > assume they are all compiled regardless of console/GUI configuration.
      > Thus, I've added preprocessor conditions to exclude all the new code
      > in the case that FEAT_GUI is defined.

      IIUC, to make a gvim "for Cygwin" you need the Cygwin X11 libraries and
      development environment, and at least one of the GUI packages (Motif,
      GTK, etc.) which can be compiled into gvim. Then to make it run you
      first need a Cygwin X11 server. IMHO it is usually not worth the
      trouble: a Cygwin console-mode vim, and a vim.exe and gvim.exe for
      "native Windows", are usually all one needs.

      Under Mac OSX, Björn Winckler maintains the MacVim port, which is a
      "flavour" of gvim for current versions of the Mac operating system.
      Check the vim_mac list if you're interested.

      >
      >> Also, IIRC, during gvim startup (when it's known that we're going to
      >> start gvim, has('gui_running') returns true, but we haven't yet (e.g.
      >> we're still sourcing the vimrc), setting 'guicursor' to values typical
      >> of the GUI gives no error even if the new values are invalid in console
      >> mode, they are remembered, and applied when starting the GUI (about when
      >> the GUIEnter event is triggered).
      >>
      >>>>> 3. I'm not sure about how much testing needs to be done for a new
      >>>>> patch (this is the first patch I've ever submitted); I've only tested
      >>>>> it on one Windows 7 machine.
      >>
      >> I suppose that it should be tested as extensively as possible, to ensure
      >> that:
      >> - it works in all Cygwin versions you could lay hands on, in as many
      >> Windows versions as possible;
      >> - it doesn't introduce new bugs in non-Cygwin Windows builds (which you
      >> can test) or in non-Windows builds (meaning Linux and Mac OSX at the
      >> very least, others if possible; here I suppose other people would have
      >> to do the testing)
      >
      > I've now tested the code change on 3 systems: Cygwin console on
      > Windows XP Home Edition SP3 (using the latest Cygwin version), Cygwin
      > console on Windows 7 Home Premium SP1 (using the latest Cygwin
      > version), and Mac OS X 10.6.8 console version. As I said before, I
      > haven't been able to compile a GUI version for testing, so hopefully
      > someone else can cover that territory (and likewise for Linux/other
      > systems).
      >
      > Is there a beta release or the equivalent that we can include this in
      > to try to get as much coverage as possible?

      hm, no, Bram does not maintain experimental branches of the code, except
      temporarily when exploring a soon-to-come new point release, and I
      haven't yet seen any sign of a 7.4 or 8.0 release of Vim; but you could
      upload your patch (in context diff form with Unix line endings) anywhere
      convenient, so that any interested tester can have a go at it. I see you
      have copied it to the end of your post, but if you can get it a "place
      to live" on the web that would be more permanent.

      One thing you might also try is compiling a Windows gvim (not for
      Cygwin) from your modified source, to check that there's no missing #ifdef


      A small nit about that patch: Bram's "house style" indents preprocessor
      conditionals by one space per level after the #, as follows:

      #ifdef MCH_CURSOR_SHAPE
      # if defined(__CYGWIN__) && !defined(FEAT_GUI)
      # include <windows.h>
      ...
      # endif /* Cygwin console */
      #endif /* MCH_CURSOR_SHAPE */

      and avoids C++ comments in C source. I know, most modern compilers
      accept both kinds of comments, but there are so many different OSes and
      compilers supported by Vim, we have to be particularly "conservative in
      what we emit". There's no way we can test them all ourselves, from
      VAX/VMS to zOS to smartphone Linux to whatever, so Bram's custom is to
      bend over backwards to make the code as compatible as possible, if
      necessary by means of a coding style so obsolete that all C compilers
      are guaranteed to support it; and (notwithstanding my pejorative
      phrasing) I believe that it's the right thing to do.


      Best regards,
      Tony.
      --
      There are three ways to get something done: do it yourself, hire
      someone, or forbid your kids to do it.

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.