Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

> Would you please DTRT and ack to me?
>
> From: Paul Pogonyshev <pogonyshev@gmx.net>
> Subject: `c-indent-command' in a rare case
> To: emacs-devel@gnu.org
> Date: Fri Oct  1 03:25:54 2004 +0200
>
> Create a new C mode buffer and type 
>
> 	#define X\ TAB
>
> in it (note: no RET.)  Emacs will hang in `c-append-backslashes-forward'
> till you press C-g.  The one-liner below solves this.  However, I'm not
> sure if this the correct way of solving.  Should `(forward-line 1)'
> return 0 when not advancing a single line and only jumping to the end
> of last, unterminated, line?

According to the documentation it should, so I'll fix the code in CC
Mode accordingly.

Still, I think that's an unfortunate special case that makes it more
complicated to use: The construct

    (while (= (forward-line 1) 0)
      ...)

is convenient to execute something once for each line, with the point
at the start of the line, as long as there are lines left. Now the
special behavior of forward-line when eob isn't directly after a
newline requires more complex measures.

I understand that it probably isn't an option to change the behavior
of forward-line for compatibility reasons, but it could still be
interesting to know the reason for the decision to return zero when it
has moved but not managed to move to a different line.

Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

[Richard Stallman]

    I understand that it probably isn't an option to change the behavior
    of forward-line for compatibility reasons, but it could still be
    interesting to know the reason for the decision to return zero when it
    has moved but not managed to move to a different line.

It seems logical to me.  The decrease in the number of lines remaining
to be moved is zero.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

[Stefan]

>     I understand that it probably isn't an option to change the behavior
>     of forward-line for compatibility reasons, but it could still be
>     interesting to know the reason for the decision to return zero when it
>     has moved but not managed to move to a different line.

> It seems logical to me.  The decrease in the number of lines remaining
> to be moved is zero.

Huh?  Contrary to skip-chars-forward, forward-line returns the number of
lines remaining, not the "decrease in the number of lines remaining".
I.e. (zerop (forward-line 1)) is often used to check that forward-line has
indeed moved.

I agree with Martin that it would be better to not return 0 when it has moved
but hasn't managed to move to a different line.


        Stefan


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

> It seems logical to me.  The decrease in the number of lines remaining
> to be moved is zero.

Yes, I also think the number of lines remaining to be moved hasn't
decreased. Therefore a return value of 1 is in order if forward-line
was called with 1 since that number hasn't decreased.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

[David Kastrup]

Martin Stjernholm <mast@lysator.liu.se> writes:

> Richard Stallman <rms@gnu.org> wrote:
>
>> It seems logical to me.  The decrease in the number of lines remaining
>> to be moved is zero.
>
> Yes, I also think the number of lines remaining to be moved hasn't
> decreased. Therefore a return value of 1 is in order if forward-line
> was called with 1 since that number hasn't decreased.

simple.el:

(defun count-lines (start end)
  "Return number of lines between START and END.
This is usually the number of newlines between them,
but can be one more if START is not equal to END
and the greater of them is not at the start of a line."
  (save-excursion
    (save-restriction
      (narrow-to-region start end)
      (goto-char (point-min))
      (if (eq selective-display t)
	  (save-match-data
	    (let ((done 0))
	      (while (re-search-forward "[\n\C-m]" nil t 40)
		(setq done (+ 40 done)))
	      (while (re-search-forward "[\n\C-m]" nil t 1)
		(setq done (+ 1 done)))
	      (goto-char (point-max))
	      (if (and (/= start end)
		       (not (bolp)))
		  (1+ done)
		done)))
	(- (buffer-size) (forward-line (buffer-size)))))))

count-lines is used a few times, and the idioms in here may have
spread to other code, too.  In particular, we have

(defun line-number-at-pos (&optional pos)
  "Return (narrowed) buffer line number at position POS.
If POS is nil, use current buffer location."
  (let ((opoint (or pos (point))) start)
    (save-excursion
      (goto-char (point-min))
      (setq start (point))
      (goto-char opoint)
      (forward-line 0)
      (1+ (count-lines start (point))))))

I am not sure about the implications of those, but I wanted to point
out that the return value of forward-line is used _very_ often in the
current operation of Emacs, so one should be careful to let it do the
right thing, whatever that may happen to be.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

[Richard Stallman]

    Huh?  Contrary to skip-chars-forward, forward-line returns the number of
    lines remaining, not the "decrease in the number of lines remaining".
    I.e. (zerop (forward-line 1)) is often used to check that forward-line has
    indeed moved.

    I agree with Martin that it would be better to not return 0 when it has moved
    but hasn't managed to move to a different line.

Ok, I agree.

Would someone like to change this?

It is important to check that the various callers that look
at the return value will still work.  But I tend to think they
mostly will, because this change would increase the consistency
of the return value.

Re: [pogonyshev@gmx.net: `c-indent-command' in a rare case]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Huh?  Contrary to skip-chars-forward, forward-line returns the number of
>     lines remaining, not the "decrease in the number of lines remaining".
>     I.e. (zerop (forward-line 1)) is often used to check that forward-line has
>     indeed moved.
>
>     I agree with Martin that it would be better to not return 0 when it has moved
>     but hasn't managed to move to a different line.
>
> Ok, I agree.
>
> Would someone like to change this?
>
> It is important to check that the various callers that look
> at the return value will still work.  But I tend to think they
> mostly will, because this change would increase the consistency
> of the return value.

As David pointed out, count-lines and line-number-at-pos both depend
on the current behaviour in case the last line has no newline.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk