| Message ID | patch-3.3-9da5bc4a0c-20210512T084137Z-avarab@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | SubmittingPatches: a few unrelated minor fixes | expand |
On 12.05.2021 10:45, Ævar Arnfjörð Bjarmason wrote: >There hasn't been a release of Pine since late 2005, in Alpine the >no-strip-whitespace-before-send switch is already the default. > >This documentation was initially added in 9740d289ee7 (Update >SubmittingPatches to add MUA specific notes., 2005-08-26), at this >point it's safe to say that it's not useful to anyone anymore, let's >remove it. What is wrong with keeping it in there? My latest version of the etiquette patch moves my Mutt MUA config notes to this section on MUAs. It could eventually become a somewhat exhaustive reference of MUA tweaks. Old tools may not be popular but they sometime have niche uses and/or userbases. My recent switch to Mutt has been mixed at best and I went back to take a look at mh/nmh to see if I liked it better and I may give it a go for a while to kick the tires, likely making me the only developer that uses nmh. Keeping these notes on old tools--at the bottom of documentation no less--seems to have little to no "cruft cost" with the potential of helping somebody someday, even if nostalgia is the only reason. Cheers! Dave
Dave Huseby wrote: > On 12.05.2021 10:45, Ævar Arnfjörð Bjarmason wrote: > >There hasn't been a release of Pine since late 2005, in Alpine the > >no-strip-whitespace-before-send switch is already the default. > > > >This documentation was initially added in 9740d289ee7 (Update > >SubmittingPatches to add MUA specific notes., 2005-08-26), at this > >point it's safe to say that it's not useful to anyone anymore, let's > >remove it. > > What is wrong with keeping it in there? My latest version of the > etiquette patch moves my Mutt MUA config notes to this section on MUAs. > It could eventually become a somewhat exhaustive reference of MUA > tweaks. Old tools may not be popular but they sometime have niche uses > and/or userbases. My recent switch to Mutt has been mixed at best and I > went back to take a look at mh/nmh to see if I liked it better and I may > give it a go for a while to kick the tires, likely making me the only > developer that uses nmh. Have you tried notmuch? There's multiple clients.
On Wed, May 12 2021, Dave Huseby wrote: > On 12.05.2021 10:45, Ævar Arnfjörð Bjarmason wrote: >>There hasn't been a release of Pine since late 2005, in Alpine the >>no-strip-whitespace-before-send switch is already the default. >> >>This documentation was initially added in 9740d289ee7 (Update >>SubmittingPatches to add MUA specific notes., 2005-08-26), at this >>point it's safe to say that it's not useful to anyone anymore, let's >>remove it. > > What is wrong with keeping it in there? My latest version of the > etiquette patch moves my Mutt MUA config notes to this section on MUAs. > It could eventually become a somewhat exhaustive reference of MUA > tweaks. Old tools may not be popular but they sometime have niche uses > and/or userbases. My recent switch to Mutt has been mixed at best and I > went back to take a look at mh/nmh to see if I liked it better and I may > give it a go for a while to kick the tires, likely making me the only > developer that uses nmh. > > Keeping these notes on old tools--at the bottom of documentation no > less--seems to have little to no "cruft cost" with the potential of > helping somebody someday, even if nostalgia is the only reason. I think there's an inherent value in keeping guides like these short and to the point, and only including those things relevant to most readers. So I do think that if we're including such a niche guide we're better off splitting it into another file and linking to it, same with the whole guide in SubmittingPatches now teaching people to manually craft a patch without using git-format-patch, another obscure edge case we give too much space / causes distraction. In this case though I think saying anything about pine crosses the line from niche to obscure archaeology. We're inlining a patch for abandoned software that has a replacement. If we're going to say anything about Pine in such a list I think it should be: Pine: abandoned and has known flowed text bugs, use its successor alpine or another MUA instead.
On 13.05.2021 09:50, Ævar Arnfjörð Bjarmason wrote: >So I do think that if we're including such a niche guide we're better >off splitting it into another file and linking to it, same with the >whole guide in SubmittingPatches now teaching people to manually craft a >patch without using git-format-patch, another obscure edge case we give >too much space / causes distraction. I agree with you on this approach. There's one other subtle distinction that I realized last night and that is the distinction between best practices for using email for working *with* Git and using email for working *on* Git. I think Junio pointed it out in the thread on writing down the mailing list etiquette that the Git project itself has its own etiquette that is likely different than the etiquette of other projects that use Git and email. Maybe we should make that distinction clearer. SubmittingPatches and MyFirstContribution.txt are clearly about using email and Git to work *on* Git. So is the MailingListEtiquette.txt file I'm proposing in the other thread. Some of the tips that would go into MUA-specific files would only apply to using email and Git to work *on* Git while others are likely to be about using email and Git to work *with* Git. It is subtle but important. IMO, I think we should have a Documentation/WorkingOnGit subfolder where all of the documentation for the Git project resides just to clarify the distinction. >In this case though I think saying anything about pine crosses the line >from niche to obscure archaeology. We're inlining a patch for abandoned >software that has a replacement. If we're going to say anything about >Pine in such a list I think it should be: > > Pine: abandoned and has known flowed text bugs, use its successor > alpine or another MUA instead. I'm good with this. I suppose the old docs are always in Git history. Cheers! Dave
On 13.05.2021 01:38, Felipe Contreras wrote:
>Have you tried notmuch? There's multiple clients.
I haven't. Is that popular for mailing list style Git work? When I was
part of the Tor Project back in the day, a couple of the main developers
used nmh and custom python scripts to great effect. I was always
impressed with the CLI-fu they had.
I decided to try Mutt after decades of using Alpine and Pine before
that. I'm open to something that is more congruent with the way I prefer
to work. Where do you recomment I start with notmuch? Tutorials?
Favorite client?
Cheers!
Dave
Dave Huseby wrote: > On 13.05.2021 01:38, Felipe Contreras wrote: > >Have you tried notmuch? There's multiple clients. > > I haven't. Is that popular for mailing list style Git work? When I was > part of the Tor Project back in the day, a couple of the main developers > used nmh and custom python scripts to great effect. I was always > impressed with the CLI-fu they had. The notmuch cli-fu is superior to anything else, by far (IMO). > Where do you recomment I start with notmuch? Tutorials? The getting started guide [1], of course. > Favorite client? The one I wrote ;) notmuch-vim [2] [3] Cheers. [1] https://notmuchmail.org/getting-started/ [2] https://github.com/felipec/notmuch-vim [3] https://www.youtube.com/watch?v=JGD7IbZmnIs
On 13.05.2021 15:08, Felipe Contreras wrote: >Cheers. > >[1] https://notmuchmail.org/getting-started/ >[2] https://github.com/felipec/notmuch-vim >[3] https://www.youtube.com/watch?v=JGD7IbZmnIs Oh wow. As a fellow vim user this looks amazing. I had no idea this existed. Thank you for sharing. Cheers! Dave
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 2aa217da9c..e616d20556 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -498,62 +498,6 @@ first patch.\n", if you really want to put in the patch e-mail, should come after the three-dash line that signals the end of the commit message. - -=== Pine - -(Johannes Schindelin) - -.... -I don't know how many people still use pine, but for those poor -souls it may be good to mention that the quell-flowed-text is -needed for recent versions. - -... the "no-strip-whitespace-before-send" option, too. AFAIK it -was introduced in 4.60. -.... - -(Linus Torvalds) - -.... -And 4.58 needs at least this. - -diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1) -Author: Linus Torvalds <torvalds@g5.osdl.org> -Date: Mon Aug 15 17:23:51 2005 -0700 - - Fix pine whitespace-corruption bug - - There's no excuse for unconditionally removing whitespace from - the pico buffers on close. - -diff --git a/pico/pico.c b/pico/pico.c ---- a/pico/pico.c -+++ b/pico/pico.c -@@ -219,7 +219,9 @@ PICO *pm; - switch(pico_all_done){ /* prepare for/handle final events */ - case COMP_EXIT : /* already confirmed */ - packheader(); -+#if 0 - stripwhitespace(); -+#endif - c |= COMP_EXIT; - break; -.... - -(Daniel Barkalow) - -.... -> A patch to SubmittingPatches, MUA specific help section for -> users of Pine 4.63 would be very much appreciated. - -Ah, it looks like a recent version changed the default behavior to do the -right thing, and inverted the sense of the configuration option. (Either -that or Gentoo did it.) So you need to set the -"no-strip-whitespace-before-send" option, unless the option you have is -"strip-whitespace-before-send", in which case you should avoid checking -it. -.... - === Thunderbird, KMail, GMail See the MUA-SPECIFIC HINTS section of linkgit:git-format-patch[1].
Remove the whole section about configuring pine with no-strip-whitespace-before-send. There hasn't been a release of Pine since late 2005, in Alpine the no-strip-whitespace-before-send switch is already the default. This documentation was initially added in 9740d289ee7 (Update SubmittingPatches to add MUA specific notes., 2005-08-26), at this point it's safe to say that it's not useful to anyone anymore, let's remove it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- Documentation/SubmittingPatches | 56 --------------------------------- 1 file changed, 56 deletions(-)