emacs-devel
[Top][All Lists]
Advanced

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

Fwd: [patch] make electric-pair-mode smarter/more useful


From: João Távora
Subject: Fwd: [patch] make electric-pair-mode smarter/more useful
Date: Mon, 16 Dec 2013 19:02:57 +0000

On Mon, Dec 16, 2013 at 3:30 PM, Stefan Monnier
<address@hidden> wrote:
>>        With ""foo""bar", try input " at point 1. Should become """"foo""bar" 
>> and point at 2
> Why should it become """"foo""bar"?

Mind you, don't confuse the docstring's quotes with the quotes in the
fixture text. The fixture is

  "foo" "bar

Which I (and font-lock) interpret as one perfectly terminated string
followed by an unterminated string.

So typing a quote at the very beginning should make it autopair IMO,
so that you get.

  """foo" "bar

Which is a perfectly terminated empty string, followed by the original fixture's
terminated and unterminated strings.

>> - "always" or "never" (depending on whether it's pair or skip)
>> - "balance, maybe"    (the default we're discussing)
>> - "balance, always"
>> - "don't balance, be conservative"
> Not sure what the "balance, always" refers to or why we need it, but
> other than that, yes.  The "balance" entry will be a "balance maybe".

Yes, it's silly probably.

"balance, always" would be "balance without depending on
electric-pair-preserve-balance.
"balance, maybe" would be "balance, but depending on
electric-pair-preserve-balance.".

You want me to strike "balance, always" and keep only "balance, maybe",
renamed as as "balance", right?

> That's different: this `or' test is to distinguish between two different
> notions of "interactively" (i.e. whether the user interactively
> triggered this specific function, vs whether the function was called
> using call-interactively).

Oh OK, I read the docstring in diagonal and didn't test much. But that
docstring might be a little confusing...

> Maybe, maybe not (it probably depends on the specific case), but since
> it's very rarely called from Lisp, I think we'd better not worry about
> it until someone reports an actual problem with it.

Then (newline 1 t) it is!

>>>> +(put 'electric-pair-post-self-insert-function   'priority  20)
>>>> +(put 'electric-layout-post-self-insert-function 'priority  40)
>>>> +(put 'electric-indent-post-self-insert-function 'priority  60)
>>>> +(put 'blink-paren-post-self-insert-function     'priority 100)
>>> These belong next to the corresponding functions.
>> Do they? The relative order is between them,
> The whole point of using priorities is to make them not depend on each
> other but on some external total order.

But in the end they do depend directly on each other. OK, you can
make it generic and say this one gets 20 because it inserts and deletes
characters, this other one gets 40 because it inserts extra newlines,
that 60 because something, and this one gets 100 because it does the
sit-for. But developing this theory for now seemed like overkill to me,
and without it would appear to the reader that ETOOMANYWORDS.

OK I'll do it.

>> In js-mode layout rules, pairing must come before layout, there's a test
>> for that.
> Do you know the underlying reason why the test fails if you do it the
> other way around?

I don't remember anymore, but its very easy to reproduce if you scratch
the sort function and write an additional test with the order of minor modes
reversed. Then I can check. I don't have emacs handy now.

Hoping this message isn't too garbled by the gmail interface,
João



reply via email to

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