unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: How to opt out of curly-quote spamming altogether?
Date: Mon, 24 Aug 2015 09:34:09 -0700 (PDT)	[thread overview]
Message-ID: <c8408881-dddb-4661-9e7f-6ec42d9bf5fa@default> (raw)
In-Reply-To: <<83fv38hfsx.fsf@gnu.org>>

> > `help-quote-translation' does seem to prevent curly quotes in
> > *Help* buffers, so at least there's that.  But I'm looking for
> > a switch to turn this virus OFF everywhere - to return to
> > Classic Emacs.  Surely such a simple ON/OFF switch exists?
> 
> It doesn't.  What you see in Info is literal characters generated
> when the documentation is built during the Emacs build process.
> So, to change that, you will have to regenerate the documentation, 
> telling makeinfo not to produce Unicode characters there.
> 
> Alternatively, you can set up your standard-display-table to display
> those characters as their ASCII equivalents.

That's horrible.  Users should be able to control this, easily.

I don't see this problem in a Windows binary from 2014-11-30.  The
regression was apparently introduced to the Windows builds between
then and 2014-12-29.

It sounds like this is a makeinfo build-time configuration decision.
In that case, can Emacs please provide doc produced both ways, and
let users choose the appearance they want?  At least please make the
non-curlified doc available as a separate download, with releases.

Both doc alternatives could be separate downloads, with Emacs
imposing no prejudice wrt bundling.  The download site could also
let users choose which they want, and automatically download both
the code tarball sans doc and the chosen doc format.

A display-table hack would presumably change all uses of a curly
quote.  That's not appropriate - it is only the code-"quoting"
uses that need to be changable/configurable by a user.  And if
this is not really a problem then please provide users with a
runtime choice, which fiddles with the display table as needed.

Code-"quoting" (inline code display) is a final presentation
thing.  It should not be, in effect, hardcoded.

If Texinfo/makeinfo is as inflexible as you suggest, maybe it
really is time to move to XML/HTML with XSLT/CSS.  Presentation
should be separated from content/structure, and that is apparently
not the case now.  There should be some flexibility in how a given
semantic construct, such as inline code, is finally presented.

There has been a lot of noise about "modernizing" Emacs's
appearance, behind the move to use curly quotes.  Modernizing
Emacs's appearance, including its doc, should first of all mean
separating out presentation from content/structure.  Whether the
fault for this regression is with Texinfo/makeinf or Emacs core
code changes, this "modernization" puts the cart before the
horse, and is a step backward for users.



       reply	other threads:[~2015-08-24 16:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<a4c77735-a9de-400e-88f2-243c66e24836@default>
     [not found] ` <<83fv38hfsx.fsf@gnu.org>
2015-08-24 16:34   ` Drew Adams [this message]
2015-08-24 16:45     ` How to opt out of curly-quote spamming altogether? Eli Zaretskii
2015-08-24 17:09     ` Paul Eggert
2015-08-24 17:29       ` Drew Adams
2015-08-24 18:44         ` Paul Eggert
     [not found]   ` <<c8408881-dddb-4661-9e7f-6ec42d9bf5fa@default>
     [not found]     ` <<837fokhby1.fsf@gnu.org>
2015-08-24 17:06       ` Drew Adams
2015-08-24 17:25         ` Eli Zaretskii
     [not found] <<c1f42565-e538-49e6-b246-07e43dab673a@default>
     [not found] ` <<834mjoha4r.fsf@gnu.org>
2015-08-24 17:57   ` Drew Adams
2015-08-24 18:05     ` Eli Zaretskii
2015-08-24 18:36     ` David Kastrup
2015-08-24 21:44       ` Drew Adams
2015-08-25  4:25         ` David Kastrup
2015-08-24  4:16 Drew Adams
2015-08-24 15:22 ` Eli Zaretskii
2015-08-24 15:26 ` Paul Eggert
2015-08-24 17:06   ` 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

  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=c8408881-dddb-4661-9e7f-6ec42d9bf5fa@default \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.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).