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

Re: List of suggestions, questions and bugs

Expand Messages
  • Bram Moolenaar
    ... Right. ... Not really. One is using the count, the other is about using . . ... OK. ... OK. ... That is intentional. Double click selects a word, triple
    Message 1 of 16 , Jun 2, 2004
    • 0 Attachment
      Jens Paulus wrote:

      > when reading :help visual.txt I found the following things.
      > In line 54 the tilde command is mentioned but not the U command which is
      > also an exception and makes the highlighted text uppercase.

      Right.

      > Lines 126-140 and lines 319-328 describe the same thing twice.

      Not really. One is using the count, the other is about using ".".

      > Change line 118 from
      > <LeftRelease> This works like a <LeftMouse>, if it is not a
      > to
      > <LeftRelease> This works like a <LeftMouse>, if it is not at

      OK.

      > In :help gui.txt I found the following thing.
      > Change line 190 from
      > is on the left halve, the right scrollbar column will contain scrollbars for
      > to
      > is on the left half, the right scrollbar column will contain scrollbars for

      OK.

      > Here are a number of other things. I was not subscribed to the list the
      > last time, so I wrote it down for a later.
      >
      > 1. Visual mode
      > When double clicking with the left mouse button on a character to start
      > characterwise visual mode, the highlight starts with the whole word not
      > only with this character, I do not know if this is normal.

      That is intentional. Double click selects a word, triple click a line,
      quadruple click a block (if you manage to do this in one spot...).
      Selecting a single character is done by pressing the left button and
      dragging.

      > 2. Cursor position
      > If on a line like
      > abcdefgh
      > the characters cdef are highlighted and yanked and 4v is typed to
      > visually highlight 16 characters, which are more than the line consists
      > of, and v is typed again to leave visual mode, the cursor remains on
      > column $+1 which may be considered a bug according to the current cursor
      > positioning philosophy.

      Looks like it. It's actually worse: "h" doesn't move the cursor left.
      I'll fix that.

      > 3. Inner paragraphs
      > If I have some paragraphs like
      > ---- Line 0 ----
      > first paragraph
      > first paragraph
      >
      >
      > second paragraph
      > second paragraph
      >
      >
      > third paragraph
      > third paragraph
      >
      >
      > fourth paragraph
      > fourth paragraph
      > ----------------
      > and the cursor is in line 3 which is the first empty line in the example
      > above then the commands 2dip and 3dip have the same result, also d4ip
      > and d5ip have the same result. The results are wrong for the odd counts
      > because then the paragraphs should be concatenated and appended to each
      > other which is done only if 1 is the count.

      "3dip" should delete the trailing white lines. I'll see if that can be
      fixed.

      > 4. Deleting words
      > If I have a sentence like
      >
      > This is an example long sentence, it is finished soon I hope.
      >
      > and I delete the two words "long sentence" with 2daw I get
      >
      > This is an example , it is finished soon I hope.
      >
      > But if I enter daw daw I get this.
      >
      > This is an example, it is finished soon I hope.
      >
      > I think in both cases the result should be the daw daw result. The same
      > is with the two words "I hope" at the end of the example sentence. Also,
      > if a sentence is not terminated with a . and I type 2daw on the second
      > last word, no trailing space should be there. For example, if the cursor
      > is on the word Text in "Text objects" below and I type 4daw there should
      > be 5. without a trailing space.

      I'll see if that can be fixed.

      > 5. Text objects backwards direction
      > The next thing is that I suggest to add the object selectors I and A to
      > work like i and a in text objects, but just in the opposite direction,
      > backwards. For example, typing 2dIs should delete the current and
      > previous or two previous inner sentences and d2Ap should delete the
      > current and previous or last two a paragraphs. I also suggest to create
      > the commands yY and dD to yank and delete the current and count-1
      > previous lines. It does not disturb me that yy on a line does not put
      > the cursor to the column 1 but I was wondering if this is consistent.

      Although this is not a bad idea, we should be careful with the few
      characters that we still have available to make commands. We could use
      something like "2di-s", where the "-" indicates selecting backwards.

      It's not difficult to first move the cursor back to the area you want to
      operate upon. For example, "(" takes you back one sentence. Thus this
      backwards selection isn't really needed, it's only to turn two commands
      into one.

      > 6. Insert mode
      > Then, I discovered that if I am in Insert mode and press META-key
      > what happens is that the key command of Normal mode is executed and
      > Insert mode is left. I think this is not listed in the manual and I am
      > not sure if this should be like this.

      This probably means your terminal puts an ESC before the actual key when
      META is used. That is a bug in your terminal, this is an ambiguous way
      to use META, it produces escape sequences that are not according to the
      termcap/terminfo entries.

      > 7. Error message not highlighted
      > Doing :g//norm G triggers an error. The error message is not colored and
      > highlighted like the other error messages.

      This is not really an error but a normal message. The E486 should not
      be used here. I won't change it right now, it would cause trouble for
      the translations.

      > 8. Bottom line
      > When I have a text and not all of the lines fit on one screen so that I
      > cannot see the bottom of this text and I delete as many lines as are
      > needed to see the bottom with either dd or 2dd then the statusline does
      > not display "Bot" as it should, but it does only after moving the
      > cursor. It seems to work correctly with 3dd and 4dd or a greater count.

      Right, when the line count changes the ruler isn't updated. I'll fix
      that.

      > 9. Repeating commands
      > When using the ; or , command to repeat a previous t or T command these
      > commands should jump to before the next matching character in the given
      > search direction again and again and not stay at the position before the
      > first found matching character. The commands t and T and ; and , also do
      > not work right with a count because they only jump count-1 positions
      > further and not count positions further as it should be if the start
      > position is a matching destination position. The current behaviour is an
      > obvious bug.

      These commands work as intended. I don't see why you call this a bug.
      Compare with Vi, these commands should behave the same way in Vim and Vi.

      > 10. Additional motion commands wanted
      > Using blockwise visual mode every now and then, I found there should be
      > commands for moving the cursor to the last and first line of a paragraph
      > while keeping the column position. I think CTRL-J and CTRL-K could be
      > used for this or CTRL-| as a switch to toggle between these positions,
      > but this would perhaps not be so useful with a given count to go count-1
      > paragraphs further.

      You could make a mapping for this. These movements are too specific
      to add a new command for.

      > 11. Paragraph termination
      > Maybe it would be useful if the a flag in formatoptions is present to
      > optionally consider a paragraph as ended if a trailing space is present
      > at the end of the line. If the end of line is already checked for the
      > presence of a trailing space with the w flag in formatoptions, this
      > would just be the inverse of it.

      I've never seen this method to mark the end of a paragraph. Using
      trailing space to indicate the paragraph continues already is a strange
      way to do formatting. It is quite common though.

      > 12. Opening a file in a new window
      > Finally I want to ask if it is possible to enter on the command line
      > something like "vim -someoption file" and it would be checked if a
      > running vim is already there, if no, open a new vim with the file, if
      > yes, open the file in a new window of the running vim just if I would
      > have entered ":split file" there. By the way, entering something like
      > ":_split file" would be fine to open the file in a maximum sized new
      > window, like entering ":split file" CTRL-W_. I suggested this already.

      These things are easily done with a function, mapping or user command.
      Generally, if something can already be done with two or more commands,
      and it's not something that everybody regularly uses, you can either
      type those two commands or find a solution yourself.

      --
      Now it is such a bizarrely improbable coincidence that anything as
      mind-bogglingly useful as the Babel fish could have evolved purely by chance
      that some thinkers have chosen to see it as a final and clinching proof of the
      NON-existence of God.
      The argument goes something like this: 'I refuse to prove that I exist,' says
      God, 'for proof denies faith, and without faith I am nothing.'
      'But,' says Man, 'the Babel fish is a dead giveaway, isn't it? It could not
      have evolved by chance. It proves you exist, and so therefore, by your own
      arguments, you don't. QED.'
      'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a
      puff of logic.
      'Oh, that was easy,' says Man, and for an encore goes on to prove that black
      is white and gets himself killed on the next pedestrian crossing.
      -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

      /// 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 ///
    • Jens Paulus
      Hi Yakov, ... It is Solaris and xterm. ... Yes, this is exactly what I see. ... thank you for your little script. However, in my understanding the loop is
      Message 2 of 16 , Jun 2, 2004
      • 0 Attachment
        Hi Yakov,

        On Wed, Jun 02, 2004 at 12:36:45 +0200, Yakov Lerner wrote:
        > >6. Insert mode
        > >Then, I discovered that if I am in Insert mode and press META-key
        > >what happens is that the key command of Normal mode is executed and
        > >Insert mode is left. I think this is not listed in the manual and I am
        > >not sure if this should be like this.
        >
        > Which OS and which terminal emulator you are using ?

        It is Solaris and xterm.

        > What you describe happens with non-GUI vim under some terminal
        > emulators -- those which generate escape-sequences for META-characters.
        > The actually generated escape-sequences are <ESC>a .. <ESC>z.
        > You must manually configure vim to recognize escape-sequences
        > as META-characters. Terminal emulators which generate
        > <ESC>a..<ESC>z for META-keys are: rxvt (unix), putty (PC),
        > teraterm (PC).
        >
        > Here's how to fix this on vim side:
        > --
        > - check what your META-keys generate:
        > i<press Ctrl-V><press Meta-A>
        >
        > if you see ^[a (that is, escape character followed by something),
        > then add this snippet to your vimrc:

        Yes, this is exactly what I see.

        > " fix meta-keys which generate <esc>a .. <esc>z
        > let c='a'
        > while c != 'z'
        > exec "set <M-".toupper(c).">=\e".c
        > exec "imap \e".c." <M-".toupper(c).">"
        > let c = nr2char(1+char2nr(c))
        > endw

        thank you for your little script. However, in my understanding the loop
        is executed one time too less often, that means it works for the letters
        a to y but for z it is not done. It should be better like this.

        wh char2nr(c) <= char2nr('z')
        ....
        endw

        Or, based on the ASCII table, best would be this.

        wh c != '{'
        ....
        endw

        Right now, I tested your script and it does not work like it should.
        When pressing <Esc> to leave the Insert mode I have to wait a short time
        for the next normal command to work correctly. Typing a normal command
        shortly after pressing <Esc> to leave Insert mode results in strange
        characters being inserted. This seems because of the imap mapping.

        > Alternatively, to fix META-keys definitions manually key-by-key:
        > set <M-A>=<press Ctrl-V><press Meta-A>
        > :imap <press ctrl-v><press Esc>a <M-A>
        > ; repeat for each META-key.

        This also does not work right. The same described problem occurs. Each
        key of the alphabet that is redefined like this cannot be used directly
        after leaving Insert mode to give a Normal mode command. Also, after
        redefining like you suggested I entered :imap <M-B> abcdefgh and
        abcdefgh was not inserted when pressing <M-B> in Insert mode.

        Best regards

        Jens
      • Jens Paulus
        Hi Bram, ... well, I think if there will be a text objects backward direction then it should be available for all text objects. Otherwise one must always think
        Message 3 of 16 , Jun 2, 2004
        • 0 Attachment
          Hi Bram,

          On Wed, Jun 02, 2004 at 12:29:59 +0200, Bram Moolenaar wrote:
          > > 5. Text objects backwards direction
          > > The next thing is that I suggest to add the object selectors I and A to
          > > work like i and a in text objects, but just in the opposite direction,
          > > backwards. For example, typing 2dIs should delete the current and
          > > previous or two previous inner sentences and d2Ap should delete the
          > > current and previous or last two a paragraphs. I also suggest to create
          > > the commands yY and dD to yank and delete the current and count-1
          > > previous lines. It does not disturb me that yy on a line does not put
          > > the cursor to the column 1 but I was wondering if this is consistent.
          >
          > Although this is not a bad idea, we should be careful with the few
          > characters that we still have available to make commands. We could use
          > something like "2di-s", where the "-" indicates selecting backwards.
          >
          > It's not difficult to first move the cursor back to the area you want to
          > operate upon. For example, "(" takes you back one sentence. Thus this
          > backwards selection isn't really needed, it's only to turn two commands
          > into one.

          well, I think if there will be a text objects backward direction then it
          should be available for all text objects. Otherwise one must always
          think before using one if it will work or not. All text objects have
          been developed to turn several commands into one for faster editing. If
          you mean this is not needed then I wonder why the text objects are there
          at all.

          > > 6. Insert mode
          > > Then, I discovered that if I am in Insert mode and press META-key
          > > what happens is that the key command of Normal mode is executed and
          > > Insert mode is left. I think this is not listed in the manual and I am
          > > not sure if this should be like this.
          >
          > This probably means your terminal puts an ESC before the actual key when
          > META is used. That is a bug in your terminal, this is an ambiguous way
          > to use META, it produces escape sequences that are not according to the
          > termcap/terminfo entries.

          The strange thing with this is that, for example, if I enter META-A in
          Insert mode, the letter "a" is displayed in the cursor for about three
          quarters of a second or so and if the cursor was in column 1 the cursor
          is moved to column 2, like it is expected because the Normal mode
          command "a" moves the cursor. But if the cursor was not in the first
          column when META-A was pressed, the column position is not changed.

          When pressing META-B in Insert mode, then "b" is displayed in the cursor
          for a short time and the cursor is moved to the beginning of the
          previous word no matter in which column it was before. Insert mode is
          left.

          When pressing META-W in Insert mode, then "w" is displayed in the cursor
          for a short time and the cursor is moved to the beginning of the next
          word only if the cursor was in the first column. Insert mode is left.

          In Normal mode, META-B and META-W work like the b and w commands.

          > > 9. Repeating commands
          > > When using the ; or , command to repeat a previous t or T command these
          > > commands should jump to before the next matching character in the given
          > > search direction again and again and not stay at the position before the
          > > first found matching character. The commands t and T and ; and , also do
          > > not work right with a count because they only jump count-1 positions
          > > further and not count positions further as it should be if the start
          > > position is a matching destination position. The current behaviour is an
          > > obvious bug.
          >
          > These commands work as intended. I don't see why you call this a bug.
          > Compare with Vi, these commands should behave the same way in Vim and Vi.

          Repeating commands should repeat the given command. Suppose I have a
          sentence like this.

          This is a very short sentence.
          ^ ^ ^ ^
          If the cursor is at the beginning of the sentence and I enter tete or
          te; then I expect the cursor to be on the s of sentence.

          If the cursor is at the beginning of the sentence and I enter te;;; then
          I expect the cursor to be on the c of sentence, passing the letters v,
          s, t on the way to it.

          If the cursor is at the beginning of the sentence and I enter te3; or
          3te; then I also expect the cursor to be on the c of sentence, but only
          passing the characters v like in the first case or t like in the second
          case on the way to it. The commands T and , should work similar.

          The problem is that when giving the commands t and T a count, they are
          repeated count times only if the character to search for is in a column
          greater than col(".")+1 in case of the t command or less than col(".")-1
          in case of the T command, otherwise the repeat happens only count-1
          times. The ; and , commands correctly repeat the wrong number of times.
          This is why entering 2te gives a different result than tete does and
          entering te;; gives a different result than te2; does.

          Also, I think it would be much better if these commands would not stop
          at the boundaries of the current line but continue the search on the
          next or previous line. If one gets on the other line by mistake one can
          easily get back with the corresponding , or ; other direction command.
          But there is no advantage if the search stops.

          The t and T commands are most useful for deleting the rest or beginning
          of the sentence excluding the dot. The dot could be made the default
          character for the ; and , commands if no f, F, t or T has been entered
          before. The search character could also be stored in the file where the
          normal last search pattern or mark positions are stored.

          > > 10. Additional motion commands wanted
          > > Using blockwise visual mode every now and then, I found there should be
          > > commands for moving the cursor to the last and first line of a paragraph
          > > while keeping the column position. I think CTRL-J and CTRL-K could be
          > > used for this or CTRL-| as a switch to toggle between these positions,
          > > but this would perhaps not be so useful with a given count to go count-1
          > > paragraphs further.
          >
          > You could make a mapping for this. These movements are too specific
          > to add a new command for.

          Well, if you think so. See the following mappings.

          map <silent> <C-J> :let colpos=col(".")<Bar>exec "norm }k".colpos."<Bar>"<CR>
          map <silent> <C-K> :let colpos=col(".")<Bar>exec "norm {j".colpos."<Bar>"<CR>

          These mappings work in Normal mode but unexpectly cause the error E481
          in Visual block mode.

          > > 12. Opening a file in a new window
          > > Finally I want to ask if it is possible to enter on the command line
          > > something like "vim -someoption file" and it would be checked if a
          > > running vim is already there, if no, open a new vim with the file, if
          > > yes, open the file in a new window of the running vim just if I would
          > > have entered ":split file" there. By the way, entering something like
          > > ":_split file" would be fine to open the file in a maximum sized new
          > > window, like entering ":split file" CTRL-W_. I suggested this already.
          >
          > These things are easily done with a function, mapping or user command.
          > Generally, if something can already be done with two or more commands,
          > and it's not something that everybody regularly uses, you can either
          > type those two commands or find a solution yourself.

          Alright, but if there is no way to open a file in new window of a
          running Vim from the shell, a shell script also cannot do it.

          Best regards

          Jens
        • Jens Paulus
          Hi Bram, ... well, I understand why the error occurs. Vim tries to apply the commands to the highlighted lines. A function will apparently be needed for it.
          Message 4 of 16 , Jun 2, 2004
          • 0 Attachment
            Hi Bram,

            On Thu, Jun 03, 2004 at 04:29:54 +0200, Jens Paulus wrote:
            > > > 10. Additional motion commands wanted
            > > > Using blockwise visual mode every now and then, I found there should be
            > > > commands for moving the cursor to the last and first line of a paragraph
            > > > while keeping the column position. I think CTRL-J and CTRL-K could be
            > > > used for this or CTRL-| as a switch to toggle between these positions,
            > > > but this would perhaps not be so useful with a given count to go count-1
            > > > paragraphs further.
            > >
            > > You could make a mapping for this. These movements are too specific
            > > to add a new command for.
            >
            > Well, if you think so. See the following mappings.
            >
            > map <silent> <C-J> :let colpos=col(".")<Bar>exec "norm }k".colpos."<Bar>"<CR>
            > map <silent> <C-K> :let colpos=col(".")<Bar>exec "norm {j".colpos."<Bar>"<CR>
            >
            > These mappings work in Normal mode but unexpectly cause the error E481
            > in Visual block mode.

            well, I understand why the error occurs. Vim tries to apply the commands
            to the highlighted lines. A function will apparently be needed for it.

            Best regards

            Jens Paulus
          • Antoine J. Mechelynck
            Jens Paulus wrote: [...] ... This is consistent with the behaviour of a from Insert monde: Esc moves the cursor left unless you re
            Message 5 of 16 , Jun 2, 2004
            • 0 Attachment
              Jens Paulus <jpaulus@...> wrote:
              [...]
              > > > 6. Insert mode
              > > > Then, I discovered that if I am in Insert mode and press META-key
              > > > what happens is that the key command of Normal mode is executed
              > > > and Insert mode is left. I think this is not listed in the manual
              > > > and I am not sure if this should be like this.
              > >
              > > This probably means your terminal puts an ESC before the actual key
              > > when META is used. That is a bug in your terminal, this is an
              > > ambiguous way
              > > to use META, it produces escape sequences that are not according to
              > > the termcap/terminfo entries.
              >
              > The strange thing with this is that, for example, if I enter META-A in
              > Insert mode, the letter "a" is displayed in the cursor for about three
              > quarters of a second or so and if the cursor was in column 1 the
              > cursor
              > is moved to column 2, like it is expected because the Normal mode
              > command "a" moves the cursor. But if the cursor was not in the first
              > column when META-A was pressed, the column position is not changed.

              This is consistent with the behaviour of <Esc>a from Insert monde: Esc moves
              the cursor left unless you're already at column 1; a moves the cursor right,
              ready to "append" after what was under the cursor in Normal mode.
              >
              > When pressing META-B in Insert mode, then "b" is displayed in the
              > cursor
              > for a short time and the cursor is moved to the beginning of the
              > previous word no matter in which column it was before. Insert mode is
              > left.

              What happens if the cursor starts at the start of a word?
              >
              > When pressing META-W in Insert mode, then "w" is displayed in the
              > cursor
              > for a short time and the cursor is moved to the beginning of the next
              > word only if the cursor was in the first column. Insert mode is left.

              w is (count) "word forward". After <Esc>w the cursor should stay put if at
              the start of a word, otherwise move to the next one.
              >
              > In Normal mode, META-B and META-W work like the b and w commands.
              >
              [...]

              I guess in Normal mode they beep.

              All that is consistent with the Meta key being represented as an <Esc>
              prefix.

              See
              :help set-termcap
              :help 'timeout'
              :help 'timeoutlen'
              :help 'ttimeout'
              :help 'ttimeoutlen'

              NB. ":set <M-a>=^[a" etc. (where <M-a> is five characters and ^[ is entered
              by pressing Ctrl-V [or Ctrl-Q] followed by Esc), as mentioned in ":help
              set-termcap" might not work in the GUI, "where key codes are unchangeable".

              HTH,
              Tony.
            • Bram Moolenaar
              ... Selecting a whole sentence actually isn t that simple, especially if you want to include trailing or leading white space. Before text objects existed
              Message 6 of 16 , Jun 3, 2004
              • 0 Attachment
                Jens Paulus wrote:

                > well, I think if there will be a text objects backward direction then it
                > should be available for all text objects. Otherwise one must always
                > think before using one if it will work or not. All text objects have
                > been developed to turn several commands into one for faster editing. If
                > you mean this is not needed then I wonder why the text objects are there
                > at all.

                Selecting a whole sentence actually isn't that simple, especially if you
                want to include trailing or leading white space. Before text objects
                existed several people made complicated mappings for this.

                Moving backwards a number of words, sentences or paragraphs is something
                you need to be able to do anyway. Vi and Vim has always been an editor
                where you need to know a number of basic commands and use them together
                to get things done. Combining two commands into one command you rarily
                use is not in that spirit. Only when it really simplifies things or for
                things people do very often it's useful.

                > The strange thing with this is that, for example, if I enter META-A in
                > Insert mode, the letter "a" is displayed in the cursor for about three
                > quarters of a second or so

                When Vim gets the ESC it's not clear yet what follows. Could be a
                special key sequence. The typed character is then displayed until it's
                clear what was typed. This involves a timeout.

                Before trying to understand what is going, please understand that the
                mechanism to have the META key prepend ESC to the character is a lousy
                mechanism. You should disable it instead of trying to work around the
                problems it causes.

                > > > 9. Repeating commands
                > > > When using the ; or , command to repeat a previous t or T command these
                > > > commands should jump to before the next matching character in the given
                > > > search direction again and again and not stay at the position before the
                > > > first found matching character. The commands t and T and ; and , also do
                > > > not work right with a count because they only jump count-1 positions
                > > > further and not count positions further as it should be if the start
                > > > position is a matching destination position. The current behaviour is an
                > > > obvious bug.
                > >
                > > These commands work as intended. I don't see why you call this a bug.
                > > Compare with Vi, these commands should behave the same way in Vim and Vi.
                >
                > Repeating commands should repeat the given command. Suppose I have a
                > sentence like this.
                >
                > This is a very short sentence.
                > ^ ^ ^ ^
                > If the cursor is at the beginning of the sentence and I enter tete or
                > te; then I expect the cursor to be on the s of sentence.

                If the command is repeated with the cursor at "v", you end up at the
                same character. That's how it works, it stops before the next "e".

                You might argue that it's already at that position and it's not very
                useful to stay there, but that's how it always worked in Vi and I didn't
                think it is useful to be incompatible here. Can't change it now without
                being incompatible. Thus "2te" is different from "tete". You should
                read "2te" as going to the second "e", instead of doing "te" twice.

                Note that using "/e/s-1" does move like you want. A search always moves
                the cursor. The offset wasn't present in Vi thus I was free to make it
                work in a useful way.

                Further suggestions to modify the behavior of these commands are
                pointless, I consider being backwards compatible much more important
                than the details of how these commands work. You should travel back in
                time and explain Bill Joy how he has to do these things. :-)

                > > > 12. Opening a file in a new window
                > > > Finally I want to ask if it is possible to enter on the command line
                > > > something like "vim -someoption file" and it would be checked if a
                > > > running vim is already there, if no, open a new vim with the file, if
                > > > yes, open the file in a new window of the running vim just if I would
                > > > have entered ":split file" there. By the way, entering something like
                > > > ":_split file" would be fine to open the file in a maximum sized new
                > > > window, like entering ":split file" CTRL-W_. I suggested this already.
                > >
                > > These things are easily done with a function, mapping or user command.
                > > Generally, if something can already be done with two or more commands,
                > > and it's not something that everybody regularly uses, you can either
                > > type those two commands or find a solution yourself.
                >
                > Alright, but if there is no way to open a file in new window of a
                > running Vim from the shell, a shell script also cannot do it.

                You can do these things with the client-server functions.

                --
                'Well, here's something to occupy you and keep your mind off things.'
                'It won't work, I have an exceptionally large mind.'
                -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

                /// 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 ///
              • Jens Paulus
                Hi Bram, ... but if the META key generates an ESC character, it is indistinguishable whether the META or the ESC key is pressed. So I think there cannot be a
                Message 7 of 16 , Jun 4, 2004
                • 0 Attachment
                  Hi Bram,

                  On Thu, Jun 03, 2004 at 11:29:06 +0200, Bram Moolenaar wrote:
                  > > The strange thing with this is that, for example, if I enter META-A in
                  > > Insert mode, the letter "a" is displayed in the cursor for about three
                  > > quarters of a second or so
                  >
                  > When Vim gets the ESC it's not clear yet what follows. Could be a
                  > special key sequence. The typed character is then displayed until it's
                  > clear what was typed. This involves a timeout.
                  >
                  > Before trying to understand what is going, please understand that the
                  > mechanism to have the META key prepend ESC to the character is a lousy
                  > mechanism. You should disable it instead of trying to work around the
                  > problems it causes.

                  but if the META key generates an ESC character, it is indistinguishable
                  whether the META or the ESC key is pressed. So I think there cannot be a
                  workaround for it when using the same terminal.

                  > > > > 9. Repeating commands
                  > > > > When using the ; or , command to repeat a previous t or T command these
                  > > > > commands should jump to before the next matching character in the given
                  > > > > search direction again and again and not stay at the position before the
                  > > > > first found matching character. The commands t and T and ; and , also do
                  > > > > not work right with a count because they only jump count-1 positions
                  > > > > further and not count positions further as it should be if the start
                  > > > > position is a matching destination position. The current behaviour is an
                  > > > > obvious bug.
                  > > >
                  > > This is a very short sentence.
                  > > ^ ^ ^ ^
                  > > If the cursor is at the beginning of the sentence and I enter tete or
                  > > te; then I expect the cursor to be on the s of sentence.
                  >
                  > If the command is repeated with the cursor at "v", you end up at the
                  > same character. That's how it works, it stops before the next "e".
                  > You might argue that it's already at that position and it's not very
                  > useful to stay there, but that's how it always worked in Vi and I didn't
                  > think it is useful to be incompatible here. Can't change it now without
                  > being incompatible. Thus "2te" is different from "tete". You should
                  > read "2te" as going to the second "e", instead of doing "te" twice.

                  Right, I think it is not smart to not move the cursor or having to enter
                  2; to go to before the next match.

                  > Note that using "/e/s-1" does move like you want. A search always moves
                  > the cursor. The offset wasn't present in Vi thus I was free to make it
                  > work in a useful way.

                  This is not true, entering /e/s-1 does not do this as I try it. I was
                  thinking of a 'T' flag in 'cpoptions' which starts the search one column
                  next to the cursor position and which continues the search on the
                  previous or next line.

                  > Further suggestions to modify the behavior of these commands are
                  > pointless, I consider being backwards compatible much more important
                  > than the details of how these commands work. You should travel back in
                  > time and explain Bill Joy how he has to do these things. :-)

                  As Vim is supposed to be an improvement from the original editor, being
                  useful is sometimes better than being backwards compatible.

                  By the way, I fear that there is a bug somewhere because it happened
                  that when I typed dt. with a count to delete something it did not work,
                  but I cannot reconstruct it now. Best is to always investigate strange
                  things when they happen.

                  Best regards

                  Jens
                • Jens Paulus
                  Hi Antoine, ... Right. ... Then it also works like pressing b in Normal mode and Insert mode is left, this is no matter in which column the cursor was. ...
                  Message 8 of 16 , Jun 4, 2004
                  • 0 Attachment
                    Hi Antoine,

                    On Thu, Jun 03, 2004 at 05:10:01 +0200, Antoine J. Mechelynck wrote:
                    > > The strange thing with this is that, for example, if I enter META-A in
                    > > Insert mode, the letter "a" is displayed in the cursor for about three
                    > > quarters of a second or so and if the cursor was in column 1 the
                    > > cursor
                    > > is moved to column 2, like it is expected because the Normal mode
                    > > command "a" moves the cursor. But if the cursor was not in the first
                    > > column when META-A was pressed, the column position is not changed.

                    > This is consistent with the behaviour of <Esc>a from Insert monde: Esc moves
                    > the cursor left unless you're already at column 1; a moves the cursor right,
                    > ready to "append" after what was under the cursor in Normal mode.

                    Right.

                    > > When pressing META-B in Insert mode, then "b" is displayed in the
                    > > cursor
                    > > for a short time and the cursor is moved to the beginning of the
                    > > previous word no matter in which column it was before. Insert mode is
                    > > left.
                    >
                    > What happens if the cursor starts at the start of a word?

                    Then it also works like pressing b in Normal mode and Insert mode is
                    left, this is no matter in which column the cursor was.

                    > > When pressing META-W in Insert mode, then "w" is displayed in the
                    > > cursor
                    > > for a short time and the cursor is moved to the beginning of the next
                    > > word only if the cursor was in the first column. Insert mode is left.
                    >
                    > w is (count) "word forward". After <Esc>w the cursor should stay put if at
                    > the start of a word, otherwise move to the next one.

                    Right, it is like you describe.

                    > >
                    > > In Normal mode, META-B and META-W work like the b and w commands.
                    > >
                    > [...]
                    >
                    > I guess in Normal mode they beep.

                    No beep is made. In gvim a terrible beep appears when pressing the ESC
                    key in Normal mode, I suggest to turn this off by default.

                    Best regards

                    Jens
                  • Bram Moolenaar
                    Jens - ... The terminal probably has an option to change this behavior. If not, then use another terminal. ... /e/s-1 works fine for me, no matter if
                    Message 9 of 16 , Jun 4, 2004
                    • 0 Attachment
                      Jens -

                      > On Thu, Jun 03, 2004 at 11:29:06 +0200, Bram Moolenaar wrote:
                      > > > The strange thing with this is that, for example, if I enter META-A in
                      > > > Insert mode, the letter "a" is displayed in the cursor for about three
                      > > > quarters of a second or so
                      > >
                      > > When Vim gets the ESC it's not clear yet what follows. Could be a
                      > > special key sequence. The typed character is then displayed until it's
                      > > clear what was typed. This involves a timeout.
                      > >
                      > > Before trying to understand what is going, please understand that the
                      > > mechanism to have the META key prepend ESC to the character is a lousy
                      > > mechanism. You should disable it instead of trying to work around the
                      > > problems it causes.
                      >
                      > but if the META key generates an ESC character, it is indistinguishable
                      > whether the META or the ESC key is pressed. So I think there cannot be a
                      > workaround for it when using the same terminal.

                      The terminal probably has an option to change this behavior. If not,
                      then use another terminal.

                      > Right, I think it is not smart to not move the cursor or having to enter
                      > 2; to go to before the next match.
                      >
                      > > Note that using "/e/s-1" does move like you want. A search always moves
                      > > the cursor. The offset wasn't present in Vi thus I was free to make it
                      > > work in a useful way.
                      >
                      > This is not true, entering /e/s-1 does not do this as I try it. I was
                      > thinking of a 'T' flag in 'cpoptions' which starts the search one column
                      > next to the cursor position and which continues the search on the
                      > previous or next line.

                      /e/s-1 works fine for me, no matter if 'compatible' is set or not. "2n"
                      moves to the second match. Don't see a problem.

                      > > Further suggestions to modify the behavior of these commands are
                      > > pointless, I consider being backwards compatible much more important
                      > > than the details of how these commands work. You should travel back in
                      > > time and explain Bill Joy how he has to do these things. :-)
                      >
                      > As Vim is supposed to be an improvement from the original editor, being
                      > useful is sometimes better than being backwards compatible.

                      Sometimes, yes. But not always.

                      > By the way, I fear that there is a bug somewhere because it happened
                      > that when I typed dt. with a count to delete something it did not work,
                      > but I cannot reconstruct it now. Best is to always investigate strange
                      > things when they happen.

                      I very much doubt there is a bug in "dt.", since it's an often used
                      command. Perhaps you just typed it wrong?

                      --
                      Microsoft is to software what McDonalds is to gourmet cooking

                      /// 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 ///
                    • George V. Reilly
                      ... From: Bram Moolenaar ... One nice feature that Emacs has had forever is C-h l or view-lossage, which shows the last 100 characters
                      Message 10 of 16 , Jun 4, 2004
                      • 0 Attachment
                        ----- Original Message -----
                        From: "Bram Moolenaar" <Bram@...>

                        > I very much doubt there is a bug in "dt.", since it's an often used
                        > command. Perhaps you just typed it wrong?

                        One nice feature that Emacs has had forever is "C-h l" or view-lossage,
                        which shows the last 100 characters typed. It makes it easier to debug
                        issues like this.

                        --
                        A penny saved is a girl lost.
                        (Get Witty Auto-Generated Signatures from http://SmartBee.org)
                        George V. Reilly george@...
                      • Benji Fisher
                        ... You could try putting after the : . This should remove the range that is automatically inserted when typing : from Visual mode, and I think it will
                        Message 11 of 16 , Jun 7, 2004
                        • 0 Attachment
                          On Thu, Jun 03, 2004 at 04:48:35AM +0200, Jens Paulus wrote:
                          > Hi Bram,
                          >
                          > > > You could make a mapping for this. These movements are too specific
                          > > > to add a new command for.
                          > >
                          > > Well, if you think so. See the following mappings.
                          > >
                          > > map <silent> <C-J> :let colpos=col(".")<Bar>exec "norm }k".colpos."<Bar>"<CR>
                          > > map <silent> <C-K> :let colpos=col(".")<Bar>exec "norm {j".colpos."<Bar>"<CR>
                          > >
                          > > These mappings work in Normal mode but unexpectly cause the error E481
                          > > in Visual block mode.
                          >
                          > well, I understand why the error occurs. Vim tries to apply the commands
                          > to the highlighted lines. A function will apparently be needed for it.

                          You could try putting <C-U> after the : . This should remove the
                          range that is automatically inserted when typing : from Visual mode, and
                          I think it will be harmless when starting in Normal mode. Better than
                          harmless: if you give a count when starting in Normal mode, then it
                          will be ignored with the <C-U> variant instead of generating an error.

                          I like the idea of a function. Among other advantages, it allows
                          you to use local variables instead of your local colpos. You can also
                          make exceptions for the last paragraph of the buffer. (If there is no
                          blank line at the end, then } takes you to the last line, and you do not
                          want to use the "k".)

                          Note that $VIMRUNTIME/macros/matchit.vim illustrates one way to
                          define a new motion: deal with counts, different modes, etc.

                          HTH --Benji Fisher
                        • Jens Paulus
                          Hi Bram, ... sorry for the delay in replying. Entering /e/s-1 places the cursor on the v of very in the given example sentence. The destination jump position I
                          Message 12 of 16 , Jun 11, 2004
                          • 0 Attachment
                            Hi Bram,

                            On Fri, Jun 04, 2004 at 23:04:48 +0200, Bram Moolenaar wrote:
                            > > Right, I think it is not smart to not move the cursor or having to enter
                            > > 2; to go to before the next match.
                            > >
                            > > > Note that using "/e/s-1" does move like you want. A search always moves
                            > > > the cursor. The offset wasn't present in Vi thus I was free to make it
                            > > > work in a useful way.
                            > >
                            > > This is not true, entering /e/s-1 does not do this as I try it. I was
                            > > thinking of a 'T' flag in 'cpoptions' which starts the search one column
                            > > next to the cursor position and which continues the search on the
                            > > previous or next line.
                            >
                            > /e/s-1 works fine for me, no matter if 'compatible' is set or not. "2n"
                            > moves to the second match. Don't see a problem.

                            sorry for the delay in replying. Entering /e/s-1 places the cursor on
                            the v of very in the given example sentence. The destination jump
                            position I wanted is the before the c in sentence in the given example.

                            This is a very short sentence.

                            Entering /c<CR> or 4/e/s-1<CR> does this but it changes the search
                            pattern I previously had.

                            > > > Further suggestions to modify the behavior of these commands are
                            > > > pointless, I consider being backwards compatible much more important
                            > > > than the details of how these commands work. You should travel back in
                            > > > time and explain Bill Joy how he has to do these things. :-)
                            > >
                            > > As Vim is supposed to be an improvement from the original editor, being
                            > > useful is sometimes better than being backwards compatible.
                            >
                            > Sometimes, yes. But not always.

                            You may thing about it again.

                            > > By the way, I fear that there is a bug somewhere because it happened
                            > > that when I typed dt. with a count to delete something it did not work,
                            > > but I cannot reconstruct it now. Best is to always investigate strange
                            > > things when they happen.
                            >
                            > I very much doubt there is a bug in "dt.", since it's an often used
                            > command. Perhaps you just typed it wrong?

                            Well, hopefully. Normally I know the keys I am pressing.

                            Best regards

                            Jens
                          • Jens Paulus
                            Hi Bram, ... sorry, this should be like this. You may think about it again. Best regards Jens
                            Message 13 of 16 , Jun 11, 2004
                            • 0 Attachment
                              Hi Bram,

                              On Fri, Jun 11, 2004 at 17:08:51 +0200, Jens Paulus wrote:
                              > > > As Vim is supposed to be an improvement from the original editor, being
                              > > > useful is sometimes better than being backwards compatible.
                              > >
                              > > Sometimes, yes. But not always.
                              >
                              > You may thing about it again.

                              sorry, this should be like this.

                              You may think about it again.

                              Best regards

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