emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: text-quoting-style


From: N. Jackson
Subject: Re: text-quoting-style
Date: Wed, 02 Sep 2015 16:34:50 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

At 14:31 -0300 on Monday 2015-08-31, Stefan Monnier wrote:

> Same as for Alan: without an explicit description of the concrete
> problems you face with curly quotes, this "+1" is meaningless.

Sorry for the delay in posting this response, it's taken me two days to
gather my thoughts enough to come up with something remotely coherent;
there are several different issues here.

It seems clear, in principle and without need for concrete examples, that
if Emacs is going to cleverly display by default something different on
the screen than is in a file or buffer there needs to be an easy way to
turn that cleverness off and see what is actually in the file or buffer,
for those occasions when the user decides that the cleverness is not
helpful.

I see the issues under discussion (or that maybe should be under
discussion) are:

1. symbol markup
1.1. internal representation
1.2. entry in Emacs
1.3. display in Emacs
1.3.1. in text modes
1.3.2. in programming modes
1.3.3. in help
1.3.4. in info
1.4. entry and display outside Emacs

2. English quoting (single and double)
2.1. internal representation
2.2. entry in Emacs
2.3. display in Emacs
2.3.1. in text modes
2.3.2. in programming modes
2.3.3. in help
2.3.4. in info
2.4. entry and display outside Emacs

Some participants in this discussion have confabulated symbol markup and
English quoting. Personally I think this is a mistake, and sacrifices
too much for a questionable gain in simplicity. It certainly has
confused the discussion over the past few months.

For symbol markup, I think that an internal representation in the
traditional form with a grave accent and a single straight quote is
perfectly fine. Entry is easy and there are no issues for display on
legacy systems. For display on graphical displays, in help and in info
it might be nice, at the user's option, to use a proportional font,
curly quotes for English quoting, and a typewriter font for markedup
symbols. There could also be an option (although I think it would be
perverse) in text and programming modes to display symbol markup in some
way different from the internal representation of grave accent /
straight quote, such as curly quotes or bold text. Such options ought to
be able to be turned on and off by the user on a per buffer / per mode
basis.

For English quoting, I think it's great that Emacs is adding (more)
support for curly quotes. The internal representation needs to be
(obviously, I think) that each type of quote is represented by itself.
For display, each type of quote could be displayed as itself, but it
would be nice to have an option to display curly quotes as straight
quotes. (This is because in normal use I have Emacs use a monospaced
font as small as I can make it and still see, despite a slight
astigmatism, all the symbols I use (especially distinguishing `,' from
`.' and `;' from `:' and `{' from `[' from `('). At these font sizes
(with every monospaced font I've tried) curly quotes are almost
impossible to see and are generally indistinguishable from motes of dust
on my monitor. In my opinion, straight quotes just work better with a
monospaced font.) Meanwhile I can imagine that others might want the
option to display straight quotes as curly ones. However, we'd want to
be able to turn these features on and off on a per buffer / per mode
basis, because sometimes one wants to see exactly what's there, without
any magic. A smart quote feature that converts straight quotes to
appropriate left and right curly quotes as one types is great -- but
obviously it needs to be something one can turn on and off. (And, for
completeness, it would also be nice to have a feature to convert all the
quotes in a buffer to straight quotes or to appropriate left and right
curly quotes.)

I realise that much of this already exists or is in the process of
being implemented; I'm writing this to emphasise the need to be able to
turn such features on and off, on a per buffer / per mode basis.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]