emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New optional Eshell module: em-elecslash


From: Sean Whitton
Subject: Re: New optional Eshell module: em-elecslash
Date: Tue, 19 Apr 2022 09:52:59 -0700
User-agent: Emacs/29.0.50 (x86_64-pc-linux-gnu)

Hello,

On Sun 17 Apr 2022 at 09:20am +03, Eli Zaretskii wrote:

> IME, use of passive tense is not the "disease", it's a symptom.  The
> "disease" is overly complicated sentences that make the text hard to
> understand.  Using passive tense is a good indicator that the
> structure of the text is sub-optimal and needs to be rethought.
> Trying to use active tense as much as possible in many cases leads to
> such rethinking and makes the text more clear.
>
> For example, here's how I'd rephrase the above paragraph:
>
>   To help you type file-name arguments to remote commands, add the
>   @code{eshell-elecslash} module to @code{eshell-modules-list}.  Then
>   typing the first @kbd{/} character of a command-line argument will
>   automatically insert the Tramp prefix if the
>   @code{default-directory} is remote.  If this is not what you want
>   (e.g., you want to type a local absolute file name instead), type
>   another @kbd{/} to undo this automatic prefix insertion.  Typing
>   @kbd{~/} also inserts the Tramp prefix.  By contrast, typing
>   arguments to external commands, which always run locally, doesn't
>   insert the prefix.  The result is that in most cases you get the
>   Tramp prefix inserted automatically only when you should reasonably
>   expect it.
>
> Do you see how using the active tense makes the text more clear?
> Another thing to remember for writing clear documentation is not to
> put the important parts too far near the end of a sentence; the above
> rewording fixed a few instances of that in your original text.

Thanks for this, I will read it carefully and revise my patch.

> No, the NEWS entries where the first line is not a complete sentence
> ending in a period are in error and should be fixed.  (We usually fix
> that close to starting a pretest, if not earlier.)

Good to know.

> We all bump into that from time to time.  Some techniques for dealing
> with the difficulties:
>
>   . omit some less important parts, like "the" etc.
>   . rearrange the text to make it shorter (for example, say "buffer
>     text" instead of "the text of the buffer")
>   . omit less important details from the first sentence, and describe
>     them in the following parts of the doc string

Right, I'll try to be more willing to say less in that first sentence.

-- 
Sean Whitton



reply via email to

[Prev in Thread] Current Thread [Next in Thread]