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

MacVim.app - snapshot r300 - available for download

Expand Messages
  • björn
    I have uploaded a new snapshot (r300) of MacVim.app to: http://code.google.com/p/macvim/ The biggest change I ve worked on the last week is support for
    Message 1 of 13 , Sep 30, 2007
    • 0 Attachment
      I have uploaded a new snapshot (r300) of MacVim.app to:

      http://code.google.com/p/macvim/

      The biggest change I've worked on the last week is support for
      'encoding'. I have not tested it very thoroughly myself, so please if
      you use other 'enc' values than "utf-8", then let me know how it goes.
      Note that 'enc' still defaults to utf-8; this has certain
      side-effects that you should be aware of...check the help on 'enc' and
      also check ":h macvim-encoding". You can override the default by
      setting 'enc' in your .gvimrc (.vimrc does not work!).

      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).

      Other changes:
      - colorscheme updated (e.g. popup menu, status lines have changed,
      visual group changes on focus lost/gained)
      - vim flushes before delays (some warning messages used to not show
      up, e.g. :set tenc=latin1 would show no message)
      - the Visual group is no longer modified in the code
      - documentation updated
      - Ctrl-PageUp/Down now works to map to
      - added font size up/down to menu with key equivalents <D-=> and <D-->

      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 ;-) ).


      /Björn


      P.S. I have not had time to fix all bugs and implement some of the
      feature request this week, but I have not forgotten about them!

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Jeremy Conlin
      ... Since you asked :P, my friend and I would both like the MacVim colorscheme with a dark background. My favorite feature of this colorscheme is the
      Message 2 of 13 , Sep 30, 2007
      • 0 Attachment
        On 9/30/07, björn <bjorn.winckler@...> wrote:

        > 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 ;-) ).

        Since you asked :P, my friend and I would both like the MacVim
        colorscheme with a dark background. My favorite feature of this
        colorscheme is the italicized comments. That is a really nice touch.
        I don't know if a dark background would require an entire new
        colorschem (MacVim_dark).

        Just my 2 cents. Thanks again for the nice work.

        Jeremy

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Tim Allen
        ... Yay! Thanks again! ... The new documentation is good, but perhaps a little misleading: having enc set to UTF-8 is fine whenever you re editing a file
        Message 3 of 13 , Sep 30, 2007
        • 0 Attachment
          On Oct 1, 5:20 am, "björn" <bjorn.winck...@...> wrote:
          > I have uploaded a new snapshot (r300) of MacVim.app to:
          >
          > http://code.google.com/p/macvim/

          Yay! Thanks again!

          > Note that 'enc' still defaults to utf-8; this has certain
          > side-effects that you should be aware of...check the help on 'enc' and
          > also check ":h macvim-encoding".

          The new documentation is good, but perhaps a little misleading: having
          'enc' set to UTF-8 is fine whenever you're editing a file with a
          known, specific encoding (although if it's not autodetected with
          'fencs' then you'll have to use magic *++enc* parameter when you open
          the file). Having 'enc' set to UTF-8 might not be the most efficient
          way of editing files with other encodings, but it should work just
          fine.

          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.

          > 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)?

          > P.S. I have not had time to fix all bugs and implement some of the
          > feature request this week, but I have not forgotten about them!

          Do you prefer issues to be raised on the list, or filed in the Google
          Code issue tracker?


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • björn
          ... Ok, I ll see what can be done about that. Thanks for the comment. /Björn --~--~---------~--~----~------------~-------~--~----~ You received this message
          Message 4 of 13 , Sep 30, 2007
          • 0 Attachment
            > > 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 ;-) ).
            >
            > Since you asked :P, my friend and I would both like the MacVim
            > colorscheme with a dark background. My favorite feature of this
            > colorscheme is the italicized comments. That is a really nice touch.
            > I don't know if a dark background would require an entire new
            > colorschem (MacVim_dark).
            >
            > Just my 2 cents. Thanks again for the nice work.

            Ok, I'll see what can be done about that. Thanks for the comment.

            /Björn

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • björn
            Hi Tim, Thanks for the feedback... ... Thanks for that information. If you have the time and inclination, please consider making a patch for the current docs.
            Message 5 of 13 , Sep 30, 2007
            • 0 Attachment
              Hi Tim,

              Thanks for the feedback...

              > > Note that 'enc' still defaults to utf-8; this has certain
              > > side-effects that you should be aware of...check the help on 'enc' and
              > > also check ":h macvim-encoding".
              >
              > The new documentation is good, but perhaps a little misleading: having
              > 'enc' set to UTF-8 is fine whenever you're editing a file with a
              > known, specific encoding (although if it's not autodetected with
              > 'fencs' then you'll have to use magic *++enc* parameter when you open
              > the file). Having 'enc' set to UTF-8 might not be the most efficient
              > way of editing files with other encodings, but it should work just
              > fine.
              >
              > 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? ;-)


              > > 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.


              > > P.S. I have not had time to fix all bugs and implement some of the
              > > feature request this week, but I have not forgotten about them!
              >
              > 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.


              /Björn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.