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

Re: imap key

Expand Messages
  • Charles E. Campbell, Jr.
    ... Looks like your encodings are the same, so that s ok. The s in the left-hand-side of your maps kind of worries me. Please try commenting out all but
    Message 1 of 28 , Feb 1, 2006
    • 0 Attachment
      Jorge Almeida wrote:

      > Just in case, this is my ~/.vim/ftplugin/c/geral.vim:
      > :set tabstop=4
      > :vmap <C-X><C-D> :s/^/\/\//<CR>
      > :vmap <C-X><C-U> :s/^\(\s*\)\(\/\/\)/\1<CR>
      > :nmap <C-X><C-D> V:s/^/\/\//<CR>
      > :nmap <C-X><C-U> V::s/^\(\s*\)\(\/\/\)/\1<CR>
      > " anular »
      > :imap »<Esc> <Esc>a
      > " excesso de »'s, ou » literal...
      > :imap »»» »
      > " jump to ...
      > :imap <C-J><C-J> <Esc>/®/e<CR>a<BS>
      > :imap »/ <Esc>/®/e<CR>a<BS>
      > :imap ». <Esc>/®/e<CR>a<BS>
      > :nmap ». <Esc>/®/e<CR>a<BS>
      > "parenteses....
      > :imap »8 ()®<ESC>hi
      > :imap »9 []®<ESC>hi
      > :imap »0 {}®<ESC>hi
      > :imap »\ {<ESC>o}<ESC>k$a
      > :imap »; ""®<ESC>hi
      > "abreviaturas
      > :imap »a alfa
      >
      Looks like your encodings are the same, so that's ok. The <esc>s in the
      left-hand-side of your
      maps kind of worries me. Please try commenting out all but the last
      line (with imap...alfa).
      Does it work yet? I don't have a » key to try this out (and actually
      I'll be gone for awhile so
      you get a breather from my pestering you).

      If it happens to work, then try uncommenting lines until it stops working.

      Regards,
      Chip Campbell
    • Jorge Almeida
      ... Did that. It still doesn t work. ... Thanks for trying. Regards, Jorge Almeida
      Message 2 of 28 , Feb 1, 2006
      • 0 Attachment
        On Wed, 1 Feb 2006, Charles E. Campbell, Jr. wrote:

        >>
        > Looks like your encodings are the same, so that's ok. The <esc>s in the
        > left-hand-side of your
        > maps kind of worries me. Please try commenting out all but the last line
        > (with imap...alfa).
        Did that. It still doesn't work.
        > Does it work yet? I don't have a » key to try this out (and actually I'll be
        > gone for awhile so
        > you get a breather from my pestering you).
        >
        Thanks for trying.

        Regards,

        Jorge Almeida
      • Luc Hermitte
        Hello, ... Just a few suggestions -- they may not solve anything you can see, yet. - %s:/ ([ivn] )map/ 1noremap/ To avoid recursive mappings - :h
        Message 3 of 28 , Feb 1, 2006
        • 0 Attachment
          Hello,

          * On Wed, Feb 01, 2006 at 09:56:35PM +0000, Jorge Almeida <jalmeida@...> wrote:
          > Just in case, this is my ~/.vim/ftplugin/c/geral.vim:
          > :set tabstop=4
          > :vmap <C-X><C-D> :s/^/\/\//<CR>
          > [...]
          > "abreviaturas
          > :imap »a alfa

          Just a few suggestions -- they may not solve anything you can see, yet.

          -> %s:/\([ivn]\)map/\1noremap/
          To avoid recursive mappings
          -> :h :map-<buffer>
          Because you are defining ftplugins. You do not want your mapping to
          pollute your other filetypes.
          -> :h :setlocal
          Same reason.

          Having global and recursive mappings defined in several places may be a
          very good explanation to misbehaviors. But, I do not see any direct
          link to what you experience.

          What is echoed when you type from the command line:
          :imap »a
          ?
          You should read exactly one response. Are there others ? None ?


          HTH,

          BTW, the filetype for C++ is 'cpp'

          --
          Luc Hermitte
          http://hermitte.free.fr/vim/c.php
        • Benji Fisher
          ... I think this is the right line of questioning, but I wonder why you did not suggest the simpler ... Now that I look more closely, I think you meant to
          Message 4 of 28 , Feb 1, 2006
          • 0 Attachment
            On Wed, Feb 01, 2006 at 04:53:12PM -0500, Charles E. Campbell, Jr. wrote:
            > Jorge Almeida wrote:
            >
            > >I'm having a _really frustating_ problem with the » key I use for maps.
            >
            > OK, time for the next stab in the dark. Please try the following:
            >
            > vim .vimrc
            > :echo "encoding=".&encoding." termencoding=".&termencoding." fencs=".&fencs
            > :q
            >
            > and then try
            >
            > vim ~/.vim/ftplugin/c/geral.vim
            > :echo "encoding=".&encoding." termencoding=".&termencoding." fencs=".&fencs
            > :q
            >
            > Are these encodings the congruent?

            I think this is the right line of questioning, but I wonder why you
            did not suggest the simpler

            :e ~/.vimrc
            :redir @a
            :verbose set enc? tenc? fenc?
            :e ~/,vim/ftplugin/c/geral.vim
            :verbose set enc? tenc? fenc?
            :redir END
            :e mail.txt
            :put a

            Now that I look more closely, I think you meant to write "fenc" (no "s")
            instead of "fencs". That is the most likely culprit, so let's try again!

            Another possibility: does either file contain a :scriptencoding
            command? (Minimal form is :scripte .)

            HTH --Benji Fisher
          • Jorge Almeida
            ... OK (But there are no recursive mappings.) And what would happen if a mapping :imap ... is sourced _first_ and a conflicting mapping :inoremap ... is
            Message 5 of 28 , Feb 2, 2006
            • 0 Attachment
              On Thu, 2 Feb 2006, Luc Hermitte wrote:

              >
              > Just a few suggestions -- they may not solve anything you can see, yet.
              >
              > -> %s:/\([ivn]\)map/\1noremap/
              > To avoid recursive mappings
              OK (But there are no recursive mappings.)
              And what would happen if a mapping ":imap ..." is sourced _first_ and
              a conflicting mapping ":inoremap ..." is sourced later?
              > -> :h :map-<buffer>
              > Because you are defining ftplugins. You do not want your mapping to
              > pollute your other filetypes.
              > -> :h :setlocal
              > Same reason.
              I don't understand. A file in ~/.vim.ftplugin/c/ would be sourced only
              when editing a *.c file (right?). How could pollution arise?
              >
              > Having global and recursive mappings defined in several places may be a
              > very good explanation to misbehaviors. But, I do not see any direct
              > link to what you experience.
              Aren't the files in ~/.vim.ftplugin/c/ sourced _after_ ~/.vimrc? And a
              mapping in the former would not override a mapping in the latter?
              >
              > What is echoed when you type from the command line:
              > :imap »a
              > ?
              "No mapping found"


              I noticed also the following behaviour:
              In ~/.vim/ftplugin/c/geral.vim I have the mappings

              1) :imap <C-J><C-J> <Esc>/®/e<CR>a<BS>
              2) :imap »8 ()®<ESC>hi
              3) :imap »a alfa

              Now, 3) doesn't work. But 2) does work! And 1) doesn't work, echoing the
              message:
              E486: Pattern not found: ®


              All this happens only with c files. All mappings work perfectly with tex
              files.

              Thanks,

              Jorge Almeida
            • Jorge Almeida
              ... encoding=latin1 termencoding= fileencoding= ... encoding=latin1 termencoding= fileencoding=utf-8 ... OK: vim .vimrc ... encoding=latin1 termencoding= fenc=
              Message 6 of 28 , Feb 2, 2006
              • 0 Attachment
                On Wed, 1 Feb 2006, Benji Fisher wrote:

                > On Wed, Feb 01, 2006 at 04:53:12PM -0500, Charles E. Campbell, Jr. wrote:
                >> Are these encodings the congruent?
                >
                > I think this is the right line of questioning, but I wonder why you
                > did not suggest the simpler
                >
                > :e ~/.vimrc
                > :redir @a
                > :verbose set enc? tenc? fenc?
                encoding=latin1
                termencoding=
                fileencoding=

                > :e ~/,vim/ftplugin/c/geral.vim
                > :verbose set enc? tenc? fenc?
                encoding=latin1
                termencoding=
                fileencoding=utf-8

                > :redir END
                > :e mail.txt
                > :put a
                >
                > Now that I look more closely, I think you meant to write "fenc" (no "s")
                > instead of "fencs". That is the most likely culprit, so let's try again!
                >
                OK:

                vim .vimrc
                :echo "encoding=".&encoding." termencoding=".&termencoding." fenc=".&fenc
                encoding=latin1 termencoding= fenc=

                vim ~/.vim/ftplugin/c/geral.vim
                :echo "encoding=".&encoding." termencoding=".&termencoding." fenc=".&fenc
                encoding=latin1 termencoding= fenc=utf-8

                > Another possibility: does either file contain a :scriptencoding
                > command? (Minimal form is :scripte .)
                No.

                Thanks,

                Jorge Almeida
              • iler_ml@fastmail.fm
                Jorge Almeida : What is echoed when you type from the command line: :imap »a ? No mapping foundThis No
                Message 7 of 28 , Feb 2, 2006
                • 0 Attachment
                  "Jorge Almeida" <jalmeida@...>:
                  > > What is echoed when you type from the command line:
                  > > :imap »a
                  > > ?
                  > "No mapping found"

                  This "No mapping found" probably means that you'll want to find
                  which line in which script scauses removal of the mapping in question.
                  What if you add the following commands into script that
                  has ':imap »a alpha' right after this imap:

                  :imap »a alpha
                  " first, we want to check that mapping exists at the point of
                  creation
                  :imap »a
                  :call input("did you see the mapping? ")
                  " increase verbosity to the max
                  :set verbose=20

                  If you're lucky, you'll spot iunmap :-) At any rate, you'll which
                  scripts are sourced.
                  Ideally, you'll want to insert commands
                  :imap »a
                  :call input("did you see the mapping? ")
                  after each line, but failing that, you could insert these into
                  various points of the scripts that are executed after geral.vim, and
                  then
                  dichotomy is your friend to find which line causes disappearance of the
                  mapping.

                  Yakov
                  --

                  iler_ml@...

                  --
                  http://www.fastmail.fm - One of many happy users:
                  http://www.fastmail.fm/docs/quotes.html
                • A. J. Mechelynck
                  ... [...] You could have a file of a different type (for instance, a help file) in another (split) window. Or you could edit a file needing none of these
                  Message 8 of 28 , Feb 2, 2006
                  • 0 Attachment
                    Jorge Almeida wrote:
                    > On Thu, 2 Feb 2006, Luc Hermitte wrote:
                    >
                    >>
                    >> Just a few suggestions -- they may not solve anything you can see, yet.
                    >>
                    >> -> %s:/\([ivn]\)map/\1noremap/
                    >> To avoid recursive mappings
                    > OK (But there are no recursive mappings.)
                    > And what would happen if a mapping ":imap ..." is sourced _first_ and
                    > a conflicting mapping ":inoremap ..." is sourced later?
                    >> -> :h :map-<buffer>
                    >> Because you are defining ftplugins. You do not want your mapping to
                    >> pollute your other filetypes.
                    >> -> :h :setlocal
                    >> Same reason.
                    > I don't understand. A file in ~/.vim.ftplugin/c/ would be sourced only
                    > when editing a *.c file (right?). How could pollution arise?
                    [...]

                    You could have a file of a different type (for instance, a help file) in
                    another (split) window. Or you could edit a file needing none of these
                    mappings just afterwards (for instance, a text file). Now if you use
                    ":set" and "map" (without <buffer>) rather than the recommended
                    ":setlocal" and ":map <buffer>", your options and mappings are set
                    across the board for all present and future files until you unset them.
                    That's unhealthy for settings set by a filetype-plugin. Mappings and
                    abbreviations set in a filetype-plugin should always include the
                    <buffer> restriction, and option settings set in filetype-plugins should
                    always be set by ":setlocal" (and concern options which are local or
                    global-local).


                    Best regards,
                    Tony.
                  • Jorge Almeida
                    ... OK, got it. Thank you, Jorge Almeida
                    Message 9 of 28 , Feb 2, 2006
                    • 0 Attachment
                      On Thu, 2 Feb 2006, A. J. Mechelynck wrote:
                      >> I don't understand. A file in ~/.vim.ftplugin/c/ would be sourced only
                      >> when editing a *.c file (right?). How could pollution arise?
                      > [...]
                      >
                      > You could have a file of a different type (for instance, a help file) in
                      > another (split) window. Or you could edit a file needing none of these
                      > mappings just afterwards (for instance, a text file). Now if you use
                      > ":set" and "map" (without <buffer>) rather than the recommended
                      > ":setlocal" and ":map <buffer>", your options and mappings are set
                      > across the board for all present and future files until you unset them.
                      > That's unhealthy for settings set by a filetype-plugin. Mappings and
                      > abbreviations set in a filetype-plugin should always include the
                      > <buffer> restriction, and option settings set in filetype-plugins should
                      > always be set by ":setlocal" (and concern options which are local or
                      > global-local).
                      >
                      OK, got it.

                      Thank you,

                      Jorge Almeida
                    • Benji Fisher
                      ... Yes, I thought that was the problem. Now the details have been snipped; remind me what the files were where it worked and where it did not work. There
                      Message 10 of 28 , Feb 2, 2006
                      • 0 Attachment
                        On Thu, Feb 02, 2006 at 10:10:35AM +0000, Jorge Almeida wrote:
                        > On Wed, 1 Feb 2006, Benji Fisher wrote:
                        >
                        > >Now that I look more closely, I think you meant to write "fenc" (no "s")
                        > >instead of "fencs". That is the most likely culprit, so let's try again!
                        > >
                        > OK:
                        >
                        > vim .vimrc
                        > :echo "encoding=".&encoding." termencoding=".&termencoding."
                        > fenc=".&fenc
                        > encoding=latin1 termencoding= fenc=
                        >
                        > vim ~/.vim/ftplugin/c/geral.vim
                        > :echo "encoding=".&encoding." termencoding=".&termencoding."
                        > fenc=".&fenc
                        > encoding=latin1 termencoding= fenc=utf-8

                        Yes, I thought that was the problem. Now the details have been
                        snipped; remind me what the files were where it worked and where it did
                        not work. There was also a tex plugin involved, right? What is the
                        value of 'fenc' for that one, and which were the files where it worked
                        and did not work?

                        > > Another possibility: does either file contain a :scriptencoding
                        > >command? (Minimal form is :scripte .)
                        > No.

                        I did not expect that to be the problem, but :scriptencoding is the
                        solution.

                        The reason the map sometimes works and sometimes does not is that
                        the character you are using is sometimes read as latin1 and sometimes as
                        utf-8. One way to fix it is to add something like this to the file
                        where the map is not working:

                        " Make sure the character ?? is interpreted properly:
                        scriptencoding latin1
                        imap ??a ...
                        scriptencoding " Return to the default, just to be on the safe side.

                        I may have this backwards: if that does not work, try
                        "scriptencoding utf-8" instead of "scriptencoding latin1".

                        There is an entirely different solution. If you think that the
                        future is utf-8 and not latin1, add

                        set enc=utf-8

                        to your vimrc file. (I think that the future *is* utf-8, but I defer to
                        others on this list on such points.) This may fix the problem all by
                        itself, or it may break the mapping that currently works, or it may
                        switch which one works and which does not. If you want to try this, do
                        it first; then fix remaining problems by adding :scriptencoding lines to
                        the appropriate files.

                        :help 'encoding'
                        :help 'fenc'

                        HTH --Benji Fisher
                      • Zdenek Sekera
                        ... I am following this thread for a while trying to find out what *was* a similar problem I had some time ago, unfortunately I am not able to figure that out.
                        Message 11 of 28 , Feb 2, 2006
                        • 0 Attachment
                          > -----Original Message-----
                          > From: iler_ml@... [mailto:iler_ml@...]
                          > Sent: 02 February 2006 13:17
                          > To: Jorge Almeida; vim@...
                          > Subject: Re: imap key
                          >
                          > "Jorge Almeida" <jalmeida@...>:
                          > > > What is echoed when you type from the command line:
                          > > > :imap >a
                          > > > ?
                          > > "No mapping found"
                          >
                          > This "No mapping found" probably means that you'll want to find
                          > which line in which script scauses removal of the mapping in question.
                          > What if you add the following commands into script that
                          > has ':imap >a alpha' right after this imap:
                          >
                          > :imap >a alpha
                          > " first, we want to check that mapping exists at the point of
                          > creation
                          > :imap >a
                          > :call input("did you see the mapping? ")
                          > " increase verbosity to the max
                          > :set verbose=20
                          >
                          > If you're lucky, you'll spot iunmap :-) At any rate, you'll which
                          > scripts are sourced.
                          > Ideally, you'll want to insert commands
                          > :imap >a
                          > :call input("did you see the mapping? ")
                          > after each line, but failing that, you could insert these into
                          > various points of the scripts that are executed after geral.vim, and
                          > then
                          > dichotomy is your friend to find which line causes
                          > disappearance of the
                          > mapping.

                          I am following this thread for a while trying to find out
                          what *was* a similar problem I had some time ago, unfortunately
                          I am not able to figure that out. All I remember was that
                          the problem disappeared when I started using latin1 (not utf-8)
                          exclusively (and that's what I am still using).
                          Actually, I had to go as fas as setting LANG=c in ~/.i18n,
                          because just :set enconding=latin1 wouldn't help.
                          I am on Linux, xterm, console vim.

                          ---Zdenek
                        • Jorge Almeida
                          ... It works for *.tex files (I have similar mappings in .vim/ftplugin/tex/geral.tex) but not for *.c files. For tex files: fenc= So it appears that the
                          Message 12 of 28 , Feb 2, 2006
                          • 0 Attachment
                            On Thu, 2 Feb 2006, Benji Fisher wrote:

                            >> OK:
                            >>
                            >> vim .vimrc
                            >> :echo "encoding=".&encoding." termencoding=".&termencoding."
                            >> fenc=".&fenc
                            >> encoding=latin1 termencoding= fenc=
                            >>
                            >> vim ~/.vim/ftplugin/c/geral.vim
                            >> :echo "encoding=".&encoding." termencoding=".&termencoding."
                            >> fenc=".&fenc
                            >> encoding=latin1 termencoding= fenc=utf-8
                            >
                            > Yes, I thought that was the problem. Now the details have been
                            > snipped; remind me what the files were where it worked and where it did
                            > not work. There was also a tex plugin involved, right? What is the
                            > value of 'fenc' for that one, and which were the files where it worked
                            > and did not work?
                            It works for *.tex files (I have similar mappings in
                            .vim/ftplugin/tex/geral.tex) but not for *.c files.
                            For tex files:
                            fenc=

                            So it appears that the problem arises with c files because these files
                            have 'fenc=', whereas the plugin for c files has 'fenc=utf-8'. Can't
                            guess why. New files have 'fenc=', and so have old files (like the tex
                            plugin).
                            >
                            >>> Another possibility: does either file contain a :scriptencoding
                            >>> command? (Minimal form is :scripte .)
                            >> No.
                            >
                            > I did not expect that to be the problem, but :scriptencoding is the
                            > solution.
                            >
                            > The reason the map sometimes works and sometimes does not is that
                            > the character you are using is sometimes read as latin1 and sometimes as
                            > utf-8. One way to fix it is to add something like this to the file
                            > where the map is not working:
                            >
                            > " Make sure the character ?? is interpreted properly:
                            > scriptencoding latin1
                            > imap ??a ...
                            > scriptencoding " Return to the default, just to be on the safe side.
                            >
                            > I may have this backwards: if that does not work, try
                            > "scriptencoding utf-8" instead of "scriptencoding latin1".
                            >
                            Yes, it works now, with "scriptencoding utf-8".
                            I can also create a new c plugin file and enter all mappings by hand
                            (cat'ing the contents of the former c plugin file yields a bad encoding,
                            again, and so does copying and pasting. Silly...)

                            I suppose the problem is solved, although a somewhat uncomfortable
                            feeling still lingers. Encoding issues are always a PITA.
                            > There is an entirely different solution. If you think that the
                            > future is utf-8 and not latin1, add
                            >
                            > set enc=utf-8
                            >
                            > to your vimrc file. (I think that the future *is* utf-8, but I defer to
                            > others on this list on such points.) This may fix the problem all by
                            > itself, or it may break the mapping that currently works, or it may
                            > switch which one works and which does not. If you want to try this, do
                            > it first; then fix remaining problems by adding :scriptencoding lines to
                            > the appropriate files.
                            >
                            > :help 'encoding'
                            > :help 'fenc'
                            >
                            Thank you, and thanks to everyone else who replied.
                            --
                            Jorge Almeida
                          • Luc Hermitte
                            I m just addressing some pending questions as the original problem has been solved. ... You can not be sure about that until the day you install a plugin that
                            Message 13 of 28 , Feb 2, 2006
                            • 0 Attachment
                              I'm just addressing some pending questions as the original problem has
                              been solved.

                              * On Thu, Feb 02, 2006 at 09:56:47AM +0000, Jorge Almeida <jalmeida@...> wrote:
                              > >-> %s:/\([ivn]\)map/\1noremap/
                              > > To avoid recursive mappings
                              > OK (But there are no recursive mappings.)

                              You can not be sure about that until the day you install a plugin that
                              overiddes the key sequences used in your mappings.
                              (The same is true with ":normal!")

                              > And what would happen if a mapping ":imap ..." is sourced _first_ and
                              > a conflicting mapping ":inoremap ..." is sourced later?

                              The latest :i*map wil overidde any previous :i*map. In case there is a
                              local (<buffer>) mapping and a global one. The local mapping is the one
                              active, whatever the definitions order is.

                              > >-> :h :map-<buffer>
                              > > Because you are defining ftplugins. You do not want your mapping to
                              > > pollute your other filetypes.
                              > >-> :h :setlocal
                              > > Same reason.
                              > I don't understand. A file in ~/.vim.ftplugin/c/ would be sourced only
                              > when editing a *.c file (right?). How could pollution arise?

                              When I asked this question, I was wondering I you haven't defined things
                              like:
                              " ::::{rtp}/ftplugin/tex/foo.vim ::::
                              imap «aa foo
                              " Yes, two "a"'s

                              " ::::{rtp}/ftplugin/cpp/bar.vim
                              imap «a bar
                              " Only one "a"

                              And then using vim in such a way
                              :e /tmp/foo.tex
                              :sp /tmp/bar.cpp
                              a«a

                              > >Having global and recursive mappings defined in several places may be
                              > >a very good explanation to misbehaviors. But, I do not see any direct
                              > >link to what you experience.
                              > Aren't the files in ~/.vim.ftplugin/c/ sourced _after_ ~/.vimrc? And a
                              > mapping in the former would not override a mapping in the latter?

                              It can be polluted very easilly. Some
                              :inoremap bar «a
                              anywhere would have nullified the work of your mapping on «a

                              --
                              Luc Hermitte
                              http://hermitte.free.fr/vim/
                            • Jorge Almeida
                              ... Thank you, I ll keep the whole thread archived. The problem sums up to this: I had an old plugin file, utf-8 encoded, whereas all new files are latin1. By
                              Message 14 of 28 , Feb 2, 2006
                              • 0 Attachment
                                On Fri, 3 Feb 2006, Luc Hermitte wrote:

                                > I'm just addressing some pending questions as the original problem has
                                > been solved.
                                >
                                Thank you, I'll keep the whole thread archived.

                                The problem sums up to this: I had an old plugin file, utf-8 encoded,
                                whereas all new files are latin1. By "old" I mean created before I
                                reinstalled the system, when I had utf-8 as default.

                                Regards,

                                Jorge Almeida
                              • A. J. Mechelynck
                                ... Any plugin written in other than 7-bit ASCII should beware of encoding problems. In general, IMHO the simplest possible encoding should be used, both as
                                Message 15 of 28 , Feb 2, 2006
                                • 0 Attachment
                                  Jorge Almeida wrote:
                                  > On Fri, 3 Feb 2006, Luc Hermitte wrote:
                                  >
                                  >> I'm just addressing some pending questions as the original problem has
                                  >> been solved.
                                  >>
                                  > Thank you, I'll keep the whole thread archived.
                                  >
                                  > The problem sums up to this: I had an old plugin file, utf-8 encoded,
                                  > whereas all new files are latin1. By "old" I mean created before I
                                  > reinstalled the system, when I had utf-8 as default.
                                  >
                                  > Regards,
                                  >
                                  > Jorge Almeida
                                  >
                                  >
                                  >

                                  Any plugin written in other than 7-bit ASCII should beware of encoding
                                  problems. In general, IMHO the "simplest" possible encoding should be
                                  used, both as 'fileencoding' for the script and mentioned in
                                  ":scriptencoding". For instance, the character « (left double angle
                                  quotation mark) exists in both latin1 and Unicode; many other encodings
                                  lack it. You should seriously hesitate before using it in a mapping's
                                  {lhs} in Vim, because it is not portable. If you decide to use it, it
                                  may be better to encode the script containing it with ":set
                                  fileencoding=latin1" and possibly include in it the line "scriptencoding
                                  latin1". This guarantees that the script will be readable both with
                                  'encoding' set to UTF-8 and set to latin1: When 'encoding' is set to
                                  UTF-8, Vim can read any file (with appropriate settings and commands);
                                  OTOH, when 'encoding' is set to latin1, it can read only the 256
                                  characters defined in the ISO-8859-1 norm. It _can_ translate them from
                                  other encoding which possess the same characters at a different place,
                                  or represented by a different byte (or sequence of bytes), but only if
                                  compiled with +multi_byte (though, for some of those "other" encodings,
                                  Vim will require the external iconv library); and (still with 'encoding'
                                  set to latin1) Vim cannot represent "sensibly" in memory any character
                                  (in a file in a different encoding) which has no representation in
                                  Latin1. If a script is in UTF-8 and includes many different Unicode
                                  codepoints (such as English, Russian, Greek, Arabic and Chinese text in
                                  the same file, maybe in quoted strings or in comments ;-) ) it won't be
                                  readable if 'encoding' is set to any non-Unicode setting, so in that
                                  case it should begin by setting 'encoding' to UTF-8. This in turn may
                                  create additional problems though, so the following (untested) may be
                                  needed:

                                  if &termencoding == ""
                                  let &termencoding = &encoding
                                  endif
                                  set encoding=utf8
                                  windo if (&l:buftype != "nofile")
                                  \ && (&l:buftype != "nowrite")
                                  \ | edit %
                                  \ | endif
                                  " setglobal bomb " optional, uncomment if wanted
                                  " set fencs=ucs-bom,utf8,latin1 " v7 Vim does this automagically
                                  scriptencoding utf8


                                  Best regards,
                                  Tony.
                                • Jorge Almeida
                                  ... I know, the problem is that ASCII characters are usually needed for something other than mappings, so I ve chosen a character that is otherwise useless.
                                  Message 16 of 28 , Feb 3, 2006
                                  • 0 Attachment
                                    On Fri, 3 Feb 2006, A. J. Mechelynck wrote:

                                    >
                                    > Any plugin written in other than 7-bit ASCII should beware of encoding
                                    > problems. In general, IMHO the "simplest" possible encoding should be
                                    > used, both as 'fileencoding' for the script and mentioned in
                                    > ":scriptencoding". For instance, the character « (left double angle
                                    > quotation mark) exists in both latin1 and Unicode; many other encodings
                                    > lack it. You should seriously hesitate before using it in a mapping's
                                    >
                                    I know, the problem is that ASCII characters are usually needed for
                                    something other than mappings, so I've chosen a character that is
                                    otherwise useless. OK, I might use '`' (and setup the keyboard so that
                                    the '»' would yield '`' instead). But what about the marker to jump out
                                    of braces? Currently I have
                                    {}®
                                    The ® is both _visible_ and otherwise useless. Something like <> or <<>>
                                    is certainly visible but is somewhat visually "heavy". (An editor named
                                    alpha, for the old Macintosh, used a "bullet". Excelent choice...)

                                    Best regards,

                                    Jorge
                                  • A. J. Mechelynck
                                    ... Well, of course you should use what fits you best; but in general I recommend using F keys for the {lhs} of Vim mappings. Some people, however, have told
                                    Message 17 of 28 , Feb 3, 2006
                                    • 0 Attachment
                                      Jorge Almeida wrote:
                                      > On Fri, 3 Feb 2006, A. J. Mechelynck wrote:
                                      >
                                      >>
                                      >> Any plugin written in other than 7-bit ASCII should beware of encoding
                                      >> problems. In general, IMHO the "simplest" possible encoding should be
                                      >> used, both as 'fileencoding' for the script and mentioned in
                                      >> ":scriptencoding". For instance, the character « (left double angle
                                      >> quotation mark) exists in both latin1 and Unicode; many other encodings
                                      >> lack it. You should seriously hesitate before using it in a mapping's
                                      >>
                                      > I know, the problem is that ASCII characters are usually needed for
                                      > something other than mappings, so I've chosen a character that is
                                      > otherwise useless. OK, I might use '`' (and setup the keyboard so that
                                      > the '»' would yield '`' instead). But what about the marker to jump out
                                      > of braces? Currently I have
                                      > {}®
                                      > The ® is both _visible_ and otherwise useless. Something like <> or <<>>
                                      > is certainly visible but is somewhat visually "heavy". (An editor named
                                      > alpha, for the old Macintosh, used a "bullet". Excelent choice...)
                                      >
                                      > Best regards,
                                      >
                                      > Jorge

                                      Well, of course you should use what fits you best; but in general I
                                      recommend using F keys for the {lhs} of Vim mappings. Some people,
                                      however, have told me that those keys are "too far for their fingers"
                                      from the home position ASDF-HJKL (or QSDF--JKLM or ...). YMMV.


                                      Best regards,
                                      Tony.
                                    • Luc Hermitte
                                      Hello, ... I m maintaining a plugin [1] that permits to dynamically change the marker (/placeholder characters). The default is «», however I have still
                                      Message 18 of 28 , Feb 8, 2006
                                      • 0 Attachment
                                        Hello,

                                        * On Fri, Feb 03, 2006 at 09:26:12AM +0000, Jorge Almeida <jalmeida@...> wrote:
                                        > I know, the problem is that ASCII characters are usually needed for
                                        > something other than mappings, so I've chosen a character that is
                                        > otherwise useless. OK, I might use '`' (and setup the keyboard so that
                                        > the '»' would yield '`' instead). But what about the marker to jump out
                                        > of braces? Currently I have
                                        > {}®
                                        > The ® is both _visible_ and otherwise useless. Something like <> or <<>>
                                        > is certainly visible but is somewhat visually "heavy". (An editor named
                                        > alpha, for the old Macintosh, used a "bullet". Excelent choice...)

                                        I'm maintaining a plugin [1] that permits to dynamically change the
                                        marker (/placeholder characters). The default is «», however I have
                                        still problems when starting Vim in utf-8 with the default
                                        configuration.

                                        The solution adopted by IMAPS.vim (which history is related to the one
                                        of my bracketing system ; and which is packaged inlatex-suite) is to
                                        have <++> as the default placeholder characters. Which is also the
                                        default setting set by my no-longer-maintained LaTeX ftplugin.

                                        Having two characters is quite useful to insert code-snippets that
                                        expand, for instance, into:
                                        for («container-type»::«const_»iterator b = myvector.begin(),
                                        e = myvector.end()
                                        ; b != e
                                        ; ++b
                                        )
                                        {«code»}«»


                                        [1] http://hermitte.free.fr/vim/ressources/lh-map-tools.tar.gz ;
                                        actually, it does much more than providing a jump-to-marker feature
                                        --
                                        Luc Hermitte
                                        http://hermitte.free.fr/vim/
                                      • Jorge Almeida
                                        ... My problem with plugins in general (not specificaly yours) is that my grasp of the vim scripting language is not good enough to allow me to understand the
                                        Message 19 of 28 , Feb 9, 2006
                                        • 0 Attachment
                                          On Thu, 9 Feb 2006, Luc Hermitte wrote:

                                          >
                                          > I'm maintaining a plugin [1] that permits to dynamically change the
                                          > marker (/placeholder characters). The default is «», however I have
                                          > still problems when starting Vim in utf-8 with the default
                                          > configuration.
                                          >
                                          My problem with plugins in general (not specificaly yours) is that my
                                          grasp of the vim scripting language is not good enough to allow me to
                                          understand the macros and adapt them to my own preferences. And I don't
                                          like to use "packages", which will always have features I don't need and
                                          probably won't even understand. So, I just make a few macros I know I
                                          will use and are good enough for my needs, even if limited in scope.

                                          I wish vim-script were something simple, like, say, Perl...:)

                                          Regards,

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