Emacs pretest

Emacs pretest

[Stefan Monnier]

I think we're ready for the first pretest.  Sean, can you take care of it?


        Stefan

Re: Emacs pretest

[Bastien]

Hi Stefan,

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

> I think we're ready for the first pretest.

Did I miss a deadline?

I didn't have time to release Org 8.2.3 yet, and to
merge it into Emacs trunk.

Thanks,

-- 
 Bastien

Re: Emacs pretest

[Tassilo Horn]

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

> I think we're ready for the first pretest.

Could you please look into my patch for bookmark.el and doc-view.el that
fixes bug#16090?

The patch is in this message:
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16090#56

Bye,
Tassilo

Re: Emacs pretest

[João Távora]

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

> I think we're ready for the first pretest.  Sean, can you take care of
> it?

I'd like to commit a minor functional change to lisp/elec-pair.el. I've
been holding on to it for lazyness. Is it too late?

João

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 747bbcf..aa08b90 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,11 @@
+2014-03-31  João Távora  <joaotavora@gmail.com>
+
+	* elec-pair.el (electric-pair-inhibit-if-helps-balance): Inhibit
+	quote pairing if `point-max' is inside an unterminated string.
+	(electric-pair--looking-at-unterminated-string-p):
+	Delete.
+	(electric-pair--in-unterminated-string-p): New function.
+
 2014-03-29  Juri Linkov  <juri@jurta.org>
 
 	* dired-aux.el (dired-compress-file): Don't use string-match-p
diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el
index 52ad9bc..77d4bd2 100644
--- a/lisp/elec-pair.el
+++ b/lisp/elec-pair.el
@@ -364,18 +364,17 @@ If point is not enclosed by any lists, return ((t) . (t))."
                   (funcall ended-prematurely-fn)))))))
     (cons innermost outermost)))
 
-(defun electric-pair--looking-at-unterminated-string-p (char)
-  "Return non-nil if following string starts with CHAR and is unterminated."
-  ;; FIXME: ugly/naive
-  (save-excursion
-    (skip-chars-forward (format "^%c" char))
-    (while (not (zerop (% (save-excursion (skip-syntax-backward "\\")) 2)))
-      (unless (eobp)
-        (forward-char 1)
-        (skip-chars-forward (format "^%c" char))))
-    (and (not (eobp))
-         (condition-case nil
-             (progn (forward-sexp) nil)
+(defun electric-pair--in-unterminated-string-p (char)
+  "Say if inside an unterminated string started with CHAR"
+  (let* ((ppss (syntax-ppss))
+         (relevant-ppss (if (nth 4 ppss) ; in comment
+                            (electric-pair--syntax-ppss)
+                          ppss))
+         (string-delim (nth 3 relevant-ppss)))
+    (and (or (eq t string-delim)
+             (eq char string-delim))
+         (condition-case nil (progn (scan-sexps (nth 8 relevant-ppss) 1)
+                                    nil)
            (scan-error t)))))
 
 (defun electric-pair--inside-string-p (char)
@@ -409,7 +408,9 @@ happened."
                           (t
                            (eq (cdr outermost) pair)))))
                  ((eq syntax ?\")
-                  (electric-pair--looking-at-unterminated-string-p char))))
+                  (save-excursion
+                    (goto-char (point-max))
+                    (electric-pair--in-unterminated-string-p char)))))
        (insert-char char)))))
 
 (defun electric-pair-skip-if-helps-balance (char)
diff --git a/test/ChangeLog b/test/ChangeLog
index 5e5a8ae..1d3fb7b 100644
--- a/test/ChangeLog
+++ b/test/ChangeLog
@@ -1,3 +1,8 @@
+2014-03-31  João Távora  <joaotavora@gmail.com>
+
+	* automated/electric-tests.el (inhibit-if-strings-mismatched):
+	Change from `inhibit-only-of-next-is-mismatched'.
+
 2014-03-24  Barry O'Reilly  <gundaetiapo@gmail.com>
 
 	* automated/undo-tests.el (undo-test-marker-adjustment-nominal):
