* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
[not found] ` <E1Z5qtC-0001Xe-1y@vcs.savannah.gnu.org>
@ 2015-06-21 19:09 ` Dmitry Gutov
2015-06-21 19:56 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-21 19:09 UTC (permalink / raw)
To: emacs-devel, Paul Eggert
Hi Paul,
On 06/19/2015 10:39 AM, Paul Eggert wrote:
> branch: master
> commit c4151ebe15479de4c2e511b068cdf9af6a4576cf
> Author: Paul Eggert <eggert@cs.ucla.edu>
> - (princ (format "\n ‘%s’ value is\n " symbol))
> + (princ (format (substitute-command-keys "\n ‘%s’ value is\n ")
> + symbol))
> (if (and value (symbolp value))
> - (princ (format "‘%s’" value))
> + (princ (format (substitute-command-keys "‘%s’") value))
> ...etc
With this change, the source files might as well contain ASCII quotes,
couldn't they?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-21 19:09 ` [Emacs-diffs] master c4151eb: Improve the optional translation of quotes Dmitry Gutov
@ 2015-06-21 19:56 ` Paul Eggert
2015-06-21 19:57 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-06-21 19:56 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
> With this change, the source files might as well contain ASCII quotes, couldn't
> they?
No, as it's more efficient when substitute-command-keys is a no-op, as this puts
less pressure on the garbage collector. Besides, it's no longer important to
insist on ASCII-only strings in Emacs Lisp files.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-21 19:56 ` Paul Eggert
@ 2015-06-21 19:57 ` Dmitry Gutov
2015-06-21 20:03 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-21 19:57 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/21/2015 10:56 PM, Paul Eggert wrote:
> Besides, it's no
> longer important to insist on ASCII-only strings in Emacs Lisp files.
Since when?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-21 19:57 ` Dmitry Gutov
@ 2015-06-21 20:03 ` Paul Eggert
2015-06-21 20:29 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-06-21 20:03 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
>> it's no
>> longer important to insist on ASCII-only strings in Emacs Lisp files.
>
> Since when?
We've had non-ASCII strings in GNU Emacs Lisp source-code strings for several
years. It hasn't been a problem in practice. Obviously we can't use any
Unicode character willy-nilly in any context, but it's quite safe now to use
curved single quotes in docstrings.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-21 20:03 ` Paul Eggert
@ 2015-06-21 20:29 ` Dmitry Gutov
2015-06-21 20:46 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-21 20:29 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/21/2015 11:03 PM, Paul Eggert wrote:
> We've had non-ASCII strings in GNU Emacs Lisp source-code strings for
> several years. It hasn't been a problem in practice. Obviously we
> can't use any Unicode character willy-nilly in any context, but it's
> quite safe now to use curved single quotes in docstrings.
Okay, rather than ASCII or not in Elisp code, my concern is whether
`substitute-command-keys' should translate *from* curved quotes. It's
not hard to imagine `substitute-command-keys' being called on its result
again, and then there will be risk of matching different pairs or quotes.
I'd rather keep them in the destination strings, if at all. Like
mentioned in the other thread, we can switch to simply using a face to
highlight code segments, and then the curved quotes won't be needed at
all (at least if that's the user's preference).
Regarding the GC argument, I think you'll be hard-pressed to find a
machine where it'll make a noticeable difference when processing
read-life docstrings.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-21 20:29 ` Dmitry Gutov
@ 2015-06-21 20:46 ` Paul Eggert
2015-06-21 23:52 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-06-21 20:46 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
> It's not hard to imagine `substitute-command-keys' being called on its result again
True, but that's always been a bug, even before the recent changes.
substitute-command-keys has never been idempotent.
> I'd rather keep them [curved quotes] in the destination strings, if at all.
If I understand you correctly, curved quotes will normally be kept in
destination strings so it should be OK. The only exceptions will be if users
customize help-quote-translation to say that they prefer straight quotes, or if
they run in an obsolescent environment that can't display curved quotes.
Neither case should be common.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-21 20:46 ` Paul Eggert
@ 2015-06-21 23:52 ` Dmitry Gutov
2015-06-22 6:50 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-21 23:52 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/21/2015 11:46 PM, Paul Eggert wrote:
> True, but that's always been a bug, even before the recent changes.
> substitute-command-keys has never been idempotent.
Shouldn't we try not to make things worse?
> If I understand you correctly, curved quotes will normally be kept in
> destination strings so it should be OK.
They would make little no to sense in the source strings. Have you read
this subthread?
http://lists.gnu.org/archive/html/emacs-devel/2015-06/msg00358.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-21 23:52 ` Dmitry Gutov
@ 2015-06-22 6:50 ` Paul Eggert
2015-06-22 15:09 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-06-22 6:50 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
>> substitute-command-keys has never been idempotent.
>
> Shouldn't we try not to make things worse?
I don't see the point. Code should never invoke substitute-command-keys on the
output of substitute-command-keys; the function is not designed that way.
That's always been true. It's not "making things worse" to rely on a property
that's been in Emacs for ages.
>> If I understand you correctly, curved quotes will normally be kept in
>> destination strings so it should be OK.
>
> They would make little no to sense in the source strings. Have you read this
> subthread?
>
> http://lists.gnu.org/archive/html/emacs-devel/2015-06/msg00358.html
Yes, I've been reading and participating in these subthreads. I don't follow
your point here, though. Normally, curved quotes pass through
substitute-command-keys unchanged. This is simple and intuitive and is what
Emacs has always normally done. Perhaps we'll come up with a better way to
highlight the output of substitute-command-keys at some point, a way that treats
quotes and key substitutions differently. That might be nice, but it's not
clear how it would work exactly, and in the meantime we have a simple approach
that does work.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-22 6:50 ` Paul Eggert
@ 2015-06-22 15:09 ` Dmitry Gutov
2015-06-23 5:36 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-22 15:09 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/22/2015 09:50 AM, Paul Eggert wrote:
> It's not "making things worse" to
> rely on a property that's been in Emacs for ages.
All right, I guess that's true.
> Yes, I've been reading and participating in these subthreads. I don't
> follow your point here, though. Normally, curved quotes pass through
> substitute-command-keys unchanged.
I don't see what's "normally" have to do with anything.
In the input, we don't need quotes that usually pass unchanged to the
output. We need some output-independent markup that will eventually
translate into whatever presentation we choose. The more we're able to
defer that choice, the better. It's why I'm liking the original
suggestion to do it via font-lock better and better now.
> This is simple and intuitive and is
> what Emacs has always normally done. Perhaps we'll come up with a
> better way to highlight the output of substitute-command-keys at some
> point, a way that treats quotes and key substitutions differently. That
> might be nice, but it's not clear how it would work exactly, and in the
> meantime we have a simple approach that does work.
Please recall the suggestion to do everything via font-lock. It would
also allow us to use some different quoting mechanism other than \\=,
which Stefan complained about.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-22 15:09 ` Dmitry Gutov
@ 2015-06-23 5:36 ` Paul Eggert
2015-06-23 10:55 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-06-23 5:36 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
> We need some output-independent markup that will eventually translate into
> whatever presentation we choose.
Yes, and we have that now. The simplest way to use it is to use the same curved
quotes in input as in output, but we can add more complex ways as needed.
> Please recall the suggestion to do everything via font-lock. It would also allow
> us to use some different quoting mechanism other than \\=, which Stefan
> complained about.
Of course. Font-lock is pretty much independent of the quoting mechanism that
docstrings use. For example, if we decide to support only backslash escapes to
quote in docstrings (yuck!), we could get that to work with font-lock; or if we
decide to support only curved quotes to quote in docstrings (too aggressive, if
you ask me), we could get that to work with font-lock too.
When I tried font-lock mode in this area I came away baffled (see Bug#20385
Message#289, and Bug#20613), so I don't know how well it'd really work in
practice for this problem. It is a poorly documented area, unfortunately.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-23 5:36 ` Paul Eggert
@ 2015-06-23 10:55 ` Dmitry Gutov
2015-06-24 5:24 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-23 10:55 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/23/2015 08:36 AM, Paul Eggert wrote:
> Yes, and we have that now. The simplest way to use it is to use the
> same curved quotes in input as in output, but we can add more complex
> ways as needed.
It may look easiest, but I wouldn't call it "simplest". It would be
better to have a clear separation between the input and output. If you
don't like the `' quotes so much, why not borrow a quoting method from
some other popular markup language, like tildes from org?
For the other options, see "fixed width text" in
http://hyperpolyglot.org/lightweight-markup.
> Of course. Font-lock is pretty much independent of the quoting
> mechanism that docstrings use.
That's not true. For better results, font-lock will need to handle the
escaping and quote conversion.
Otherwise, it won't know whether a given character was escaped in the
docstring, or was present there verbatim.
> For example, if we decide to support
> only backslash escapes to quote in docstrings (yuck!), we could get that
> to work with font-lock; or if we decide to support only curved quotes to
> quote in docstrings (too aggressive, if you ask me), we could get that
> to work with font-lock too.
>
> When I tried font-lock mode in this area I came away baffled (see
> Bug#20385 Message#289, and Bug#20613), so I don't know how well it'd
> really work in practice for this problem. It is a poorly documented
> area, unfortunately.
I gave you a recipe for a fix in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20385#292, and it worked
fine for me locally. (I thought I've also sent a patch, but apparently not).
So if you had trouble applying that, maybe you should've asked for the
proper patch instead of rushing the other way.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-23 10:55 ` Dmitry Gutov
@ 2015-06-24 5:24 ` Paul Eggert
2015-06-25 12:52 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-06-24 5:24 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
> I gave you a recipe for a fix in
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20385#292, and it worked fine for
> me locally. (I thought I've also sent a patch, but apparently not).
>
> So if you had trouble applying that, maybe you should've asked for the proper
> patch instead of rushing the other way.
As I mentioned earlier I never fully understood the font-lock proposal. I could
not easily decipher most of the abovementioned message. Luckily, though, the
abovementioned message briefly mentioned not using font-locking and said of it
"...but indeed, this approach could be the simpler one." -- an assessmeent that
seemed sound to me -- and so I took the simpler approach.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-24 5:24 ` Paul Eggert
@ 2015-06-25 12:52 ` Dmitry Gutov
2015-06-25 14:05 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-25 12:52 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/24/2015 08:24 AM, Paul Eggert wrote:
> As I mentioned earlier I never fully understood the font-lock proposal.
> I could not easily decipher most of the abovementioned message.
Asking questions might help. I can't help but feel frustrated that you
haven't made an informed decision. See the bottom of this email for the
patch against f743819 (which was the version in master at the time). It
only adds one line, the one I've mentioned in that message.
I'm not sure what more to explain, but the undesirable effect you've
seen was due to
http://www.gnu.org/software/emacs/manual/html_node/elisp/Syntactic-Font-Lock.html
> Luckily, though, the abovementioned message briefly mentioned not using
> font-locking and said of it "...but indeed, this approach could be the
> simpler one." -- an assessmeent that seemed sound to me -- and so I took
> the simpler approach.
I did say that, tentatively, and I've changed my mind since.
- Using font-lock will allow to change the output significantly in the
future, without breaking the substitute-command-keys API.
- This functionality is closely related to linkification of identifiers
between the quotes, also performed in Lisp (see the usages of
help-xref-symbol-regexp). If substitute-command-keys handles escapes,
help-xref-symbol-regexp (and the function using it) don't know whether a
given quote was escaped or not). Especially if the source file can
contain curly quotes, and substitute-command-keys also translates into them.
- "too tempting to implement complicated heuristics that would have been
a pain to document" is not a good argument not to do something in a
high-level language.
Now, there are still problems with that patch:
- It doesn't handle escaping either. Someone just needs to pick the
escaping syntax, and we can handle it in Lisp just as well as in C. Why
did we decide that "\\" isn't good enough?
- Like you said: "describe-variable should curve the quotes in the doc
string, but not in the contents of the variable". The code that prints
the value will need to add some text property to it ("verbatim"?
"font-lock-ignore"?), and the font-lock rule can look it up and skip
those regions. Nothing too hard.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-25 12:52 ` Dmitry Gutov
@ 2015-06-25 14:05 ` Paul Eggert
2015-06-25 14:56 ` Dmitry Gutov
2015-06-25 14:59 ` Dmitry Gutov
0 siblings, 2 replies; 22+ messages in thread
From: Paul Eggert @ 2015-06-25 14:05 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
> See the bottom of this email for the patch
I didn't see any patch in that email, unfortunately -- perhaps you forgot to
include it?
> - "too tempting to implement complicated heuristics that would have been a pain
> to document" is not a good argument not to do something in a high-level language.
True. But it's still a temptation we should strive to avoid.
> - Like you said: "describe-variable should curve the quotes in the doc string,
> but not in the contents of the variable". The code that prints the value will
> need to add some text property to it ("verbatim"? "font-lock-ignore"?), and the
> font-lock rule can look it up and skip those regions. Nothing too hard.
As you'll recall, I don't understand font-lock. That being said, I worry that
all this stuff would be complicated and would involve using undocumented or
poorly-documented features (see Bug#20613).
Also, it's not clear how the overall approach would work on limited displays
that don't have alternate fonts and/or colors. Suppose, for example, that the
user is running 'emacs --color=never' on a character terminal?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-25 14:05 ` Paul Eggert
@ 2015-06-25 14:56 ` Dmitry Gutov
2015-07-31 18:51 ` Paul Eggert
2015-06-25 14:59 ` Dmitry Gutov
1 sibling, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-25 14:56 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/25/2015 05:05 PM, Paul Eggert wrote:
> I didn't see any patch in that email, unfortunately -- perhaps you
> forgot to include it?
Sorry, it's attached now.
> True. But it's still a temptation we should strive to avoid.
Depends on what we call complicated. Like Richard mentioned, at least we
can try to leave unpaired quotes alone. Or not, I don't really care that
much personally.
>> - Like you said: "describe-variable should curve the quotes in the doc
>> string,
>> but not in the contents of the variable". The code that prints the
>> value will
>> need to add some text property to it ("verbatim"?
>> "font-lock-ignore"?), and the
>> font-lock rule can look it up and skip those regions. Nothing too hard.
>
> As you'll recall, I don't understand font-lock.
There's no requirement for you to implement all of it yourself. You can
take my patch, look for problems, and ask for them to be fixed.
You'll have to do the substitute-command-keys part, though.
> That being said, I
> worry that all this stuff would be complicated and would involve using
> undocumented or poorly-documented features (see Bug#20613).
I've enumerated practical considerations of having it implemented *not*
in font-lock. If some font-lock features lack documentation, demand it
to be added, then.
> Also, it's not clear how the overall approach would work on limited
> displays that don't have alternate fonts and/or colors. Suppose, for
> example, that the user is running 'emacs --color=never' on a character
> terminal?
diff --git a/lisp/help-mode.el b/lisp/help-mode.el
index f99e916..6256513 100644
--- a/lisp/help-mode.el
+++ b/lisp/help-mode.el
@@ -287,6 +287,13 @@ Commands:
\\{help-mode-map}"
(set (make-local-variable 'revert-buffer-function)
'help-mode-revert-buffer)
+ (setq font-lock-defaults '(nil t))
+ (font-lock-add-keywords
+ nil '(("`\\([^[:space:]'`‘’][^'`‘’]*\\)?'"
+ . (0 (progn (compose-region (match-beginning 0)
+ (1+ (match-beginning 0)) ?‘)
+ (compose-region (1- (match-end 0)) (match-end 0) ?’)
+ nil)))))
(set (make-local-variable 'bookmark-make-record-function)
'help-bookmark-make-record))
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-25 14:05 ` Paul Eggert
2015-06-25 14:56 ` Dmitry Gutov
@ 2015-06-25 14:59 ` Dmitry Gutov
2015-06-25 15:11 ` Eli Zaretskii
1 sibling, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-25 14:59 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 06/25/2015 05:05 PM, Paul Eggert wrote:
> Also, it's not clear how the overall approach would work on limited
> displays that don't have alternate fonts and/or colors. Suppose, for
> example, that the user is running 'emacs --color=never' on a character
> terminal?
I thought this was implemented somewhere in the display engine? If not,
it could be.
Or someone could tell me how to check whether curly quotes are
undisplayable in Lisp, and the rule will perform no substitutions, for
instance.
And colors -- what about them?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-25 14:59 ` Dmitry Gutov
@ 2015-06-25 15:11 ` Eli Zaretskii
2015-06-25 15:33 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2015-06-25 15:11 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: eggert, emacs-devel
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 25 Jun 2015 17:59:58 +0300
>
> On 06/25/2015 05:05 PM, Paul Eggert wrote:
>
> > Also, it's not clear how the overall approach would work on limited
> > displays that don't have alternate fonts and/or colors. Suppose, for
> > example, that the user is running 'emacs --color=never' on a character
> > terminal?
>
> I thought this was implemented somewhere in the display engine? If not,
> it could be.
I didn't track this discussion, so forgive me if what I say below
makes no sense.
With that caveat, since you (AFAIU) are talking about using the
font-lock mechanism for producing effects other than color, whether
the terminal supports colors should not bother you. That's because
the actual expression of the faces that have color attributes happens
on the lowest level of terminal-specific parts of the display engine,
and the rest of display doesn't care -- it manipulates faces, not
colors.
> Or someone could tell me how to check whether curly quotes are
> undisplayable in Lisp, and the rule will perform no substitutions, for
> instance.
I think you want char-displayable-p.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-25 15:11 ` Eli Zaretskii
@ 2015-06-25 15:33 ` Dmitry Gutov
0 siblings, 0 replies; 22+ messages in thread
From: Dmitry Gutov @ 2015-06-25 15:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, emacs-devel
On 06/25/2015 06:11 PM, Eli Zaretskii wrote:
> With that caveat, since you (AFAIU) are talking about using the
> font-lock mechanism for producing effects other than color, whether
> the terminal supports colors should not bother you.
Yes, that's why I didn't understand why mention colors. The question of
supported characters seems to be a pertinent one, though.
> I think you want char-displayable-p.
Seems so. Thanks.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-06-25 14:56 ` Dmitry Gutov
@ 2015-07-31 18:51 ` Paul Eggert
2015-07-31 19:24 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-07-31 18:51 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
> If some font-lock features lack documentation, demand it to be added, then.
"Demand" is a pretty strong word. I did ask for better documentation in
Bug#20613. I realize it's not always easy to write good documentation.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-07-31 18:51 ` Paul Eggert
@ 2015-07-31 19:24 ` Dmitry Gutov
2015-08-01 1:16 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2015-07-31 19:24 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 07/31/2015 09:51 PM, Paul Eggert wrote:
> "Demand" is a pretty strong word. I did ask for better documentation in
> Bug#20613. I realize it's not always easy to write good documentation.
I thought I addressed that bug report more or less adequately.
The piece of code you've quoted does not follow the idiomatic way
font-lock-keywords should be used, but it plays by the documented rules,
and simply adds compose-region as a side-effect. We can't document every
way people might want to write a Lisp program.
In any case, I thought we've moved away from the idea of using
font-lock, to translating the buffer contents directly, in Lisp?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-07-31 19:24 ` Dmitry Gutov
@ 2015-08-01 1:16 ` Paul Eggert
2015-08-01 1:28 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2015-08-01 1:16 UTC (permalink / raw)
To: Dmitry Gutov, emacs-devel
Dmitry Gutov wrote:
> I thought we've moved away from the idea of using font-lock, to translating the
> buffer contents directly, in Lisp?
Ah, I wasn't aware of that. At least, not the Lisp part.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
2015-08-01 1:16 ` Paul Eggert
@ 2015-08-01 1:28 ` Dmitry Gutov
0 siblings, 0 replies; 22+ messages in thread
From: Dmitry Gutov @ 2015-08-01 1:28 UTC (permalink / raw)
To: Paul Eggert, emacs-devel
On 08/01/2015 04:16 AM, Paul Eggert wrote:
> Ah, I wasn't aware of that. At least, not the Lisp part.
I hoped to move, at least.
http://lists.gnu.org/archive/html/emacs-devel/2015-07/msg00063.html
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2015-08-01 1:28 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20150619073901.5856.32718@vcs.savannah.gnu.org>
[not found] ` <E1Z5qtC-0001Xe-1y@vcs.savannah.gnu.org>
2015-06-21 19:09 ` [Emacs-diffs] master c4151eb: Improve the optional translation of quotes Dmitry Gutov
2015-06-21 19:56 ` Paul Eggert
2015-06-21 19:57 ` Dmitry Gutov
2015-06-21 20:03 ` Paul Eggert
2015-06-21 20:29 ` Dmitry Gutov
2015-06-21 20:46 ` Paul Eggert
2015-06-21 23:52 ` Dmitry Gutov
2015-06-22 6:50 ` Paul Eggert
2015-06-22 15:09 ` Dmitry Gutov
2015-06-23 5:36 ` Paul Eggert
2015-06-23 10:55 ` Dmitry Gutov
2015-06-24 5:24 ` Paul Eggert
2015-06-25 12:52 ` Dmitry Gutov
2015-06-25 14:05 ` Paul Eggert
2015-06-25 14:56 ` Dmitry Gutov
2015-07-31 18:51 ` Paul Eggert
2015-07-31 19:24 ` Dmitry Gutov
2015-08-01 1:16 ` Paul Eggert
2015-08-01 1:28 ` Dmitry Gutov
2015-06-25 14:59 ` Dmitry Gutov
2015-06-25 15:11 ` Eli Zaretskii
2015-06-25 15:33 ` Dmitry Gutov
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.