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

Re: MacVim.app - snapshot r300 - available for download

Expand Messages
  • Nico Weber
    ... wouldn t 0..1 or 0..100 be a more sensible range? ... Better. Some more complaints: white foreground on pink background for TODO markers in C code is a)
    Message 1 of 13 , Oct 1, 2007
    • 0 Attachment
      > Apart from that we have a nice addition to the "eye candy" department;
      > I have integrated George Harker's transparency patch. Try it out by
      > typing ":set transp=50" (0=opaque, 255=transparent). Be sure to let
      > George know if you like it (I think it looks pretty neat myself
      > George).

      wouldn't 0..1 or 0..100 be a more sensible range?

      > Other changes:
      > - colorscheme updated (e.g. popup menu, status lines have changed,
      > visual group changes on focus lost/gained)

      Better. Some more complaints: white foreground on pink background for
      TODO markers in C code is a) ugly (what's wrong with the standard
      yellow background? You can use the "washed out yellow" they use at
      37signals.com if you want, but it's supposed to look like text you
      mark with a yellow highlighter, isn't it?) and b) invisible when the
      cursor is in the line containing the TODO when 'cursorline' is set.

      > If you haven't already, be sure to try the MacVim colorscheme...I have
      > it set as default myself and am getting quite attached to it. (It
      > also has some nifty features such as changing the highlight color when
      > focus changes.) Also, let me know if there is something you
      > like/dislike about it and I will forward your comments to its author
      > (which is not me, by the way ;-) ).

      I still don't like the status bar colors, especially of the active
      window (white on black). And I'm not too happy with pink numbers, but
      I guess I can live with that.

      For the people using `set cursorline`: If you put

      " show cursorline in active window only
      set cursorline
      au WinEnter * set cursorline
      au WinLeave * set nocursorline
      au FocusGained * set cursorline
      au FocusLost * set nocursorline

      into your _vimrc, the cursorline is only displayed in the window that
      currently has the focus. Is it possible to do something like that for
      the statusbar color by default (ie, change the color of the active
      statusline to the passive statusline color on focuslost and change it
      back on focusgained)?


      Thanks for the release :-)
      Nico

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tim Allen
      ... Glad to help! ... How about this? I m not sure if this is too much or too little ... +++ gui_mac.txt 2007-10-02 15:56:09.000000000 +1000 @@ -62,13 +62,18
      Message 2 of 13 , Oct 2, 2007
      • 0 Attachment
        On Oct 1, 4:30 pm, "björn" <bjorn.winck...@...> wrote:
        > Hi Tim,
        >
        > Thanks for the feedback...

        Glad to help!

        > > The only time when having 'enc' set to UTF-8 causes a problem is when
        > > you are editing a file with an unknown encoding, or multiple
        > > encodings. To avoid any possible encoding problems when editing such a
        > > file, you should set both 'enc' and 'fencs' to a simple 8-bit encoding
        > > like latin1 before opening the file.
        >
        > Thanks for that information. If you have the time and inclination,
        > please consider making a patch for the current docs. You seem to have
        > a better grasp on the situation than I do. Would you do it if I asked
        > nicely? Pretty please? ;-)

        How about this? I'm not sure if this is too much or too little
        information, but I think it covers all the bases:

        --- gui_mac_original.txt 2007-10-02 15:40:01.000000000 +1000
        +++ gui_mac.txt 2007-10-02 15:56:09.000000000 +1000
        @@ -62,13 +62,18 @@
        this is done in "$VIM/gvimrc" so you can override it by adding the
        following
        line to "~/.gvimrc": >
        set enc=latin1
        -Note: Having 'encoding' default to "utf-8" has the side-effect that
        all files
        -you load will be converted in memory (unless they are already utf-8
        encoded).
        -When you save them back to their original encoding, the contents in
        memory are
        -converted once again. This means that if you read and then write a
        file
        -immediately the file might still change. This is no problem if you
        are
        -editing utf-8 encoded files, but if you edit say a binary file then
        you should
        -set 'encoding' to "latin1" since this does no conversion.
        +Note: UTF-8 can represent all characters defined in Unicode, which
        includes
        +all characters in all other standard encodings, so it should be
        perfectly
        +safe to edit files in any encoding while 'encoding' is set to UTF-8.
        Of
        +course, you may need to set 'fileencodings' to auto-detect the
        encoding of the
        +files you edit, or force the detection with *++enc* on the command
        line.
        +
        +However, if you are editing files that use multiple encodings
        (container
        +formats like MIME or Unix mbox files) or no standard encoding (binary
        data,
        +see also |edit-binary|), you may want to prevent MacVim from re-
        encoding the
        +file at all. In this situation, you'll need to set both 'encoding'
        and
        +'fileencodings' to a simple single-byte encoding such as Latin1 so
        that when
        +the file is read into memory, the original bytes are left untouched.

        *macvim-shift-
        movement*
        Text editors on Mac OS X lets the user hold down shift+movement key
        to extend

        > > > You can override the default by
        > > > setting 'enc' in your .gvimrc (.vimrc does not work!).
        >
        > > Any reason you did not set the default in $VIM/vimrc (or even in code,
        > > like other Vim ports do)?
        >
        > No excuse. I just wanted it in last night's snapshot and I had no
        > time to look into doing it with code. It will be there though. This
        > is a temporary measure.
        >
        > Actually, if you can enlighten me as to what needs to be done to make
        > sure utf-8 is the default encoding, then please do. Bram said
        > something about set_init_1() in options.c, but I'm not quite sure what
        > needs to be done.

        I had a look at set_init_1() in options.c, and OMG it's a giant
        hairball. It looks like the actual auto-detection work is being done
        by a function called "enc_locale()" in mbyte.c. On Windows, it calls
        GetACP() which returns the system's default 8-bit encoding (kind of
        silly if you're on NT which is natively UTF-16), while on POSIX-y
        platform it checks the LANG and LC_ALL environment variables which are
        used to configure POSIX locales.

        I searched for information about what encoding OS X uses natively, but
        the Apple documentation I found rather uselessly states "Unicode is
        generally considered the native encoding for Mac OS X and should be
        used in nearly all situations." (somebody needs to tell them that
        "Unicode" is not an actual encoding). There is an NSLocale object that
        has some locale information in it, but "default character set" does
        not appear to be there.

        I'd suggest hacking enc_locale() to just say something like "if this
        is OS X, the encoding should be UTF-8".

        > > Do you prefer issues to be raised on the list, or filed in the Google
        > > Code issue tracker?
        >
        > If it is a clear problem, e.g. X does not work, then please file an
        > issue. If it is something more involved, maybe a feature request, or
        > anything that other people on the list might want to comment on, e.g.
        > like the discussion on the red close button, then I think it is better
        > handled on the list.

        I've added my Dvorak-QWERTY issue to the list, then.


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        ... Is it possible to have options that take floating point values? If not, 0..100 does seem more sensible than 0-255 and I guess nobody will be too upset
        Message 3 of 13 , Oct 2, 2007
        • 0 Attachment
          > > Apart from that we have a nice addition to the "eye candy" department;
          > > I have integrated George Harker's transparency patch. Try it out by
          > > typing ":set transp=50" (0=opaque, 255=transparent). Be sure to let
          > > George know if you like it (I think it looks pretty neat myself
          > > George).
          >
          > wouldn't 0..1 or 0..100 be a more sensible range?

          Is it possible to have options that take floating point values? If
          not, 0..100 does seem more sensible than 0-255 and I guess nobody will
          be too upset about loosing some precision in specifying the
          transparency. (Or maybe there are some people who think the
          difference between a 'transp' value of 132 and 133 out of 255 is
          simply staggering... ;-) )

          > > Other changes:
          > > - colorscheme updated (e.g. popup menu, status lines have changed,
          > > visual group changes on focus lost/gained)
          >
          > Better. Some more complaints: white foreground on pink background for
          > TODO markers in C code is a) ugly (what's wrong with the standard
          > yellow background? You can use the "washed out yellow" they use at
          > 37signals.com if you want, but it's supposed to look like text you
          > mark with a yellow highlighter, isn't it?) and b) invisible when the
          > cursor is in the line containing the TODO when 'cursorline' is set.

          Thanks, I will forward that (although I don't personally see why it
          has got to be yellow, there are other colored marker pens, right? ;-)
          ).

          > > If you haven't already, be sure to try the MacVim colorscheme...I have
          > > it set as default myself and am getting quite attached to it. (It
          > > also has some nifty features such as changing the highlight color when
          > > focus changes.) Also, let me know if there is something you
          > > like/dislike about it and I will forward your comments to its author
          > > (which is not me, by the way ;-) ).
          >
          > I still don't like the status bar colors, especially of the active
          > window (white on black). And I'm not too happy with pink numbers, but
          > I guess I can live with that.

          I kind of wanted a status bar with color (not shades of gray)...I
          don't know if that sounds completely crazy...

          > For the people using `set cursorline`: If you put
          >
          > " show cursorline in active window only
          > set cursorline
          > au WinEnter * set cursorline
          > au WinLeave * set nocursorline
          > au FocusGained * set cursorline
          > au FocusLost * set nocursorline
          >
          > into your _vimrc, the cursorline is only displayed in the window that
          > currently has the focus. Is it possible to do something like that for
          > the statusbar color by default (ie, change the color of the active
          > statusline to the passive statusline color on focuslost and change it
          > back on focusgained)?

          I guess that wouldn't be too hard to do...I'll try it out.


          /Björn

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • björn
          ... Thank you Tim! It looks good to me...I ve integrated it with the help. ... Thanks for digging into those functions. I followed your suggestion and simply
          Message 4 of 13 , Oct 2, 2007
          • 0 Attachment
            > > Thanks for that information. If you have the time and inclination,
            > > please consider making a patch for the current docs. You seem to have
            > > a better grasp on the situation than I do. Would you do it if I asked
            > > nicely? Pretty please? ;-)
            >
            > How about this? I'm not sure if this is too much or too little
            > information, but I think it covers all the bases:

            Thank you Tim! It looks good to me...I've integrated it with the help.


            > I'd suggest hacking enc_locale() to just say something like "if this
            > is OS X, the encoding should be UTF-8".

            Thanks for digging into those functions. I followed your suggestion
            and simply returned "utf-8" in enc_locale(). On my machine that
            always returned en_us or something similar, which just caused Vim to
            fall back on the default (latin1).


            > I've added my Dvorak-QWERTY issue to the list, then.

            That's good. I am still having problems with this one...the input
            handling is a big mess at the moment, due to how Cocoa deals with
            keyboard input (and partly due to me learning about it as I was
            writing MacVim). I am thinking about it though.


            /Björn

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Bram Moolenaar
            ... I would say: If none of the environment variables is defined, then default to utf-8. Someone using a shell might want to set those variables to tell his
            Message 5 of 13 , Oct 2, 2007
            • 0 Attachment
              Tim Allen wrote:

              > I had a look at set_init_1() in options.c, and OMG it's a giant
              > hairball. It looks like the actual auto-detection work is being done
              > by a function called "enc_locale()" in mbyte.c. On Windows, it calls
              > GetACP() which returns the system's default 8-bit encoding (kind of
              > silly if you're on NT which is natively UTF-16), while on POSIX-y
              > platform it checks the LANG and LC_ALL environment variables which are
              > used to configure POSIX locales.
              >
              > I searched for information about what encoding OS X uses natively, but
              > the Apple documentation I found rather uselessly states "Unicode is
              > generally considered the native encoding for Mac OS X and should be
              > used in nearly all situations." (somebody needs to tell them that
              > "Unicode" is not an actual encoding). There is an NSLocale object that
              > has some locale information in it, but "default character set" does
              > not appear to be there.
              >
              > I'd suggest hacking enc_locale() to just say something like "if this
              > is OS X, the encoding should be UTF-8".

              I would say: If none of the environment variables is defined, then
              default to utf-8. Someone using a shell might want to set those
              variables to tell his programs what he prefers.

              --
              "Lisp has all the visual appeal of oatmeal with nail clippings thrown in."
              -- Larry Wall

              /// 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_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              ... Ok, I ve changed the procedure in set_init_1() as follows: 1) call enc_locale(). no changes to the enc_locale() code is done...so this (as far as I
              Message 6 of 13 , Oct 8, 2007
              • 0 Attachment
                > > I'd suggest hacking enc_locale() to just say something like "if this
                > > is OS X, the encoding should be UTF-8".
                >
                > I would say: If none of the environment variables is defined, then
                > default to utf-8. Someone using a shell might want to set those
                > variables to tell his programs what he prefers.

                Ok, I've changed the procedure in set_init_1() as follows:

                1) call enc_locale(). no changes to the enc_locale() code is
                done...so this (as far as I understand) checks the "encoding related"
                environment variables.

                2) call mbyte_init() using the encoding returned in 1

                3) if 2 fails then set p_enc to "utf-8" and call mbyte_init() again

                4) if 3 fails then use "latin1" (although 3 should never fail)

                This should permit the user to override the environment variables,
                whilst defaulting to utf-8. Any comments?


                /Björn

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Bram Moolenaar
                ... Ehm, wouldn t it work to change the value of ENC_DFLT in option.h to utf-8 ? With an #ifdef, of course. -- The average life of an organization chart is
                Message 7 of 13 , Oct 9, 2007
                • 0 Attachment
                  Bjorn Winckler wrote:

                  > > > I'd suggest hacking enc_locale() to just say something like "if this
                  > > > is OS X, the encoding should be UTF-8".
                  > >
                  > > I would say: If none of the environment variables is defined, then
                  > > default to utf-8. Someone using a shell might want to set those
                  > > variables to tell his programs what he prefers.
                  >
                  > Ok, I've changed the procedure in set_init_1() as follows:
                  >
                  > 1) call enc_locale(). no changes to the enc_locale() code is
                  > done...so this (as far as I understand) checks the "encoding related"
                  > environment variables.
                  >
                  > 2) call mbyte_init() using the encoding returned in 1
                  >
                  > 3) if 2 fails then set p_enc to "utf-8" and call mbyte_init() again
                  >
                  > 4) if 3 fails then use "latin1" (although 3 should never fail)
                  >
                  > This should permit the user to override the environment variables,
                  > whilst defaulting to utf-8. Any comments?

                  Ehm, wouldn't it work to change the value of ENC_DFLT in option.h to
                  "utf-8"? With an #ifdef, of course.

                  --
                  The average life of an organization chart is six months. You can safely
                  ignore any order from your boss that would take six months to complete.
                  (Scott Adams - The Dilbert principle)

                  /// 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_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • björn
                  ... That was the first thing I tried...but then the multibyte stuff does not seem to get initialized, e.g. typing :digraphs shows nothing. Is this because
                  Message 8 of 13 , Oct 9, 2007
                  • 0 Attachment
                    > > > > I'd suggest hacking enc_locale() to just say something like "if this
                    > > > > is OS X, the encoding should be UTF-8".
                    > > >
                    > > > I would say: If none of the environment variables is defined, then
                    > > > default to utf-8. Someone using a shell might want to set those
                    > > > variables to tell his programs what he prefers.
                    > >
                    > > Ok, I've changed the procedure in set_init_1() as follows:
                    > >
                    > > 1) call enc_locale(). no changes to the enc_locale() code is
                    > > done...so this (as far as I understand) checks the "encoding related"
                    > > environment variables.
                    > >
                    > > 2) call mbyte_init() using the encoding returned in 1
                    > >
                    > > 3) if 2 fails then set p_enc to "utf-8" and call mbyte_init() again
                    > >
                    > > 4) if 3 fails then use "latin1" (although 3 should never fail)
                    > >
                    > > This should permit the user to override the environment variables,
                    > > whilst defaulting to utf-8. Any comments?
                    >
                    > Ehm, wouldn't it work to change the value of ENC_DFLT in option.h to
                    > "utf-8"? With an #ifdef, of course.

                    That was the first thing I tried...but then the multibyte stuff does
                    not seem to get initialized, e.g. typing :digraphs shows nothing. Is
                    this because mbyte_init() never gets called perhaps?


                    /Björn

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  Your message has been successfully submitted and would be delivered to recipients shortly.