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

34266Re: Small nit in the manual

Expand Messages
  • Benji Fisher
    Jan 2, 2004
      > On Thu, Jan 01, 2004 at 09:06:25PM -0500, Fran├žois Pinard wrote:
      > > Hi, people. Would you check if the following diff is appropriate? I

      On Thu, Jan 01, 2004 at 10:20:33PM -0500, Fran├žois Pinard wrote:
      > [Benji Fisher]
      > > I agree with the content of your change. As for format, I prefer to
      > > use the same one as the official patches: context-style diffs (diff
      > > -c) generated from the top-level distribution directory. Something
      > > like this for a single file:
      > This is annoying... Some maintainers like context diffs and hate
      > unidiffs, other maintainers just want the contrary. I find it difficult
      > to remember, for every tool I use, what are the little whims of each
      > maintainer. They all try to educate me into their particular habits.

      I am sorry. I interpreted the first line quoted above as asking
      for advice on the format as well as the content of the diff.

      > Plain diffs, I would understand. But context diffs or unidiffs are
      > fully equivalent, and moreover, there are tools converting between
      > both, which maintainers should silently use for themselves. (I think I
      > even have one somewhere in my distributions, contributed long ago by an
      > employee from Borland. There are others floating around, as well.)

      I think the main reason for preferring context diffs is that some
      versions of patch cannot deal with the unified format. Perhaps I should
      have stressed that this is a preference, not a requirement: most
      readers of this list can deal with either type, but context diffs are
      more convenient for a minority.

      > Times have changed. Not so long ago, I would have written a very simple
      > message directly to the maintainer that a "not" word was missing,
      > quoting the document and the sentence, and this would have fully
      > sufficient, and plain welcome. In this case, I ought to make the effort
      > of prematurely subscribing to the `vim-dev' mailing list (working my
      > way around a slightly broken robot, but this is another matter), and
      > producing a diff for this tiny nit, well aware that a diff is likely
      > overkill: a simple and quick Vim session is probably much more efficient
      > than `patch' in this case. You scrutinise diffs anyway, don't you! :-)
      > I spent nearly an hour for a single word, and you're still not happy?

      A bug in the documentation can be reported to bugs@... (which
      goes to Bram Moolenaar) just like any other bug. This address does not
      require any subscription. I just appended a note to this effect to my
      tip at http://www.vim.org/tips/tip.php?tip_id=618 .

      I agree that, in this case, a patch is overkill. In my experience,
      Bram is more than happy to accept informal notes about such corrections.

      :help bugs
      :help design-documented

      > On the other hand, it could have been much worse, and you might have
      > thrown bug trackers at me :-). Who knows, I may adapt to these blatant
      > failures of UI-design, but for now, I just refuse to contribute when
      > maintainers want me to spend hours studying concepts and fighting bugs
      > of their new Web toys, each maintainer his own, for acquiring the right
      > of submitting a report. I wish Vim never goes there! For the packages
      > I maintained or maintain, I warmly receive reports and suggestions as
      > worth contributions, and value the time of the submitters too, not only
      > mine. I'm reasonable, and they are. One of these days, I'll write a
      > Web page for moaning all my soul about the current trends :-).

      I think we all try to be reasonable. I am sorry for the waste of
      time, especially since I am probably partly responsible. At least, I
      expect it to be a one-time cost.

      --Benji Fisher
    • Show all 10 messages in this topic