diff --git a/test/automated/electric-tests.el b/test/automated/electric-tests.el
index e3ffd1a..c43b87f 100644
--- a/test/automated/electric-tests.el
+++ b/test/automated/electric-tests.el
@@ -295,9 +295,9 @@ Should %s \"%s\" and point at %d"
   :bindings `((electric-pair-text-syntax-table
                . ,prog-mode-syntax-table)))
 
-(define-electric-pair-test inhibit-only-if-next-is-mismatched
+(define-electric-pair-test inhibit-if-strings-mismatched
   "\"foo\"\"bar" "\""
-  :expected-string "\"\"\"foo\"\"bar"
+  :expected-string "\"\"foo\"\"bar"
   :expected-point 2
   :test-in-strings nil
   :bindings `((electric-pair-text-syntax-table

Re: Emacs pretest

[Stefan Monnier]

> I'd like to commit a minor functional change to lisp/elec-pair.el.
> I've been holding on to it for lazyness.  Is it too late?

I suggest you install it in trunk.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

>> I'd like to commit a minor functional change to lisp/elec-pair.el.
>> I've been holding on to it for lazyness.  Is it too late?
>
> I suggest you install it in trunk.

Done, r116926. 

Any chance this makes it to the pretests and 24.4?
`electric-pair-preserve-balance' is a new feature and the old behaviour
for quote-pairing will almost surely annoy any new adopters.

Anyway I've haven't gotten little feedback for this feature, negative or
positive.

João

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> Any chance this makes it to the pretests and 24.4?

I don't think there's a hurry, in this respect.  It's a UI change, so we
can change it later without breaking other people's code.

> `electric-pair-preserve-balance' is a new feature and the old behaviour
> for quote-pairing will almost surely annoy any new adopters.

We'll see if we get many complaints.

> Anyway I've haven't gotten little feedback for this feature, negative or
> positive.

`electric-pair-mode' (even the old one) is not a commonly used option,
IIUC.  This is largely because it's not enabled by default, many people
don't like/want such a feature, and those who do want it have many ways
to get it, many of which predate electric-pair-mode.

I do hope/expect it to become the standard way to get the feature,
but it'll take a little while to get there.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

>> Any chance this makes it to the pretests and 24.4?
>
> I don't think there's a hurry, in this respect.  It's a UI change, so we
> can change it later without breaking other people's code.

The problem is not breaking code, but users' expectations of the
upcoming feature. To undestand exactly what we're talking about: typing
a single " double quote in front with point at just before the "Hello"

    ss << Hello";

Will produce, both with and without the fix, the expected

    ss << "Hello";

But only with the fix will you get the same result when your buffer
contents are

    ss << Hello" << 42 << "World";

Without the fix you will get

    ss << ""Hello" << 42 << "World";

This last behaviour is also arguable but it is "way too clever", almost
buggy. The trunk's behaviour is better: it always inhibits pairing, the
surprising electric action, whenever there is unbalance, and as such is
more predictable.

>> `electric-pair-preserve-balance' is a new feature and the old behaviour
>> for quote-pairing will almost surely annoy any new adopters.
>
> We'll see if we get many complaints.

There might be complaints of people currently using my autopair.el that
follow my advice to go with electric-pair-mode in emacs 24.4. But I
can/will only tell them that once 24.4 is out.

>> Anyway I've haven't gotten little feedback for this feature, negative or
>> positive.
>
> `electric-pair-mode' (even the old one) is not a commonly used option,
> IIUC.  This is largely because it's not enabled by default, many people
> don't like/want such a feature, and those who do want it have many ways
> to get it, many of which predate electric-pair-mode.

There is a fair, maybe even great, number of people using autopair.el,
which does what Emacs's trunk now does, and smartparens.el which doesn't
provide any balancing at all.

But both being predictable, these users these packages are less likely
to switch or even try electric-pair-mode if it feels alien or hard to
predict, which IMO was *exactly* the problem with the "old"
electric-pair-mode.

> I do hope/expect it to become the standard way to get the feature,
> but it'll take a little while to get there.

I'm not arguing that it should be made default in 24.4 or even later
versions, but you can expect a slower route if releases contain this
particular gratutious idiosyncrasy, one that I regret having implemented
back in october without sufficent review/feedback (or am I mistaken and
did you or anyone else think about this particular edge case?)

João

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> This last behaviour is also arguable but it is "way too clever", almost
> buggy. The trunk's behaviour is better: it always inhibits pairing, the
> surprising electric action, whenever there is unbalance, and as such is
> more predictable.

That makes sense.  But its calling (syntax-ppss (point-max)) will result
in large delays at times (since it will syntax-propertize any part of
the buffer not yet propertized).  Maybe it's OK because the rest of the
code already causes similar delays.
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.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

>> This last behaviour is also arguable but it is "way too clever", almost
>> buggy. The trunk's behaviour is better: it always inhibits pairing, the
>> surprising electric action, whenever there is unbalance, and as such is
>> more predictable.
>
> That makes sense.  But its calling (syntax-ppss (point-max)) will result
> in large delays at times

You're right. I dug up

    https://github.com/capitaomorte/autopair/issues/38
    https://github.com/capitaomorte/autopair/pull/30

and noticed that I managed to improve autopair there, but not beyond the
limit that you mention. In the large python file attached to the first
issue, I experience a 1 sec delay in my linux box and 5-6 secs in
windows (on par with moving to the end of the buffer).

> (since it will syntax-propertize any part of the buffer not yet
> propertized).

This suggests it's a kind of one-time delay per buffer, but that's not
the case at least for the large python above

> Maybe it's OK because the rest of the code already
> causes similar delays.

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.

> 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?). But even even in those languages, syntax (and
fontification) works across newlines, so do we pair for the language or
for the syntax?

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)

(defvar electric-pair-quote-scan-bound 50000
  "Number of chars to search when deciding quote pairing.")

(defun electric-pair--unbalanced-strings-p (char)
  "Return non-nil if there are unbalanced strings started by CHAR"
  (let* ((bound (+ electric-pair-quote-scan-bound (point)))
         (selector-ppss (syntax-ppss))
         (relevant-ppss (save-excursion
                          (if (nth 4 selector-ppss) ; comment
                              (electric-pair--syntax-ppss
                               (progn
                                 (goto-char (nth 8 selector-ppss))
                                 (forward-comment (point-max))
                                 (skip-syntax-backward " >!")
                                 (point)))
                            (syntax-ppss (min bound (point-max))))))
         (string-delim (nth 3 relevant-ppss)))
    (and (or (eq t string-delim)
             (eq char string-delim))
         (condition-case nil
             (progn (scan-sexps (nth 8 relevant-ppss) 1)
                    nil)
           (scan-error t)))))

João

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

>> (since it will syntax-propertize any part of the buffer not yet
>> propertized).
> This suggests it's a kind of one-time delay per buffer, but that's not
> the case at least for the large python above

A modification at position X flushes all syntax propertization after X.
So it's a "one time delay" but only until the next buffer modification.

> 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.  ]

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).

>> 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.

> 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".  IOW, we
write the code assuming that the buffer is correct (and failing
gracefully if it is not).

In this case, of course, the test itself is trying to figure out if the
code is correct, so "assume that it is correct" needs to be refined.

> 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.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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          

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

>> [ 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?

Ah, so the difference is in the way they're compiled.  The OS factor is
just "an accident".

> Yes I see. But for me it's definitely better not to pair in those
> situations

But you'll also do the opposite: if there's an extra " somewhere far in
the rest of the file (somewhere the user can't see and/or can't care
less about), and the user has added a spurious " nearby, she will expect
her next " to not-pair up (so as to complete the locally-unmatched, tho
globally matched quote), whereas your code will decide to pair.

> Anyway the "oh, it didn't pair..." disappointment is better than

Yes, but the code can go wrong both ways.

> "Something acceptible" then is "not pairing", just the self-insertion
> the user asked for, rught?

Yes.  Actually both pairing and non-pairing are acceptable.  What is not
would be to signal an error, for example.

> If (+ (point) <constant>) is less than (point-max) and inside a string
> we additionally assert that at least that string is paired.

Let's say (+ (point) <constant>) falls on the second line of the text
below:

   foo "bar" baz "toto
   titi
   tata "tutu" "blabla"

should it say "yup, we're within the string 'toto\ntiti\ntata ' or
should it say "no, we're not within a string"?

If we agree that using (point-max) is a bad idea, then the only other
option is to try and find some other spot in the buffer (and after
point) which is somehow known to be "outside of a string", and in
general we don't know how to find such a thing (point-max is the only
one we know in general).  Hence electric-pair-string-bound-function
(or give up on this idea and do something different).

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

I think this will fail when unmatched ' appear in comments.  You could
fix that by not changing the syntax-table, i.e. only replace syntax-ppss
with parse-partial-sexp, but then you'll find other cases (more corner-case
and harder to reproduce) where the lack of syntax-propertization causes
parse-partial-sexp to get it wrong (e.g. unmatched quotes in here-documents).


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

>>> [ 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
> Ah, so the difference is in the way they're compiled.

Of course, scheduling aside, in the end that's always true :-). I might
have misunderstood Eli Zaretskii's:

   http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00930.html

But in general, is the machine-code for windows builds exactly the same
(or very similar) as linux for things involved in these operations? If
so, how can I check the compile flags of a build? Because mine really is
slower. My OSX build is also much slower, FWIW, not as slow as windows
tho.

>> Yes I see. But for me it's definitely better not to pair in those
>> situations
>
> But you'll also do the opposite: if there's an extra " somewhere far in
> the rest of the file (somewhere the user can't see and/or can't care
> less about), and the user has added a spurious " nearby, she will expect
> her next " to not-pair up (so as to complete the locally-unmatched, tho
> globally matched quote), whereas your code will decide to pair.

True, with this important detail: she had the second surprise coming,
since the spurious " she added nearby *didn't* pair, which is an early
indication of unbalacing.

> Let's say (+ (point) <constant>) falls on the second line of the text
> below:
>
>    foo "bar" baz "toto
>    titi
>    tata "tutu" "blabla"
>
> should it say "yup, we're within the string 'toto\ntiti\ntata ' or
> should it say "no, we're not within a string"?

It will be mistake itself say "everything's fine, proceed with the
pairing", which is one of the cases where it's wrong, as I had already
admitted. But when it says "it's wrong,.don't pair" it will be always
right. And if constant is made big enough the number of mistakes
decreases (though not by much I admit).

> If we agree that using (point-max) is a bad idea, then the only other
> option is to try and find some other spot in the buffer (and after
> point) which is somehow known to be "outside of a string", and in
> general we don't know how to find such a thing (point-max is the only
> one we know in general).  Hence electric-pair-string-bound-function
> (or give up on this idea and do something different).

Hmmm I understand your idea better. Using that with a default
implementation returning (point-max) might be a good idea, modes that are
experiencing trouble can then write their complicated versions.

>> What about this? Seems to be much much faster in the python buffer i've
>> been testing with (even on windoze :-)
>
> I think this will fail when unmatched ' appear in comments.  You could
> fix that by not changing the syntax-table, i.e. only replace syntax-ppss
> with parse-partial-sexp, but then you'll find other cases (more corner-case
> and harder to reproduce) where the lack of syntax-propertization causes
> parse-partial-sexp to get it wrong (e.g. unmatched quotes in
> here-documents).

I see. I did that syntax-table change thinking *that* would make it
faster, but it was using `parse-partial-sexp' that did (why?). Anyway, I
think I could live with those cases of mispairings like those
here-documents. Do you have other prominent cases? I always think of
electric-pair-mode's balancing as a best-effort thing.

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

>> Let's say (+ (point) <constant>) falls on the second line of the text
>> below:
>> 
>> foo "bar" baz "toto
>> titi
>> tata "tutu" "blabla"
>> 
>> should it say "yup, we're within the string 'toto\ntiti\ntata ' or
>> should it say "no, we're not within a string"?

> It will be mistake itself say "everything's fine, proceed with the
> pairing", which is one of the cases where it's wrong, as I had already
> admitted. But when it says "it's wrong,.don't pair" it will be always
> right. And if constant is made big enough the number of mistakes
> decreases (though not by much I admit).

It basically means that we'll always say "don't pair" if (+ (point)
<constant>) is before the last quote in the buffer.  If (+ (point)
<constant>) is not near point-max then it'll basically "always" be
before the last quote.  So this heuristic reduces to "only try to pair
in the last <constant> chars of the buffer".

>> If we agree that using (point-max) is a bad idea, then the only other
>> option is to try and find some other spot in the buffer (and after
>> point) which is somehow known to be "outside of a string", and in
>> general we don't know how to find such a thing (point-max is the only
>> one we know in general).  Hence electric-pair-string-bound-function
>> (or give up on this idea and do something different).
> Hmmm I understand your idea better. Using that with a default
> implementation returning (point-max) might be a good idea, modes that are
> experiencing trouble can then write their complicated versions.

