unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 3568@debbugs.gnu.org, larsi@gnus.org
Subject: bug#3568: 23.0.94; no doc for character composition
Date: Wed, 27 Apr 2016 14:18:20 -0700 (PDT)	[thread overview]
Message-ID: <c9f2afff-2575-44f6-8e68-f6fc4e631c58@default> (raw)
In-Reply-To: <<83mvoeyfpx.fsf@gnu.org>>

> > No.  `compose-region' already had that doc string when the bug was
> > reported.  That doc string has been around since at least Emacs 22.
> 
> Then I don't understand what else do you want to know about
> compose-region and character composition in general.
> 
> > I would expect some conceptual explanation of character composition
> > in the Elisp manual.
> 
> Please start by explaining what is missing from the doc string of
> compose-region, because otherwise it is impossible to translate your
> expectation to any concrete text.
> 
> The example you gave in the bug report is not about character
> composition, it's about font-lock.  So maybe that is what you need to
> be explained.  However, the bug report says "character composition",
> so until you agree it's about something else, "character composition"
> it is.
> 
> > Including how to decompose composed chars etc.
> 
> You can't.  This question makes no sense.  Character composition
> converts several characters into one or more glyphs to be displayed;
> you cannot "decompose" them, and in any case the result of such
> decomposition is known in advance: they are the original characters.
> 
> > What the bug report mentions.  I don't think that a doc string for
> > one command covers this topic.
> 
> Well, I think it does.  You could change my mind by telling what is it
> that you miss in that doc string.

I'd like an explanation of character composition, in the Elisp manual.
If you don't want to add one, or you don't think it is useful for users,
so be it.

As one user, I know nothing about this.  And I still know nothing
about it after reading that doc string.  FWIW.





  parent reply	other threads:[~2016-04-27 21:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-14 23:17 bug#3568: 23.0.94; no doc for character composition Drew Adams
2016-04-27 19:23 ` Lars Ingebrigtsen
2016-04-27 19:42   ` Drew Adams
2016-04-27 20:11     ` Eli Zaretskii
     [not found]   ` <<623906f5-d8d6-416b-b435-7f3b0f44944a@default>
     [not found]     ` <<83mvoeyfpx.fsf@gnu.org>
2016-04-27 21:18       ` Drew Adams [this message]
2016-04-28  5:07         ` 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

  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=c9f2afff-2575-44f6-8e68-f6fc4e631c58@default \
    --to=drew.adams@oracle.com \
    --cc=3568@debbugs.gnu.org \
    --cc=eliz@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 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).