From: Eli Zaretskii <eliz@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 17779@debbugs.gnu.org
Subject: bug#17779: 24.4.50; (elisp) `Using Interactive'
Date: Mon, 05 Aug 2019 19:25:59 +0300 [thread overview]
Message-ID: <83ftmfd1ew.fsf@gnu.org> (raw)
In-Reply-To: <87blx4dkp4.fsf@mouse.gnus.org> (message from Lars Ingebrigtsen on Mon, 05 Aug 2019 11:29:27 +0200)
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: drew.adams@oracle.com, 17779@debbugs.gnu.org
> Date: Mon, 05 Aug 2019 11:29:27 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > It isn't an introduction, it's a full description of how to use
> > 'interactive'. And I find nothing confusing about that part of the
> > text, I think that single paragraph with 2 examples to illustrate the
> > issue is quite appropriate here.
>
> I hadn't read that section before, and I just found it an odd thing to
> talk about in that context -- as if there was something in particular
> about code in the interactive spec that has to be extra careful about
> buffer contents changing, when that's a general issue with points.
Right, and that is exactly the point what the text tries to make.
> > Please just leave this alone. I object in principle to making
> > significant changes in the manuals based on hair-splitting arguments,
> > not in the least because someone will always come back later and claim
> > that the new text is worse, or less clear, or whatever.
>
> Emacs has great documentation, but it (as everything else) can be
> improved. The argument you're making here seems to veer into the "well,
> everything is subjective, so let's not even try" territory, which I know
> you don't mean.
Indeed I didn't mean anything even close, and I'm sorry it seemed to
come across as something very different from my intent. I
specifically mentioned "hair-splitting" and "minuscule" to make my
intent clear, but I guess this wasn't enough.
Our documentation does have places which need improvement -- places
where the text is unclear or confusing or presents the subject in an
order that is methodologically wrong, etc. This particular text is
none of the above: it is very clear, describes real practical issues,
presents them in an order which makes sense, and is quite short, even
with the 2 examples and the surrounding small digression. So my point
is that this is not one of the places where the manuals really do need
improvement, it's a place where different people might have different
opinions due to their personal preferences and experience.
> While going through these doc clarification bug reports, I do close
> the ones I don't think are not worth doing and only bring up the
> ones I think could benefit from some consideration.
I very much respect your opinions on those matters, and this case is a
very rare situation where we happen to disagree.
Thanks.
next prev parent reply other threads:[~2019-08-05 16:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 15:50 bug#17779: 24.4.50; (elisp) `Using Interactive' Drew Adams
2019-08-04 12:41 ` Lars Ingebrigtsen
2019-08-04 17:13 ` Eli Zaretskii
2019-08-05 9:29 ` Lars Ingebrigtsen
2019-08-05 16:25 ` Eli Zaretskii [this message]
2019-08-05 2:05 ` Drew Adams
2019-08-06 3:20 ` Richard Stallman
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=83ftmfd1ew.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=17779@debbugs.gnu.org \
--cc=larsi@gnus.org \
/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.