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

Typo in help file

Expand Messages
  • Tony Mechelynck
    options.txt (latest version) line 2944 there is: * fileignorecase * * wic * * nofileignorecase * * nowic * there should be: * fileignorecase * * fic *
    Message 1 of 8 , Apr 5, 2013
      options.txt (latest version) line 2944

      there is:
      *'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*


      there should be:
      *'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*


      Note that there are two entries for 'wic' in the help tags file (at
      lines 1078 and 1079) but since they issue a search command and not a
      line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
      gives the wrong one, etc.


      Best regards,
      Tony.
      --
      "Nice boy, but about as sharp as a sack of wet mice."
      -- Foghorn Leghorn

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ingo Karkat
      ... Already reported (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J), probably already fixed; Bram s last runtime update is from Mar 19. I d
      Message 2 of 8 , Apr 5, 2013
        On 05-Apr-13 20:14:34 +0200, Tony Mechelynck wrote:

        > options.txt (latest version) line 2944
        >
        > there is:
        > *'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*
        >
        >
        > there should be:
        > *'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*
        >
        >
        > Note that there are two entries for 'wic' in the help tags file (at
        > lines 1078 and 1079) but since they issue a search command and not a
        > line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
        > gives the wrong one, etc.

        Already reported
        (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J),
        probably already fixed; Bram's last runtime update is from Mar 19.

        I'd like to use this occasion to plead for more frequent runtime
        updates, ideally one commit per change (as with the patches), not the
        current bulk updates. It would prevent these issues, we would always
        have an up-to-date Todo list, and could effectively use Mercurial
        features like log and blame for the runtime. (I would not send out patch
        emails for these changes, though.)

        -- regards, ingo

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Tony Mechelynck
        ... ah, sorry, I missed that. ... Well, maybe it s fixed in Bram s private repo but all I have is the public one, https://vim.googlecode.com/hg/ , where (at
        Message 3 of 8 , Apr 5, 2013
          On 05/04/13 20:47, Ingo Karkat wrote:
          > On 05-Apr-13 20:14:34 +0200, Tony Mechelynck wrote:
          >
          >> options.txt (latest version) line 2944
          >>
          >> there is:
          >> *'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*
          >>
          >>
          >> there should be:
          >> *'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*
          >>
          >>
          >> Note that there are two entries for 'wic' in the help tags file (at
          >> lines 1078 and 1079) but since they issue a search command and not a
          >> line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
          >> gives the wrong one, etc.
          >
          > Already reported

          ah, sorry, I missed that.

          > (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J),
          > probably already fixed; Bram's last runtime update is from Mar 19.

          Well, maybe it's fixed in Bram's private repo but all I have is the
          public one, https://vim.googlecode.com/hg/ , where (at changeset
          8653c39b85ea dated Fri Apr 05 19:50:17 2013 +0200 and tagged v7-3-882)
          it is definitely *not* fixed.

          >
          > I'd like to use this occasion to plead for more frequent runtime
          > updates, ideally one commit per change (as with the patches), not the
          > current bulk updates. It would prevent these issues, we would always
          > have an up-to-date Todo list, and could effectively use Mercurial
          > features like log and blame for the runtime. (I would not send out patch
          > emails for these changes, though.)
          >
          > -- regards, ingo
          >


          Best regards,
          Tony.
          --
          It is strictly forbidden to dance on Good Friday
          (real standing law in Germany).

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Ben Fritz
          ... I ve been sitting on a draft email for a few months now that I haven t gotten around to finishing and sending. I d like to take this one step further. The
          Message 4 of 8 , Apr 5, 2013
            On Friday, April 5, 2013 1:47:13 PM UTC-5, Ingo Karkat wrote:
            > Already reported
            >
            > (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J),
            >
            > probably already fixed; Bram's last runtime update is from Mar 19.
            >
            >
            >
            > I'd like to use this occasion to plead for more frequent runtime
            >
            > updates, ideally one commit per change (as with the patches), not the
            >
            > current bulk updates. It would prevent these issues, we would always
            >
            > have an up-to-date Todo list, and could effectively use Mercurial
            >
            > features like log and blame for the runtime. (I would not send out patch
            >
            > emails for these changes, though.)
            >

            I've been sitting on a draft email for a few months now that I haven't gotten around to finishing and sending.

            I'd like to take this one step further. The runtime files are already largely maintained by people other than Bram. Bram, would you be opposed to using Mercurial to PULL changes to runtime files, from a separate public clone of the main Vim repository? Runtime file maintainers who like, could then maintain their files directly in a clone of the Vim repository and push to the "vim-runtime" repository whenever they have a version ready for release.

            This would also facilitate applying "big" patches that happen to large groups of runtime files from time to time, it would allow for wider testing of experimental or cutting-edge runtime updates, and allow for easy "team maintenance" of runtime files where the maintainer agrees.

            The last time I recall seeing a discussion along these lines was here:

            https://groups.google.com/d/topic/vim_dev/XGz56RXff3g/discussion

            I don't think we ever reached consensus there but there was a lot of support for such an idea. Bram, if you might be willing to "pull" runtime updates I think it will work quite well; we can work out the details in a new thread. I am quite busy but it does not take much effort to set up a public repository somewhere and periodically pull changes from a few sources; I'd be willing to help administer a runtime repository if nobody else steps forward.

            I'm envisioning a full clone of the main Vim repository for the vim-runtime repository, except that a policy of "no C code changes" would be strictly enforced.

            Obviously Bram's is the most important voice here, but does anyone else have input on this?

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Bram Moolenaar
            ... The current method is working quite well. There is not much overhead for me. Only disadvantage is that you get ten updates at the same time, every two
            Message 5 of 8 , Apr 5, 2013
              Ben Fritz wrote:

              > On Friday, April 5, 2013 1:47:13 PM UTC-5, Ingo Karkat wrote:
              > > Already reported
              > >
              > > (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J),
              > > probably already fixed; Bram's last runtime update is from Mar 19.
              > >
              > > I'd like to use this occasion to plead for more frequent runtime
              > > updates, ideally one commit per change (as with the patches), not the
              > > current bulk updates. It would prevent these issues, we would always
              > > have an up-to-date Todo list, and could effectively use Mercurial
              > > features like log and blame for the runtime. (I would not send out patch
              > > emails for these changes, though.)
              >
              > I've been sitting on a draft email for a few months now that I haven't
              > gotten around to finishing and sending.
              >
              > I'd like to take this one step further. The runtime files are already
              > largely maintained by people other than Bram. Bram, would you be
              > opposed to using Mercurial to PULL changes to runtime files, from a
              > separate public clone of the main Vim repository? Runtime file
              > maintainers who like, could then maintain their files directly in a
              > clone of the Vim repository and push to the "vim-runtime" repository
              > whenever they have a version ready for release.
              >
              > This would also facilitate applying "big" patches that happen to large
              > groups of runtime files from time to time, it would allow for wider
              > testing of experimental or cutting-edge runtime updates, and allow for
              > easy "team maintenance" of runtime files where the maintainer agrees.
              >
              > The last time I recall seeing a discussion along these lines was here:
              >
              > https://groups.google.com/d/topic/vim_dev/XGz56RXff3g/discussion
              >
              > I don't think we ever reached consensus there but there was a lot of
              > support for such an idea. Bram, if you might be willing to "pull"
              > runtime updates I think it will work quite well; we can work out the
              > details in a new thread. I am quite busy but it does not take much
              > effort to set up a public repository somewhere and periodically pull
              > changes from a few sources; I'd be willing to help administer a
              > runtime repository if nobody else steps forward.
              >
              > I'm envisioning a full clone of the main Vim repository for the
              > vim-runtime repository, except that a policy of "no C code changes"
              > would be strictly enforced.
              >
              > Obviously Bram's is the most important voice here, but does anyone
              > else have input on this?

              The current method is working quite well. There is not much overhead
              for me. Only disadvantage is that you get ten updates at the same time,
              every two weeks or so. I don't think the version history is interesting
              enough that someone misses it.

              A new method with a repository has many new problems:
              - How to control access to the public repository? Only the actual
              maintainer must be allowed to check in changes. So we need a small
              group of people to maintain the access rights.
              - What if the maintainer can't be reached? This happens a lot.
              - I still need to pull for changes once in a while, it is unlikely this
              will happen more often than what happens now.
              - The version in the public respository will differ from what I have. I
              often reject new files or new versions of a file because it contains
              mistakes.
              - etc.

              I think the advantage is theoretical only.

              --
              The difference between theory and practice, is that in theory, there
              is no difference between theory and practice.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Bram Moolenaar
              ... This was already mentioned and fixed. I ll send out the update files after checking for problems. -- I m writing a book. I ve got the page numbers done.
              Message 6 of 8 , Apr 5, 2013
                Tony Mechelynck wrote:

                > options.txt (latest version) line 2944
                >
                > there is:
                > *'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*
                >
                >
                > there should be:
                > *'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*
                >
                >
                > Note that there are two entries for 'wic' in the help tags file (at
                > lines 1078 and 1079) but since they issue a search command and not a
                > line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
                > gives the wrong one, etc.

                This was already mentioned and fixed. I'll send out the update files
                after checking for problems.

                --
                I'm writing a book. I've got the page numbers done.

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ an exciting new programming language -- http://www.Zimbu.org ///
                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Ingo Karkat
                ... Well, I remember at least two occasions where I pulled up the Mercurial log (to answer a Stack Overflow question or investigate why Vim behaved differently
                Message 7 of 8 , Apr 7, 2013
                  On 05-Apr-13 22:16:54 +0200, Bram Moolenaar wrote:

                  > [2 messages deleted]
                  >
                  > The current method is working quite well. There is not much overhead
                  > for me. Only disadvantage is that you get ten updates at the same time,
                  > every two weeks or so. I don't think the version history is interesting
                  > enough that someone misses it.

                  Well, I remember at least two occasions where I pulled up the Mercurial
                  log (to answer a Stack Overflow question or investigate why Vim behaved
                  differently after an update), arrived at the commit, and then didn't
                  know how to proceed. "Updated runtime files" isn't exactly helpful, and
                  the fact that the updates may have originated from any message on
                  vim_dev from the preceding several weeks (or even was prompted by a
                  private message to Bram) makes searching for the reason tedious.

                  I think there should be the same level of accountability for runtime
                  updates in Mercurial; it's not so much more work to commit each change
                  separately and provide a short suitable message. It's less about the
                  timeliness; I'm fine with biweekly updates.

                  > [13 lines deleted]

                  -- regards, ingo

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Benjamin Fritz
                  ... Obviously if it doesn t work for you, then it doesn t work. But, while the current method works great for you, it s not as nice for the maintainers.
                  Message 8 of 8 , Apr 8, 2013
                    On Friday, April 5, 2013 3:16:54 PM UTC-5, Bram Moolenaar wrote:
                    > Ben Fritz wrote:
                    > >
                    > > I'd like to take this one step further. The runtime files are already
                    > > largely maintained by people other than Bram. Bram, would you be
                    > > opposed to using Mercurial to PULL changes to runtime files, from a
                    > > separate public clone of the main Vim repository? Runtime file
                    > > maintainers who like, could then maintain their files directly in a
                    > > clone of the Vim repository and push to the "vim-runtime" repository
                    > > whenever they have a version ready for release.
                    > >
                    > The current method is working quite well. There is not much overhead
                    > for me. Only disadvantage is that you get ten updates at the same time,
                    > every two weeks or so. I don't think the version history is interesting
                    > enough that someone misses it.
                    >

                    Obviously if it doesn't work for you, then it doesn't work.

                    But, while the current method works great for you, it's not as nice for the
                    maintainers.

                    Conceptually, all the runtime files are part of Vim. They should be
                    maintainable within a clone of the Vim repository. New potential
                    contributors who want to change something should be able to get a clone of
                    the Vim repository and start hacking. If every maintainer works in their own
                    little custom repository it causes headaches in merging later.

                    If a maintainer DOES choose to edit their files in a clone of Vim's
                    repostory, they face the problem that none of their commits will ever be an
                    ancestor of any commits on trunk. So they will have their own personal
                    branch forever. I've made my branch explicit in my clone for TOhtml to make
                    things easier to keep track of, but it is still quite annoying when I go to
                    make an update after a long absence, because I need to merge in a bunch of
                    files from the default branch, even though the TOhtml files I'm pulling in
                    are identical (minus timestamps).

                    Finally, as Ingo points out, tracking what changed in any given runtime
                    update is tricky. This would be easier if you could see the history. I DO
                    think the history is interesting, and I don't think anything would be lost
                    by showing it, "warts and all" as Mercurial types like to say. You would
                    still presumably tag each C code update, and would pull/merge runtime
                    updates in batches, so the "main" line of the default branch would remain
                    much the same as it is now. The only difference is that runtime updates
                    would have a second parent which could be examined to see what changed and
                    how.

                    > A new method with a repository has many new problems:
                    > - How to control access to the public repository? Only the actual
                    > maintainer must be allowed to check in changes. So we need a small
                    > group of people to maintain the access rights.

                    I was thinking that a small team of only a few people would control the
                    public vim-runtime or vim-unstable or whatever repository. They get changes
                    from maintainers on vim_dev and do a quick review before pushing to the
                    repository. Maintainers could email files as they have been doing, but would
                    be encouraged to set up a clone of the vim repository as well so that the
                    vim-runtime admins can just pull the changes with Mercurial as well.

                    > - What if the maintainer can't be reached? This happens a lot.

                    This is a separate problem that happens now as well. I don't see using
                    Mercurial causing any additional problems in this area. And it could make
                    things better. Some maintainers might opt for a more team-maintenance mode
                    for their files so that if they don't respond for a while, important patches
                    like the 'cpo' handling can be applied without them. Other maintainers might
                    drop out for a while, but will easily be able to see what changes have been
                    made and against which version of their files when and if they come back.

                    > - I still need to pull for changes once in a while, it is unlikely this
                    > will happen more often than what happens now.

                    That's OK. If users are interested in getting changes faster, they can pull
                    them into their own private repository clone. Otherwise, they can wait for
                    your blessing on a "stable" version. Right now there is no way for users to
                    get changes faster unless the maintainer CCs vim_dev when sending you a new
                    version.

                    And I agree with Ingo here, I don't care as much about the speed of updates,
                    as I care about being able to see quickly what happened in those updates.
                    Currently when you push a set of revisions, I glance at the commit log for
                    each C code change, but I then go into every runtime file of interest to me
                    and examine the changes to figure out what happened there. You could make
                    this a lot better by writing brief summaries of the content of those runtime
                    updates.

                    Since Vim is already developed in Mercurial, I think it would be less work
                    for you to just make the changelog of the runtime files visible to anybody
                    interested in what changes were made and why.

                    > - The version in the public respository will differ from what I have. I
                    > often reject new files or new versions of a file because it contains
                    > mistakes.

                    It may differ somewhat, but if you make changes also in Mercurial those will
                    be tracked as well. I presume you normally alert the maintainer if there are
                    problems; the maintainer can fix them before you pull instead.

                    >
                    > I think the advantage is theoretical only.

                    I think the advantage is flexibility. Your workflow is working for a lot of
                    people. Heck, it's actually working for me. I just think it could be a
                    little better and a little smoother around the edges, and I think the
                    community as a whole could benefit from Mercurial being used closer to its
                    full potential.

                    If you're still not open to the idea, I'll drop it now, but I thought I'd
                    speak up while the subject was fresh again.

                    And since I suppose I've hijacked Ingo's request, I'd also like you to
                    consider at least adding a summary of changes for runtime updates, if you
                    don't like the idea of pulling in all the development history.
                    One-commit-per-update would also work if it had a succinct summary like the
                    patch updates (but you don't need to send an email for each probably).

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  Your message has been successfully submitted and would be delivered to recipients shortly.