parentheses matching failure on valid sexp

parentheses matching failure on valid sexp

[Joe Wells]

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

To reproduce this bug:

1. Save the attached file as foobar.el.
2. Run “emacs -Q foobar.el”.
3. Delete the trailing right parenthesis on line 435.
4. Type a right parenthesis.

The correct behavior would be to match the leading left parenthesis on
line 1.  The actual buggy behavior is that the message “Mismatched
parentheses” is given.

This bug is sensitive to the size of the input.  If you delete much of
the input, then the bug goes away.

I hope this report helps someone track this problem down and fix it.

Joe


[-- Attachment #2: foo.el --]
[-- Type: application/emacs-lisp, Size: 26046 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1246 bytes --]


======================================================================
In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-06-27 on artemis
Windowing system distributor `The X.Org Foundation', version 11.0.70000000
configured using `configure  '--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls' '--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: jbw
  value of $LANG: nil
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  auto-fill-function: do-auto-fill
  shell-dirtrack-mode: t
  outline-minor-mode: t
  desktop-save-mode: t
  url-handler-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  size-indication-mode: t
  line-number-mode: t
  transient-mark-mode: t
  overwrite-mode: overwrite-mode-textual

Re: parentheses matching failure on valid sexp

[Sven Joachim]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> To reproduce this bug:
>
> 1. Save the attached file as foobar.el.
> 2. Run “emacs -Q foobar.el”.
> 3. Delete the trailing right parenthesis on line 435.
> 4. Type a right parenthesis.
>
> The correct behavior would be to match the leading left parenthesis on
> line 1.  The actual buggy behavior is that the message “Mismatched
> parentheses” is given.
>
> This bug is sensitive to the size of the input.  If you delete much of
> the input, then the bug goes away.

This is documented behavior, see the variable blink-matching-paren-distance:

,----
| blink-matching-paren-distance is a variable defined in `simple.el'.
| Its value is 25600
| 
| 
| Documentation:
| *If non-nil, maximum distance to search backwards for matching open-paren.
| If nil, search stops at the beginning of the accessible portion of the buffer.
| 
| You can customize this variable.
`----

Re: parentheses matching failure on valid sexp

[martin rudalics]

 > This bug is sensitive to the size of the input.  If you delete much of
 > the input, then the bug goes away.

Emacs reports a bug because the matching left paren is more than
`blink-matching-paren-distance' characters before the right one.  The
message will go away if you customize that variable accordingly.

It might be worth looking at the syntax-ppss cache for paren matching.
I know, the paren matching algorithms usually find a matching paren
within a few characters distance and there's no profound reason to do
that.  But when font-locking is on, the cache contains the position of
all open parens for some line-beginning before point anyway.  Hence, we
could look for an opening paren within one or two lines and consult the
cache if we didn't find anything useful there.  In this case we could
ignore `blink-matching-paren-distance'.  Stefan what do you think?

Re: parentheses matching failure on valid sexp

[Joe Wells]

Sven Joachim <svenjoac@gmx.de> writes:

> Joe Wells <jbw@macs.hw.ac.uk> writes:
>
>> To reproduce this bug:
>>
>> 1. Save the attached file as foobar.el.
>> 2. Run “emacs -Q foobar.el”.
>> 3. Delete the trailing right parenthesis on line 435.
>> 4. Type a right parenthesis.
>>
>> The correct behavior would be to match the leading left parenthesis on
>> line 1.  The actual buggy behavior is that the message “Mismatched
>> parentheses” is given.
>>
>> This bug is sensitive to the size of the input.  If you delete much of
>> the input, then the bug goes away.
>
> This is documented behavior, see the variable blink-matching-paren-distance:

Thank you for pointing this out!

-- 
Joe

Re: parentheses matching failure on valid sexp

[Joe Wells]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> Sven Joachim <svenjoac@gmx.de> writes:
>
>> Joe Wells <jbw@macs.hw.ac.uk> writes:
>>
>>> To reproduce this bug:
>>>
>>> 1. Save the attached file as foobar.el.
>>> 2. Run “emacs -Q foobar.el”.
>>> 3. Delete the trailing right parenthesis on line 435.
>>> 4. Type a right parenthesis.
>>>
>>> The correct behavior would be to match the leading left parenthesis on
>>> line 1.  The actual buggy behavior is that the message “Mismatched
>>> parentheses” is given.
>>>
>>> This bug is sensitive to the size of the input.  If you delete much of
>>> the input, then the bug goes away.
>>
>> This is documented behavior, see the variable blink-matching-paren-distance:
>
> Thank you for pointing this out!

I suggest there should be a different error message ("Could not find
matching parentheses within %d characters") if the failure is due to
exceeding the blink-matching-paren-distance limit.  The current
message of "Mismatched parentheses" in this case makes one think the
error is due to a bracket matching a brace, or something like that.

-- 
Joe

Re: parentheses matching failure on valid sexp

[Stefan Monnier]

>> This bug is sensitive to the size of the input.  If you delete much of
>> the input, then the bug goes away.

> Emacs reports a bug because the matching left paren is more than
> `blink-matching-paren-distance' characters before the right one.  The
> message will go away if you customize that variable accordingly.

> It might be worth looking at the syntax-ppss cache for paren matching.
> I know, the paren matching algorithms usually find a matching paren
> within a few characters distance and there's no profound reason to do
> that.  But when font-locking is on, the cache contains the position of
> all open parens for some line-beginning before point anyway.  Hence, we
> could look for an opening paren within one or two lines and consult the
> cache if we didn't find anything useful there.  In this case we could
> ignore `blink-matching-paren-distance'.  Stefan what do you think?

I'm not sure syntax-ppss is such a great idea here.  I mean, maybe it'll
work, but we may as well just set `blink-matching-paren-distance' to nil.
The only time it's a problem is when you bump into an extraneous close
paren, in which case Emacs will scan all the way to the beginning of
the buffer.  But even then: unless your buffer is 200MB long, this is still
almost instantaneous, so it seems acceptable.


        Stefan

Re: parentheses matching failure on valid sexp

[Andreas Röhler]

Am Dienstag, 11. September 2007 09:07 schrieb Joe Wells:
> Joe Wells <jbw@macs.hw.ac.uk> writes:
> > Sven Joachim <svenjoac@gmx.de> writes:
> >> Joe Wells <jbw@macs.hw.ac.uk> writes:
> >>> To reproduce this bug:
> >>>
> >>> 1. Save the attached file as foobar.el.
> >>> 2. Run “emacs -Q foobar.el”.
> >>> 3. Delete the trailing right parenthesis on line 435.
> >>> 4. Type a right parenthesis.
> >>>
> >>> The correct behavior would be to match the leading left parenthesis on
> >>> line 1.  The actual buggy behavior is that the message “Mismatched
> >>> parentheses” is given.
> >>>
> >>> This bug is sensitive to the size of the input.  If you delete much of
> >>> the input, then the bug goes away.
> >>
> >> This is documented behavior, see the variable
> >> blink-matching-paren-distance:
> >
> > Thank you for pointing this out!
>
> I suggest there should be a different error message ("Could not find
> matching parentheses within %d characters") if the failure is due to
> exceeding the blink-matching-paren-distance limit.  The current
> message of "Mismatched parentheses" in this case makes one think the
> error is due to a bracket matching a brace, or something like that.


Meanwhile this might be helpful:

http://www.emacswiki.org/cgi-bin/wiki/MatchParenthesis

Andreas Röhler