unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: martin rudalics <rudalics@gmx.at>,
	"Stephen J. Turnbull" <stephen@xemacs.org>,
	emacs-devel@gnu.org
Subject: Re: Default behaviour of RET.
Date: Fri, 18 Oct 2013 20:45:51 +0000	[thread overview]
Message-ID: <20131018204551.GC3012@acm.acm> (raw)
In-Reply-To: <jwvzjq6pdek.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Fri, Oct 18, 2013 at 03:52:22PM -0400, Stefan Monnier wrote:
> >> > The traditional docstring says that it moves to the left margin and
> >> > handles auto-filling.  Eli's suggestion of `(insert "\n")' doesn't do
> >> > that, and it's not what `newline' does when corrupted by
> >> > `electric-shock-mode'.  But I think it's useful behavior, and I think
> >> > programs should be able to rely on it (as opposed to users who can
> >> > modify the behavior of `One-Flew-Over-the-Cuckoos-Nest-mode' by
> >> > removing ?\n, or not invoke the mode in the first place).

> >> I can't remember ever seeing a piece of code which wants "the Emacs-23
> >> newline behavior".  Usually it either wants to (insert "\n") or it wants
> >> to simulate hitting RET.

> > I gave an example of such code in the post which opened this thread.  To
> > recap:

> > (newline)
> > (insert "(vi)")
> > (fill-paragraph)

> > The `-and-indent' behaviour messes up the indentation of "(vi)" and
> > causes it to get re-attached to the previous paragraph.

> I see why the above doesn't want the "simulate RET" behavior.
> But I don't see why it wouldn't work just fine with the (insert
> "\n") behavior?

The `newline' tidies up the previous paragraph, in particular it fills
it.  It might also cause abbreviations to be expanded.

I could easily adapt this piece of code to cope with the `-and-indent'
which has been attached to `newline', but that's not the point.

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
says.  Their existence makes the utility of electric-indent-mode, at the
moment, questionable.

> >> 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.  It's not
a particularly bizarre piece of code, either.

electric-indent-mode's indentation of a new line is broken.  Please take
this behaviour out.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2013-10-18 20:45 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-13 10:13 electric-indent-mode: abolition of `newline' function is not the Right Thing Alan Mackenzie
2013-10-13 13:23 ` Stefan Monnier
2013-10-13 14:09   ` Alan Mackenzie
2013-10-13 16:22     ` Stefan Monnier
2013-10-13 17:28       ` Alan Mackenzie
2013-10-14 12:56         ` Stefan Monnier
2013-10-16 18:46           ` Alan Mackenzie
2013-10-15 18:28         ` martin rudalics
2013-10-16 17:12           ` Alan Mackenzie
2013-10-16 17:59             ` Stefan Monnier
2013-10-16 18:58               ` Alan Mackenzie
2013-10-16 20:55                 ` chad
2013-10-16 21:07                   ` Daniel Colascione
2013-10-18 16:51                   ` Alan Mackenzie
2013-10-16 23:22               ` Stephen J. Turnbull
2013-10-16 18:34             ` martin rudalics
2013-10-16 19:26               ` Default behaviour of RET Alan Mackenzie
2013-10-16 19:47                 ` Eli Zaretskii
2013-10-16 23:17                 ` Stephen J. Turnbull
2013-10-17  0:47                   ` Stefan Monnier
2013-10-18 17:03                     ` Alan Mackenzie
2013-10-18 19:52                       ` Stefan Monnier
2013-10-18 20:45                         ` Alan Mackenzie [this message]
2013-10-19  1:59                           ` Stefan Monnier
2013-10-19 10:58                             ` Alan Mackenzie
2013-10-19 15:07                               ` Drew Adams
2013-10-20 14:55                                 ` Alan Mackenzie
2013-10-20 22:26                                   ` Richard Stallman
2013-10-21  2:38                                     ` Eli Zaretskii
2013-10-19 22:20                               ` Stefan Monnier
2013-10-20 15:00                                 ` Alan Mackenzie
2013-10-18 16:57                   ` Alan Mackenzie
2013-10-13 20:00 ` electric-indent-mode: abolition of `newline' function is not the Right Thing Matthias Meulien
2013-10-14 13:21   ` Stefan Monnier
2013-10-14 13:31     ` Matthias Meulien
2013-10-14 16:46       ` Stefan Monnier
2013-10-15 15:54         ` Davis Herring
2013-10-15 20:03         ` Matthias Meulien
2013-10-16  2:44           ` Stefan Monnier
     [not found] <<525EDC50.8010401@gmx.at>
     [not found] ` <<20131016192642.GD3125@acm.acm>
     [not found]   ` <<87mwm8g61e.fsf@uwakimon.sk.tsukuba.ac.jp>
     [not found]     ` <<jwv4n8globm.fsf-monnier+emacs@gnu.org>
     [not found]       ` <<20131018170320.GC2569@acm.acm>
     [not found]         ` <<jwvzjq6pdek.fsf-monnier+emacs@gnu.org>
     [not found]           ` <<20131018204551.GC3012@acm.acm>
     [not found]             ` <<jwvzjq6c9da.fsf-monnier+emacs@gnu.org>
     [not found]               ` <<20131019105836.GA2991@acm.acm>
     [not found]                 ` <<762fa4a6-1a42-48b2-97ba-0f3ab7ef7ba5@default>
     [not found]                   ` <<20131020145513.GC3484@acm.acm>
     [not found]                     ` <<E1VY1SB-0006V5-EH@fencepost.gnu.org>
     [not found]                       ` <<83a9i3l554.fsf@gnu.org>
2013-10-21  3:26                         ` Default behaviour of RET Drew Adams
2013-10-21 12:12                           ` Rustom Mody
2013-10-22  1:25                             ` Richard Stallman
2013-10-23  1:20                               ` Stephen J. Turnbull
2013-10-22 13:53                             ` Kenichi Handa
2013-10-21 16:13                           ` Eli Zaretskii
     [not found] <<febb6245-ceda-4c33-a220-b0f24a1c34d2@default>
     [not found] ` <<8361sqli02.fsf@gnu.org>
2013-10-21 17:01   ` Drew Adams
2013-10-21 20:04     ` Dmitry Gutov
2013-10-21 20:53       ` Drew Adams
2013-10-21 21:15         ` Dmitry Gutov
2013-10-21 22:03         ` chad
2013-10-21 22:12           ` Daniel Colascione
2013-10-21 23:10             ` Drew Adams
2013-10-22  6:49             ` Lars Brinkhoff
2013-10-23 20:23             ` Alan Mackenzie
2013-10-21 22:13           ` Davis Herring
2013-10-21 23:12             ` Drew Adams
2013-10-21 22:59           ` Jorgen Schaefer
2013-10-22 14:02             ` Stefan Monnier
2013-10-23  0:10               ` Richard Stallman
2013-10-23  4:36               ` Josh
2013-10-23 12:29                 ` Stefan Monnier
2013-10-23 18:15                   ` Josh
2013-10-24 13:35                     ` Stefan Monnier
2013-10-21 23:10           ` Drew Adams
2013-10-22  7:45             ` Jarek Czekalski
2013-10-22 12:03               ` Rustom Mody
2013-10-23 20:18       ` Alan Mackenzie
2013-10-23 23:43         ` Stephen J. Turnbull
2013-10-24  1:53         ` Dmitry Gutov
2013-10-21 22:59     ` Xue Fuqiao
  -- strict thread matches above, loose matches on Subject: below --
2013-10-21 23:09 Drew Adams
2013-10-22  0:37 ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131018204551.GC3012@acm.acm \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=rudalics@gmx.at \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).