12:11 p.m.
Bring up a java-mode (or JDE) buffer and insert this into it:
public class Foo
{
class Bar // foo.
{
class Baz
{
/* foo. */
int flobble (String foo)
{
}
}
}
}
Note that the second closing parenthesis is believed (by, for instance,
`(goto-char (scan-sexps (point) -1))') to match the very first open
parenthesis, and that deleting either of the comments corrects this
misbehaviour.
Am I right that this can only reasonably be interpreted as a bug in the
XEmacs C core, or is it something completely different?
--
`I'm not sure whether libtool is an existence proof that you _can_
write a shell script that handles its arguments correctly, or a
demonstration that you may try but you are doomed to failure.'
-- Zack Weinberg
5:45 p.m.
-- Nix <nix(a)esperi.demon.co.uk> spake thusly:
Bring up a java-mode (or JDE) buffer and insert this into it:
public class Foo
{
class Bar // foo.
{
class Baz
{
/* foo. */
int flobble (String foo)
{
}
}
}
}
Note that the second closing parenthesis is believed (by, for
instance, `(goto-char (scan-sexps (point) -1))') to match the very
first open parenthesis, and that deleting either of the comments
corrects this misbehaviour.
Am I right that this can only reasonably be interpreted as a bug in
the XEmacs C core, or is it something completely different?
This is a bug in the syntax handling which was introduced along with
the latest syntax table enhancement I added. It also manifests in
c++-mode. I haven't yet found a fix for it, but I hope to do so soon.
6:08 p.m.
I'm sure its a bug. The syntax table stuff seemed to introduce some nasties
like this and I wish we could get the fixed (or back out the syntax table
stuff). cc-mode is too important.
andy
At 12:11 PM 7/8/01 +0100, Nix wrote:
Bring up a java-mode (or JDE) buffer and insert this into it:
public class Foo
{
class Bar // foo.
{
class Baz
{
/* foo. */
int flobble (String foo)
{
}
}
}
}
Note that the second closing parenthesis is believed (by, for instance,
`(goto-char (scan-sexps (point) -1))') to match the very first open
parenthesis, and that deleting either of the comments corrects this
misbehaviour.
Am I right that this can only reasonably be interpreted as a bug in the
XEmacs C core, or is it something completely different?
--
`I'm not sure whether libtool is an existence proof that you _can_
write a shell script that handles its arguments correctly, or a
demonstration that you may try but you are doomed to failure.'
-- Zack Weinberg
12:12 a.m.
Andy Piper <andyp(a)bea.com> writes:
I'm sure its a bug. The syntax table stuff seemed to introduce
some
nasties like this and I wish we could get the fixed (or back out the
syntax table stuff). cc-mode is too important.
Agreed. Matt, are you having a chance to look into these failures?
What's your ETA on a fix?
This has to be fixed before XEmacs 21.4 gets declared stable.
- vin
3:47 a.m.
-- Vin Shelton <acs(a)xemacs.org> spake thusly:
Andy Piper <andyp(a)bea.com> writes:
> I'm sure its a bug. The syntax table stuff seemed to introduce some
> nasties like this and I wish we could get the fixed (or back out the
> syntax table stuff). cc-mode is too important.
Agreed. Matt, are you having a chance to look into these failures?
What's your ETA on a fix?
I haven't had a chance yet; my job has been getting in the way ever
since I got back. I could give a long explanation as to why, but it's
not really relevant. However, if I don't offer some kind of response by
the end of the week, you have my permission to back out the
syntax-table changes.
What that really means, since that's not something I want happening, is
that I'll have an answer by the end of the week, either a fix or a
definite ETA. I have a pretty good idea of where the bug is; I just
need to find some time to really look into it.
This has to be fixed before XEmacs 21.4 gets declared stable.
Understood.
4:14 a.m.
Thanks,
vin
Matt Tucker <tuck(a)whistlingfish.net> writes:
-- Vin Shelton <acs(a)xemacs.org> spake thusly:
> Andy Piper <andyp(a)bea.com> writes:
>> I'm sure its a bug. The syntax table stuff seemed to introduce some
>> nasties like this and I wish we could get the fixed (or back out the
>> syntax table stuff). cc-mode is too important.
>
> Agreed. Matt, are you having a chance to look into these failures?
> What's your ETA on a fix?
I haven't had a chance yet; my job has been getting in the way ever
since I got back. I could give a long explanation as to why, but it's
not really relevant. However, if I don't offer some kind of response by
the end of the week, you have my permission to back out the
syntax-table changes.
What that really means, since that's not something I want happening, is
that I'll have an answer by the end of the week, either a fix or a
definite ETA. I have a pretty good idea of where the bug is; I just
need to find some time to really look into it.
> This has to be fixed before XEmacs 21.4 gets declared stable.
Understood.
7:33 a.m.
-- Vin Shelton <acs(a)xemacs.org> spake thusly:
Andy Piper <andyp(a)bea.com> writes:
> I'm sure its a bug. The syntax table stuff seemed to introduce some
> nasties like this and I wish we could get the fixed (or back out the
> syntax table stuff). cc-mode is too important.
Agreed. Matt, are you having a chance to look into these failures?
What's your ETA on a fix?
This has to be fixed before XEmacs 21.4 gets declared stable.
Okay, I've got a fix for this which I've applied to the trunk (21.5).
Since I haven't committed anything since the tree was moved around and
since I'm pretty sure this needs to go in 21.4 as well, I was wondering
what else I should do with the patch. I'd be happy to apply it to the
appropiate branch or let someone else do it; just wasn't sure what the
procedure currently is.
I'll browse back through xemacs-beta to see if there are any other
nasties that need to be fixed that this probably won't address,
although I probably won't have time to fix anything else until next
week.
2:25 p.m.
>>>> "Matt" == Matt Tucker
<tuck(a)whistlingfish.net> writes:
Matt> -- Vin Shelton <acs(a)xemacs.org> spake thusly:
> Andy Piper <andyp(a)bea.com> writes:
>> I'm sure its a bug. The syntax table stuff seemed to introduce some
>> nasties like this and I wish we could get the fixed (or back out the
>> syntax table stuff). cc-mode is too important.
>
> Agreed. Matt, are you having a chance to look into these failures?
> What's your ETA on a fix?
>
> This has to be fixed before XEmacs 21.4 gets declared stable.
Matt> Okay, I've got a fix for this which I've applied to the
Matt> trunk (21.5). Since I haven't committed anything since the
Hi Matt,
I haven't seen a patch for this on xemacs-patches(a)xemacs.org.
Please always send a patch with ChangeLog to xemacs-patches(a)xemacs.org
before you commit a change.
You may use
M-x customize-group RET patcher RET
M-x patcher-mail
to create patches and ChangeLogs very easily.
You need to have the xemacs-devel package installed, of which patcher
is a part of.
Matt> tree was moved around and since I'm pretty sure this needs
Matt> to go in 21.4 as well, I was wondering what else I should do
Matt> with the patch. I'd be happy to apply it to the appropiate
Matt> branch or let someone else do it; just wasn't sure what the
Matt> procedure currently is.
Only Vin applies patches for 21.1.
Only Stephen applies patches for 21.4.
Only Steve applies (or asks you to apply) patches for packages.
Matt> I'll browse back through xemacs-beta to see if there are any
Matt> other nasties that need to be fixed that this probably won't
Great!
Matt> address, although I probably won't have time to fix anything
Matt> else until next week.
Best regards,
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3:03 p.m.
Matt, thanks for the patch. You need to send the patch to
xemacs-patches.
I built 21.5 from the latest CVS sources, and I still see this
behavior, which I had thought was the same as the other problems:
1. Start up xemacs-21.5 -vanilla
2. In the *scratch* buffer, place the cursor after the first closing
parenthesis (at the end of the line which says "while hitting the X
key.)"
3. M-x backward-sexp yields the following error:
Signaling: (syntax-error "Unbalanced parentheses")
scan-sexps(317 -1)
forward-sexp(-1)
backward-sexp(1)
call-interactively(backward-sexp)
command-execute(backward-sexp t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
Sorry I did not report this problem sooner.
Thanks,
vin
Matt Tucker <tuck(a)whistlingfish.net> writes:
-- Vin Shelton <acs(a)xemacs.org> spake thusly:
> Andy Piper <andyp(a)bea.com> writes:
>> I'm sure its a bug. The syntax table stuff seemed to introduce some
>> nasties like this and I wish we could get the fixed (or back out the
>> syntax table stuff). cc-mode is too important.
>
> Agreed. Matt, are you having a chance to look into these failures?
> What's your ETA on a fix?
>
> This has to be fixed before XEmacs 21.4 gets declared stable.
Okay, I've got a fix for this which I've applied to the trunk (21.5).
Since I haven't committed anything since the tree was moved around and
since I'm pretty sure this needs to go in 21.4 as well, I was wondering
what else I should do with the patch. I'd be happy to apply it to the
appropiate branch or let someone else do it; just wasn't sure what the
procedure currently is.
I'll browse back through xemacs-beta to see if there are any other
nasties that need to be fixed that this probably won't address,
although I probably won't have time to fix anything else until next
week.
--
In a minute there is time
For decisions and revisions which a minute will reverse. T.S. Eliot
[URL: http://www.cs.amherst.edu/~ccm/prufrock.html]
8333
days inactive
8337
days old
8 comments
5 participants
participants (5)
-
Adrian Aichner -
Andy Piper -
Matt Tucker -
Nix -
Vin Shelton