Re: Default behaviour of RET.

[Alan Mackenzie]

Hello, Stefan.

On Fri, Oct 18, 2013 at 09:59:54PM -0400, Stefan Monnier wrote:
> > The point is that there are a near infinite number of invocations of
> > `newline' in the wild, and an unknown proportion of these, possibly
> > quite high, will depend on `newline' doing precisely what its doc string

> but also possibly quite low.

Just how low does it have to be before we can ignore it?

> > says.  Their existence makes the utility of electric-indent-mode, at the
> > moment, questionable.

> As long as we're in the "unknown proportion", we can't tell.

> >> >> This discussion would benefit from actual examples of code that
> >> >> fall into neither "do whatever RET does" nor "insert \n".

> >> > See above.  Any code which is interested in filling (or, possibly, even
> >> > margins, if anything actually uses these) will get broken by the
> >> > `-and-indent'.

> >> "any code which..." is not concrete.

> > I've given you a concrete example of such code, several times.

> Right, but I said "examples" not "example".  So far I've seen one
> concrete example, from your ~/.emacs (i.e. a problem that will affect
> O(1) user).  That's not very compelling.

OK.  I've done a find-grep in .../lisp for all *.el matching
'^[^;\n]*(newline\([ )]\|$\)'.  There are 199 matches.

There are 27 occurences of the exact string "(or (bolp) (newline))",
which looks like making sure point is at BOL in an output file.  For
example, in uce.el, we have the following code at L359:

        ;; If message doesn't end with a newline, insert it.
        (goto-char (point-max))
        (or (bolp) (newline)))

. In org-datetree.el, we have this, at L83:

      (goto-char (point-max))
      (or (bolp) (newline))
      (org-datetree-insert-line year))

.  This same idiom appears two other times in this file alone.  I looked
at quite a few other occurences of "(or (bolp) (newline))" and all the
ones I could understand instantly were about ensuring point is at BOL, as
indeed was my own personal code.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).