Right.

> I see. I did that syntax-table change thinking *that* would make it
> faster, but it was using `parse-partial-sexp' that did (why?).

Because it avoids syntax-propertize.

> Anyway, I think I could live with those cases of mispairings like
> those here-documents.

Right, but a "mispairing" will throw off all your pairing decisions
before that mispairing.  So a mispairing near the end of the file will
throw off your algorithm pretty much all the time, and the user won't
understand it because if/when she decides to go look at the end of the
file, the problem disappears.

I.e. then it *really* becomes unpredictable.  And the frequency of
those mispairing depends on the major-mode, since some major modes
depend more on syntax-propertize then others.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

> So this heuristic reduces to "only try to pair in the last <constant>
> chars of the buffer".

Actually <constant + average length of non-string segments intended> or
some function of the latter, since it is also right when the probe falls
within the last unbalanced string. But you've convinced me that it sucks
more that I already suspected it did...

>> Hmmm I understand your idea better. Using that with a default
>> implementation returning (point-max) might be a good idea, modes that are
>> experiencing trouble can then write their complicated versions.
> Right.

OK so something like this is acceptable for trunk & 24.4?

(defvar electric-pair-string-bound-function 'point-max
  "Next buffer position where strings are syntatically unexpected.
Value is a function called with no arguments and returning a
buffer position. Major modes should set this variable
buffer-locally if they experience slowness with
`electric-pair-mode' when pairing quotes.")

(defun electric-pair--unbalanced-strings-p (char)
  "Return non-nil if there are unbalanced strings started by CHAR"
  (let* ((selector-ppss (syntax-ppss))
         (relevant-ppss (save-excursion
                          (if (nth 4 selector-ppss) ; in comment
                              (let ((comment-start
                                     (progn
                                       (goto-char (line-beginning-position))
                                       (forward-comment (- (point-max)))
                                       (skip-syntax-forward " >!")
                                       (point)))
                                    (comment-end
                                     (progn
                                       (goto-char (line-beginning-position))
                                       (forward-comment (point-max))
                                       (skip-syntax-backward " >!")
                                       (point))))
                                (with-syntax-table prog-mode-syntax-table
                              (parse-partial-sexp comment-start comment-end)))
                            (syntax-ppss
                             (funcall electric-pair-string-bound-function)))))
         (string-delim (nth 3 relevant-ppss)))
    (or (eq t string-delim)
        (eq char string-delim))))

Notice that the "in comment" bit is a completely independent improvement
and little ugly. The previous `electric-pair--syntax-ppss' technique
worked in comments but not across comment lines.

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> OK so something like this is acceptable for trunk & 24.4?

Looks OK, yes.

> (defun electric-pair--unbalanced-strings-p (char)
>   "Return non-nil if there are unbalanced strings started by CHAR"

Please terminate with ".".

>   (let* ((selector-ppss (syntax-ppss))
>          (relevant-ppss (save-excursion
>                           (if (nth 4 selector-ppss) ; in comment
>                               (let ((comment-start
>                                      (progn
>                                        (goto-char (line-beginning-position))

Huh?  Shouldn't this use (nth 8 (syntax-ppss))?


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

>>                           (if (nth 4 selector-ppss) ; in comment
>>                               (let ((comment-start
>>                                      (progn
>>                                        (goto-char (line-beginning-position))
>
> Huh?  Shouldn't this use (nth 8 (syntax-ppss))?

Yes, that was a bad mistake. But in comments, we have to
parse-partial-sexp from the comment block's start, not just from (nth 8
(syntax-ppss)), otherwise won't work in multi-line comment
blocks. Though (nth 8 ...) that does play a part too (I guess that's
what you meant)). So I changed the existing `electric-pair--syntax-ppss'
helper to provide that.

