unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefankangas@gmail.com>
To: Heime <heimeborgia@protonmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 65913@debbugs.gnu.org
Subject: bug#65913: with-help-window arranges for 'inhibit-read-only' to be set to 't'
Date: Wed, 13 Sep 2023 08:14:44 -0700	[thread overview]
Message-ID: <CADwFkmkNj23YfjE_N_WEVaFwLy=JL8VroXwF40cvoo61PiQq9w@mail.gmail.com> (raw)
In-Reply-To: <04_YeulwxttSgx-ucr-VfmWTxKH81JSzyGT-sOTCmIoygmC3J7tNUFEY6pzA1O53iwhjtDqN88gX6pkBNR7e7b_kCefsrYMoIGPKJKt99rM=@protonmail.com>

Heime <heimeborgia@protonmail.com> writes:

> Stefan, is this to say that for you it is good that there is no way
> to figure out that there is no requirement to reset buffer-read-only
> from the self documentation ?  And that it is even unnecessary to
> state that the duffer is read only by going through the different
> docstrings.  Such conclusions is seriously deficient with little regard
> to how much time developers waste in working with the language.

No, I just don't see why anyone would assume that you would have to mess
around with buffer-read-only, given that the manual (for example) says:

 -- Macro: with-help-window buffer-or-name body...
     This macro evaluates BODY like ‘with-output-to-temp-buffer’ (*note
     Temporary Displays::), inserting any output produced by its forms
     into a buffer specified by BUFFER-OR-NAME, which can be a buffer or
     the name of a buffer.

The docstring also seems pretty clear to me.  Nothing leads me to think
that I can't just

    (with-help-window "*foo*"
      (insert "bar"))

as indeed I can.  And help mode is read-only so that part is clear too.

I understand that this aspect confused you, but we can't add every
possible confusion to the ELisp manual and/or docstrings.  They would
end up being much too long, which would also "waste time".  Therefore,
we have to focus on clarifying aspects that are confusing to many.

Is this an exact science?  Not really, quite the contrary.  The purpose
of these discussions is precisely to make better decisions in cases such
as these.  In this case, Eli asked for my opinion, so I gave mine.





  reply	other threads:[~2023-09-13 15:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 10:41 bug#65913: with-help-window arranges for 'inhibit-read-only' to be set to 't' Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 13:13 ` Eli Zaretskii
2023-09-13 13:26   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 13:56     ` Eli Zaretskii
2023-09-13 14:26       ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 14:04   ` Stefan Kangas
2023-09-13 14:46     ` Eli Zaretskii
2023-09-13 14:54       ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 15:21         ` Stefan Kangas
2023-09-13 19:03         ` Eli Zaretskii
2023-09-13 19:16           ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-14  4:53             ` Eli Zaretskii
2023-09-14 10:41               ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-14 12:50                 ` Eli Zaretskii
2023-09-14 13:17                   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-14 16:03               ` Drew Adams
2023-09-14 16:15                 ` Eli Zaretskii
2023-09-14 16:40                   ` Christopher Dimech
2023-09-14 16:55                     ` Eli Zaretskii
2023-09-14 19:04                       ` Christopher Dimech
2023-09-14 16:29                 ` Christopher Dimech
2023-09-13 14:51     ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 15:14       ` Stefan Kangas [this message]
2023-09-13 15:34         ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 15:51           ` Stefan Kangas
2023-09-13 16:24             ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to='CADwFkmkNj23YfjE_N_WEVaFwLy=JL8VroXwF40cvoo61PiQq9w@mail.gmail.com' \
    --to=stefankangas@gmail.com \
    --cc=65913@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=heimeborgia@protonmail.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).