Re: electric-indent-mode: abolition of `newline' function is not the Right Thing.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Oct 14, 2013 at 08:56:25AM -0400, Stefan Monnier wrote:
> > And people calling `newline' do not simply want a \n.  They want
> > abbreviations to be processed, they want auto-fill to be run, trailing
> > space to be removed from otherwise blank lines, and so on.  What they
> > _don't_ want is indentation inserted on the new line.

> Not sure who is your "they".

The people who have written Emacs Lisp code which calls `newline' (as
contrasted with `newline-and-indent').

> In my experience, what I've seen users want is "auto-indentation" and
> by that they mean that the text should be kept indented when they hit
> RET and a few other keys.

That is a different topic from this thread's.  The question which should
be asked, should have been asked some while ago, is what is the best way
of giving these users what they want.  The answer is not, and can not be,
to have an Emacs without the traditional functionality of `newline'.

[ .... ]

> But so far, you're the only person who's complained about ?\n being in
> the default value of electric-indent-chars, so I see no evidence that
> your preference in this regard is representative.

Have I complained about \n being in electric-indent-chars?  I don't think
I have, but might be mistaken.  My complaint, and I've been perfectly
clear about it, is the abolition of the traditional functionality of the
`newline' function whenever electric-indent-mode is enabled.  You haven't
really addressed this issue in your past few posts.

> > Please take this indent-newline functionality out of
> > e-i-post-s-i-function (or let me do it).

> Very easy: remove ?\n from electric-indent-chars.
> IOW (setq-default electric-indent-chars nil) should do that for you.

Is that your solution to the ~198 uses of `newline' in Emacs and
countless others in other code and users' .emacsen?  Each caller of
`newline' should first ensure that \n is not in electric-indent-chars?

> > Incidentally, each call of e-i-post-s-i-function creates a new marker,
> > bound to the let variable `before'.  This is not set to point nowhere
> > before `before' becomes unbound.  I think it probably should.

> Let's see if/when this leads to a concrete performance problem, and at
> that point we'll see how to fix it.  Making a marker point nowhere is an
> annoyance and is itself a costly operation (O(N) for N markers), so
> I don't much like using the workaround you suggest.

Well, it's not really my suggestion, it's standard advice in the Elisp
manual on page "Overview of Markers".  Without doing this, a buffer's
performance is gradually going to worsen as a heap of useless markers
accumulates, until such time as garbage collection eventually gets rid of
them.  The cost of making a marker point nowhere, less than once per
keystroke, is hardly high.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).