electric-pair-mode as a minor mode?

electric-pair-mode as a minor mode?

[Yuri D'Elia]

I'd like to disable electric-pair-mode in certain buffers.
Probably the most important example is the minibuffer.

Incremental searching with eletric-pairing is frustrating as opposed to
being helpful as the search is "temporarily broken" as soon as the pair
is inserted.

I made eletric-pair-mode nil/buffer-local in the hooks that I need,
but somehow I feel electric-pair-mode should be a regular minor mode.

When editing regular text, as opposed to code, I also occasionally
switch it off because I find it distracting.

Opinions?

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

> I'd like to disable electric-pair-mode in certain buffers.
> Probably the most important example is the minibuffer.

> Incremental searching with eletric-pairing is frustrating as opposed to
> being helpful as the search is "temporarily broken" as soon as the pair
> is inserted.

[ I'm curious to know more about those isearch and minibuffer cases
  because I haven't bumped into them.  Not that it makes any difference
  to the following.  ]

> I made eletric-pair-mode nil/buffer-local in the hooks that I need,
> but somehow I feel electric-pair-mode should be a regular minor mode.

Hmm, electric-pair-mode *is* a regular minor mode.  Maybe you mean
that it should be buffer-local because you'd only want to enable it in
a few specific major modes?

We could very well define an electric-pair-local-mode, like we did with
electric-indent-local-mode.  In the mean time, you should be able to
hack it with something like:

   (electric-pair-mode 1)
   (setq-default electric-pair-mode nil)

   (add-hook 'foo-mode-hook
             (lambda () (setq-local electric-pair-mode t)))

> When editing regular text, as opposed to code, I also occasionally
> switch it off because I find it distracting.

I think I would agree that it should be less eager in text modes
(i.e. in modes where syntax-ppss gives notoriously unreliable results).
I'm pretty sure that can be done fairly easily, by fixing a few
concrete cases.


        Stefan

Re: electric-pair-mode as a minor mode?

[Yuri D'Elia]

On 03/27/2015 03:18 AM, Stefan Monnier wrote:
>> Incremental searching with eletric-pairing is frustrating as opposed to
>> being helpful as the search is "temporarily broken" as soon as the pair
>> is inserted.
> 
> [ I'm curious to know more about those isearch and minibuffer cases
>   because I haven't bumped into them.  Not that it makes any difference
>   to the following.  ]

It's just a nuisance. If I'm performing an isearch, looking for
"foo(bar", the matching will, of course, stop to find anything at
"foo()" just before I kill the closing paren.

There's no harm done, but I realized I never truly had to close a paren
in isearch before, I just RET-ed away. And given that the cursor
momentarily goes back to the starting point, I find it distracting since
I'm scanning visually the buffer...

>> I made eletric-pair-mode nil/buffer-local in the hooks that I need,
>> but somehow I feel electric-pair-mode should be a regular minor mode.
> 
> Hmm, electric-pair-mode *is* a regular minor mode.  Maybe you mean
> that it should be buffer-local because you'd only want to enable it in
> a few specific major modes?

[ just terminology here, isn't anything which is not global-minor
  automatically buffer local? ]

> We could very well define an electric-pair-local-mode, like we did with
> electric-indent-local-mode.  In the mean time, you should be able to
> hack it with something like:

If it's not a big issue, I would definitely do it.

I'm actually thinking that's something I would selectively turn on in
the base 'prog-mode-hook myself.

>    (electric-pair-mode 1)
>    (setq-default electric-pair-mode nil)
> 
>    (add-hook 'foo-mode-hook
>              (lambda () (setq-local electric-pair-mode t)))

That's basically what I'm doing, but in reverse at the moment (I turn it
off selectively).

Re: electric-pair-mode as a minor mode?

[João Távora]

Hi Stefan and Yuri,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'd like to disable electric-pair-mode in certain buffers.
>> Probably the most important example is the minibuffer.
> [ I'm curious to know more about those isearch and minibuffer cases
>   because I haven't bumped into them.  Not that it makes any difference
>   to the following.  ]

I also don't see it. I though that, rightfully so, the syntax in
isearch-mode is tweaked so that parens don't match there.

This is probably the case in most minibuffers (though one still has to
deal with the `electric-pair-pairs' overrider, but not isearch, where
most keys are mapped to `isearch-printing-char' and not
`self-insert'. And this is why they are pair-free.

>    (electric-pair-mode 1)
>    (setq-default electric-pair-mode nil)
>
>    (add-hook 'foo-mode-hook
>              (lambda () (setq-local electric-pair-mode t)))

I would do it like this. Though I didn't test much, it looks less hacky
to me:

   (electric-pair-mode 1)
    
   (add-hook 'foo-mode-hook
             (lambda ()
               (setq-local electric-pair-pairs nil)
               (setq-local electric-pair-text-pairs nil)
               (setq-local electric-pair-inhibit-predicate #'identity)))

So electric-pair-mode is still active (you still get autoskipping if the
syntax determines it), but autopairing is inhibited. Is this still
annoying?

But making electric-pair-local-mode also sounds good to me.

>> When editing regular text, as opposed to code, I also occasionally
>> switch it off because I find it distracting.
> I'm pretty sure that can be done fairly easily, by fixing a few
> concrete cases.

Can you name some?

`electric-pair-pairs' and `electric-pair-text-pairs' which mean "always
always pair these" are the "eager" cases, in my opinion.

At least `electric-pair-pairs' could be made to default to nil, and
probably `electric-pair-text-pairs' too. The snippet above becomes
simpler.

If I recall correctly, `electric-pair-pairs' was kept for backward
compatibility with the original implementation of `electric-pair-mode'
that didn't deduce its behaviour from the mode's syntax.

João

Re: electric-pair-mode as a minor mode?

[Tom Willemse]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'd like to disable electric-pair-mode in certain buffers.
>> Probably the most important example is the minibuffer.
>
>> Incremental searching with eletric-pairing is frustrating as opposed to
>> being helpful as the search is "temporarily broken" as soon as the pair
>> is inserted.
>
> [ I'm curious to know more about those isearch and minibuffer cases
>   because I haven't bumped into them.  Not that it makes any difference
>   to the following.  ]
>
>> I made eletric-pair-mode nil/buffer-local in the hooks that I need,
>> but somehow I feel electric-pair-mode should be a regular minor mode.
>
> Hmm, electric-pair-mode *is* a regular minor mode.  Maybe you mean
> that it should be buffer-local because you'd only want to enable it in
> a few specific major modes?
>
> We could very well define an electric-pair-local-mode, like we did with
> electric-indent-local-mode.  In the mean time, you should be able to
> hack it with something like:

Not to be a nuisance, but I wrote a patch for that some time ago and I'm
still waiting on a response:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19528

I've been using it since long before I sent it in and it's basically
just a copy of the `electric-indent-local-mode' code (comments and all).


Regards,

Tom

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

>> [ I'm curious to know more about those isearch and minibuffer cases
>> because I haven't bumped into them.  Not that it makes any difference
>> to the following.  ]
> It's just a nuisance. If I'm performing an isearch, looking for
> "foo(bar", the matching will, of course, stop to find anything at
> "foo()" just before I kill the closing paren.

I don't understand:

   C-s f o o ( b a r

does not search for "foo(bar)" but for "foo(bar" for me.

> [ just terminology here, isn't anything which is not global-minor
>   automatically buffer local? ]

Right, sorry, just terminology:
Yes, a non-global minor mode is a buffer-local minor-mode.
But to me a "non regular" minor mode is one that doesn't quite follow
all the conventions (e.g. it's not implemented with define-minor-mode,
treats its argument slightly differently or doesn't take any argument,
etc...).


        Stefan

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

>>> When editing regular text, as opposed to code, I also occasionally
>>> switch it off because I find it distracting.
>> I'm pretty sure that can be done fairly easily, by fixing a few
>> concrete cases.

> Can you name some?

I know that I regularly find myself deleting closing parens in
text-modes because I typed (...) and the closing paren inserted when
I hit the "(" is not skipped when I hit the ")".

It's probably because of something in the context, but you can't assume
that parens are properly balanced in text mode.

Here's one concrete example I bumped into earlier today:

   this is a sad example :-(
   I just wanted to type foo ())

The double close paren was due to electric-pair-mode not skipping the
first close-paren when I hit ")", because it took the sad smiley as an
open paren.


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It's probably because of something in the context, but you can't assume
> that parens are properly balanced in text mode.

I don't, not directly. I just use whatever (syntax-table) says, as does
`show-paren-mode' FWIW. And it says that text-mode buffers are all the
same context and should have balanced parenthesis. Perhaps it shouldn't.

> Here's one concrete example I bumped into earlier today:
>
>    this is a sad example :-(
>    I just wanted to type foo ())

For every :-( there should be a :-), see?

Seriously, while I won't stand in the way of having some
`electric-pair-mode'-related default hookage in text-mode-hook, why
isn't this fixed in text-mode's syntax-table? Aren't those wrong
assumptions the real culprit?

Do you want to recognize that the "sad example :-(" is in "a different
context" than the function call foo(), and so should not be paired? If
so, there's emacs machinery that separate those contexts (comment and
non-comment) and `electric-pair-mode' can take that into consideration
via `electric-pair-text-syntax-table'.

But you obviously know this, so what do you have in mind?

João

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

> Seriously, while I won't stand in the way of having some
> `electric-pair-mode'-related default hookage in text-mode-hook, why
> isn't this fixed in text-mode's syntax-table? Aren't those wrong
> assumptions the real culprit?

I don't think so: it's very useful for text-mode to match parentheses
(even if it only works 90% of the time), so I definitely don't want to
change that (that would prevent using C-M-f and friends).  But code
shouldn't assume that syntax-ppss gives any kind of useful info in such
modes because in practice it's much too frequent for parentheses not to
be properly paired.

> But you obviously know this, so what do you have in mind?

The behavior of the old electric-pair-mode did not use syntax-ppss and
its `)' simply always skipped (if there was a `)' to skip, obviously).

The assumption was basically that it's easier for the user to hit ')' one
more time than to delete an extraneous ')'.


        Stefan

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

Tom Willemse <tom@ryuslash.org> writes:
> Not to be a nuisance, but I wrote a patch for that some time ago and I'm
> still waiting on a response:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19528

João, can you take a look at that?


        Stefan

Re: electric-pair-mode as a minor mode?

[Yuri D'Elia]

On 03/27/2015 12:18 PM, João Távora wrote:
>>> I'd like to disable electric-pair-mode in certain buffers.
>>> Probably the most important example is the minibuffer.
>> [ I'm curious to know more about those isearch and minibuffer cases
>>   because I haven't bumped into them.  Not that it makes any difference
>>   to the following.  ]
> 
> I also don't see it. I though that, rightfully so, the syntax in
> isearch-mode is tweaked so that parens don't match there.

I'll have a deeper look why I have this behavior in isearch.

>    (add-hook 'foo-mode-hook
>              (lambda ()
>                (setq-local electric-pair-pairs nil)
>                (setq-local electric-pair-text-pairs nil)
>                (setq-local electric-pair-inhibit-predicate #'identity)))
> 
> So electric-pair-mode is still active (you still get autoskipping if the
> syntax determines it), but autopairing is inhibited. Is this still
> annoying?
>
> But making electric-pair-local-mode also sounds good to me.

For text buffers, I would just disable the minor mode locally.
The way I edit text is way less structured than code and much more chaotic.

Dumb is better for me in this case.

electric-pair not pairing in text mode is less expected than just
turning it off. With the same logic, if electric-pair is on, I would
expect it to pair by default even in text.

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Tom Willemse <tom@ryuslash.org> writes:
>> Not to be a nuisance, but I wrote a patch for that some time ago and I'm
>> still waiting on a response:
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19528
>
> João, can you take a look at that?

Looks pretty good so I just pushed:

    commit 40b3dcd2c06e30048be0bdc32861148a53660c90
    Author: Tom Willemse <tom@ryuslash.org>
    Date:   Sat Mar 28 14:43:33 2015 +0000
     
        New `electric-pair-local-mode'
        
        Fixes: big#19528
        
        * lisp/elec-pair.el (electric-pair-local-mode): New command.
        (electric-pair-mode): Mention `electric-pair-local-mode' in the
        docstring.

Didn't check for Tom's copyright assignment since I believe it counts as
a trivial patch (<15loc).

João

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The assumption was basically that it's easier for the user to hit ')' one
> more time than to delete an extraneous ')'.

I didn't follow this bit, sorry, just as I didn't follow the exceptions
of the old electric-pair-mode. But that just shows that assumptions
about convenience vary a lot from user to user.

I like my syntax-table to understand to know as much as possible, so
that other commands can dwim. Perhaps I'll try a message-mode hack to
make blockquotes and smileys comment syntax. That should bring the 90%
to 99%...

Anyway `electric-pair-local-mode' is now available so people can choose.

João

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

> I like my syntax-table to understand to know as much as possible, so
> that other commands can dwim. Perhaps I'll try a message-mode hack to
> make blockquotes and smileys comment syntax. That should bring the 90%
> to 99%...

My previous message was another example of problematic situations:

   The behavior of the old electric-pair-mode did not use syntax-ppss and
   its `)' simply always skipped (if there was a `)' to skip, obviously).

Those `)' thingies shouldn't be counted.  There can be many other
reasons.  Here's another: in message-mode you might have a buffer that
looks like:

   > foo far bla (blibli
   Here's my answer to that.

Again, the parens are not balanced (in this case because the matching
paren was simply in a part of the message which was omitted).

> Anyway `electric-pair-local-mode' is now available so people can choose.

I actually don't want to disable electric-pair-mode in text-modes.
But I do find it occasionally too optimistic in its assessment of what
it knows.


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I like my syntax-table to understand to know as much as possible, so
>> that other commands can dwim. Perhaps I'll try a message-mode hack to
>> make blockquotes and smileys comment syntax. That should bring the 90%
>> to 99%...
> Those `)' thingies shouldn't be counted.  There can be many other
> reasons.  Here's another: in message-mode you might have a buffer that
>
>    > foo far bla (blibli
>    Here's my answer to that.

But this is precisely the use case for the "message mode hack" earlier:
If the following line (I called it a "blockquote" but perhaps it has
another name)

   > foo bar bla (blibli

is seen, in message-mode, has having comment syntax, then you shouldn't
have that problem. If, additionally, smileys and other sporadic
artifacts can also be identified as comments or strings, the situations
you mention should be further reduced.

I haven't tested, because I don't have time to learn about implementing
comment syntaxes right now (I also probably won't if you tell me it's
futile or problematic for some other reason). But anyway in my naive
assessment it should work as well as it already does for programming
modes, where `(' and `)' thingies can exist unpaired in comments and
string literals.

> Again, the parens are not balanced (in this case because the matching
> paren was simply in a part of the message which was omitted).
>
>> Anyway `electric-pair-local-mode' is now available so people can choose.
>
> I actually don't want to disable electric-pair-mode in text-modes.
> But I do find it occasionally too optimistic in its assessment of what
> it knows.

Yes, I understand, but what do you suggest? I just hope it's not
changing the default value of `electric-pair-preserve-balance', which I
personally like very much... Why don't you

   (add-hook 'text-mode-hook
     (lambda () (setq-local electric-pair-preserve-balance nil)))

in your configuration?

João

Re: electric-pair-mode as a minor mode?

[João Távora]

joaotavora@gmail.com (João Távora) writes:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>> I like my syntax-table to understand to know as much as possible, so
>>> that other commands can dwim. Perhaps I'll try a message-mode hack to
>>> make blockquotes and smileys comment syntax. That should bring the 90%
>>> to 99%...
>>    > foo far bla (blibli
>>    Here's my answer to that.
>
> I haven't tested, because I don't have time to learn about implementing

Actually, I just tested, I find, even as I'm writing this message, that

   (modify-syntax-entry ?> "<   " message-mode-syntax-table)
   (modify-syntax-entry ?\n ">   " message-mode-syntax-table)
   (modify-syntax-entry ?\" "\"    " message-mode-syntax-table)
   (add-hook 'message-mode-hook
             (lambda () (setq-local parse-sexp-ignore-comments t)))

Works reasonably well for handling cited text. The only issue I'm seeing
is that single ?> in my code snippet that is erroneously interpreted as
a comment starter. Perhaps there's a way to fix that (two-char-long
comment sequences?), but I find it rare enough.

J

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

> But this is precisely the use case for the "message mode hack" earlier:

Yes, you can add more hacks to try and handle a few special cases, but
each one of those hacks is heuristic (i.e. will have false positives and
false negatives) and they'll never cover all actual cases (they're very
dependent on specific conventions used by people, which change
significantly between communities).

> I haven't tested, because I don't have time to learn about implementing
> comment syntaxes right now (I also probably won't if you tell me it's
> futile or problematic for some other reason).

It might be a good idea to do it in general (i.e. not as part of
electric-pair-mode but as part of message-mode for example).  But it
doesn't change the fact that syntax-ppss is unreliable.

> assessment it should work as well as it already does for programming
> modes, where `(' and `)' thingies can exist unpaired in comments and
> string literals.

In programming modes, there's a formal and unambiguous definition of what
is correct syntax and what isn't (or at least there should be for any
sane programming language), so we can hope to refine Emacs's rules until
they're correct.  But for natural language, there's no such perfection.

