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

List of suggestions, questions and bugs

Expand Messages
  • Jens Paulus
    Hi Bram, 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
    Message 1 of 16 , Jun 1, 2004
    • 0 Attachment
      Hi Bram,

      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.
      Lines 126-140 and lines 319-328 describe the same thing twice.

      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

      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

      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.

      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.

      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.

      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.

      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.

      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.

      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.

      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.

      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.

      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.

      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.

      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.

      Best regards

      Jens
    • Jens Paulus
      Hi Bram, ... well, the above sentence should make more sense like that. For example, typing 2dIs should delete the current and previous inner sentences and
      Message 2 of 16 , Jun 1, 2004
      • 0 Attachment
        Hi Bram,

        On Tue, Jun 01, 2004 at 23:57:05 +0200, Jens Paulus 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

        well, the above sentence should make more sense like that.

        For example, typing 2dIs should delete the current and previous inner
        sentences and d2Ap should delete the current and previous a paragraphs.

        This is because the cursor is of course always within a paragraph.

        Best regards

        Jens
      • 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 3 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 ///
        • Yakov Lerner
          ... Which OS and which terminal emulator you are using ? What you describe happens with non-GUI vim under some terminal emulators -- those which generate
          Message 4 of 16 , Jun 2, 2004
          • 0 Attachment
            > 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 ?

            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:

            " 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

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

            I put this info into vim tip http://www.vim.org/tips/tip.php?tip_id=738

            Yakov
          • 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.