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

Re: Typo in help file

Expand Messages
  • 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 1 of 8 , Apr 5 12:10 PM
    View Source
    • 0 Attachment
      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 2 of 8 , Apr 5 12:10 PM
      View Source
      • 0 Attachment
        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 3 of 8 , Apr 5 1:16 PM
        View Source
        • 0 Attachment
          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 4 of 8 , Apr 5 1:16 PM
          View Source
          • 0 Attachment
            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 5 of 8 , Apr 7 6:24 AM
            View Source
            • 0 Attachment
              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 6 of 8 , Apr 8 9:22 PM
              View Source
              • 0 Attachment
                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.