> Yes, I understand, but what do you suggest? I just hope it's not
> changing the default value of `electric-pair-preserve-balance', which I
> personally like very much... Why don't you
>
>    (add-hook 'text-mode-hook
>      (lambda () (setq-local electric-pair-preserve-balance nil)))
>
> in your configuration?

Ah, that might do it, indeed.  At least a quick experiment seems to
handle the cases I mentioned so far.


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> It might be a good idea to do it in general (i.e. not as part of
> electric-pair-mode but as part of message-mode for example).  

Yes, that's what I meant. This hack:

   (modify-syntax-entry ?> "<   " message-mode-syntax-table)
   (modify-syntax-entry ?\n ">   " message-mode-syntax-table)
   (add-hook 'message-mode-hook
          (lambda () (setq-local parse-sexp-ignore-comments t)))

could go somewhere into lisp/message.el if it weren't so fragile: the
comment syntax could change according to `message-yank-cited-prefix' and
also I has to be a comment only if it starts in the first column... Do
you follow?  Know any way to handle these cases?

> doesn't change the fact that syntax-ppss is unreliable.  they're
> ... 
> correct.  But for natural language, there's no such perfection.  very
> ...
> dependent on specific conventions used by people, which change
> significantly between communities).

Yes, yes and yes. Of course in natural languages there's no compiler
formally telling you the message is unsyntactic, but I personally will
go for a tool that gets it right almost everytime (some value between
90% and 100%), as long as the price when it gets it wrong is not too
high. And simple syntax changes to help the syntax-ppss heuristic are
the low-hanging fruit.

