[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questioning the new behavior of `open-line'.

From: Rasmus
Subject: Re: Questioning the new behavior of `open-line'.
Date: Thu, 12 Nov 2015 12:08:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Hi Artur,

Artur Malabarba <address@hidden> writes:

>> >I share this sentiment.  I love most of the electricity and it should be
>> >on by default IMHO.
>> >
>> >But the change to C-o is for the worse.  It should be "dumb" also at
>> >columns greater than zero.
> Hi Rasmus and David.
> Could you give an example (similar to what I did) illustrating why you
> prefer the dumb behaviour on columns grater than 0?
> i.e., when is it more convenient to break an indented line in half and have
> the second half be unindented?
> I'm willing to revert this change, but I'd really like to give a reasoning
> on the commit message.

For C-o I expect a newline to be inserted.  Nothing else.  If I want
indentation I already have RET.  If I want to return to point I have 
C-x C-x.

An example of when I use C-o is when I have to manually indent stuff,
e.g. if Emacs is not smart enough to do a good job /all of the time/.  A
case is d3.js code, where periods are typically aligned.

You may say that this is an example of separate bug (and indeed there
exists a bug report on JS mode alignment), but to the extend that
misbehaviors (even "subjective misbehaviors") exists, it’s very useful to
have dumb behavior available.  Here’s an example of d3.js.  I may want to
insert a new attribute before the width, without affecting the current
indentation.  I’d then use C-o.

    var svg = div.append("svg")
                 .attr("width", box_plot.w)
                 .attr("height", box_plot.h);


Need more coffee. . .

reply via email to

[Prev in Thread] Current Thread [Next in Thread]