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

Re: Suggest a vim task for a college workshop

Expand Messages
  • Tony Mechelynck
    ... Rather than Ctrl-D, I would demonstrate wildmenu (Tab) with a help topic. :helpgrep is essential indeed. ... hm. Never used :mkvimrc myself. My vimrc
    Message 1 of 18 , Sep 1, 2009
    • 0 Attachment
      On 25/08/09 19:08, Erik Falor wrote:
      > On Tue, Aug 25, 2009 at 09:25:51AM -0700, Ben Fritz wrote:
      >> 1. Vim is a very powerful tool with plenty of advantages over other
      >> tools.
      >> 2. Vim is complex, but there are ways to learn how to use it
      >> effectively.
      >
      > Most of my colleagues who use Vim at work do not use it to its full
      > potential. For instance, I haven't encountered a single one who was
      > aware of text objects. Most folks are content to learn only 10% of
      > Vim's unique functionality. I suspect that's true for most people who
      > use any software. But it's especially sad in the case of Vim since
      > they really are missing out on a lot.
      >
      > I believe that any approach that emphasizes using Vim's help system
      > will do them the greatest service in the long-term. And if you teach
      > them to effectively search and navigate the help system, it should
      > also have the effect of getting them hooked. You'll be showing them
      > that:
      > 1) Vim isn't really *that* hard because it comes with so much good
      > documentation.
      > 2) Vim has an overwhelming number of features, but I can learn
      > about them at my own pace because I know where to look for
      > help.
      > 3) Vim's normal-mode and ex-mode commands all adhere to
      > well-defined conventions with respect to addresses and motions.
      > Once I master that, it's just a matter of remembering the names
      > of some commands. Oh, there is tab completion for the ex-mode
      > commands! That means I really only need to memorize a few
      > normal mode commands!
      >
      >> Start them out with a pre-configured Vim with a lot of "bells and
      >> whistles" such as syntax highlighting already enabled for them. Maybe
      >> even install a snippet or skeleton plugin that pre-populates most of a
      >> C program for them. TagList would not be out of the question.
      >
      > I would also show off Vim's insert-mode completion capabilities. That
      > is something that programmers coming from an IDE very much rely on.
      >
      >> 3. Vim's help tells you basically EVERYTHING you need to know about
      >> the editor.
      >>
      >> This step is VERY important. Without knowledge of :help, Vim is
      >> basically useless, and a new user will never get beyond basic editing.
      >> If time permits, I would even demonstrate CTRL-D with a :help topic,
      >> and :helpgrep.
      >
      > Please make time to show this aspect of the help system off. I also
      > encourage you to point out that they can use Ctrl-] and Ctrl-T to
      > navigate via helptags.

      Rather than Ctrl-D, I would demonstrate 'wildmenu' (Tab) with a help
      topic. ":helpgrep" is essential indeed.

      >
      > The :options command along with :mkvimrc would be a good thing to
      > throw into a hand-out. Vim is very, very configurable. These
      > commands are a good way to explore all of those settings.

      hm. Never used :mkvimrc myself. My vimrc is something I built little by
      little, starting with

      runtime vimrc_example.vim

      then adding one command (if block, rather) above it when I got messages
      in the "wrong" language

      if has('unix')
      language messages C
      else
      language messages en
      endif

      (I already had a double-boot system by that time, and Windows and Unix
      versions didn't accept the same arguments here)

      the rest came after the call to vimrc_exmple.vim, starting with

      filetype indent off

      after a lot of searching why Vim was high-handedly changing my
      indentation and how to prevent it

      ...etc... (YMMV).

      I did (rather early) check every possible option, but I didn't use
      :mkvimrc, I added the changes, with the appropriate "if has(" or "if
      exists(" wrappers to avoid errors in different versions (such as
      vim-minimal vs. vim-enhanced vs. vim-x11 on Linux, vs. vim.exe vs.
      gvim.exe on Windows.

      >
      > In addition to the great resources Ben Fritz pointed to, you can also
      > direct new users to #vim on irc.freenode.net.
      >

      not to forget the vim_use (and possibly vim_multibyte etc.) Google
      Group, which I don't think Ben mentioned.


      Best regards,
      Tony.
      --
      "Nuclear war can ruin your whole compile."
      -- Karl Lehenbauer

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_use" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... Don t deride Turbo C, I used it on Dos and it already had a decent keyboard-driven editor, plus excellent syntax help on the C language, and it came with
      Message 2 of 18 , Sep 1, 2009
      • 0 Attachment
        On 26/08/09 17:48, Vlad Dogaru wrote:
        >
        > Ben Fritz wrote:
        >>
        >>
        >>
        >> On Aug 25, 8:14 pm, Ken Bloom<kbl...@...> wrote:
        >>>
        >>> When I first got interested in vim, it was because I watched people do
        >>> vi's relatively simple navigation things -- being able to move a word at
        >>> a time, delete a word, replace a word with simple keystrokes.
        >>>
        >>> But I don't think these make for a good tutorial.
        >>>
        >>
        >> Agreed. This is why I suggest having them do it with some rudimentary
        >> knowledge, then doing it in front of them on a projector or something.
        >> They will see all the fancy stuff and a few of them might become
        >> interested.
        >
        > Thanks to everyone for your input. We will probably give them a program
        > and a makefile, so they can use make, copen and friends along with
        > editing. As it is, many of them come from a background of Borland's C++
        > environment, not latest-and-greatest Eclipse and the like, so hopefully
        > we'll get a positive response.
        >
        > Cheers,
        > Vlad

        Don't deride Turbo C, I used it on Dos and it already had a decent
        keyboard-driven editor, plus excellent syntax help on the C language,
        and it came with an outstanding debugger.


        Best regards,
        Tony.
        --
        hundred-and-one symptoms of being an internet addict:
        118. You are on a first-name basis with your ISP's staff.

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_use" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Hari Krishna Dara
        ... I have the same observation. Even those who say they are die-hard fans don t really know much of Vim, but I guess they are really die-hard Vi fans, not
        Message 3 of 18 , Sep 1, 2009
        • 0 Attachment
          On Tue, Aug 25, 2009 at 10:08 AM, Erik Falor<ewfalor@...> wrote:
          > On Tue, Aug 25, 2009 at 09:25:51AM -0700, Ben Fritz wrote:
          >> 1. Vim is a very powerful tool with plenty of advantages over other
          >> tools.
          >> 2. Vim is complex, but there are ways to learn how to use it
          >> effectively.
          >
          > Most of my colleagues who use Vim at work do not use it to its full
          > potential.  For instance, I haven't encountered a single one who was
          > aware of text objects.  Most folks are content to learn only 10% of
          > Vim's unique functionality.  I suspect that's true for most people who
          > use any software.  But it's especially sad in the case of Vim since
          > they really are missing out on a lot.

          I have the same observation. Even those who say they are die-hard fans
          don't really know much of Vim, but I guess they are really die-hard Vi
          fans, not Vim, they simply switched over to Vim, but don't really want
          to learn more. What is funny however is there are people who worked
          for years on Vi on console and still don't know much of Vi. I guess
          these are the folks who would have been satisfied working in windows
          notepad like program, but just happened to begin their work in Vi.

          My recommendation for beginners it to use plain Vi in console (or at
          least Vim in 'compatible' mode on console) and concentrate on the core
          Vi features before trying out the newer Vim features. This was my
          learning path, though mine was natural shift with quite a few years of
          time to play with Vi before I came across Vim.

          --
          HTH,
          Hari

          >
          > I believe that any approach that emphasizes using Vim's help system
          > will do them the greatest service in the long-term.  And if you teach
          > them to effectively search and navigate the help system, it should
          > also have the effect of getting them hooked.  You'll be showing them
          > that:
          >    1) Vim isn't really *that* hard because it comes with so much good
          >       documentation.
          >    2) Vim has an overwhelming number of features, but I can learn
          >       about them at my own pace because I know where to look for
          >       help.
          >    3) Vim's normal-mode and ex-mode commands all adhere to
          >       well-defined conventions with respect to addresses and motions.
          >       Once I master that, it's just a matter of remembering the names
          >       of some commands.  Oh, there is tab completion for the ex-mode
          >       commands!  That means I really only need to memorize a few
          >       normal mode commands!
          >
          >> Start them out with a pre-configured Vim with a lot of "bells and
          >> whistles" such as syntax highlighting already enabled for them. Maybe
          >> even install a snippet or skeleton plugin that pre-populates most of a
          >> C program for them. TagList would not be out of the question.
          >
          > I would also show off Vim's insert-mode completion capabilities.  That
          > is something that programmers coming from an IDE very much rely on.
          >
          >> 3. Vim's help tells you basically EVERYTHING you need to know about
          >> the editor.
          >>
          >> This step is VERY important. Without knowledge of :help, Vim is
          >> basically useless, and a new user will never get beyond basic editing.
          >> If time permits, I would even demonstrate CTRL-D with a :help topic,
          >> and :helpgrep.
          >
          > Please make time to show this aspect of the help system off.  I also
          > encourage you to point out that they can use Ctrl-] and Ctrl-T to
          > navigate via helptags.
          >
          > The :options command along with :mkvimrc would be a good thing to
          > throw into a hand-out.  Vim is very, very configurable.  These
          > commands are a good way to explore all of those settings.
          >
          > In addition to the great resources Ben Fritz pointed to, you can also
          > direct new users to #vim on irc.freenode.net.
          >
          > --
          > Erik Falor
          > Registered Linux User #445632 http://counter.li.org
          >
          > -----BEGIN PGP SIGNATURE-----
          > Version: GnuPG v1.4.9 (GNU/Linux)
          >
          > iEYEARECAAYFAkqUGpoACgkQpMTu6iYtwselPwCffq28KFLp1vQQLiXmi9du00S4
          > xp4An2yfOofSYFo7cMwrVHkBLZPXFDVp
          > =ri5h
          > -----END PGP SIGNATURE-----
          >
          >

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_use" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Tony Mechelynck
          ... I would suggest the opposite, maybe because of /my/ learning path: If you never knew legacy Vi, don t ballast yourself with compatible mode. Run the Vim
          Message 4 of 18 , Sep 19, 2009
          • 0 Attachment
            On 02/09/09 00:41, Hari Krishna Dara wrote:
            >
            > On Tue, Aug 25, 2009 at 10:08 AM, Erik Falor<ewfalor@...> wrote:
            >> On Tue, Aug 25, 2009 at 09:25:51AM -0700, Ben Fritz wrote:
            >>> 1. Vim is a very powerful tool with plenty of advantages over other
            >>> tools.
            >>> 2. Vim is complex, but there are ways to learn how to use it
            >>> effectively.
            >>
            >> Most of my colleagues who use Vim at work do not use it to its full
            >> potential. For instance, I haven't encountered a single one who was
            >> aware of text objects. Most folks are content to learn only 10% of
            >> Vim's unique functionality. I suspect that's true for most people who
            >> use any software. But it's especially sad in the case of Vim since
            >> they really are missing out on a lot.
            >
            > I have the same observation. Even those who say they are die-hard fans
            > don't really know much of Vim, but I guess they are really die-hard Vi
            > fans, not Vim, they simply switched over to Vim, but don't really want
            > to learn more. What is funny however is there are people who worked
            > for years on Vi on console and still don't know much of Vi. I guess
            > these are the folks who would have been satisfied working in windows
            > notepad like program, but just happened to begin their work in Vi.
            >
            > My recommendation for beginners it to use plain Vi in console (or at
            > least Vim in 'compatible' mode on console) and concentrate on the core
            > Vi features before trying out the newer Vim features. This was my
            > learning path, though mine was natural shift with quite a few years of
            > time to play with Vi before I came across Vim.
            >

            I would suggest the opposite, maybe because of /my/ learning path:

            If you never knew legacy Vi, don't ballast yourself with 'compatible'
            mode. Run the Vim tutor, get an elementary vimrc, maybe just


            runtime vimrc_example.vim


            subscribe to the vim_use list (for a start: later you'll add one or more
            of the other lists), make sure you know how to use the help, and start
            editing. Now and then you will call up the help, maybe just to
            understand what the list regulars are talking about, or else to get to
            know some particular feature better than you do yet, then you'll follow
            hotlinks from one help topic to another... soon you'll be addicted to
            Vim (and its help) the way I was to my Dad's 7-volume in-folio
            dictionary when I was in 5th grade.

            Whenever you feel the need to change this or that detail of your Vim's
            default functionality, you'll add a few lines to your vimrc, usually
            below what I showed above, and after a couple of years it will have
            grown beyond recognition while becoming more and more adequate to your
            own style of Vimming.


            Best regards,
            Tony.
            --
            When in panic, fear and doubt,
            Drink in barrels, eat, and shout.

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_use" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Tim Chase
            ... Tony and I are on pretty opposite ends of this spectrum -- his .vimrc is quite a work of art. Mine is merely a handful of settings that fit on half a
            Message 5 of 18 , Sep 19, 2009
            • 0 Attachment
              > Whenever you feel the need to change this or that detail of your Vim's
              > default functionality, you'll add a few lines to your vimrc, usually
              > below what I showed above, and after a couple of years it will have
              > grown beyond recognition while becoming more and more adequate to your
              > own style of Vimming.

              Tony and I are on pretty opposite ends of this spectrum -- his
              .vimrc is quite a work of art. Mine is merely a handful of
              settings that fit on half a screen:

              set nocp vb ai lbr wrap
              set ts=2 sw=2
              set backspace=indent,eol,start
              set cpoptions-=x
              set history=50
              set report=0
              set suffixes+=.pyc suffixes+=.pyo
              syntax on
              colorscheme timchase

              to ignore python precompiled-output files. I try to keep it
              fairly close to stock settings as possible because I jump between
              umpteen machines and don't like to have to keep my .vimrc in
              sync. Tim O'Reilly puts forth similar reasoning on why he
              switched from emacs to vim[1]. I like to be able to jump on a
              machine, fire up vi(m) and have it behave about the same no
              matter where I go. But then that's one of the beautiful things
              about vim -- it more than sufficiently meets both Tony's needs
              and mine despite our dissimilarities.

              -tim


              [1]
              http://oreilly.com/pub/a/oreilly/ask_tim/1999/unix_editor.html





              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_use" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Tony Mechelynck
              ... Dissimilarities or not, I agree 100% with the last sentence above your signature. One of the reasons my vimrc grew (since I came here when Vim 6.1.xxx was
              Message 6 of 18 , Sep 19, 2009
              • 0 Attachment
                On 20/09/09 03:48, Tim Chase wrote:
                >
                >> Whenever you feel the need to change this or that detail of your Vim's
                >> default functionality, you'll add a few lines to your vimrc, usually
                >> below what I showed above, and after a couple of years it will have
                >> grown beyond recognition while becoming more and more adequate to your
                >> own style of Vimming.
                >
                > Tony and I are on pretty opposite ends of this spectrum -- his
                > .vimrc is quite a work of art. Mine is merely a handful of
                > settings that fit on half a screen:
                >
                > set nocp vb ai lbr wrap
                > set ts=2 sw=2
                > set backspace=indent,eol,start
                > set cpoptions-=x
                > set history=50
                > set report=0
                > set suffixes+=.pyc suffixes+=.pyo
                > syntax on
                > colorscheme timchase
                >
                > to ignore python precompiled-output files. I try to keep it
                > fairly close to stock settings as possible because I jump between
                > umpteen machines and don't like to have to keep my .vimrc in
                > sync. Tim O'Reilly puts forth similar reasoning on why he
                > switched from emacs to vim[1]. I like to be able to jump on a
                > machine, fire up vi(m) and have it behave about the same no
                > matter where I go. But then that's one of the beautiful things
                > about vim -- it more than sufficiently meets both Tony's needs
                > and mine despite our dissimilarities.
                >
                > -tim
                >
                >
                > [1]
                > http://oreilly.com/pub/a/oreilly/ask_tim/1999/unix_editor.html

                Dissimilarities or not, I agree 100% with the last sentence above your
                signature. One of the reasons my vimrc grew (since I came here when Vim
                6.1.xxx was current) is that I'm rather sedentary; at one time I ran Vim
                under two different Linux OSes, plus Windows (both native and Cygwin),
                but all on a single triple-boot machine and with a single vimrc (on the
                FAT32 partition with softlinks from $HOME/.vimrc on the other two) --
                that was the most I ever had, and one thing it taught me was to pay
                attention to portability and include if has() and if exists() wherever
                the help mentioned that various versions behave differently, even if all
                those I actually had behaved in fact the same way. "Plan ahead", IOW,
                for the time when a version with different compiled-in features might
                come around.

                If I were to "jump between umpteen machines" as you do, I might keep a
                vimrc and a few homewritten scripts (keymaps, after-ftplugins, maybe
                even my "almost-default" colorscheme, etc.) on a USB key and travel with
                that -- and probably invoke Vim with a -u parameter pointing to that. If
                the employer^Wcustomer wanted me to work for any length of time on a
                machine (or on several) with no USB port and either no Internet access
                or a firewall preventing me from accessing the version of my vimrc that
                I've uploaded on my home site, he'd have to be very, very, very
                $$$convincing$$$ or find someone else to work for him. But then I
                understand that other people have different priorities. For instance I'm
                retired and a bachelor. A 35-years-old with six kids in school might be
                in a much worse bargaining position, even in a two-salary household.


                Best regards,
                Tony.
                --
                hundred-and-one symptoms of being an internet addict:
                133. You communicate with people on other continents more than you
                do with your own neighbors.

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_use" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Hari Krishna Dara
                ... Though my vim setup is elaborate too, often I have to rdp into a completely new windows server to troubleshoot something, and all that I do to feel homely
                Message 7 of 18 , Sep 20, 2009
                • 0 Attachment
                  On Sat, Sep 19, 2009 at 6:48 PM, Tim Chase <vim@...> wrote:
                  >
                  >> Whenever you feel the need to change this or that detail of your Vim's
                  >> default functionality, you'll add a few lines to your vimrc, usually
                  >> below what I showed above, and after a couple of years it will have
                  >> grown beyond recognition while becoming more and more adequate to your
                  >> own style of Vimming.
                  >
                  > Tony and I are on pretty opposite ends of this spectrum -- his
                  > .vimrc is quite a work of art.  Mine is merely a handful of
                  > settings that fit on half a screen:
                  >
                  >   set nocp vb ai lbr wrap
                  >   set ts=2 sw=2
                  >   set backspace=indent,eol,start
                  >   set cpoptions-=x
                  >   set history=50
                  >   set report=0
                  >   set suffixes+=.pyc suffixes+=.pyo
                  >   syntax on
                  >   colorscheme timchase
                  >
                  > to ignore python precompiled-output files.  I try to keep it
                  > fairly close to stock settings as possible because I jump between
                  > umpteen machines and don't like to have to keep my .vimrc in
                  > sync.  Tim O'Reilly puts forth similar reasoning on why he
                  > switched from emacs to vim[1].  I like to be able to jump on a
                  > machine, fire up vi(m) and have it behave about the same no
                  > matter where I go.  But then that's one of the beautiful things
                  > about vim -- it more than sufficiently meets both Tony's needs
                  > and mine despite our dissimilarities.

                  Though my vim setup is elaborate too, often I have to rdp into a
                  completely new windows server to troubleshoot something, and all that
                  I do to feel homely is to install vim (and disable vi 'compatible'
                  mode) and less. I think this is because I don't override any of the
                  regular key combinations, so don't have to depend on existence of any
                  mappings for basic work to get done. I don't try to copy my vimrc and
                  plugins unless I plan to come back repeatedly and spend significant
                  time.

                  --
                  Hari
                  >
                  > -tim
                  >
                  >
                  > [1]
                  > http://oreilly.com/pub/a/oreilly/ask_tim/1999/unix_editor.html
                  >
                  >
                  >
                  >
                  >
                  > >
                  >

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_use" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                Your message has been successfully submitted and would be delivered to recipients shortly.