all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: joaotavora@gmail.com (João Távora)
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs pretest -- electric-pair-mode change
Date: Thu, 03 Apr 2014 17:56:52 +0100	[thread overview]
Message-ID: <jjbeh1e2vxn.fsf@gmail.com> (raw)
In-Reply-To: <jwvk3b6v7jx.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 03 Apr 2014 10:22:28 -0400")

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

>> The quote part does seem to be the most problematic.  In the big
>> lisp/ldefs-boot.el I get just under a second on windows for pairing a
>> parens, and should be much faster on linux.
> [ Unrelated: it's odd that the speed should depend on the OS.  ]

I'm using two relatively similar dual-core machines. In windows I use
the builds of http://sourceforge.net/projects/emacs-bin/. Didn't I read
somewhere that these are compiled without optimization flags?

> BTW, while speed is a factor, it's not the only one: if the unpaired
> string is very far away, the user might be very surprised/disappointed
> by electric-pair's behavior (where it will pair when the user expects
> it not to and vice-versa).

Yes I see. But for me it's definitely better not to pair in those
situations (you seem to agree with me in your explanation of the
"simplifying assumption" below). Anyway the "oh, it didn't pair..."
disappointment is better than finding the unpaired string later, and at
least in my workflow, leads me to try a one-off M-x check-parens and fix
stuff before I continue hacking.

>>> In many languages, strings can't span multiple lines, or they can
>>> only do so if end-of-lines are somehow escaped.  Maybe we could use
>>> that to try and reduce the scope of the test.
>> Maybe (how?).
>
> Don't know.  Maybe use a buffer-local variable like
> electric-pair-string-bound-function which major-modes can set to
> a function that jumps to some buffer position which should not be within
> a string according to the language rules.  E.g. in C it could search for
> "[^\\]\n".  In Python, I think that wouldn't help, since triple-quoted
> strings can contain anything whatsoever, IIUC.  But python-mode could
> use a heuristic and look for the next "thing that looks like code" and
> hope that strings containing code will be rare enough.

Hmmm, sounds a little complicated, but will give it a go if all else
fails.

>> But even even in those languages, syntax (and fontification) works
>> across newlines, so do we pair for the language or for the syntax?
>
> In Emacs we often use the simplifying assumption that we only try to
> make the code work right in the case where the buffer's content is
> "correct" and if the buffer's content is "incorrect" then we reduce our
> expectation to something like "we do something acceptable".

Ok we agree perfectly then. "Something acceptible" then is "not
pairing", just the self-insertion the user asked for, rught?

>> Anyway, best I can come up with right now is the following, but with
>> frequent false negatives in oversize buffers. I don't know if I'd
>> rather have false positives (meaning less electricity in oversize
>> buffers)
>
> Checking (nth 3 (syntax-ppss (+ (point) <constant>))) doesn't make much
> sense, since we have no reason to assert that (+ (point) <constant>)
> should be outside of a string.

If (+ (point) <constant>) is less than (point-max) and inside a string
we additionally assert that at least that string is paired. If it's not,
we say "incorrect" which is always true. Otherwise we say "correct" and
risk a false judgement and a surprising pair. How often? Don't
know. Anyway I agree it's not a very good perfect heuristic.

What about this? Seems to be much much faster in the python buffer i've
been testing with (even on windoze :-)

    (defvar electric-pair-no-strings-syntax-table
      (let ((table (make-syntax-table)))
        (dotimes (char 256) ;; only searches the first 256 chars,
          (let* ((entry (aref table char))
                 (class (and entry
                             (syntax-class entry))))
            (when (and class (eq ?\" class))
              (modify-syntax-entry char "w" table))))
        table))
     
    (defun electric-pair--unbalanced-strings-p (char)
      (let ((table (make-syntax-table electric-pair-no-strings-syntax-table))
            (ppss (syntax-ppss)))
        (modify-syntax-entry char "\"" table)
        (with-syntax-table table
          (save-excursion
            (nth 3 (parse-partial-sexp (or (and (nth 3 ppss)
                                                (nth 8 ppss))
                                           (point))
                                       (point-max)))))))
         


João          



  reply	other threads:[~2014-04-03 16:56 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADWZ7fJCws0SO1hEn38CpbRMq+Uw397uCFUnA=YJvOaLVEA8UQ@mail.gmail.com>
2014-03-31 13:27 ` Emacs pretest Stefan Monnier
2014-03-31 13:52   ` Bastien
2014-03-31 14:36   ` Tassilo Horn
2014-03-31 15:55   ` João Távora
2014-03-31 16:34     ` Stefan Monnier
2014-04-02 10:11       ` Emacs pretest -- electric-pair-mode change João Távora
2014-04-02 12:58         ` Stefan Monnier
2014-04-02 17:21           ` João Távora
2014-04-02 22:58             ` Stefan Monnier
2014-04-03 11:06               ` João Távora
2014-04-03 14:22                 ` Stefan Monnier
2014-04-03 16:56                   ` João Távora [this message]
2014-04-03 17:33                     ` Stefan Monnier
2014-04-03 20:11                       ` João Távora
2014-04-03 20:54                         ` Stefan Monnier
2014-04-04  8:08                           ` João Távora
2014-04-04 12:53                             ` Stefan Monnier
2014-04-04 23:31                               ` João Távora
2014-04-05 15:29                                 ` Stefan Monnier
2014-04-07  7:43                                   ` João Távora
2014-04-07 14:04                                     ` Stefan Monnier
2014-04-04  7:53                         ` Eli Zaretskii
2014-04-04  9:49                           ` João Távora
2014-04-11 14:42                       ` Kevin Rodgers
2014-04-11 15:53                         ` Stefan Monnier
2014-04-11 18:23                           ` João Távora
2014-04-11 19:58                             ` Stefan Monnier
2014-04-12  0:42                               ` João Távora
2014-04-11 16:08                         ` João Távora
2014-04-03 19:13                   ` Eli Zaretskii
2014-04-03 12:15             ` Dmitry Gutov
2014-04-03 13:43               ` João Távora
2014-04-03 15:24                 ` Stefan Monnier
2014-04-03 14:24               ` Stefan Monnier
2014-04-01 15:15   ` Emacs pretest Dmitry Antipov
2014-04-01 16:36     ` Dmitry Antipov
2014-04-02 12:37       ` Stefan Monnier
2014-04-01 20:50   ` Stephen Berman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jjbeh1e2vxn.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this 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.