So I commited this to trunk, with two new tests for this behaviour in
ruby line-comments and c block-style comments.

João

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> Yes, that was a bad mistake. But in comments, we have to
> parse-partial-sexp from the comment block's start, not just from (nth 8
> (syntax-ppss)), otherwise won't work in multi-line comment
> blocks.

Yes, but that's covered by the (forward-comment (- (point))) that comes
right after, IIUC.

> So I commited this to trunk, with two new tests for this behaviour in
> ruby line-comments and c block-style comments.

Thanks.  I think this can go into emacs-24.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

> Thanks.  I think this can go into emacs-24.
> 
Done, emacs-24's revs r116922 and r116923 backported from trunk's
r116926 and r116940, respectively.

João

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

>> Thanks.  I think this can go into emacs-24.
> Done, emacs-24's revs r116922 and r116923 backported from trunk's
> r116926 and r116940, respectively.

Thanks,


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[Eli Zaretskii]

> From: joaotavora@gmail.com (João Távora)
> Date: Thu, 03 Apr 2014 21:11:49 +0100
> Cc: emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
> >>> [ 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
> > Ah, so the difference is in the way they're compiled.
> 
> Of course, scheduling aside, in the end that's always true :-).

Scheduling is not really relevant here, since Emacs has only one
thread that runs Lisp, and its other threads, if there are any, don't
run any computation-intensive tasks that could yield user-visible
speed differences.

> I might have misunderstood Eli Zaretskii's:
> 
>    http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00930.html

That just describes how Windows binaries are compiled, but says
nothing about their speed relative to other systems.

> But in general, is the machine-code for windows builds exactly the same
> (or very similar) as linux for things involved in these operations?

It's the same compiler (GCC) and similar or identical machine
architectures, so I don't expect very different code.  Optimizations
change things, of course, but only by a factor of about 2.  Any
greater speed difference is due to something else.

> If so, how can I check the compile flags of a build?

"M-: system-configuration-options RET"

> Because mine really is slower. My OSX build is also much slower,
> FWIW, not as slow as windows tho.

Again, if the slow-down is more than twice, it's not the compiler
switches.  You should also compare the CPU speed for a single core.
Or just rebuild the same code with different optimizations and see if
you get the slower/faster speed.

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> Of course, scheduling aside, in the end that's always true :-).
> Scheduling is not really relevant here, since Emacs has only one
> thread that runs Lisp, and its other threads, if there are any, don't
> run any computation-intensive tasks that could yield user-visible
> speed differences.

I actually meant process scheduling, but yes assume no other relevant
threads or processes and the architecture/compiled code combination
determines it.

>>    http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00930.html
>
> That just describes how Windows binaries are compiled, but says
> nothing about their speed relative to other systems.

It suggests they are compiled with -O0, as is indeed my current one,
just checked. But is it just these unofficial builds that are -O0?
nt/INSTALL seems to suggest so. Are the builds in
http://ftp.gnu.org/gnu/emacs/windows/ optimized?

>> But in general, is the machine-code for windows builds exactly the same
>> (or very similar) as linux for things involved in these operations?
> It's the same compiler (GCC) and similar or identical machine
> architectures, so I don't expect very different code.  Optimizations
> change things, of course, but only by a factor of about 2.  Any
> greater speed difference is due to something else.

I would expect that factor to vary according to type of operation. But
OK, that would make my w32 hardware about 3 times slower for that
particular syntax-ppss operation, since total time is about 6 times
greater, I haven't measured exactly.

> "M-: system-configuration-options RET"

Thanks for the tip!

Re: Emacs pretest -- electric-pair-mode change

[Kevin Rodgers]

On 4/3/14 11:33 AM, Stefan Monnier wrote:
>>> [ 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?
>
> Ah, so the difference is in the way they're compiled.  The OS factor is
> just "an accident".
>
>> Yes I see. But for me it's definitely better not to pair in those
>> situations
>
> But you'll also do the opposite: if there's an extra " somewhere far in
> the rest of the file (somewhere the user can't see and/or can't care
> less about), and the user has added a spurious " nearby, she will expect
> her next " to not-pair up (so as to complete the locally-unmatched, tho
> globally matched quote), whereas your code will decide to pair.
>
>> Anyway the "oh, it didn't pair..." disappointment is better than
>
> Yes, but the code can go wrong both ways.
>
>> "Something acceptible" then is "not pairing", just the self-insertion
>> the user asked for, rught?
>
> Yes.  Actually both pairing and non-pairing are acceptable.  What is not
> would be to signal an error, for example.
>
>> If (+ (point)<constant>) is less than (point-max) and inside a string
>> we additionally assert that at least that string is paired.
>
> Let's say (+ (point)<constant>) falls on the second line of the text
> below:
>
>     foo "bar" baz "toto
>     titi
>     tata "tutu" "blabla"
>
> should it say "yup, we're within the string 'toto\ntiti\ntata ' or
> should it say "no, we're not within a string"?
>
> If we agree that using (point-max) is a bad idea, then the only other
> option is to try and find some other spot in the buffer (and after
> point) which is somehow known to be "outside of a string", and in
> general we don't know how to find such a thing (point-max is the only
> one we know in general).  Hence electric-pair-string-bound-function
> (or give up on this idea and do something different).

