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

[npostavs@users.sourceforge.net]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2017-04-19, at 02:04, npostavs@users.sourceforge.net wrote:
>
>> Marcin Borkowski <mbork@mbork.pl> 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
                           (parse-partial-sexp
                            (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).