[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: beginning-of-defun-comments bug [was: Re: 26.0.90: mark-defun proble

From: Marcin Borkowski
Subject: Re: beginning-of-defun-comments bug [was: Re: 26.0.90: mark-defun problem in c-mode]
Date: Wed, 03 Jan 2018 05:51:35 +0100
User-agent: mu4e 0.9.19; emacs 27.0.50

On 2017-12-30, at 14:05, Alan Mackenzie <address@hidden> wrote:

> Hello, Eli.
> On Sat, Dec 30, 2017 at 14:53:27 +0200, Eli Zaretskii wrote:
>> > Date: Sat, 30 Dec 2017 12:01:36 +0000
>> > Cc: address@hidden, zhang cc <address@hidden>,
>> >   Noam Postavsky <address@hidden>
>> > From: Alan Mackenzie <address@hidden>
>> > > I see the error, with point anywhere in the body of the second function.
>> > > Critical seems to be there being no blank line between the functions.
>> > > I think there's a bug in beginning-of-defun-comments, which I'm in the
>> > > middle of edebugging.  It moves point into the first function.
>> > beginning-of-defun-comments has a bug.  On doing M-x
>> > beginning-of-defun-comments from the inside of a function, when there's
>> > no blank lines between it and the previous function, point ends up
>> > inside that previous function, not at the comments which may separate
>> > them.
>> > Perhaps this bug should be fixed before the next Emacs-26 pretest.
>> How old is this problem?  It looks like it's new in Emacs 26?  If so,
>> we should try fixing it on the release branch.
> beginning-of-defun-comments came into existence on 2017-03-31, so this
> problem is definitely new in Emacs 26.

Yep, it was committed by me.  Sorry for the mess.  And I thought I had
tested that thoroughly...

> I've diagnosed the bug.  At one place, it is necessary to scan a line of
> text from BOL to detect any non-comment/non-space character.  The
> current code tries to do this by using parse-partial-sexp with the
> fourth argument STOPBEFORE non-nil.
> This STOPBEFORE causes the scanning to stop at any character which
> begins a sexp.  A closing brace doesn't fit into this category.  The
> scan therefore reaches EOL, and the code therefore falsely assumes there
> are no non-syntactic-ws characters on that line.
> I'm sure I can fix this today.

Any success?  If not, can I help in any way?  (At the very least,
I could write some more tests to cover this case.)


Marcin Borkowski

reply via email to

[Prev in Thread] Current Thread [Next in Thread]