Would replacing (+ (point) <constant>) with (window-end) give reliable
behavior, from the user's perspective?  If the extra " is not visible,
it would not impact the result.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> Would replacing (+ (point) <constant>) with (window-end) give reliable
> behavior, from the user's perspective?  If the extra " is not visible,
> it would not impact the result.

No, the problem is not the distance, the problem is to find a position
that we know is outside of a string.  There's no reason why
(window-end) should be presumed to be outside of any string.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

>> Would replacing (+ (point) <constant>) with (window-end) give reliable
>> behavior, from the user's perspective?  If the extra " is not visible,
>> it would not impact the result.
>
> No, the problem is not the distance, the problem is to find a position
> that we know is outside of a string.  There's no reason why
> (window-end) should be presumed to be outside of any string.

Re-reading Kevin's message I think there are two separate things here:

* deciding if the buffer is quote-balanced for pairing purposes. That
  can indeed only be done according to your idea Stefan, i.e. finding a
  safe spot the we assert to be outside a string.

* after having obtained reliable info that the buffer is unbalanced, we
  can further decide if we want to surprise/disappoint the user. This
  might be argued I think: if we know that there is an unbalance but
  that it is outside the users view, decide to pair anyway.  If it is in
  the user's view, try to repair the unbalance by not pairing (this
  second bit is what is already done)

I don't know if I personally would like it, perhaps it can be a
customization option.

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> Re-reading Kevin's message I think there are two separate things here:

> * deciding if the buffer is quote-balanced for pairing purposes. That
>   can indeed only be done according to your idea Stefan, i.e. finding a
>   safe spot the we assert to be outside a string.

> * after having obtained reliable info that the buffer is unbalanced, we
>   can further decide if we want to surprise/disappoint the user. This
>   might be argued I think: if we know that there is an unbalance but
>   that it is outside the users view, decide to pair anyway.  If it is in
>   the user's view, try to repair the unbalance by not pairing (this
>   second bit is what is already done)

> I don't know if I personally would like it, perhaps it can be a
> customization option.

For strings, if we know that position POS, which should be outside of
a string, is inside a string, we know that there's an imbalance.  *But*
we don't actually know where that imbalance comes from (it's just
"somewhere before POS"), so we can't really tell if that imbalance is
before or after window-end unless POS is itself before window-end.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

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

>> Re-reading Kevin's message I think there are two separate things here:
>
>> * deciding if the buffer is quote-balanced for pairing purposes. That
>>   can indeed only be done according to your idea Stefan, i.e. finding a
>>   safe spot the we assert to be outside a string.
>
>> * after having obtained reliable info that the buffer is unbalanced, we
>>   can further decide if we want to surprise/disappoint the user. This
>>   might be argued I think: if we know that there is an unbalance but
>>   that it is outside the users view, decide to pair anyway.  If it is in
>>   the user's view, try to repair the unbalance by not pairing (this
>>   second bit is what is already done)
>
>> I don't know if I personally would like it, perhaps it can be a
>> customization option.
>
> For strings, if we know that position POS, which should be outside of
> a string, is inside a string, we know that there's an imbalance.  *But*
> we don't actually know where that imbalance comes from (it's just
> "somewhere before POS"), so we can't really tell if that imbalance is
> before or after window-end unless POS is itself before window-end.

I think you're right. But if there is unbalance and one of the following
is true:

* the first non-string position searching backwards from (window-end)
  downto (point) is sucessfully asserted to be outside a string, or

* there are no strings at all between (point) and window end (basically
  implies the previous point).

then I think it is doable, i.e. there is a case for autopairing despite
the unbalance. Not sure how useful, though. Needs prototyping, and I'm
not super-motivated to do it right now.

João

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
> On 4/3/14 11:33 AM, Stefan Monnier wrote:
>> If we agree that using (point-max) is a bad idea, then the only other
>> option is to try and find some other spot in the buffer (and after
>> point) which is somehow known to be "outside of a string", and in
>> general we don't know how to find such a thing (point-max is the only
>> one we know in general).  Hence electric-pair-string-bound-function
>> (or give up on this idea and do something different).
>
> Would replacing (+ (point) <constant>) with (window-end) give reliable
> behavior, from the user's perspective?  If the extra " is not visible,
> it would not impact the result.

I remember considering this idea, and then abandoning it. I can't
remember the reasoning any more :-), but I think it went along the lines
of "It's possibly nice when (window-end) lands me outside a string, but
what if it lands me inside one? Should I assume the buffer is
quote-unbalanced and not autopair the quote? Should I check if that
window-end-crossing string is terminated? In general it will always be
even if by some other unbalanced quote. So if I do that it's just as
slow and also harder to predict.".

All in all think I prefer the current behaviour, which, by default, only
asserts that (point-max) is outside a string for sure. Here's a related
argument I've made before: If the user has left an unbalanced string far
away down the buffer (i.e. unbalancing starts there), there might be
some disappointment to not seeing the current quote being inserted pair,
but then it's also a warning that something is wrong with the quote
balance somewhere down. The warning comes from not only seeing the quote
not be autopaired but also from the strange fontification that ensues.

