unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Joost Kremers <joostkremers@fastmail.fm>, Eli Zaretskii <eliz@gnu.org>
Cc: eggert@cs.ucla.edu,
	"Clément Pit--Claudel" <clement.pit@gmail.com>,
	emacs-devel@gnu.org
Subject: RE: Character literals for Unicode (control) characters
Date: Sun, 6 Mar 2016 08:55:48 -0800 (PST)	[thread overview]
Message-ID: <2840a8a5-828b-4a3d-99c0-448ad76d0746@default> (raw)
In-Reply-To: <87h9gjmwsy.fsf@fastmail.fm>

> > so M-q is just not up to the job, and shouldn't be used.
> 
> But there's no real alternative, is there? IOW, you might as well
> use M-q, because if you use something like \\[my-function], you
> never know if that'll display as a short key binding, a long key 
> binding, or as `M-x my-function', which can actually be very long.

You never know for sure.  But usually you know what to _expect_.
Often a doc string with \\[...] is for a command that is used
in a given context, where you can have a good idea whether the
command is likely to be bound to a key or not.

But of course, it could be bound to another key than the
default one, and the bound key could have a much longer
description because of prefix keys.

So no, there is no silver bullet here.  You just need to use
good, common sense, aiming for the most typical, expected,
default use case/context.

The reason for conventional doc strings, including a maximum
line length, is for user convenience.  This includes simply
reading but also things like window and frame fitting to the
buffer content (line lengths and number of lines).

As with all attempts to help users at coding time, we can
only either (1) try to address the most common expected use
cases or (2) provide users a way to customize the behavior.
For doc strings, this comes down mainly to #1.

> (I guess the best way would be to custom-wrap doc strings before
> displaying them, after constructs such as \\[...] have been
> resolved.)

It's not just about wrapping.  You need to look at rendered
doc strings to see what the effect is on embedded TAB chars
also, e.g., to try to align text that is essentially tabular,
such as key descriptions.

It's really not a big deal to use `C-M-x' to reevaluate,
and then use `C-h f' to see what the doc string looks like
when rendered.

And yes, you might need to first put the current buffer in
the right mode, so it picks up the right keymaps.  You might
even need to set the font so that it displays each of the
chars in the doc string correctly.



      reply	other threads:[~2016-03-06 16:55 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-03  5:47 Character literals for Unicode (control) characters Lars Ingebrigtsen
2016-03-03  6:20 ` John Wiegley
2016-03-03  6:25   ` Lars Ingebrigtsen
2016-03-03  6:34 ` Drew Adams
2016-03-03 16:11 ` Paul Eggert
2016-03-03 20:48   ` Eli Zaretskii
2016-03-03 23:58     ` Paul Eggert
2016-03-05 15:28   ` Philipp Stephani
2016-03-05 15:39     ` Marcin Borkowski
2016-03-05 16:51       ` Philipp Stephani
2016-03-06  2:27     ` John Wiegley
2016-03-06 15:24       ` Philipp Stephani
2016-03-06 15:54         ` Eli Zaretskii
2016-03-06 17:35           ` Philipp Stephani
2016-03-06 18:08             ` Paul Eggert
2016-03-06 18:28               ` Philipp Stephani
2016-03-06 19:03                 ` Paul Eggert
2016-03-06 19:16                   ` Philipp Stephani
2016-03-06 20:05                     ` Eli Zaretskii
2016-03-13 20:31                       ` Philipp Stephani
2016-03-14 20:03                         ` Paul Eggert
2016-03-14 20:30                           ` Eli Zaretskii
2016-03-15 11:09                             ` Nikolai Weibull
2016-03-15 17:10                               ` Eli Zaretskii
2016-03-16  8:16                                 ` Nikolai Weibull
2016-03-14 21:27                           ` Clément Pit--Claudel
2016-03-14 21:48                             ` Paul Eggert
2016-03-19 16:27                           ` Philipp Stephani
2016-03-20 12:58                             ` Paul Eggert
2016-03-20 13:25                               ` Philipp Stephani
2016-03-25 17:41                                 ` Philipp Stephani
2016-04-22  2:39                                   ` Paul Eggert
2016-04-22  7:57                                     ` Eli Zaretskii
2016-04-22  8:01                                       ` Eli Zaretskii
2016-04-22  9:39                                         ` Elias Mårtenson
2016-04-22 10:01                                           ` Eli Zaretskii
2016-04-25 17:48                                             ` Paul Eggert
2016-03-05 16:35   ` Clément Pit--Claudel
2016-03-05 17:12     ` Paul Eggert
2016-03-05 17:53       ` Clément Pit--Claudel
2016-03-05 18:16         ` Eli Zaretskii
2016-03-05 18:34           ` Clément Pit--Claudel
2016-03-05 18:56             ` Eli Zaretskii
2016-03-05 19:08               ` Drew Adams
2016-03-05 22:52                 ` Clément Pit--Claudel
2016-03-06 15:49           ` Joost Kremers
2016-03-06 16:55             ` Drew Adams [this message]

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=2840a8a5-828b-4a3d-99c0-448ad76d0746@default \
    --to=drew.adams@oracle.com \
    --cc=clement.pit@gmail.com \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joostkremers@fastmail.fm \
    /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).