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

FW: russian translation for vim

Expand Messages
  • vassily ragosin
    hello, ruvim project will be refactoring its existing vim documentation translation base to conform with 6.2.299 patch starting from 0.5 release, which is
    Message 1 of 22 , Apr 20, 2004
      hello,

      ruvim project will be refactoring its existing vim documentation translation
      base to conform with 6.2.299 patch starting from 0.5 release, which is
      scheduled to be released in May, 2004. Besides documentation translations it
      will also include message translation for the first time.

      would you please add "Russian (User Manual, rest is half complete), to be
      specified" on the page http://www.vim.org/translations.php? I will inform
      you of 0.5 release and url for getting translation package immediately after
      release happens.

      I also have a comment on 6.2.299 patch. Although it is long awaited, I think
      it misses one important point: charsets. For example, Russian documentation
      is supplied in three codepages, namely koi8-r (unix), cp866 (dos), cp1251
      (windows). The current realization does not address availability of help
      files in different codepages. For example, if a user needs to use both
      win32-console vim and win32-gui gvim, they may want to keep both cp866 and
      cp1251 help files in a shared runtime directory. Would you please comment on
      this in reply to this message any time soon, so that when ruvim 0.5 is ready
      to be released, its file structure will be refactored properly? I mean, is
      there any change to happen in the wake of 6.2.299 patch regarding codepage
      problem (say, using subdirectories for helpsets for different
      languages+codepages), or the given structure with filename extension is
      pretty much settled and you would reject any change of this kind?

      ruvim project can be found at http://www.sourceforge.net/projects/ruvim

      resourcefully yours,
      vassily

      mailto:vr[at]vrgraphics.ru
      pgp key id 0x92B4A97C
    • Bram Moolenaar
      ... Very good. ... I have updated the translations page. ... Currently the help files are assumed to be either latin1 or utf-8. Would it be acceptable to make
      Message 2 of 22 , Apr 21, 2004
        Vassily Ragosin wrote:

        > ruvim project will be refactoring its existing vim documentation translation
        > base to conform with 6.2.299 patch starting from 0.5 release, which is
        > scheduled to be released in May, 2004. Besides documentation translations it
        > will also include message translation for the first time.

        Very good.

        > would you please add "Russian (User Manual, rest is half complete), to be
        > specified" on the page http://www.vim.org/translations.php? I will inform
        > you of 0.5 release and url for getting translation package immediately after
        > release happens.

        I have updated the translations page.

        > I also have a comment on 6.2.299 patch. Although it is long awaited, I think
        > it misses one important point: charsets. For example, Russian documentation
        > is supplied in three codepages, namely koi8-r (unix), cp866 (dos), cp1251
        > (windows). The current realization does not address availability of help
        > files in different codepages. For example, if a user needs to use both
        > win32-console vim and win32-gui gvim, they may want to keep both cp866 and
        > cp1251 help files in a shared runtime directory. Would you please comment on
        > this in reply to this message any time soon, so that when ruvim 0.5 is ready
        > to be released, its file structure will be refactored properly? I mean, is
        > there any change to happen in the wake of 6.2.299 patch regarding codepage
        > problem (say, using subdirectories for helpsets for different
        > languages+codepages), or the given structure with filename extension is
        > pretty much settled and you would reject any change of this kind?

        Currently the help files are assumed to be either latin1 or utf-8.
        Would it be acceptable to make all the Russian help files in utf-8 and
        let Vim handle the conversion? On MS-Windows systems I would assume
        that conversion always works, since conversion from Unicode to codepages
        always works. I don't know about koi8-r, I suppose it requires the
        iconv library. Is it too much of a restriction that we require Vim
        compiled with iconv to be able to read the help in koi8-r?

        Making the same documentation available in several encodings has a few
        obvious problems, such as a tag matching in several files. Making a
        choice based on 'encoding' would be possible. Would require being able
        to tell which help file is in which encoding. That's not simple, thus I
        hope using one encoding and conversions is acceptable.

        --
        Eye have a spelling checker, it came with my PC;
        It plainly marks four my revue mistakes I cannot sea.
        I've run this poem threw it, I'm sure your please to no,
        It's letter perfect in it's weigh, my checker tolled me sew!

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
      • vassily ragosin
        hello, ... plans are go for menu translations, option window and some other neaties. :) ... oh! then it s a fantastically wise design decision, maybe should be
        Message 3 of 22 , Apr 21, 2004
          hello,

          > > ruvim project will be refactoring its existing vim documentation
          > > translation base to conform with 6.2.299 patch starting from 0.5
          > > release, which is scheduled to be released in May, 2004. Besides
          > > documentation translations it will also include message
          > translation for the first time.
          >
          > Very good.

          plans are go for menu translations, option window and some other neaties. :)

          > Currently the help files are assumed to be either latin1 or utf-8.
          > Would it be acceptable to make all the Russian help files in
          > utf-8 and let Vim handle the conversion? On MS-Windows
          > systems I would assume that conversion always works, since
          > conversion from Unicode to codepages always works.

          oh! then it's a fantastically wise design decision, maybe should be enforced
          as a rule.
          we don't need to care of supplying it in three different encodings then.
          however, here are some issues and worries:

          > Making the same documentation available in several encodings
          > has a few obvious problems, such as a tag matching in several
          > files. Making a choice based on 'encoding' would be
          > possible. Would require being able to tell which help file
          > is in which encoding. That's not simple, thus I hope using
          > one encoding and conversions is acceptable.

          1) yes. despite your advice not to translate tags, ruvim project does
          translate tags in help files.
          this was desided on the very beginning a year ago for the reason that it can
          be very inconvinient
          grammatically to mix english tags with russian text, rendering translations
          to be very cryptic
          (more cryptic as help files are sometimes by themselves). however, english
          tags were, are and will be
          also preserved. Question is: will russian tags be usable in multibyte
          encoding and will it be possible to
          tune syntax highlighting for multibyte strings in help files tags?

          2) win32 console version. afaik windows reports encoding to be used as
          win1251, while in fact
          cp866 is used in a console window. if we are making utf8->other encoding
          conversion to display
          help files in a console window, proper encoding needs to be used (in case of
          Russian, cp1251
          for gui vim and cp866 for console vim). same concern applies to
          scriptencodings as well.
          I will try to try all this myself as soon as I will get my hands on win32
          console version of Vim.

          3) how will conversion of characters present in unicode but not present in
          single byte ancodings
          be handled inside vim? it won't be nice if it will die or show
          half-translated help file.
          in the current translation base of ruvim project we supply manually hacked
          versions of
          usr_24.txt file (there's an issue where it talks about digraphs) -- it is
          not possible to convert this
          file to other encodings using iconv in a strict mode.

          resourcefully yours,
          vassily

          mailto:vr[at]vrgraphics.ru
          pgp key id 0x92B4A97C
        • Bram Moolenaar
          ... It should be possible to use Russian tags. You have to verify it really works though, I never used them. When you think a Russian tag is required, you
          Message 4 of 22 , Apr 22, 2004
            Vassily Ragosin wrote:

            > > Currently the help files are assumed to be either latin1 or utf-8.
            > > Would it be acceptable to make all the Russian help files in
            > > utf-8 and let Vim handle the conversion? On MS-Windows
            > > systems I would assume that conversion always works, since
            > > conversion from Unicode to codepages always works.
            >
            > oh! then it's a fantastically wise design decision, maybe should be enforced
            > as a rule.
            > we don't need to care of supplying it in three different encodings then.
            > however, here are some issues and worries:
            >
            > > Making the same documentation available in several encodings
            > > has a few obvious problems, such as a tag matching in several
            > > files. Making a choice based on 'encoding' would be
            > > possible. Would require being able to tell which help file
            > > is in which encoding. That's not simple, thus I hope using
            > > one encoding and conversions is acceptable.
            >
            > 1) yes. despite your advice not to translate tags, ruvim project does
            > translate tags in help files.
            > this was desided on the very beginning a year ago for the reason that it can
            > be very inconvinient
            > grammatically to mix english tags with russian text, rendering translations
            > to be very cryptic
            > (more cryptic as help files are sometimes by themselves). however, english
            > tags were, are and will be
            > also preserved. Question is: will russian tags be usable in multibyte
            > encoding and will it be possible to
            > tune syntax highlighting for multibyte strings in help files tags?

            It should be possible to use Russian tags. You have to verify it really
            works though, I never used them. When you think a Russian tag is
            required, you might consider also keeping the English tag. Otherwise it
            is very difficult to find the same text in the English version (e.g.,
            when something is not translated or has been changed after the
            translation was done).

            > 2) win32 console version. afaik windows reports encoding to be used as
            > win1251, while in fact
            > cp866 is used in a console window. if we are making utf8->other encoding
            > conversion to display
            > help files in a console window, proper encoding needs to be used (in case of
            > Russian, cp1251
            > for gui vim and cp866 for console vim). same concern applies to
            > scriptencodings as well.
            > I will try to try all this myself as soon as I will get my hands on win32
            > console version of Vim.

            Why does this cp1251 versus cp866 mistake happen? Vim uses the GetACP()
            and GetConsoleCP() functions, that should return the current codepage.
            Note that GetConsoleCP() was a recent addition, perhaps you didn't
            include this patch yet?

            > 3) how will conversion of characters present in unicode but not present in
            > single byte ancodings
            > be handled inside vim? it won't be nice if it will die or show
            > half-translated help file.
            > in the current translation base of ruvim project we supply manually hacked
            > versions of
            > usr_24.txt file (there's an issue where it talks about digraphs) -- it is
            > not possible to convert this
            > file to other encodings using iconv in a strict mode.

            Vim will show "?" (upside down if possible) for characters that can't be
            translated. At least, that is the intention. I haven't verified this
            works for help files. Also, we might need to check for utf-8 encoding
            even when 'encoding' is not "utf-8". That's in readfile(), search for
            "enc_utf8". We should be able to find a way to automatically handle
            utf-8 help files, without causing trouble for the latin1 files.

            --
            For large projects, Team Leaders use sophisticated project management software
            to keep track of who's doing what. The software collects the lies and guesses
            of the project team and organizes them in to instantly outdated charts that
            are too boring to look at closely. This is called "planning".
            (Scott Adams - The Dilbert principle)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
          • vassily ragosin
            hello, ... we keep every english tag -- just add some more russian in. they work well in koi-8 and cp1251. ... you may be right, last time I was trying this
            Message 5 of 22 , Apr 23, 2004
              hello,

              > It should be possible to use Russian tags. You have to
              > verify it really works though, I never used them. When you
              > think a Russian tag is required, you might consider also
              > keeping the English tag.

              we keep every english tag -- just add some more russian in. they work well
              in koi-8 and cp1251.

              > Why does this cp1251 versus cp866 mistake happen? Vim uses
              > the GetACP() and GetConsoleCP() functions, that should return
              > the current codepage.
              > Note that GetConsoleCP() was a recent addition, perhaps you
              > didn't include this patch yet?

              you may be right, last time I was trying this was with Vim 6.1.something. I
              will have try to check it again.


              > Vim will show "?" (upside down if possible) for characters
              > that can't be translated. At least, that is the intention.
              > I haven't verified this works for help files.

              ok

              > Also, we might need to check for utf-8 encoding even when 'encoding' is
              not "utf-8".
              > We should be able to find a way to automatically handle
              > utf-8 help files, without causing trouble for the latin1 files

              yes, right. this needs to work whatever 'encoding' value.
              ruvim 0.5 will be released in three legacy encodings plus utf-8 archive with
              new file names. Just to make the transition to utf-8-only 0.6 release more
              smooth.

              resourcefully yours,
              vassily

              mailto:vr[at]vrgraphics.ru
              pgp key id 0x92B4A97C
            • Bram Moolenaar
              ... Can you send me a translated Russian help file in utf-8? Then I can try out how it works when encoding is something else. Would be nice to make this
              Message 6 of 22 , Apr 23, 2004
                Vassily Ragosin wrote:

                > > Vim will show "?" (upside down if possible) for characters
                > > that can't be translated. At least, that is the intention.
                > > I haven't verified this works for help files.
                >
                > ok
                >
                > > Also, we might need to check for utf-8 encoding even when 'encoding' is
                > > not "utf-8".
                > > We should be able to find a way to automatically handle
                > > utf-8 help files, without causing trouble for the latin1 files
                >
                > yes, right. this needs to work whatever 'encoding' value.
                > ruvim 0.5 will be released in three legacy encodings plus utf-8 archive with
                > new file names. Just to make the transition to utf-8-only 0.6 release more
                > smooth.

                Can you send me a translated Russian help file in utf-8? Then I can try
                out how it works when 'encoding' is something else. Would be nice to
                make this work in 6.3.

                --
                If someone questions your market projections, simply point out that your
                target market is "People who are nuts" and "People who will buy any damn
                thing". Nobody is going to tell you there aren't enough of those people
                to go around.
                (Scott Adams - The Dilbert principle)

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
              • vr
                Dear Bram, here is a promised summary of all rights and wrongs with message and documentation support in Vim on win32. It actually revealed some not-gettext
                Message 7 of 22 , Apr 26, 2004
                  Dear Bram,

                  here is a promised summary of all rights and wrongs with message and
                  documentation support in Vim on win32. It actually revealed some not-gettext
                  related problems we have.

                  My environment:
                  ============
                  I am on winXP, and am building Vim with MS VC++ 7.0. I am using latest
                  libiconv-1.9.1 and gettext-0.13.1 built with MS VC++ 7.0 as well. Vim used
                  in all these experiments is fresh compiled from 6.2.501 sources updated from
                  cvs on the same machine.

                  compilation options:

                  vim:

                  MS-Windows 32 bit console version
                  Included patches: 1-501
                  Compiled by vr@SILVER
                  Huge version without GUI. Features included (+) or not (-):
                  +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent

                  +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
                  +comments
                  +cryptv +cscope +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval
                  +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer
                  +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap
                  +langmap
                  +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
                  +modify_fname +mouse -mouseshape +multi_byte +multi_lang -netbeans_intg
                  -osfiletype +path_extra -perl -postscript +printer -python +quickfix
                  +rightleft
                  -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop
                  +syntax
                  +tag_binary +tag_old_static -tag_any_white -tcl -tgetent -termresponse
                  +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual
                  +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup
                  -xfontset -xim -xterm_save -xpm_w32
                  system vimrc file: "$VIM\vimrc"
                  user vimrc file: "$HOME\_vimrc"
                  2nd user vimrc file: "$VIM\_vimrc"
                  user exrc file: "$HOME\_exrc"
                  2nd user exrc file: "$VIM\_exrc"
                  Compilation: cl -c /W3 /nologo -ML -I. -Iproto -DHAVE_PATHDEF -DWIN32
                  -DFEAT_CSCOPE -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 /Ox -DNDEBUG /Zi
                  /G6 -DFEAT_OLE -DFEAT_MBYTE -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_HUGE
                  Linking: link /RELEASE /nologo /subsystem:console /incremental:no
                  /nodefaultlib:libc advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib
                  uuid.lib libc.lib oleaut32.lib user32.lib /PDB:.\ObjCO/

                  gvim:

                  VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Apr 26 2004 12:17:33)
                  Версия с графическим интерфейсом для MS-Windows 32 бит с поддержкой OLE
                  Заплатки: 1-501
                  Скомпилирован vr@SILVER
                  Огромная версия с графическим интерфейсом.
                  Включённые (+) и отключённые (-) особенности:
                  +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent

                  +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
                  +comments
                  +cryptv +cscope +dialog_con_gui +diff +digraphs -dnd -ebcdic +emacs_tags
                  +eval
                  +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer
                  +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap
                  +langmap
                  +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
                  +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang
                  +netbeans_intg
                  +ole -osfiletype +path_extra -perl -postscript +printer -python +quickfix
                  +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline
                  -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl
                  -tgetent
                  -termresponse +textobjects +title +toolbar +user_commands +vertsplit
                  +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu
                  +windows +writebackup -xfontset -xim -xterm_save -xpm_w32
                  общесистемный файл vimrc: "$VIM\vimrc"
                  пользовательский файл vimrc: "$HOME\_vimrc"
                  второй пользовательский файл vimrc: "$VIM\_vimrc"
                  пользовательский файл exrc: "$HOME\_exrc"
                  второй пользовательский файл exrc: "$VIM\_exrc"
                  общесистемный файл gvimrc: "$VIM\gvimrc"
                  пользовательский файл gvimrc: "$HOME\_gvimrc"
                  второй пользовательский файл gvimrc: "$VIM\_gvimrc"
                  общесистемный файл меню: "$VIMRUNTIME\menu.vim"
                  Параметры компиляции: cl -c /W3 /nologo -ML -I. -Iproto -DHAVE_PATHDEF
                  -DWIN32 -DFEAT_CSCOPE -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 /Ox
                  -DNDEBUG /Zi /G6 -DFEAT_OLE -DFEAT_MBYTE -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT
                  -DFEAT_HUGE
                  Сборка: link /RELEASE /nologo /subsystem:console /incremental:no
                  /nodefaultlib:libc advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib
                  uuid.lib libc.lib oleaut32.lib user32.lib /PDB:.\ObjCO/

                  Requirements/Suggestions:
                  ====================

                  What would be nice is to make vim work seamlessly with translations, whether
                  in win32 console version, or in GUI mode. Some users keep both console and
                  gui version, both working under the same runtime environment, and it would
                  be nice to use only one message translation file and one set of
                  documentation files for both vims. Besides, as I already said, documentation
                  must be in utf-8 encoding, since we have help files using multiple
                  languages, such as farsi.txt. Given this, using utf-8 as a default encoding
                  for help files, as it is done now, is a good decision. Because environments
                  might differ ('encoding', 'termencoding' not necessarily are utf-8, and
                  should not really be), there probably is a need for some special treatment
                  of help files. No matter what user environment is, help files and messages
                  should display ok as long as libiconv library is available.

                  Talking about messages, I think it is reasonable to use koi8-r on Unix
                  platform and cp1251 on Windows (for both console and GUI).

                  Vim's behavior and misbehavior
                  =======================

                  Message translations
                  ==============

                  gvim: there are no problems

                  vim:

                  all messages written to stdout (for example, vim --version, vim --help), as
                  well as when setting window title, need to be converted to cp866 from cp1251
                  before they get written. Otherwise, we see these messages in incorrect
                  encoding.

                  vim reports that 'termencoding' is cp866 and 'encoding' is cp1251

                  talking about text inside vim, things are very weird here. First, messages
                  appear in the correct encoding, except CYRILLIC CAPITAL LETTER A is
                  represented as CYRILLIC CAPITAL LETTER I, and of other glyphs only the
                  following are visible (and represented on screen correctly:

                  CYRILLIC SMALL LETTER A
                  CYRILLIC SMALL LETTER D
                  CYRILLIC SMALL LETTER ZH
                  CYRILLIC SMALL LETTER Z
                  CYRILLIC SMALL LETTER J
                  CYRILLIC SMALL LETTER L
                  CYRILLIC SMALL LETTER M
                  CYRILLIC SMALL LETTER N
                  CYRILLIC SMALL LETTER O
                  CYRILLIC CAPITAL LETTER V
                  CYRILLIC CAPITAL LETTER D
                  CYRILLIC CAPITAL LETTER E
                  CYRILLIC CAPITAL LETTER ZH
                  CYRILLIC CAPITAL LETTER Z
                  CYRILLIC CAPITAL LETTER J
                  CYRILLIC CAPITAL LETTER L
                  CYRILLIC CAPITAL LETTER S
                  CYRILLIC CAPITAL LETTER T
                  CYRILLIC CAPITAL LETTER U
                  CYRILLIC CAPITAL LETTER F
                  CYRILLIC CAPITAL LETTER KH
                  CYRILLIC CAPITAL LETTER TS
                  CYRILLIC CAPITAL LETTER CH
                  CYRILLIC CAPITAL LETTER SCH

                  other glyphs are replaced with whitespace.

                  Further, investigations have shown that it concerns any text on the screen,
                  not only messages -- same goes for text in buffers as well. whether typed or
                  loaded. Such behavior is completely unrelated to the presence or absence of
                  iconv.dll or libiconv.dll (being lame enough I tried both) -- it just works
                  this way. I have a feeling that iconv is not supported or used on win32
                  console.

                  Documentation (help files)
                  =================

                  I converted *.rux files from ruvim project from koi8-r to utf-8 and put them
                  under $VIMRUNTIME/doc and did :helptags $VIMRUNTIME/doc to generate a
                  tagfile. Russian tags in a tagfile were written in utf-8 encoding.

                  gvim:
                  'encoding' is cp1251, 'termencoding' is empty. (out of box)

                  doing :help showed help page in russian. when trying to jump to a russian
                  tag E149 was given.

                  when doing autocomplete on :help<Tab>, utf-8 encoding in tags is not
                  detected.

                  It appears, that utf-8 is detected only in some of help files.
                  (should I send samples of both detectable and not detectable files?)

                  vim:
                  problems we have are not different from gvim, plus the already discussed
                  "missing glyphs" problem.


                  resourcefully yours,
                  vassily

                  mailto:vr[at]vrgraphics.ru
                  pgp key id 0x92B4A97C
                • Bram Moolenaar
                  ... Makes sense. Does this mean you prefer to make the Russian message translations in utf-8, and convert it koi8-r and cp1251? Note that conversion between
                  Message 8 of 22 , Apr 26, 2004
                    Vassily Ragosin wrote:

                    > Requirements/Suggestions:
                    >
                    > What would be nice is to make vim work seamlessly with translations, whether
                    > in win32 console version, or in GUI mode. Some users keep both console and
                    > gui version, both working under the same runtime environment, and it would
                    > be nice to use only one message translation file and one set of
                    > documentation files for both vims. Besides, as I already said, documentation
                    > must be in utf-8 encoding, since we have help files using multiple
                    > languages, such as farsi.txt. Given this, using utf-8 as a default encoding
                    > for help files, as it is done now, is a good decision. Because environments
                    > might differ ('encoding', 'termencoding' not necessarily are utf-8, and
                    > should not really be), there probably is a need for some special treatment
                    > of help files. No matter what user environment is, help files and messages
                    > should display ok as long as libiconv library is available.
                    >
                    > Talking about messages, I think it is reasonable to use koi8-r on Unix
                    > platform and cp1251 on Windows (for both console and GUI).

                    Makes sense. Does this mean you prefer to make the Russian message
                    translations in utf-8, and convert it koi8-r and cp1251?

                    Note that conversion between Unicode and MS-Windows codepages is
                    possible without libiconv, but between koi8-r and codepages is not.

                    > Vim's behavior and misbehavior
                    >
                    > Message translations
                    >
                    > gvim: there are no problems
                    >
                    > vim:
                    >
                    > all messages written to stdout (for example, vim --version, vim --help), as
                    > well as when setting window title, need to be converted to cp866 from cp1251
                    > before they get written. Otherwise, we see these messages in incorrect
                    > encoding.
                    >
                    > vim reports that 'termencoding' is cp866 and 'encoding' is cp1251

                    Thus that is correct. The gettext library must use cp1251, the value of
                    'encoding'. Perhaps it's using cp866 messages and then assumes they are
                    cp1251 and converts them to cp866? How about using ":lang mess" to set
                    the encoding? Don't know the full name for it, something like
                    "Russia_Russian.cp1251".

                    > talking about text inside vim, things are very weird here. First, messages
                    > appear in the correct encoding, except CYRILLIC CAPITAL LETTER A is
                    > represented as CYRILLIC CAPITAL LETTER I, and of other glyphs only the
                    > following are visible (and represented on screen correctly:

                    [...]

                    > other glyphs are replaced with whitespace.
                    >
                    > Further, investigations have shown that it concerns any text on the screen,
                    > not only messages -- same goes for text in buffers as well. whether typed or
                    > loaded. Such behavior is completely unrelated to the presence or absence of
                    > iconv.dll or libiconv.dll (being lame enough I tried both) -- it just works
                    > this way. I have a feeling that iconv is not supported or used on win32
                    > console.

                    Sounds like conversion problems. As mentioned above, the internal
                    MS-Windows functions are used for conversion between Unicode and
                    codepages. But these should be correct. Perhaps a wrong translation is
                    done somewhere? Otherwise it assumes the wrong codepage when doing the
                    conversions.

                    > Documentation (help files)
                    > =================
                    >
                    > I converted *.rux files from ruvim project from koi8-r to utf-8 and put them
                    > under $VIMRUNTIME/doc and did :helptags $VIMRUNTIME/doc to generate a
                    > tagfile. Russian tags in a tagfile were written in utf-8 encoding.
                    >
                    > gvim:
                    > 'encoding' is cp1251, 'termencoding' is empty. (out of box)
                    >
                    > doing :help showed help page in russian. when trying to jump to a russian
                    > tag E149 was given.

                    OK. this one of the things I suspected was not implemented: doing
                    conversion for the help tags. This is tricky: help tags can be latin1
                    or utf-8. This depends on the file they come from, not the tags file.
                    Fortunately, it should be simple to distinguish the encoding of the tag
                    by checking for an illegal utf-8 sequence. A latin1 word with non-ASCII
                    characters that is a valid utf-8 sequence is very rare.

                    Simplest solution would be to first search for the tag without
                    conversion, then with conversion from 'encoding' to utf-8.

                    > when doing autocomplete on :help<Tab>, utf-8 encoding in tags is not
                    > detected.

                    When listing help tags they should be converted from utf-8 to 'encoding'
                    when possible.

                    > It appears, that utf-8 is detected only in some of help files.
                    > (should I send samples of both detectable and not detectable files?)

                    Make sure the first line contains non-ASCII characters in utf-8
                    encoding. The translation of "for Vim version 6.2" should be
                    sufficient. If that doesn't work check for an illegal utf-8 sequence in
                    the file. If, after fixing that, it still doesn't work send me the
                    file.

                    --
                    How To Keep A Healthy Level Of Insanity:
                    15. Five days in advance, tell your friends you can't attend their
                    party because you're not in the mood.

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                    \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                    \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                  • vr
                    hello, ... what I would prefer is having just a single utf-8 file that goes for any platform, but I am not sure yet how utf-8 mo gonna behave on unix -- I had
                    Message 9 of 22 , Apr 26, 2004
                      hello,

                      > > Talking about messages, I think it is reasonable to use
                      > koi8-r on Unix
                      > > platform and cp1251 on Windows (for both console and GUI).
                      >
                      > Makes sense. Does this mean you prefer to make the Russian
                      > message translations in utf-8, and convert it koi8-r and cp1251?

                      what I would prefer is having just a single utf-8 file that goes for any
                      platform,
                      but I am not sure yet how utf-8 mo gonna behave on unix -- I had some
                      problems
                      with utf-8 messages under koi8-r locale when running from "screen" term.
                      I just don't want to break things now as it would take time to fix them. For
                      now, let them be
                      as they are: koi8-r distribution, and convert to cp1251 for win32 builds.

                      > > vim reports that 'termencoding' is cp866 and 'encoding' is cp1251
                      >
                      > Thus that is correct. The gettext library must use cp1251,
                      > the value of 'encoding'. Perhaps it's using cp866 messages
                      > and then assumes they are
                      > cp1251 and converts them to cp866?

                      not. it is using cp1251 messages. what's going on is it doesn't care to
                      convert them to cp866 when
                      the output is external to vim (console in "vim --version", "vim --help",
                      window title). it doesn't care
                      to convert them to cp866 at all, but inside vim it works fine except loosing
                      half the alphabet, you know...

                      > How about using ":lang
                      > mess" to set the encoding? Don't know the full name for it,
                      > something like "Russia_Russian.cp1251".

                      :lang mess is "ru". I repeat: message codepage is correct inside Vim, except
                      loosing certain glyphs,
                      but is wrong when string goes outside vim, straight to console. In the
                      latter case, no glyphs lost,
                      but encoding is wrong. It has to talk two different encodings when running
                      in console.


                      > Sounds like conversion problems. As mentioned above, the
                      > internal MS-Windows functions are used for conversion between
                      > Unicode and codepages. But these should be correct. Perhaps
                      > a wrong translation is done somewhere? Otherwise it assumes
                      > the wrong codepage when doing the conversions.

                      it works perfectly fine in gui version with the same mo file.

                      > When listing help tags they should be converted from utf-8 to
                      > 'encoding' when possible.

                      they should be or they will be in future patches?

                      > Make sure the first line contains non-ASCII characters in
                      > utf-8 encoding. The translation of "for Vim version 6.2"
                      > should be sufficient. If that doesn't work check for an
                      > illegal utf-8 sequence in the file. If, after fixing that,
                      > it still doesn't work send me the file.

                      how can utf-8 sequences be illegal in files iconved from koi8-r?

                      resourcefully yours,
                      vassily

                      mailto:vr[at]vrgraphics.ru
                      pgp key id 0x92B4A97C
                    • Bram Moolenaar
                      ... termencoding is not used for vim --help and vim --version . The .vimrc isn t read in these cases, thus the value of encoding should be the default
                      Message 10 of 22 , Apr 26, 2004
                        Vassily Ragosin wrote:

                        > > > vim reports that 'termencoding' is cp866 and 'encoding' is cp1251
                        > >
                        > > Thus that is correct. The gettext library must use cp1251,
                        > > the value of 'encoding'. Perhaps it's using cp866 messages
                        > > and then assumes they are
                        > > cp1251 and converts them to cp866?
                        >
                        > not. it is using cp1251 messages. what's going on is it doesn't care to
                        > convert them to cp866 when the output is external to vim (console in
                        > "vim --version", "vim --help", window title). it doesn't care to
                        > convert them to cp866 at all, but inside vim it works fine except

                        'termencoding' is not used for "vim --help" and "vim --version". The
                        .vimrc isn't read in these cases, thus the value of 'encoding' should be
                        the default anyway. Only when your console codepage is different from
                        the active codepage you would get wrong characters.

                        > loosing half the alphabet, you know...

                        I don't understand why this happens. Is conversion between cp1251 and
                        cp866 not possible for these characters?

                        > > How about using ":lang
                        > > mess" to set the encoding? Don't know the full name for it,
                        > > something like "Russia_Russian.cp1251".
                        >
                        > :lang mess is "ru". I repeat: message codepage is correct inside Vim, except
                        > loosing certain glyphs, but is wrong when string goes outside vim,
                        > straight to console. In the latter case, no glyphs lost, but encoding
                        > is wrong. It has to talk two different encodings when running in
                        > console.

                        I don't understand why it would go wrong then. You will have to explain
                        how you come to these conclusions.

                        > > Sounds like conversion problems. As mentioned above, the
                        > > internal MS-Windows functions are used for conversion between
                        > > Unicode and codepages. But these should be correct. Perhaps
                        > > a wrong translation is done somewhere? Otherwise it assumes
                        > > the wrong codepage when doing the conversions.
                        >
                        > it works perfectly fine in gui version with the same mo file.

                        The GUI can output text directly, thus I suspect the console codepage is
                        the problem.

                        > > When listing help tags they should be converted from utf-8 to
                        > > 'encoding' when possible.
                        >
                        > they should be or they will be in future patches?

                        Both.

                        > > Make sure the first line contains non-ASCII characters in
                        > > utf-8 encoding. The translation of "for Vim version 6.2"
                        > > should be sufficient. If that doesn't work check for an
                        > > illegal utf-8 sequence in the file. If, after fixing that,
                        > > it still doesn't work send me the file.
                        >
                        > how can utf-8 sequences be illegal in files iconved from koi8-r?

                        The utf-8 sequences won't be illegal, the latin1 ones will be. We can
                        use that to detect utf-8 tags.

                        --
                        I'm not familiar with this proof, but I'm aware of a significant
                        following of toddlers who believe that peanut butter is the solution
                        to all of life's problems... -- Tim Hammerquist

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                        \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                      • vassily ragosin
                        hello, ... it is possible. all these glyphs are in both codepages. ... what you see on console when doing vim --version and when doing :version inside vim is
                        Message 11 of 22 , Apr 26, 2004
                          hello,

                          > > loosing half the alphabet, you know...
                          >
                          > I don't understand why this happens. Is conversion between cp1251 and
                          > cp866 not possible for these characters?

                          it is possible. all these glyphs are in both codepages.

                          > > vim, straight to console. In the latter case, no glyphs lost, but
                          > > encoding is wrong. It has to talk two different encodings
                          > when running
                          > > in console.
                          >
                          > I don't understand why it would go wrong then. You will have
                          > to explain how you come to these conclusions.

                          what you see on console when doing vim --version and when doing :version
                          inside vim is not the same codepage output.
                          try it with using cp1251 mo file, :lang mess set to "ru" and default
                          codepage set to russian cp1251 in windows XP.

                          > > > When listing help tags they should be converted from utf-8 to
                          > > > 'encoding' when possible.
                          > >
                          > > they should be or they will be in future patches?

                          > Both.

                          they don't: utf-8 is not detected in tags files, they are assumed to be in
                          native encoding looks like.

                          > The utf-8 sequences won't be illegal, the latin1 ones will
                          > be. We can use that to detect utf-8 tags.

                          uh-uh, that smells like a trouble. what is illegal latin1 sequence exactly?
                          ain't what we deal with in utf8 strings from the point of view of latin1 is
                          just a number of perfectly legal characters? they are just byte values, and
                          in latin1 we have the whole range of 128...255 + ascii.

                          Is it really hard to make the switch to utf-8 in help files? what do we gain
                          by allowing them to be in latin1? btw, the beauty of utf-8 is that for
                          original english files they won't be any much different from what we have
                          now, same plain english text. But, you would also gain an extra bonus when
                          trying to explain what all those glyphs in farsi.txt are when showing that
                          file in a multibyte environment. Vim documentation, as it is, even not
                          translated, cries for unicode approach.

                          resourcefully yours,
                          vassily

                          mailto:vr[at]vrgraphics.ru
                          pgp key id 0x92B4A97C
                        • Bram Moolenaar
                          ... Well, any idea why some characters are dropped then? ... I can t reproduce this without a lot of effort, please explain the problem clearly. It s normal
                          Message 12 of 22 , Apr 27, 2004
                            Vassily Ragosin wrote:

                            > > > loosing half the alphabet, you know...
                            > >
                            > > I don't understand why this happens. Is conversion between cp1251 and
                            > > cp866 not possible for these characters?
                            >
                            > it is possible. all these glyphs are in both codepages.

                            Well, any idea why some characters are dropped then?

                            > > > vim, straight to console. In the latter case, no glyphs lost, but
                            > > > encoding is wrong. It has to talk two different encodings
                            > > when running
                            > > > in console.
                            > >
                            > > I don't understand why it would go wrong then. You will have
                            > > to explain how you come to these conclusions.
                            >
                            > what you see on console when doing vim --version and when doing :version
                            > inside vim is not the same codepage output.
                            > try it with using cp1251 mo file, :lang mess set to "ru" and default
                            > codepage set to russian cp1251 in windows XP.

                            I can't reproduce this without a lot of effort, please explain the
                            problem clearly.

                            It's normal that "vim --version" and ":version" have different output.
                            As mentioned before, 'encoding' and 'termencoding' are not initialized
                            when using "vim --version", thus not output conversion is done for it.

                            > > > > When listing help tags they should be converted from utf-8 to
                            > > > > 'encoding' when possible.
                            > > >
                            > > > they should be or they will be in future patches?
                            >
                            > > Both.
                            >
                            > they don't: utf-8 is not detected in tags files, they are assumed to be in
                            > native encoding looks like.

                            I know, I said they should be detected, but it doesn't happen yet.

                            > > The utf-8 sequences won't be illegal, the latin1 ones will
                            > > be. We can use that to detect utf-8 tags.
                            >
                            > uh-uh, that smells like a trouble. what is illegal latin1 sequence exactly?

                            There is no such thing, only a latin1 word that is an illegal utf-8
                            sequence.

                            > ain't what we deal with in utf8 strings from the point of view of latin1 is
                            > just a number of perfectly legal characters? they are just byte values, and
                            > in latin1 we have the whole range of 128...255 + ascii.

                            Right.

                            > Is it really hard to make the switch to utf-8 in help files? what do we gain
                            > by allowing them to be in latin1? btw, the beauty of utf-8 is that for
                            > original english files they won't be any much different from what we have
                            > now, same plain english text. But, you would also gain an extra bonus when
                            > trying to explain what all those glyphs in farsi.txt are when showing that
                            > file in a multibyte environment. Vim documentation, as it is, even not
                            > translated, cries for unicode approach.

                            I know utf-8 is a nice encoding. But it's not supported when compiled
                            without the multi-byte feature, thus we still need most help files to be
                            in latin1. Many systems use a minimal Vim for their "vi" command, thus
                            this is quite important.

                            --
                            hundred-and-one symptoms of being an internet addict:
                            30. Even though you died last week, you've managed to retain OPS on your
                            favorite IRC channel.

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                            \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                          • vr
                            hello, ... no idea. I m asking people on fido7.ru.vim whether they experience anything like this. I m starting to get a vague feeling something may be wrong
                            Message 13 of 22 , Apr 27, 2004
                              hello,

                              > > it is possible. all these glyphs are in both codepages.
                              >
                              > Well, any idea why some characters are dropped then?

                              no idea. I'm asking people on fido7.ru.vim whether they experience anything
                              like this.
                              I'm starting to get a vague feeling something may be wrong with my builds
                              also.
                              Mind you, I'm still :browseless :)

                              > > what you see on console when doing vim --version and when doing
                              > > :version inside vim is not the same codepage output.
                              > > try it with using cp1251 mo file, :lang mess set to "ru"
                              > and default
                              > > codepage set to russian cp1251 in windows XP.
                              >
                              > I can't reproduce this without a lot of effort, please
                              > explain the problem clearly.
                              >
                              > It's normal that "vim --version" and ":version" have different output.
                              > As mentioned before, 'encoding' and 'termencoding' are not
                              > initialized when using "vim --version", thus not output
                              > conversion is done for it.

                              that's it. which makes localized vim --version, vim --help, window title
                              feature and the like
                              inaccessible on win32 console. possible solutions are: do initialize
                              'encoding' and 'termencoding'
                              in those cases too; use not localized strings for output; something else?

                              > > they don't: utf-8 is not detected in tags files, they are
                              > assumed to
                              > > be in native encoding looks like.
                              >
                              > I know, I said they should be detected, but it doesn't happen yet.

                              ok

                              > I know utf-8 is a nice encoding. But it's not supported when
                              > compiled without the multi-byte feature, thus we still need
                              > most help files to be in latin1. Many systems use a minimal
                              > Vim for their "vi" command, thus this is quite important.

                              I see. So, as I understand, you are going to fix utf-8 detection instead.
                              what would you advise to do with language packs: I thought of
                              discontinuing 8-bit ruvim releases, but now I am concerned with
                              those systems and thinking of retreating back and staying with 8-bits.
                              by the way, documentation in cp1251 works just perfect on GUI win32 Vim.
                              may be we'll stay with three releases: cp1251, koi8-r and utf-8?
                              Then, how do we make a knob for supplying 3 mo files for russian instead of
                              two?

                              resourcefully yours,
                              vassily

                              mailto:vr[at]vrgraphics.ru
                              pgp key id 0x92B4A97C
                            • Bram Moolenaar
                              ... The file dialog should work just fine in the GUI (not in the console, of course). If it doesn t work it s very likely a problem with how you build Vim.
                              Message 14 of 22 , Apr 27, 2004
                                Vassily Ragosin wrote:

                                > > > it is possible. all these glyphs are in both codepages.
                                > >
                                > > Well, any idea why some characters are dropped then?
                                >
                                > no idea. I'm asking people on fido7.ru.vim whether they experience
                                > anything like this. I'm starting to get a vague feeling something may
                                > be wrong with my builds also. Mind you, I'm still :browseless :)

                                The file dialog should work just fine in the GUI (not in the console, of
                                course). If it doesn't work it's very likely a problem with how you
                                build Vim.

                                > that's it. which makes localized vim --version, vim --help, window title
                                > feature and the like inaccessible on win32 console. possible solutions
                                > are: do initialize 'encoding' and 'termencoding' in those cases too;
                                > use not localized strings for output; something else?

                                This is up to the gettext library. It should see the encoding of he
                                message files and the encoding of the system (or the console). The
                                defaults should work without Vim doing something.

                                > I see. So, as I understand, you are going to fix utf-8 detection instead.
                                > what would you advise to do with language packs: I thought of
                                > discontinuing 8-bit ruvim releases, but now I am concerned with
                                > those systems and thinking of retreating back and staying with 8-bits.
                                > by the way, documentation in cp1251 works just perfect on GUI win32 Vim.
                                > may be we'll stay with three releases: cp1251, koi8-r and utf-8?
                                > Then, how do we make a knob for supplying 3 mo files for russian instead of
                                > two?

                                For Win32 most people use the big version with multi-byte support. It's
                                quite simple to tell Russian help readers to use this version when they
                                want Russian help files. With the latest patches conversion of utf-8
                                help files to any codepage now works without iconv.

                                On Unix with a minimal Vim no conversion would be possible. Russian
                                people using the koi8-r locale would then need the help files in koi8-r
                                encoding. I don't know how big or small this group is. Many people
                                would be willing to install Vim with more features, since installing the
                                Russian help files is extra work anyway.

                                --
                                Everyone has a photographic memory. Some don't have film.

                                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                              • Alejandro López-Valencia
                                ... Hmm... While reading this thread with interest I tried browse in my Cygwin console vim (never done it to tell the truth), and the outcome is surreal! Of
                                Message 15 of 22 , Apr 27, 2004
                                  At 10:31 a.m. 27/04/2004, Bram Moolenaar wrote:
                                  >Vassily Ragosin wrote:
                                  >
                                  > > > > it is possible. all these glyphs are in both codepages.
                                  > > >
                                  > > > Well, any idea why some characters are dropped then?
                                  > >
                                  > > no idea. I'm asking people on fido7.ru.vim whether they experience
                                  > > anything like this. I'm starting to get a vague feeling something may
                                  > > be wrong with my builds also. Mind you, I'm still :browseless :)
                                  >
                                  >The file dialog should work just fine in the GUI (not in the console, of
                                  >course). If it doesn't work it's very likely a problem with how you
                                  >build Vim.

                                  Hmm... While reading this thread with interest I tried browse in my Cygwin
                                  console vim (never done it to tell the truth), and the outcome is surreal!

                                  Of course ':browse' won't open a file browser or anything described in
                                  'eval.txt' but you can browse all internal variables, functions and
                                  settings!? E.g., ':browse set' shows all the non-standard settings; while
                                  in the GUI version it opens the 'set-options' page in a new buffer.
                                  ':browse augroup' shows all the autocommand groups defined in the running
                                  session... This is not documented in 'eval.txt' therefore it is either an
                                  Easter egg, or I'm having a psychedelic experience. :-)

                                  Perhaps Vassily has been talking about this ':browse' undocumented behavior?

                                  BTW, way to go with patch 506. UTF-8 conversion has bitten me a couple of
                                  times, when I haven't an iconv.dll installed.


                                  --
                                  Alejandro López-Valencia
                                  http://dradul.tripod.com/
                                  The limits of my language are the limits of my world.
                                  (L. Wittgenstein)
                                • vassily ragosin
                                  hello, ... may be, I ll try to build it again with latest patches in the end of this week and will report if anything is right or wrong. I will do more
                                  Message 16 of 22 , Apr 27, 2004
                                    hello,

                                    > The file dialog should work just fine in the GUI (not in the
                                    > console, of course). If it doesn't work it's very likely a
                                    > problem with how you build Vim.

                                    may be, I'll try to build it again with latest patches in the end of this
                                    week and
                                    will report if anything is right or wrong. I will do more investigations,
                                    with
                                    different compile options then.

                                    > > that's it. which makes localized vim --version, vim --help, window
                                    > > title feature and the like inaccessible on win32 console. possible
                                    > > solutions
                                    > > are: do initialize 'encoding' and 'termencoding' in those
                                    > cases too;
                                    > > use not localized strings for output; something else?

                                    > This is up to the gettext library. It should see the
                                    > encoding of he message files and the encoding of the system
                                    > (or the console). The defaults should work without Vim doing
                                    > something.

                                    ok, then it's a gettext problem. but then, vim does do something when output
                                    is
                                    inside vim, so that it appears ok: will fixing gettext break the way things
                                    get shown
                                    inside the vim?

                                    > For Win32 most people use the big version with multi-byte
                                    > support. It's quite simple to tell Russian help readers to
                                    > use this version when they want Russian help files. With the
                                    > latest patches conversion of utf-8 help files to any codepage
                                    > now works without iconv.

                                    I have to see how utf-8 messages are working on win32. perhaps limiting our
                                    distributions to utf-8 and koi8-r I a good idea.

                                    resourcefully yours,
                                    vassily

                                    mailto:vr[at]vrgraphics.ru
                                    pgp key id 0x92B4A97C
                                  • Jacob Lerner
                                    ... Neither. What happens is, I think, when command after :browse is not one of those commands modified by :browse , :browse simply executes it without
                                    Message 17 of 22 , Apr 28, 2004
                                      Alejandro López-Valencia wrote:
                                      > Of course ':browse' won't open a file browser or anything described
                                      > in 'eval.txt' but you can browse all internal variables, functions
                                      > and settings!? E.g., ':browse set' shows all the non-standard
                                      > settings; while in the GUI version it opens the 'set-options' page in
                                      > a new buffer. ':browse augroup' shows all the autocommand groups
                                      > defined in the running session... This is not documented in
                                      > 'eval.txt' therefore it is either an Easter egg, or I'm having a
                                      > psychedelic experience. :-)

                                      Neither. What happens is, I think, when command after ':browse' is not
                                      one of those commands modified by ':browse', ':browse'
                                      simply executes it without modifiction. (According to ':help :browse',
                                      modified commands are ":e", ":w", ":r", ":sp", ":mkexrc",
                                      ":mkvimrc" and ":mksession")

                                      I think your ':browse set'(':browse augroup', ':browse let', ':browse
                                      function') behaves exactly as commands ':set' (':augroup', :function',
                                      ':let') respectively. Is this what you're observing ? This is what I see.

                                      Whatever, commands ':set', ':augroup', ':let', and ':function' always
                                      behaved this way.

                                      Or maybe ':browse let' allows you to do something different with
                                      the output, something that original ':let' won't ? Like, scrolling
                                      the output back or picking a variable from the list ? I doubt it.

                                      Yakov
                                    • Alejandro López-Valencia
                                      ... OK. If browse is a noop, it should behave as such and fail, don t you think? -- Alejandro López-Valencia http://dradul.tripod.com/ The limits of my
                                      Message 18 of 22 , Apr 28, 2004
                                        At 03:44 a.m. 28/04/2004, Jacob Lerner wrote:

                                        >Or maybe ':browse let' allows you to do something different with
                                        >the output, something that original ':let' won't ? Like, scrolling
                                        >the output back or picking a variable from the list ? I doubt it.


                                        OK. If browse is a noop, it should behave as such and fail, don't you think?


                                        --
                                        Alejandro López-Valencia
                                        http://dradul.tripod.com/
                                        The limits of my language are the limits of my world.
                                        (L. Wittgenstein)
                                      • Benji Fisher
                                        ... Why should it fail? The point of :browse is that it lets us use GUI widgets to accomplish something that can also be done without them. In the syntax ...
                                        Message 19 of 22 , May 1, 2004
                                          On Wed, Apr 28, 2004 at 06:31:28AM -0500, Alejandro López-Valencia wrote:
                                          > At 03:44 a.m. 28/04/2004, Jacob Lerner wrote:
                                          >
                                          > >Or maybe ':browse let' allows you to do something different with
                                          > >the output, something that original ':let' won't ? Like, scrolling
                                          > >the output back or picking a variable from the list ? I doubt it.
                                          >
                                          >
                                          > OK. If browse is a noop, it should behave as such and fail, don't you think?

                                          Why should it fail? The point of :browse is that it lets us use
                                          GUI widgets to accomplish something that can also be done without them.
                                          In the syntax

                                          :browse frob

                                          what I really want to accomplish is :frob, not :browse, so it should
                                          only fail if there is a problem with the :frob command. In other words,
                                          :browse is a modifier, like :vertical or :verbose, rather than a
                                          command. The appropriate behavior for a noop modifier is to execute the
                                          modified command in the ordinary way.

                                          If :browse were likely to fail, then anyone using it in a script
                                          would be forced to put in code for what to do then. Ugh.

                                          HTH --Benji Fisher
                                        • Alejandro López-Valencia
                                          ... As VimL has been out for a number of years, of course changing the behavior now would be a disaster. Yet, this silent echoing of the next command instead
                                          Message 20 of 22 , May 1, 2004
                                            At 06:03 a.m. 01/05/2004, Benji Fisher wrote:
                                            > >
                                            > > OK. If browse is a noop, it should behave as such and fail, don't you
                                            > think?
                                            >
                                            > Why should it fail? The point of :browse is that it lets us use
                                            >GUI widgets to accomplish something that can also be done without them.
                                            >In the syntax
                                            >
                                            >:browse frob
                                            >
                                            >what I really want to accomplish is :frob, not :browse, so it should
                                            >only fail if there is a problem with the :frob command. In other words,
                                            >:browse is a modifier, like :vertical or :verbose, rather than a
                                            >command. The appropriate behavior for a noop modifier is to execute the
                                            >modified command in the ordinary way.
                                            >
                                            > If :browse were likely to fail, then anyone using it in a script
                                            >would be forced to put in code for what to do then.

                                            As VimL has been out for a number of years, of course changing the behavior
                                            now would be a disaster. Yet, this silent echoing of the next command
                                            instead of failing with some sort of exception error makes my mental nose
                                            twitch a bit. But that's just my nose.


                                            --
                                            Alejandro López-Valencia
                                            http://dradul.tripod.com/
                                            The limits of my language are the limits of my world.
                                            (L. Wittgenstein)
                                          • Edward Peschko
                                            hey all, just wondering if you can use vim to do mathematical operations on contents of the buffer. ctrl-v (to get the number list) ???? to multiply by 1.3 p
                                            Message 21 of 22 , May 27, 2004
                                              hey all,

                                              just wondering if you can use vim to do mathematical operations on contents of
                                              the buffer.

                                              ctrl-v (to get the number list)
                                              ???? to multiply by 1.3
                                              p to paste back.

                                              sort of an 'excel lite' - don't need anything fancy, but it sure would be helpful
                                              to increment numbers automatically (without macros) and/or multiply columns without
                                              going into the shell or resorting to perl..

                                              thanks,

                                              Ed
                                            • Edward Peschko
                                              ... hmm. that s sort of clunky. as opposed to: ctrl-v (select text to operate on, save in buffer a) ... (get same results) IMO the above syntax is much easier
                                              Message 22 of 22 , May 28, 2004
                                                > aaaaaaa 12 ___
                                                > aaaaaaa 34 ___
                                                > aaaaaaa 56 ___
                                                > aaaaaaa 78 ___
                                                > ==========================
                                                > The start column is 10, and the width is 2. so
                                                > :%s/\%>9c.\{2}/\=( substitute(submatch(0)*13, '\d$', '.&', '') )

                                                hmm. that's sort of clunky. as opposed to:

                                                ctrl-v
                                                (select text to operate on, save in buffer a)
                                                :opa * 1.3 (or any arbitrary mathematical operation)

                                                (get same results)

                                                IMO the above syntax is much easier to use. Magnitudes in fact. I don't know off-hand
                                                if buffers are integrated into the perl options, but that would be cool too - ie:

                                                :perl a '$_ * 1.3'

                                                operating on strings in buffer a would be neat too.

                                                Ed
                                              Your message has been successfully submitted and would be delivered to recipients shortly.