There is also GNU style and GNU diction: <a href="https://www.gnu.org/software/diction/" rel="nofollow">https://www.gnu.org/software/diction/</a><p>; cat <<EOF >/tmp/testfile<p>Diction and style are two old standard Unix commands. Diction identifies wordy and commonly misused phrases. Style analyses surface characteristics of a document, including sentence length and other readability measures.<p>These programs cannot help you structure a document well, but they can help to avoid poor wording and compare the readability (not the understandability!) of your documents with others. Both commands support English and German documents.<p>EOF<p>; LANG=C diction --lang en --suggest /tmp/testfile<p>/tmp/testfile:2: These programs cannot help you structure a document well, but [they -> (do not use as substitute for "each, each one, everybody, every one, anybody, any one, somebody, some one")] [can -> (do not confuse with "may")] help to avoid poor wording and [compare -> "Compare" to points out resemblances, "compare with" points out differences.] the readability (not the understandability!) of your documents with others.<p>3 phrases in 5 sentences found.
Nobody should be using Strunk and White as a style guide after primary school. There's nothing fundamentally wrong with passive voice, or adverbs, or any of the other things that he mentions here.<p><a href="http://www.chronicle.com/article/50-Years-of-Stupid-Grammar/25497" rel="nofollow">http://www.chronicle.com/article/50-Years-of-Stupid-Grammar/...</a><p>He doesn't even correctly identify what weasel words are. ("Some people say", "It is believed", etc). I'm not sure why 'very close match' is any more opinionated than 'close match' is. It's not as if the latter is precisely defined.
I read the whole article thinking "this needs to be an emacs mode!" only to get to the punchline at the bottom.<p>>> Benjamin Beckwith has contributed a "writegood" mode for emacs inspired by these scripts.<p>This is going into my .emacs right now.
Is there anything like this for Google Docs, Gmail or Atom?<p>We've had spellcheckers for decades but I find it really surprising that automated grammar and proofreading checkers aren't in common use yet. For example, having my email client highlight overly long sentences, duplicate words, ambiguous references (e.g. what noun does "it" refer to) and more would undoubtable save proofreading time and doesn't sounds that difficult to implement. I see online comments every few days of someone pointing out the word loose/lose is used incorrectly for instance.<p>I recall that many grammar checkers suffer from false positives though but has the technology not advanced?
Hello, I wrote similar script to do the Belcher diagnostic test in LaTeX documents. This test consists in highlighting parts of the text with potential problems (e.g., vague pronouns, weak verbs, and passive voice, among others).<p>You can find the instructions to do the test (and some good examples) in the book Writing your journal article in twelve weeks: A guide to academic publishing success.<p>The script and its documentation are here:<p><a href="https://github.com/carlobar/BDT_latex" rel="nofollow">https://github.com/carlobar/BDT_latex</a>
<a href="https://github.com/carlobar/BDT_latex/blob/master/docs/documentation.pdf" rel="nofollow">https://github.com/carlobar/BDT_latex/blob/master/docs/docum...</a>
You may also be interested in LanguageTool, which catches many potential problems in several languages. It's the best Free Software style and grammar checker I've seen:<p><a href="https://languagetool.org/" rel="nofollow">https://languagetool.org/</a>
Oh, that reminds me: I rewrote that bash script (and a bit more) as a Rust lib (+ CLI) for fun last year. If anyone wants to build on it: <a href="https://github.com/killercup/english-lint" rel="nofollow">https://github.com/killercup/english-lint</a>
Looks like good guidelines overall, I just have one complaint<p>> Bad: We used various methods to isolate four samples.
> Better: We isolated four samples.<p>The first sentence is right if a different method was used to obtain different samples. This is relevant information
So, on a related note, someone wrote a blog post a few years ago that just perfectly epitomized the annoyingly pretentious writing style everyone in the tech world seems to have, and I recommended to him that he use simpler phrases and words and sentences. Everyone in that chatroom criticized me as both an idiot and an asshole. Skip ahead a year or two, and PG writes the same fucking thing in a blog post and posts it here, and everyone praises him. What I took from this is that I'm not actually an idiot after all, and I should probably stop listening to people who say that I am.
In the footnote, what is that comma after "Regehr" doing there? Delete it!<p>But yes, "note that" is a bugaboo I have to battle in my own writing. With rare exceptions it can just be deleted; occasionally it indicates that the following point deserves more emphasis than I have given it.
I've kept these in my GitHub for a while now<p><a href="https://github.com/feld/technical-writing" rel="nofollow">https://github.com/feld/technical-writing</a>
[edit: I see @erlehmann_ beat me to it but am leaving it here anyway]<p>I would be great if someone could enhance the programs `style` and `diction` [1] to incorporate these hints. And make a browser add-in for good measure!<p>I used `diction` religiously back when I used a UNIX System V system -- it helped me a lot.<p>1. <a href="https://www.gnu.org/software/diction/" rel="nofollow">https://www.gnu.org/software/diction/</a>
Love this! English is my third language; I often fall for using passive voice, adverbs or fillers. Much like this script, I found Grammarly to be extremely helpful in forcing me to rethink the above when composing.
I do something similar to the OP. When I'm working on a long project with multiple pieces that I might have left incomplete, I'll use a grep-like (like ack, which has PCRE) to quickly look for placeholders or cusswords:<p><pre><code> ack -C -i 'tk|to ?do|lorem|fu.k|shit|wt[fh]|[!?.]{3,}'
</code></pre>
Maybe the OP's goal is to have his phds practice more shell scripting and syntax. But it seems the same effect could be achieved with grep and the flag to filter from a file of patterns, rather than creating an unwieldy single string to enumerate all the possible words. Instead of having to write if/else logic to provide a lackluster CLI, have students create a repo of weasel words and use git clone/curl with grep.<p>I didn't read through his third script for detecting duplicate words, but couldn't it be achieved by using PCRE regex and backreferences?<p><a href="http://stackoverflow.com/questions/2823016/regular-expression-for-consecutive-duplicate-words" rel="nofollow">http://stackoverflow.com/questions/2823016/regular-expressio...</a><p>Off-topic, but I've been meaning to write a post on how learning the command-line made me a significantly more productive writer. I do most of my writing on sites built from static site generators, such as Jekyll and Middleman and Sphinx. For many of my tutorials, I have to describe graphical elements which require taking screenshots.<p>I of course know the OSX keyboard shortcut to turn on the screen grab utility and interactively make a selection. But this saves the screenshot to a default location with a generic file name. To include that image in my blog, I have to move it over to my working directory, rename it, and then write the img code and src attribute to my blog post. It's enough annoying small steps that including images in my posts was a huge chore.<p>Sometime ago, this blog post on OS X Terminal Utilities [0] made it to HN's front page and I learned that screencapture could be invoked from the Terminal. So I wrote a little Ruby wrapper that, when invoked from the command-line with an argument for output path, would call screencapture after a 2-second delay -- enough time for me to Cmd-Tab from a Terminal to the application I want to screensnap -- and then save the snap to the specified destination and output HTML/Markdown that I could paste into my blogpost.<p>Sample usage:<p><pre><code> $ screenpy images/path/to/screenshot.jpg
</code></pre>
stderr:<p><pre><code> Writing to: images/path/to/screenshot.jpg
Format: jpeg
quality: 75
optimize: True
</code></pre>
stdout:<p><pre><code> <img src="images/path/to/screenshot.jpg" alt="screenshot.jpg">
</code></pre>
I've iterated the tool, converting it to Python and including the was-sdk so I could upload to S3 if I need an absolute URL. And I've written plenty of other utilities since...but it's hard to overstate how much being able to operate via CLI has smoothed my writing experience. It's not just that it saves me time, but I'll write visual-heavy posts that I would have never even tried, especially back in my Wordpress days.<p>[0] <a href="http://www.mitchchn.me/2014/os-x-terminal/" rel="nofollow">http://www.mitchchn.me/2014/os-x-terminal/</a><p>[1] <a href="https://gist.github.com/dannguyen/bfb45408d43986eefdf83b59bc9e8629" rel="nofollow">https://gist.github.com/dannguyen/bfb45408d43986eefdf83b59bc...</a>