João

Re: Emacs pretest -- electric-pair-mode change

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 03 Apr 2014 10:22:28 -0400
> Cc: emacs-devel@gnu.org
> 
> > 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.  ]

It doesn't.

Re: Emacs pretest -- electric-pair-mode change

[Dmitry Gutov]

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

> This last behaviour is also arguable but it is "way too clever", almost
> buggy. The trunk's behaviour is better: it always inhibits pairing, the
> surprising electric action, whenever there is unbalance, and as such is
> more predictable.

I don't see what can be "too clever" about it. It's either buggy, or just
sloppy (as in: electric-pair-mode isn't aware of that specific case).

>>> Anyway I've haven't gotten little feedback for this feature, negative or
>>> positive.

I'm using it. I like it, and I've filed just one bug for it as of yet.

>> `electric-pair-mode' (even the old one) is not a commonly used option,
>> IIUC.  This is largely because it's not enabled by default, many people
>> don't like/want such a feature, and those who do want it have many ways
>> to get it, many of which predate electric-pair-mode.

Since it's not commonly used, yet, any possible breakage introduced with
this change would also be less of a problem.

> But both being predictable, these users these packages are less likely
> to switch or even try electric-pair-mode if it feels alien or hard to
> predict, which IMO was *exactly* the problem with the "old"
> electric-pair-mode.

+1

Re: Emacs pretest -- electric-pair-mode change

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> joaotavora@gmail.com (João Távora) writes:
>
>> This last behaviour is also arguable but it is "way too clever", almost
>> buggy. The trunk's behaviour is better: it always inhibits pairing, the
>> surprising electric action, whenever there is unbalance, and as such is
>> more predictable.
>
> I don't see what can be "too clever" about it. It's either buggy, or just
> sloppy (as in: electric-pair-mode isn't aware of that specific case).

It's too clever because I was trying to implement the reasoning that
only if the string immediately following point being unbalanced can you
be sure that inhibiting is the right thing. Because if strings are
unbalanced in the whole buffer you can't really be sure whether the
correct is thing is to add just the one quote at beginning or at the
end. I also had faster implementation, but that was a side effect.

Anyway, a few weeks using it, I realized that this behaviour is
annoying, is practically never what I want, and is hard to predict.

João

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> Anyway, a few weeks using it, I realized that this behaviour is
> annoying, is practically never what I want, and is hard to predict.

Agreed.  For emacs-24 we should either change it to improve the check
whether the string is balanced (e.g. what we have on trunk), or not
check at all.


        Stefan

Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

> Since it's not commonly used, yet, any possible breakage introduced with
> this change would also be less of a problem.

Good point.
Still, I think that code that needs to parse the whole buffer is
a problem.  And UI behavior that needs that is even worse.


        Stefan

Re: Emacs pretest

[Dmitry Antipov]

On 03/31/2014 05:27 PM, Stefan Monnier wrote:

> I think we're ready for the first pretest.  Sean, can you take care of it?

I have a fix for http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125 on the way;
hopefully the fix will be confirmed in a day or so - can we wait a bit more?

Dmitry

Re: Emacs pretest

[Dmitry Antipov]

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

On 04/01/2014 07:15 PM, Dmitry Antipov wrote:

> On 03/31/2014 05:27 PM, Stefan Monnier wrote:
>
>> I think we're ready for the first pretest.  Sean, can you take care of it?
>
> I have a fix for http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125 on the way;
> hopefully the fix will be confirmed in a day or so - can we wait a bit more?

Also I have LTO support for clang users; does that makes sense for pretest as well?

Dmitry


[-- Attachment #2: clang_lto_1.patch --]
[-- Type: text/x-patch, Size: 4477 bytes --]

=== modified file 'INSTALL'
--- INSTALL	2014-03-27 19:41:57 +0000
+++ INSTALL	2014-04-01 16:08:38 +0000
@@ -331,12 +331,17 @@
 there should be no warnings; on older and on non-GNU systems the
 generated warnings may still be useful.
 
-Use --enable-link-time-optimization to enable link-time optimizer, which
-is available in GNU compiler since version 4.5.0.  If your compiler is not
-GNU or older than version 4.5.0, this option does nothing.  If `configure'
-can determine number of online CPUS on your system, final link-time
-optimization and code generation is executed in parallel using one job
-per each available online CPU.
+Use --enable-link-time-optimization to enable link-time optimizer.  If
+you're using GNU compiler, this feature is supported since version 4.5.0.
+If `configure' can determine number of online CPUS on your system, final
+link-time optimization and code generation is executed in parallel using
+one job per each available online CPU.
+
+This option is also supported for clang.  You should have GNU binutils
+with `gold' linker and plugin support, and clang with LLVMgold.so plugin.
+Read http://llvm.org/docs/GoldPlugin.html for details.  Also note that
+this feature is still experimental, so prepare to build binutils and
+clang snapshots from their source code repositories.
 
 The `--prefix=PREFIXDIR' option specifies where the installation process
 should put emacs and its data files.  This defaults to `/usr/local'.

=== modified file 'configure.ac'
--- configure.ac	2014-03-31 05:02:08 +0000
+++ configure.ac	2014-04-01 16:07:34 +0000
@@ -764,32 +764,6 @@
   [gl_gcc_warnings=no]
 )
 
