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

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

Expand Messages
  • 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 1 of 13 , Oct 2, 2007
      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 2 of 13 , Oct 2, 2007
        > > 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 3 of 13 , Oct 2, 2007
          > > 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 4 of 13 , Oct 2, 2007
            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 5 of 13 , Oct 8, 2007
              > > 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 6 of 13 , Oct 9, 2007
                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 7 of 13 , Oct 9, 2007
                  > > > > 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.