>>    (add-hook 'text-mode-hook
>>      (lambda () (setq-local electric-pair-preserve-balance nil)))
> Ah, that might do it, indeed.  At least a quick experiment seems to
> handle the cases I mentioned so far.

Not suprising considering that brings back precisely your old
implementation :-)

(oh no an unpaired smiley!)

João 

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

> could go somewhere into lisp/message.el if it weren't so fragile: the
> comment syntax could change according to `message-yank-cited-prefix' and
> also I has to be a comment only if it starts in the first column...
> Do you follow?  Know any way to handle these cases?

I guess you'd have to use syntax-propertize-function to catch&handle the
"unusual cases".

> Yes, yes and yes. Of course in natural languages there's no compiler
> formally telling you the message is unsyntactic, but I personally will
> go for a tool that gets it right almost everytime (some value between
> 90% and 100%), as long as the price when it gets it wrong is not too
> high. And simple syntax changes to help the syntax-ppss heuristic are
> the low-hanging fruit.

Agreed.  BTW, someone has written some syntax-propertize-function code
to "neutralize" the smileys, along the same ideas.  Can't remember where
it was discussed, tho, maybe gnu.emacs.help.

> Not suprising considering that brings back precisely your old
> implementation :-)

Ah, well, then this should work brilliantly, obviously,


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I guess you'd d have to use syntax-propertize-function to catch&handle the
> "unusual cases". 

Here's my current attempt.

    (add-hook 'message-mode-hook 'joaot/setup-message-mode-syntax)
     
    (defun joaot/setup-message-mode-syntax ()
      (setq-local syntax-propertize-function 'message--syntax-propertize
      (setq-local parse-sexp-lookup-properties t)
      (setq-local parse-sexp-ignore-comments t))
     
    (defun message--syntax-propertize (beg end)
      ;; first, remove all `syntax-table' properties
      ;;
      (remove-text-properties beg end '(syntax-table nil))
      ;; propertize smileys as "generic comments"
      ;;
      (goto-char beg)
      (while (search-forward-regexp ":-?[()]" end 'noerror)
        (add-text-properties (match-beginning 0) (match-end 0)
                             '(syntax-table (14 . nil))))
      ;; idem for citations
      ;;
      (goto-char beg)
      (while (search-forward-regexp
              (concat "^" message-cite-prefix-regexp ".*")
              end 'noerror)
        (add-text-properties (match-beginning 0) (match-end 0)
                             '(syntax-table (14 . nil)))))


It seems works well but:

* I have no idea how "expensive" this naive approach is.

* Although the `syntax-table' property seems to be set correctly, and
  both show-paren mode and electric-pair-mode seem to dtrt, I saw many
  cases where M-: (nth 4 (syntax-ppss)) didn't return non-nil when it
  should have, and vice versa. Is this part of the
  `parse-sexp-lookup-properties' sematics, that `syntax-ppss' becomes
  meaningless?
  
* I'm using `message-cite-prefix-regexp' to detect citations. It's what
  font-lock in lisp/gnus/message.el uses so it seems ideal. But there
  are also a lot of vars like `message-yank-prefix', whose docstring
  contains the following line which baffles me:

>    Fix `message-cite-prefix-regexp' if it is set to an abnormal value.

Can you have a look and give it some testing?

João

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

>     (defun message--syntax-propertize (beg end)
>       ;; first, remove all `syntax-table' properties
>       (remove-text-properties beg end '(syntax-table nil))

This should not be necessary (it's done by syntax-propertize before it
calls syntax-propertize-function).

>       ;; propertize smileys as "generic comments"
>       ;;
>       (goto-char beg)
>       (while (search-forward-regexp ":-?[()]" end 'noerror)
>         (add-text-properties (match-beginning 0) (match-end 0)
>                              '(syntax-table (14 . nil))))

14 is definitely not right.  A "comment fence" means "this char starts
or ends a comment, depending on whether we're inside a comment".
So putting this on 3 consecutive chars tells Emacs that the first
2 chars make up a comment and the 3rd is the beginning of a comment
(which might extend til the end of the buffer).

>       ;; idem for citations
>       ;;
>       (goto-char beg)
>       (while (search-forward-regexp
>               (concat "^" message-cite-prefix-regexp ".*")
>               end 'noerror)

You might want to move the "concat" out of the loop ;-)

>         (add-text-properties (match-beginning 0) (match-end 0)
>                              '(syntax-table (14 . nil)))))

> * I have no idea how "expensive" this naive approach is.

Shouldn't be much more expensive than doing the same thing in font-lock.

Not sure who's considered maintainer of message.el, but you should check
with Lars, see what he thinks of it.

> * Although the `syntax-table' property seems to be set correctly, and
>   both show-paren mode and electric-pair-mode seem to dtrt, I saw many
>   cases where M-: (nth 4 (syntax-ppss)) didn't return non-nil when it
>   should have, and vice versa. Is this part of the
>   `parse-sexp-lookup-properties' sematics, that `syntax-ppss' becomes
>   meaningless?

That's because you mis-used the comment markers.  They should only be
put at the beginning and at the end of the comment.

> * I'm using `message-cite-prefix-regexp' to detect citations. It's what
>   font-lock in lisp/gnus/message.el uses so it seems ideal. But there
>   are also a lot of vars like `message-yank-prefix', whose docstring
>   contains the following line which baffles me:
>> Fix `message-cite-prefix-regexp' if it is set to an abnormal value.

Hopefully Lars can say something useful about that.


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 14 is definitely not right.  A "comment fence" means "this char starts
> or ends a comment, depending on whether we're inside a comment".

oh, silly.

> That's because you mis-used the comment markers.  They should only be
> put at the beginning and at the end of the comment.

Makes sense. Look better?

(defvar message--comment-regexps
  ;; TODO: make this user-visible/customizable???
  (list
        ;; smiley regexp (TODO find a better one)
        ;;
        ":-?[()]"
        ;; citations
        ;;
        (concat "^" message-cite-prefix-regexp ".*$") ; citations
        ;; TODO: probably should be one here for citation header lines
        ;; TODO: also, let user add some of his own here?
        )
  "List of regexps counting as comments in message-mode buffers.")

(defun message--syntax-propertize (beg end)
  "Syntax-propertize certain message parts as comments."
  (mapc (lambda (regexp)
          (goto-char beg)
          (while (search-forward-regexp regexp end 'noerror)
            (let ((start (match-beginning 0))
                  (end (match-end 0)))
              (add-text-properties start (1+ start)
                                   '(syntax-table (11 . nil)))
              (add-text-properties (1- end) end
                                   '(syntax-table (12 . nil))))))
        message--comment-regexps))

>
>> * I'm using `message-cite-prefix-regexp' to detect citations. It's what
>>   font-lock in lisp/gnus/message.el uses so it seems ideal. But there
>>   are also a lot of vars like `message-yank-prefix', whose docstring
>>   contains the following line which baffles me:
>>> Fix `message-cite-prefix-regexp' if it is set to an abnormal value.
> Hopefully Lars can say something useful about that.

I'll follow up with a proper patch then.

João

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

> Makes sense. Look better?

Yup.

>         (concat "^" message-cite-prefix-regexp ".*$") ; citations
[...]
>               (add-text-properties start (1+ start)
>                                    '(syntax-table (11 . nil)))
>               (add-text-properties (1- end) end
>                                    '(syntax-table (12 . nil))))))

The above regexp might match only 1 character and hence (1- end) can be
equal to start.


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>         (concat "^" message-cite-prefix-regexp ".*$") ; citations
> [...]
>>               (add-text-properties start (1+ start)
>>                                    '(syntax-table (11 . nil)))
>>               (add-text-properties (1- end) end
>>                                    '(syntax-table (12 . nil))))))
>
> The above regexp might match only 1 character and hence (1- end) can be
> equal to start.

Well spotted. Though it shouldn't hurt to have a buffer pos ending a
comment that never started. Otoh I see no reason why it shouldn't be
`end' to `(1+ end)' instead...

João

Re: electric-pair-mode as a minor mode?

[João Távora]

joaotavora@gmail.com (João Távora) writes:

> Otoh I see no reason why it shouldn't be `end' to `(1+ end)'
> instead...
 
Sorry, take that back: If I do that, then

   blabla  :-((i'm not really sad) blabla

is a smiley followed by something that still has comment syntax but
should't, causing the last paren to look unpaired when it actually
is. So I'll just detect the length=1 edge case.

João

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

> Well spotted. Though it shouldn't hurt to have a buffer pos ending a
> comment that never started.

It's kind of OK, but it's suboptimal.  Another side effect (for normal
cited lines) is that the last char of that line will have "end of
comment" syntax rather than its normal syntax, so M-f may end up
stopping one char earlier than expected (if the cited lines ends with
a word).

> Otoh I see no reason why it shouldn't be
> `end' to `(1+ end)' instead...

Because you generally don't know what's after `end'.

I think in the case of the smiley regexps, rather than mark them as
comments, it's better to only change the parenthesis's syntax to be
"punctuation".


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think in the case of the smiley regexps, rather than mark them as
> comments, it's better to only change the parenthesis's syntax to be
> "punctuation".

Since Lars hasn't responded yet, here's an updated patch that addresses
the issues discussed so far.  OK to install?

João


[-- Attachment #2: 0001-Improve-sexp-based-movement-in-message-mode.patch --]
[-- Type: text/x-patch, Size: 5168 bytes --]

From 52dc7011b492523d898f797d85ee1ef924f0ad2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@gmail.com>
Date: Sat, 11 Apr 2015 16:52:44 +0100
Subject: [PATCH] Improve sexp-based movement in message-mode

Works by giving citations and smileys a different syntax.  This helps
modes like `show-paren-mode', `electric-pair-mode', and C-M-*
sexp-based movement.

* lisp/gnus/message.el (message--syntax-propertize): New function.
(message-mode): Set syntax-related vars.

* test/automated/message-mode-tests.el: New file
---
 lisp/gnus/message.el                 | 30 ++++++++++++++++++++-
 test/automated/message-mode-tests.el | 52 ++++++++++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 test/automated/message-mode-tests.el

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 04145de..4a8a8a6 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -2961,6 +2961,27 @@ See also `message-forbidden-properties'."
 
 (autoload 'ecomplete-setup "ecomplete") ;; for Emacs <23.
 
+(defun message--syntax-propertize (beg end)
+  "Syntax-propertize certain message text specially."
+  (let ((citation-regexp (concat "^" message-cite-prefix-regexp ".*$"))
+        (smiley-regexp (regexp-opt '(":-)" ":)"
+                                     ":-(" ":("
+                                     ";-)" ";)"))))
+    (goto-char beg)
+    (while (search-forward-regexp citation-regexp
+                                  end 'noerror)
+      (let ((start (match-beginning 0))
+            (end (match-end 0)))
+        (add-text-properties start (1+ start)
+                             '(syntax-table (11 . nil)))
+        (add-text-properties end (min (1+ end) (point-max))
+                             '(syntax-table (12 . nil)))))
+    (goto-char beg)
+    (while (search-forward-regexp smiley-regexp
+            end 'noerror)
+      (add-text-properties (match-beginning 0) (match-end 0)
+                           '(syntax-table (1 . nil))))))
+
 ;;;###autoload
 (define-derived-mode message-mode text-mode "Message"
   "Major mode for editing mail and news to be sent.
@@ -3063,7 +3084,14 @@ M-RET    `message-newline-and-reformat' (break the line and reformat)."
     ;; multibyte is not necessary at all. -- zsh
     (mm-enable-multibyte))
   (set (make-local-variable 'indent-tabs-mode) nil) ;No tabs for indentation.
-  (mml-mode))
+  (mml-mode)
+  ;; Syntactic fontification. Helps `show-paren-mode',
+  ;; `electric-pair-mode', and C-M-* navigation by syntactically
+  ;; excluding citations and other artifacts.
+  ;;
+  (setq-local syntax-propertize-function 'message--syntax-propertize)
+  (setq-local parse-sexp-lookup-properties t)
+  (setq-local parse-sexp-ignore-comments t))
 
 (defun message-setup-fill-variables ()
   "Setup message fill variables."
diff --git a/test/automated/message-mode-tests.el b/test/automated/message-mode-tests.el
new file mode 100644
index 0000000..6688a8a
--- /dev/null
+++ b/test/automated/message-mode-tests.el
@@ -0,0 +1,52 @@
+;;; message-mode-tests.el --- Tests for message-mdoe  -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2015  Free Software Foundation, Inc.
+
+;; Author: João Távora <joaotavora@gmail.com>
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; This file contains tests for message-mode.
+
+;;; Code:
+(require 'ert)
+(require 'ert-x)
+
+(ert-deftest message-mode-propertize ()
+  (with-temp-buffer
+    (unwind-protect
+        (progn
+          (message-mode)
+          (insert "here's an opener (\n"
+                  "here's a sad face :-(\n"
+                  "> here's citing someone with an opener (\n"
+                  "and here's a closer ")
+          (let ((last-command-event ?\)))
+            (ert-simulate-command '(self-insert-command 1)))
+          (backward-sexp)
+          (should (string= "here's an opener "
+                           (buffer-substring-no-properties
+                            (line-beginning-position)
+                            (point))))
+          (forward-sexp)
+          (should (string= "and here's a closer )"
+                           (buffer-substring-no-properties
+                            (line-beginning-position)
+                            (point)))))
+      (set-buffer-modified-p nil))))
+
+(provide 'message-mode-tests)
+;;; message-mode-tests.el ends here
-- 
1.8.2.3

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

>> I think in the case of the smiley regexps, rather than mark them as
>> comments, it's better to only change the parenthesis's syntax to be
>> "punctuation".
> Since Lars hasn't responded yet, here's an updated patch that addresses
> the issues discussed so far.  OK to install?

[ Hmm.... I'd really like Lars's input on this.
  But it looks OK to me.  ]

> +        (smiley-regexp (regexp-opt '(":-)" ":)"
> +                                     ":-(" ":("
> +                                     ";-)" ";)"))))

This list (and/or regexp) should be moved to a variable.

> +    (goto-char beg)
> +    (while (search-forward-regexp citation-regexp
> +                                  end 'noerror)
> +      (let ((start (match-beginning 0))
> +            (end (match-end 0)))
> +        (add-text-properties start (1+ start)
> +                             '(syntax-table (11 . nil)))

I'd recommend you use the string for of syntax-specifiers, as in
(string-to-syntax "<").  These are evaluated at compile-time, so
it's efficient.

> +  (setq-local parse-sexp-lookup-properties t)

This one is not needed.  The syntax-propertize code should set it for
you already.


        Stefan

Re: electric-pair-mode as a minor mode?

[João Távora]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> I think in the case of the smiley regexps, rather than mark them as
>>> comments, it's better to only change the parenthesis's syntax to be
>>> "punctuation".
>> Since Lars hasn't responded yet, here's an updated patch that addresses
>> the issues discussed so far.  OK to install?
>
> [ Hmm.... I'd really like Lars's input on this.
>   But it looks OK to me.  ]

Commited with your recommendations.

As a side note, a spurious "Summary: " prefix slipped through in the
first line of the commit message, since I ammended my local commit from
the command line, with emacsclient as EDITOR and then used M-p
`log-edit-previous-comment' to pull in the last message. I saw
'Summary:' fontified so assumed it would be killed by `log-edit-mode'.

Something like

   (defun log-edit--strip-headers-maybe ()
     (save-excursion
       (goto-char (point-min))
       (when (and (search-forward-regexp "^Summary:[ \t]+" (line-end-position) t)
                  (y-or-n-p "Possibly spurious \"Summary:\" header detected. Remove?"))
         (delete-region (match-beginning 0) (match-end 0)))))

Would have helped, but I don't know where to hook it

Re: electric-pair-mode as a minor mode?

[Dmitry Gutov]

On 04/12/2015 04:16 PM, joaotavora@gmail.com (João Távora) wrote:

> As a side note, a spurious "Summary: " prefix slipped through in the
> first line of the commit message, since I ammended my local commit from
> the command line, with emacsclient as EDITOR and then used M-p
> `log-edit-previous-comment' to pull in the last message. I saw
> 'Summary:' fontified so assumed it would be killed by `log-edit-mode'.

Thoughts:

- I wonder why you didn't have the existing message already filled in 
the buffer, so you'd had to press `M-n'.

- This kind of commit message buffers should probably use a different 
major mode: after all, the format of the contents is different.

- vc-git supports the "amend" feature, so you shouldn't have had to use 
the command line; although it's a bit awkward when you want just to edit 
the message, and there are no changes in any files: then 
`vc-next-action' doesn't even initiate commit. We should integrate it 
with `log-view-modify-change-comment'.

> Something like
>
>     (defun log-edit--strip-headers-maybe ()
>       (save-excursion
>         (goto-char (point-min))
>         (when (and (search-forward-regexp "^Summary:[ \t]+" (line-end-position) t)
>                    (y-or-n-p "Possibly spurious \"Summary:\" header detected. Remove?"))
>           (delete-region (match-beginning 0) (match-end 0)))))

Maybe somewhere in `before-save-hook' of the new major mode?

Re: electric-pair-mode as a minor mode?

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 04/12/2015 04:16 PM, joaotavora@gmail.com (João Távora) wrote:
>
>> As a side note, a spurious "Summary: " prefix slipped through in the
>> first line of the commit message, since I ammended my local commit from
>> the command line, with emacsclient as EDITOR and then used M-p
>> `log-edit-previous-comment' to pull in the last message. I saw
>> 'Summary:' fontified so assumed it would be killed by `log-edit-mode'.
>
> Thoughts:
>
> - I wonder why you didn't have the existing message already filled in
> the buffer, so you'd had to press `M-n'.

(I pressed `M-p', not `M-n'). But true, in recent tests I see always see
the last commit message when I commit --amend. Perhaps I had amended
some more times and wanted to go to some intermediate version.  I dunno
anymore.

> - This kind of commit message buffers should probably use a different
> major mode: after all, the format of the contents is different.

That's right. Although I can't resist asking why these "Summary" and
"Author" hints/cookies can't be some display-only element like a
before-string in an overlay. Why are they implemented as actual buffer
text?

> - vc-git supports the "amend" feature, so you shouldn't have had to
> use the command line; although it's a bit awkward when you want just
> to edit the message, and there are no changes in any files: then
> `vc-next-action' doesn't even initiate commit. We should integrate it
> with `log-view-modify-change-comment'.

Never tried it. Didn't know they existed even. I make commits from
vc-dir and command line alternately as is more convenient, so I
`log-edit-mode' in COMMIT_EDITMSG for a consistent UI.

> Maybe somewhere in `before-save-hook' of the new major mode?

Won't kick in when the buffer doesn't need saving. This seems works
nicely though:

    (defun log-edit--commit-editmsg-done ()
      ;; no idea why `log-edit-callback' is called with `call-interactive'
      (interactive)
      (save-excursion
        (goto-char (point-min))
        (when (and (search-forward-regexp "^Summary:[ \t]+" (line-end-position) t)
                   (y-or-n-p "Possibly spurious \"Summary:\" header detected. Remove?"))
          (delete-region (match-beginning 0) (match-end 0))))
      (save-buffer)
      (server-edit))
     
    (define-derived-mode log-edit--commit-editmsg-mode log-edit-mode "Log-Edit*"
      "Special version of `log-edit-mode' for .git/COMMIT_EDITMSG."
      (set (make-local-variable 'log-edit-callback)
           'log-edit--commit-editmsg-done)
      (setq default-directory (file-name-directory (directory-file-name default-directory))))
     
    (add-to-list 'auto-mode-alist '("\\.git/COMMIT_EDITMSG" . log-edit--commit-editmsg-mode))

Got it in my .emacs, but perhaps this could be installed, seems generic
enough. OTOH, git log --grep '^Summary:' seems to indicate this happens
only once every 5-6 years

João

Re: electric-pair-mode as a minor mode?

[Dmitry Gutov]

On 04/13/2015 01:16 AM, joaotavora@gmail.com (João Távora) wrote:

> (I pressed `M-p', not `M-n').

Right, that.

> That's right. Although I can't resist asking why these "Summary" and
> "Author" hints/cookies can't be some display-only element like a
> before-string in an overlay. Why are they implemented as actual buffer
> text?

I guess partly because it can be handled similarly to mail buffers (and 
maybe, at some point, some code can be merged).

And while "Summary:" could be implemented as a before-string on an 
overlay (or even purely with font-lock, maybe), other headers need extra 
processing: transform the value, move it to a different part of the 
buffer, etc. Aside from "Author" and "Signed-Off-By", we can encounter 
"Fixes:" and now, after the ChangeLogs conversion, 
"Copyright-paperwork-exempt:" and "Also-By:" (or some alternative thereof).

And good luck saving/restoring overlays in M-n/M-p implementations. Text 
prop-based implementation would handle this better, but how to use them 
in this context isn't necessarily apparent to me.

> Never tried it. Didn't know they existed even. I make commits from
> vc-dir and command line alternately as is more convenient, so I
> `log-edit-mode' in COMMIT_EDITMSG for a consistent UI.

I'm guessing git-commit-mode from MELPA would probably be a better fit, 
even if it has different interface.

>> Maybe somewhere in `before-save-hook' of the new major mode?
>
> Won't kick in when the buffer doesn't need saving.

But COMMIT_EDITMSG needs to be saved, doesn't it?

> This seems works nicely though:

log-edit-callback looks like a nice option, too.

> Got it in my .emacs, but perhaps this could be installed, seems generic
> enough.

It should probably handle other headers as well. I don't know if Git 
allows to set arguments like --author or --signed-off-by via some 
special comments in the commit file, but if it did, that would allow to 
unify the implementations nicely.

Re: electric-pair-mode as a minor mode?

[Lars Magne Ingebrigtsen]

joaotavora@gmail.com (João Távora) writes:

> Since Lars hasn't responded yet, here's an updated patch that addresses
> the issues discussed so far.  OK to install?

Looks OK to me, I think, but I know nothing about electric-pair-mode...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: electric-pair-mode as a minor mode?

[João Távora]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> joaotavora@gmail.com (João Távora) writes:
>
>> Since Lars hasn't responded yet, here's an updated patch that addresses
>> the issues discussed so far.  OK to install?
>
> Looks OK to me, I think, but I know nothing about electric-pair-mode...
>
The patch will help show-paren-mode, electric-pair-mode and general
C-M-f sexp-base navigation.

Anyway, the specific issue I wanted your feedback about is a few
messages back in this thread. It's about the use of

>> (let ((citation-regexp (concat "^" message-cite-prefix-regexp ".*$"))

as a way to consistently detect citations (inserted using message.el's
message-cite-* mechanisms). This is because there are lots of variables
there configuring the prefix, spacing and some other options, that
reference this variable in a comment that I couldn't understand. Like
this:

        (defcustom message-yank-prefix mail-yank-prefix
          "*Prefix inserted on the lines of yanked messages.
      ->Fix `message-cite-prefix-regexp' if it is set to an abnormal value.
        See also `message-yank-cited-prefix' and `message-yank-empty-prefix'."
          :version "23.2"
          :type 'string
          :link '(custom-manual "(message)Insertion Variables")
          :group 'message-insertion)

João 

Re: electric-pair-mode as a minor mode?

[Lars Magne Ingebrigtsen]

joaotavora@gmail.com (João Távora) writes:

> Anyway, the specific issue I wanted your feedback about is a few
> messages back in this thread. It's about the use of
>
>>> (let ((citation-regexp (concat "^" message-cite-prefix-regexp ".*$"))
>
> as a way to consistently detect citations (inserted using message.el's
> message-cite-* mechanisms). This is because there are lots of variables
> there configuring the prefix, spacing and some other options, that
> reference this variable in a comment that I couldn't understand. Like
> this:
>
>         (defcustom message-yank-prefix mail-yank-prefix
>           "*Prefix inserted on the lines of yanked messages.
>       ->Fix `message-cite-prefix-regexp' if it is set to an abnormal value.
>         See also `message-yank-cited-prefix' and `message-yank-empty-prefix'."
>           :version "23.2"
>           :type 'string
>           :link '(custom-manual "(message)Insertion Variables")
>           :group 'message-insertion)

Ah, right.  Well, there's a lot of people who use various non-standard
quoting methods.  I doubt you'd be able to make them all work out of the
box.  You have people who use stuff like "Lars | Here's the quouted text"  
and so on.

But if I understand your code correctly, I think what you're doing is
fine, and people who use weird quoting styles will just have to cope.
(Or rather, not get the new, nice functionality.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: electric-pair-mode as a minor mode?

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 04/13/2015 01:16 AM, joaotavora@gmail.com (João Távora) wrote:
>
>> (I pressed `M-p', not `M-n').
>
> Right, that.
>
>> That's right. Although I can't resist asking why these "Summary" and
>> "Author" hints/cookies can't be some display-only element like a
>> before-string in an overlay. Why are they implemented as actual buffer
>> text?
>
> I guess partly because it can be handled similarly to mail buffers
> (and maybe, at some point, some code can be merged).

Actually, once I view a commit message like an email message (which it
mostly is), things indeed start to make more sense.

> And while "Summary:" could be implemented as a before-string on an
> overlay (or even purely with font-lock, maybe), other headers need
> extra processing: transform the value, move it to a different part of
> the buffer, etc. Aside from "Author" and "Signed-Off-By", we can
> encounter "Fixes:" and now, after the ChangeLogs conversion,
> "Copyright-paperwork-exempt:" and "Also-By:" (or some alternative
> thereof).

Yeah, the problem is clearly the other headers, not Summary:

> And good luck saving/restoring overlays in M-n/M-p
> implementations. Text prop-based implementation would handle this
> better, but how to use them in this context isn't necessarily apparent
> to me.

Don't see any particular problem should be restoring overlays.

>> Never tried it. Didn't know they existed even. I make commits from
>> vc-dir and command line alternately as is more convenient, so I
>> `log-edit-mode' in COMMIT_EDITMSG for a consistent UI.
>
> I'm guessing git-commit-mode from MELPA would probably be a better
> fit, even if it has different interface.

Yes, sticking to log-edit is good.

>>> Maybe somewhere in `before-save-hook' of the new major mode?
>> Won't kick in when the buffer doesn't need saving.
> But COMMIT_EDITMSG needs to be saved, doesn't it?

Only if you change it. If the .git/COMMIT_EDITMSG is there for some
reason and you don't want to change it (perhaps you ammended something
else in the commit), then `before-save-hook' won't kick in.

>> Got it in my .emacs, but perhaps this could be installed, seems generic
>> enough.
>
> It should probably handle other headers as well. I don't know if Git
> allows to set arguments like --author or --signed-off-by via some
> special comments in the commit file, but if it did, that would allow
> to unify the implementations nicely.

Indeed. I thought it did, but I can't find any documentation for it. (1+
for the git skeptics I guess :-)). If there's interest, I'll ask
somewhere and come up with a more robust patch.

Re: electric-pair-mode as a minor mode?

[João Távora]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ah, right.  Well, there's a lot of people who use various non-standard
> quoting methods.  I doubt you'd be able to make them all work out of the
> box.  You have people who use stuff like "Lars | Here's the quouted text"  
> and so on.

This is why I said "inserted using message.el's message-cite-*
mechanisms". Do these people insert their quotes using message-yank-*
variables?

If so, the regexp could be constructed to respect those, and not
message-cite-prefix-regexp, right?

> But if I understand your code correctly, I think what you're doing is
> fine, and people who use weird quoting styles will just have to cope.
> (Or rather, not get the new, nice functionality.)

Or that. It might not be worth the effort.

On a related subject, I was thinking of (require 'smiley) in message.el
to avoid a `message-smiley' variable (a list o strings), and just use
the cars of `smiley-regexp-alist'. Can that be problematic?  (especially
because I've learned recently that changes to Emacs's Gnus are
automatically cherry-picked to the Gnus upstream where they might break
unexpectedly).

Re: electric-pair-mode as a minor mode?

[Lars Magne Ingebrigtsen]

joaotavora@gmail.com (João Távora) writes:

> This is why I said "inserted using message.el's message-cite-*
> mechanisms". Do these people insert their quotes using message-yank-*
> variables?

I'm not sure.  I've never used any of those packages, because I think
the default way message quotes is the best.  :-)

> On a related subject, I was thinking of (require 'smiley) in message.el
> to avoid a `message-smiley' variable (a list o strings), and just use
> the cars of `smiley-regexp-alist'. Can that be problematic?  (especially
> because I've learned recently that changes to Emacs's Gnus are
> automatically cherry-picked to the Gnus upstream where they might break
> unexpectedly).

Requiring smiley should be unproblematic, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: electric-pair-mode as a minor mode?

[João Távora]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> On a related subject, I was thinking of (require 'smiley) in message.el
>> to avoid a `message-smiley' variable (a list o strings), and just use
>> the cars of `smiley-regexp-alist'. Can that be problematic?
> Requiring smiley should be unproblematic, I think.

Not so, unfortunately. Requiring it eventually requires `message'
recursively. I tried with `eval-when-compile'. It works when compiling
message.el standalone, but not when making emacs (some interaction with
eager-macroexpansion, apparently):

How do I solve this?

João

PS: Here's what I tried:

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 1371e70..fe2097e 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -2964,15 +2964,13 @@ See also `message-forbidden-properties'."
 
 (autoload 'ecomplete-setup "ecomplete") ;; for Emacs <23.
 
-(defvar message-smileys '(":-)" ":)"
-                          ":-(" ":("
-                          ";-)" ";)")
-  "A list of recognized smiley faces in `message-mode'.")
+(eval-when-compile (require 'smiley)) ;; for `smiley-regexp-alist,'
+                                      ;; `eval-when-compile' needed to
+                                      ;; prevent recursive require.
 
 (defun message--syntax-propertize (beg end)
   "Syntax-propertize certain message text specially."
-  (let ((citation-regexp (concat "^" message-cite-prefix-regexp ".*$"))
-        (smiley-regexp (regexp-opt message-smileys)))
+  (let ((citation-regexp (concat "^" message-cite-prefix-regexp ".*$")))
     (goto-char beg)
     (while (search-forward-regexp citation-regexp
                                   end 'noerror)
@@ -2982,11 +2980,14 @@ See also `message-forbidden-properties'."
                              `(syntax-table ,(string-to-syntax "<")))
         (add-text-properties end (min (1+ end) (point-max))
                              `(syntax-table ,(string-to-syntax ">")))))
-    (goto-char beg)
-    (while (search-forward-regexp smiley-regexp
-            end 'noerror)
-      (add-text-properties (match-beginning 0) (match-end 0)
-                           `(syntax-table ,(string-to-syntax "."))))))
+    (when (featurep 'smiley)
+      (mapc (lambda (smiley-regexp)
+              (goto-char beg)
+              (while (search-forward-regexp smiley-regexp
+                                            end 'noerror)
+                (add-text-properties (match-beginning 0) (match-end 0)
+                                     `(syntax-table ,(string-to-syntax ".")))))
+            (mapcar #'car smiley-regexp-alist)))))
 
 ;;;###autoload
 (define-derived-mode message-mode text-mode "Message"

Re: electric-pair-mode as a minor mode?

[Lars Magne Ingebrigtsen]

joaotavora@gmail.com (João Távora) writes:

> Not so, unfortunately. Requiring it eventually requires `message'
> recursively. I tried with `eval-when-compile'. It works when compiling
> message.el standalone, but not when making emacs (some interaction with
> eager-macroexpansion, apparently):
>
> How do I solve this?

Looking at smiley.el, it seems to be referring to a few Gnus internals,
and Gnus depends on message.el all over the place.

So for this to work you'd either have to refactor smiley.el to be more
standalone, or you can move the definition of the smileys to message.el,
and do the dependencies the opposite way.  Or something.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: electric-pair-mode as a minor mode?

[Stefan Monnier]

>> Requiring smiley should be unproblematic, I think.
> Not so, unfortunately. Requiring it eventually requires `message'
> recursively.

Sounds wrong.  smiley.el should not depend on message or Gnus since it
can be useful in various other modes, such as plain text-mode.


        Stefan