all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: rpluim@gmail.com, stefankangas@gmail.com, emacs-devel@gnu.org
Subject: Re: feature/eglot-texi-manual 4725c123f3 2/5: ; eglot.texi: Fix typos and minor inconsistenciesfeature/eglot-texi-manual 4725c123f3 2/5: ; eglot.texi: Fix typos and minor inconsistencies
Date: Sun, 23 Oct 2022 08:13:05 +0300	[thread overview]
Message-ID: <83h6zvt95q.fsf@gnu.org> (raw)
In-Reply-To: <E1omKet-00018t-OG@fencepost.gnu.org> (message from Richard Stallman on Sat, 22 Oct 2022 15:59:51 -0400)

> From: Richard Stallman <rms@gnu.org>
> Cc: rpluim@gmail.com, stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Sat, 22 Oct 2022 15:59:51 -0400
> 
>   > Exactly.  We should always err on that side, out of respect to the
>   > original author(s) if for no other reasons.  Please try following this
>   > principle.
> 
> Nothing about Eglot is "existing text" as far as Emacs is concerned.
> All of it is proposed to add.  If we see ways to improve it before we
> add it, we should do so.  Better now than later.

That manual was written by yours truly.  I welcome any improvements to
it and corrections of any mistakes I might have made.  But replacing
my style preferences by someone else's is not going to improve the
manual.

> Consistency of style is a virtue in documentation, and so is
> consistency of terminology.  These are important reasons to make
> documentation text more uniform when installing it.

Exactly.

> We are not all equally skilled in writing clear English text.
> We should improve the writing that contributors submit.

Agreed.

> Documemtation shuld be structured according to the concepts of use,
> not based on implementation.  THe basic question here is, should we
> ask users to think in terms of "documenting hwo to use Eglot" or in
> terms of "documenting various features" (which happen to be provided
> by Eglot)?

We do both, please take a look at the recent changes to the Emacs user
manual, which mention capabilities provided by Eglot, and at the Eglot
manual itself.

> People seem to have assumed the former, but we ought to consider the
> latter too, and see which approach will be easiest to understand.

No such assumptions are being made.  And this discussion is not about
that anyway, it is about minor stylistic changes to the manual.

> Would someone please show me the documentation about Eglot?

There's doc/misc/eglot.texi in the Git repository on the master
branch.  And then there are references to capabilities backed up by
Eglot in the Emacs user manual, mainly in programs.texi and
maintaining.texi.



  reply	other threads:[~2022-10-23  5:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 10:38 feature/eglot-texi-manual 4725c123f3 2/5: ; eglot.texi: Fix typos and minor inconsistenciesfeature/eglot-texi-manual 4725c123f3 2/5: ; eglot.texi: Fix typos and minor inconsistencies Eli Zaretskii
2022-10-20 10:59 ` Stefan Kangas
2022-10-20 13:51   ` Eli Zaretskii
2022-10-20 11:35 ` Robert Pluim
2022-10-20 12:24   ` Stefan Kangas
     [not found]     ` <87a65qty8a.fsf@gmail.com>
2022-10-20 13:50       ` Eli Zaretskii
2022-10-22 19:59         ` Richard Stallman
2022-10-23  5:13           ` Eli Zaretskii [this message]
2022-10-23 13:19             ` Stefan Kangas
2022-10-23 16:18               ` Eli Zaretskii
2022-10-20 15:02       ` Stefan Kangas
2022-10-20 16:18         ` Eli Zaretskii
2022-10-20 20:34       ` Gregory Heytings
2022-10-20 22:35         ` Tim Cross
2022-10-21  6:04         ` Eli Zaretskii
2022-10-21  8:41           ` Gregory Heytings
2022-10-23 19:14           ` Richard Stallman
2022-10-23 19:21             ` Eli Zaretskii
2022-10-23 19:13         ` Richard Stallman
2022-10-20 15:11 ` Rudolf Adamkovič
2022-10-20 16:20   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h6zvt95q.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    --cc=rpluim@gmail.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.