-AC_ARG_ENABLE(link-time-optimization,
-[AS_HELP_STRING([--enable-link-time-optimization],
-                [build emacs with link-time optimization.
-                 This is supported only for GCC since 4.5.0.])],
-if test "${enableval}" != "no"; then
-   AC_MSG_CHECKING([whether link-time optimization is supported])
-   ac_lto_supported=no
-   if test x$GCC = xyes; then
-      CPUS=`getconf _NPROCESSORS_ONLN 2>/dev/null`
-      if test x$CPUS != x; then
-      	 LTO="-flto=$CPUS"
-      else
-	 LTO="-flto"
-      fi
-      old_CFLAGS=$CFLAGS
-      CFLAGS="$CFLAGS $LTO"
-      AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
-      	[ac_lto_supported=yes], [ac_lto_supported=no])
-      CFLAGS="$old_CFLAGS"
-   fi
-   AC_MSG_RESULT([$ac_lto_supported])
-   if test "$ac_lto_supported" = "yes"; then
-      CFLAGS="$CFLAGS $LTO"
-   fi
-fi)
-
 # gl_GCC_VERSION_IFELSE([major], [minor], [run-if-found], [run-if-not-found])
 # ------------------------------------------------
 # If $CPP is gcc-MAJOR.MINOR or newer, then run RUN-IF-FOUND.
@@ -926,7 +900,48 @@
   AC_SUBST([GNULIB_WARN_CFLAGS])
 fi
 
-
+AC_ARG_ENABLE(link-time-optimization,
+[AS_HELP_STRING([--enable-link-time-optimization],
+                [build emacs with link-time optimization.
+		 This is supported for gcc since 4.5.0 and clang.
+		 For the latter, this is experimental, see INSTALL])],
+if test "${enableval}" != "no"; then
+   ac_lto_supported=no
+   if test $emacs_cv_clang = yes; then
+      AC_MSG_CHECKING([whether link-time optimization is supported by clang])
+      GOLD_PLUGIN=`$CC -print-file-name=LLVMgold.so`
+      if test -n "$GOLD_PLUGIN" -a -x "$GOLD_PLUGIN"; then
+	 LTO="-flto"
+      fi
+   elif test x$GCC = xyes; then
+      AC_MSG_CHECKING([whether link-time optimization is supported by gcc])
+      CPUS=`getconf _NPROCESSORS_ONLN 2>/dev/null`
+      if test x$CPUS != x; then
+	 LTO="-flto=$CPUS"
+      else
+	 LTO="-flto"
+      fi
+   else
+      AC_MSG_ERROR([Link-time optimization is not supported with your compiler.])
+   fi
+   old_CFLAGS=$CFLAGS
+   CFLAGS="$CFLAGS $LTO"
+   AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+      [ac_lto_supported=yes], [ac_lto_supported=no])
+      CFLAGS="$old_CFLAGS"
+   AC_MSG_RESULT([$ac_lto_supported])
+   if test "$ac_lto_supported" = "yes"; then
+      CFLAGS="$CFLAGS $LTO"
+      if test x$emacs_cv_clang = xyes; then
+	 AC_MSG_WARN([Please read INSTALL before using link-time optimization with clang])
+	 # WARNING: 'ar --plugin ...' doesn't work without
+	 # command, so plugin name is appended to ARFLAGS...
+	 ARFLAGS="cru --plugin $GOLD_PLUGIN"
+	 # ...but this is much better for ranlib.
+	 RANLIB="$RANLIB --plugin $GOLD_PLUGIN"
+      fi
+   fi
+fi)
 
 dnl Some other nice autoconf tests.
 dnl These are commented out, since gl_EARLY and/or Autoconf already does them.

Re: Emacs pretest

[Stefan Monnier]

> Also I have LTO support for clang users; does that makes sense for
> pretest as well?

Better leave this for the trunk.


        Stefan

Re: Emacs pretest

[Stephen Berman]

On Mon, 31 Mar 2014 09:27:30 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

> I think we're ready for the first pretest.  Sean, can you take care of it?

This is sooner than I was expecting.  I have changes for Todo mode which
are almost ready but I won't be able to complete and commit them until
at least after April 8, since I'm travelling, but possibly not until
after April 15, since I have other pressing things to do when I return.

The changes include revised documentation necessitated by the changes I
committed just before the feature freeze.  I also discovered a few bugs,
which I've fixed.  In addition, I realized that it is easy to provide
the same kind of user feedback for invoking item editing as I
implemented for item insertion before the feature freeze.  For editing,
the code is much simpler; it does not add new functionality, just makes
the user interface nicer, simpler and more consistent.  I also slightly
improved the insertion feedback.  These changes also makes it much
easier to provide a practicable menu for Todo mode, which I'd been
having trouble with before.

I think these changes (again, no new features, just user interface
improvements, and some code cleanup) really should be in 24.4, since
this will be the first release containing the new Todo mode, and without
them, the user interface is worse.  So I hope you'll let me commit them
as soon as I'm able to, even if it's not in time for the first pretest.

Steve Berman