[Top][All Lists]

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

bug#21072: Brave new mark-defun (and a testing tool)

From: npostavs
Subject: bug#21072: Brave new mark-defun (and a testing tool)
Date: Sat, 22 Apr 2017 14:05:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Marcin Borkowski <address@hidden> writes:

> On 2017-04-19, at 02:04, address@hidden wrote:
>> Marcin Borkowski <address@hidden> writes:
>>>> Oh, right, I thought it was doing backward-comment, but the difference
>>>> is that it stops at blank lines, thus the *non-redundant* looking-at
>>>> call.
>>>> I wonder if that's a sensible thing to do for languages that have
>>>> multiline comments though, e.g. Javascript:
>>>> /*
>>>> This function returns 0
>>>> */
>>>> function foo () {
>>>>     return 0;
>>>> }
>>>> Although we might say that such comments should have "*" on the empty 
>>>> lines.
>>> Definitely.  OTOH, what if they don't...?  I'm not sure how to detect
>>> such a situation.  Any ideas?
>>     (defun beginning-of-defun-comments (&optional arg)
> Still not there - I tried first on Elisp, like this:
> ;; A comment
> (defun ...)
> and it left the point at the end of the "A comment" line instead of at
> the beginning...

Hmm, I don't get that, although I did miss an inf loop when the comment
is at beginning of buffer.  Here is a fixed version:

    (defun beginning-of-defun-comments (&optional arg)
      "Move to the beginning of ARGth defun, including comments."
      (interactive "^p")
      (unless arg (setq arg 1))
      (beginning-of-defun arg)
      (while (let ((pt (point))
                   (ppss (and (zerop (forward-line -1)) (syntax-ppss))))
               (cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
                     ((and ppss
                            (point) (line-end-position) nil t ppss)
                           (not (bolp)) (eolp)))
                     (t (goto-char pt) nil)))))

> I'm tempted to leave it is it is in my branch.  For one, I'm a bit tired
> by all this and I'd like to move on; also, as you said above, there is
> little hope to do it "100% correctly", and I guess my solution may be
> good enough.  (I'm pretty sure it's better than the status quo, at
> least.)

Yeah, since there's no perfect answer, I think it's fine if you just go
with whichever version you like best.  If people disagree, we'll find
out in bug reports :)

> as I mentioned a few minutes ago, I pushed the fix/bug-21072 branch with
> a few fixes discussed in this thread.  If it is in good enoug shape to
> merge into master, please tell me and I'll do it; if not, I'll fix what
> should be fixed (commit messages?)

Looks good to me (apart from the commit messages).

reply via email to

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