all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 24386@debbugs.gnu.org
Subject: bug#24386: 24.5; `read--expression' --> `read-expression', please
Date: Sat, 27 Jul 2019 09:39:45 -0700 (PDT)	[thread overview]
Message-ID: <d79a925c-8615-4433-81b0-5c971a431652@default> (raw)
In-Reply-To: <87o91ffsef.fsf@mouse.gnus.org>

> > Please consider renaming `read--expression' to `read-expression' and
> > taking away its "internal" designation.  What it does is equally
> > useful to ordinary Emacs user-programmers.
> 
> It does seem like a rather internal function (setting up eldoc stuff
> and the like), so I think it's probably well-named as is; closing.

There's _absolutely nothing_ internal about the
behavior this function offers.  You can use it
_any_ place where you want to read a sexp.

In fact, users should be _encouraged_ to use
this, as opposed to more primitive, less
sexp-oriented ways of reading text when what
they want is a Lisp sexp.

That's akin to telling users to use file-name
manipulation functions instead of just concat,
when dealing with file names.

The name should probably be changed to have
"Lisp" in it, however, as it reads only Lisp
sexps (currently).

And this function needs a doc string (badly).

As for it using `eldoc-mode': That presumably
makes the function more useful for specifically
Lisp-sexp reading.  If we think otherwise then
that could be removed or optional.  In any case,
its presence has _nothing_ whatsoever to do
with whether the function is useful generally
or should be considered internal or local to
only some uses.

This is a bad judgment call, IMHO.





  reply	other threads:[~2019-07-27 16:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-07  2:37 bug#24386: 24.5; `read--expression' --> `read-expression', please Drew Adams
2019-07-27 14:45 ` Lars Ingebrigtsen
2019-07-27 16:39   ` Drew Adams [this message]
2019-07-27 22:44     ` Michael Heerdegen
2019-07-28  0:34       ` Drew Adams

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=d79a925c-8615-4433-81b0-5c971a431652@default \
    --to=drew.adams@oracle.com \
    --cc=24386@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.