bug#20915: 25.0.50; [js-mode] electric annoyances

bug#20915: 25.0.50; [js-mode] electric annoyances

[Rasmus]

Hi,

Electric layout doesn't always quite work to my liking in js-mode.

Start with Emacs -q and try the following example.

      x.map(function(d) {return f(x);});

When electric layout mode is on this is typed as

     x.map(function(d){
         return f(d);
     };

Which IMO looks bad for an inline, anonymous function which should just be
inlined.

If electric indentation mode is on, the following characters are bound by
default.

(mapcar 'char-to-string electric-indent-chars)
   => ("{" "}" "(" ")" ":" ";" "," " ")

I think that might be a bit too many....  Consider if I'm using my own
indentation style (e.g. chain syntax as used with d3.js), my manual
indentation is is ruined when I type in basically any function. 

Consider:

var plot = {}; var plot.scale = {};
plot.scale.y = d3.scale.ordinal()
                       .domain(bar.ybins)
                       .rangeRoundBands([plot.height, 0], 0.1);

Typing the *third line*, I get something like (with electric indent and
electric layout):

plot.scale.y = d3.scale.ordinal()
                       .domain(bar.ybins)
    .rangeRoundBands([plot.height, 0
		     ], 0.1);
       

I don't know if it is even possible for electric indent mode to somehow
guess that things are indented to an unknown style....

Thanks,
Rasmus

In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.4)
 of 2015-06-21 on x200s
Repository revision: 821a3633564f36857968c7fe2b8bb6681a895905
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man
 --pdfdir=/usr/share/doc/emacs/pdf --with-sound=alsa --with-x-toolkit=gtk3
 --with-xft 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
 -fstack-protector-strong --param=ssp-buffer-size=4'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

-- 
One thing that is clear: it's all down hill from here 

bug#20915: 25.0.50; [js-mode] electric annoyances

[Eli Zaretskii]

> From: Rasmus <rasmus@gmx.us>
> Date: Sun, 28 Jun 2015 13:46:02 +0200
> 
> Electric layout doesn't always quite work to my liking in js-mode.

The "Emacsy" solution to that is to allow users to define the style
she likes.  That way, what you like and what I like doesn't have to be
put into the same procrustean framework.

Since js-mode already supports styles, why wouldn't it be possible to
solve this problem in the framework of the styles?

(Apologies if what I say makes no sense: I don't use js-mode.)

bug#20915: 25.0.50; [js-mode] electric annoyances

[Rasmus]

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> Electric layout doesn't always quite work to my liking in js-mode.
>
> The "Emacsy" solution to that is to allow users to define the style
> she likes.  That way, what you like and what I like doesn't have to be
> put into the same procrustean framework.
>
> Since js-mode already supports styles, why wouldn't it be possible to
> solve this problem in the framework of the styles?
>
> (Apologies if what I say makes no sense: I don't use js-mode.)

It is possible, I think, you can e.g. remove the active electricity chars.
I'm talking about the default here...

Something like js-default-style (like in cc) would perhaps be nice.  I
don't know what it would take to adapt such a scheme or how involved it is
to add styles.

Rasmus

-- 
If you can mix business and politics wonderful things can happen!

bug#20915: 25.0.50; [js-mode] electric annoyances

[Eli Zaretskii]

> From: Rasmus <rasmus@gmx.us>
> Date: Sun, 28 Jun 2015 16:50:23 +0200
> 
> >> Electric layout doesn't always quite work to my liking in js-mode.
> >
> > The "Emacsy" solution to that is to allow users to define the style
> > she likes.  That way, what you like and what I like doesn't have to be
> > put into the same procrustean framework.
> >
> > Since js-mode already supports styles, why wouldn't it be possible to
> > solve this problem in the framework of the styles?
> >
> > (Apologies if what I say makes no sense: I don't use js-mode.)
> 
> It is possible, I think, you can e.g. remove the active electricity chars.
> I'm talking about the default here...

Why should the default behave according to your liking? ;-)

bug#20915: 25.0.50; [js-mode] electric annoyances

[Dmitry Gutov]

On 06/28/2015 05:41 PM, Eli Zaretskii wrote:

> Since js-mode already supports styles,

For indentation? Does it really?

bug#20915: 25.0.50; [js-mode] electric annoyances

[Eli Zaretskii]

> Cc: 20915@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 28 Jun 2015 20:50:55 +0300
> 
> On 06/28/2015 05:41 PM, Eli Zaretskii wrote:
> 
> > Since js-mode already supports styles,
> 
> For indentation?

How should I know?

And why does it matter, for the issue at hand?

bug#20915: 25.0.50; [js-mode] electric annoyances

[Dmitry Gutov]

On 06/28/2015 08:59 PM, Eli Zaretskii wrote:

> And why does it matter, for the issue at hand?

Most of the complaint was about indentation. You've quoted the part 
about electric layout, though, but anyway, js--class-styles is not a 
suitable vehicle for this.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Eli Zaretskii]

> Cc: 20915@debbugs.gnu.org, rasmus@gmx.us
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 28 Jun 2015 21:12:16 +0300
> 
> On 06/28/2015 08:59 PM, Eli Zaretskii wrote:
> 
> > And why does it matter, for the issue at hand?
> 
> Most of the complaint was about indentation. You've quoted the part 
> about electric layout, though, but anyway, js--class-styles is not a 
> suitable vehicle for this.

Then let's introduce another vehicle.

The main point is that personal stylistic preferences should be
handled as stylistic preferences, not as something that everyone else
need to have to live with.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Dmitry Gutov]

On 06/28/2015 09:24 PM, Eli Zaretskii wrote:

> Then let's introduce another vehicle.

Sure.

> The main point is that personal stylistic preferences should be
> handled as stylistic preferences, not as something that everyone else
> need to have to live with.

Sometimes it's good to update the defaults, though.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Eli Zaretskii]

> Cc: 20915@debbugs.gnu.org, rasmus@gmx.us
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 28 Jun 2015 21:54:47 +0300
> 
> Sometimes it's good to update the defaults, though.

Sure, when many users complain about the old ones.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Stefan Monnier]

> Electric layout doesn't always quite work to my liking in js-mode.
>
> Start with Emacs -q and try the following example.
>
>       x.map(function(d) {return f(x);});
>
> When electric layout mode is on this is typed as
>
>      x.map(function(d){
>          return f(d);
>      };

I can't think of any way Emacs could guess that you want to keep this as
a single line.  Any idea?

> Typing the *third line*, I get something like (with electric indent and
> electric layout):
>
> plot.scale.y = d3.scale.ordinal()
>                        .domain(bar.ybins)
>     .rangeRoundBands([plot.height, 0
> 		     ], 0.1);

electric-indent-mode presumes indentation works correctly.  In this
case, I think we clearly have an indentation bug (can someone imagine
a sane programmer who'd want the above indentation?), so the thing to do
is to fix the indentation code.

> I don't know if it is even possible for electric indent mode to somehow
> guess that things are indented to an unknown style....

I can't imagine how.  You can tell Emacs, tho, by disabling
electric-indent-(local-)mode.


        Stefan

bug#20915: 25.0.50; [js-mode] electric annoyances

[Rasmus]

Hi,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Electric layout doesn't always quite work to my liking in js-mode.
>>
>
>> Start with Emacs -q and try the following example.
>>
>>       x.map(function(d) {return f(x);});
>>
>> When electric layout mode is on this is typed as
>>
>>      x.map(function(d){
>>          return f(d);
>>      };
>
> I can't think of any way Emacs could guess that you want to keep this as
> a single line.  Any idea?

I don't know if this is possible.  Perhaps via js2 since it knows more
about semantics.

What about differentiating between functions saved to a var or an object
slot:

    var foo = function(a,b){...};
    baz.f = function(a,b){...};

Versus functions that are not saved.

    [1,2,3].map(function(d){...});

Is that identifiable and desirable?

I'm expect Dmitry has a better understanding of this issue.

>> Typing the *third line*, I get something like (with electric indent and
>> electric layout):
>>
>> plot.scale.y = d3.scale.ordinal()
>>                        .domain(bar.ybins)
>>     .rangeRoundBands([plot.height, 0
>> 		     ], 0.1);
>
> electric-indent-mode presumes indentation works correctly.  In this
> case, I think we clearly have an indentation bug (can someone imagine
> a sane programmer who'd want the above indentation?), so the thing to do
> is to fix the indentation code.

And you would not consider the lonely "]" an stylistic annoyance?  That, I
guess, is the work of electric layout.

>> I don't know if it is even possible for electric indent mode to somehow
>> guess that things are indented to an unknown style....
>
> I can't imagine how.  You can tell Emacs, tho, by disabling
> electric-indent-(local-)mode.

Of course.  I can also remove some of the most unpleasant characters in
electric-indent-chars...

Rasmus

-- 
C is for Cookie

bug#20915: 25.0.50; [js-mode] electric annoyances

[Dmitry Gutov]

On 06/29/2015 04:26 AM, Rasmus wrote:

> What about differentiating between functions saved to a var or an object
> slot:
>
>      var foo = function(a,b){...};
>      baz.f = function(a,b){...};
>
> Versus functions that are not saved.
>
>      [1,2,3].map(function(d){...});
>
> Is that identifiable and desirable?
>
> I'm expect Dmitry has a better understanding of this issue.

Looks doable: you skip to the current "function" keyword and see if it's 
preceded by an assignment operator.

An electric-layout-rules element can be a function, so that's not a problem.

> And you would not consider the lonely "]" an stylistic annoyance?  That, I
> guess, is the work of electric layout.

I'm not sure it is. Before we start guessing, why don't you write down 
the minimal configuration needed to reproduce this? Start with 'emacs -Q'.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Rasmus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 06/29/2015 04:26 AM, Rasmus wrote:
>
>> What about differentiating between functions saved to a var or an object
>> slot:
>>
>>      var foo = function(a,b){...};
>>      baz.f = function(a,b){...};
>>
>> Versus functions that are not saved.
>>
>>      [1,2,3].map(function(d){...});
>>
>> Is that identifiable and desirable?
>>
>> I'm expect Dmitry has a better understanding of this issue.
>
> Looks doable: you skip to the current "function" keyword and see if
> it's preceded by an assignment operator.

Right.

>> And you would not consider the lonely "]" an stylistic annoyance?  That, I
>> guess, is the work of electric layout.
>
> I'm not sure it is. Before we start guessing, why don't you write down
> the minimal configuration needed to reproduce this? Start with 'emacs
> -Q'.

In fact I am now unable to reproduce that indentation example again,
though the original was created with emacs -q.  So ignore it for now.


Dmitry Gutov <dgutov@yandex.ru> writes:

> On 06/29/2015 04:12 AM, Stefan Monnier wrote:
>
>>> plot.scale.y = d3.scale.ordinal()
>>>                         .domain(bar.ybins)
>>>      .rangeRoundBands([plot.height, 0
>>> 		     ], 0.1);
>>
>> electric-indent-mode presumes indentation works correctly.  In this
>> case, I think we clearly have an indentation bug (can someone imagine
>> a sane programmer who'd want the above indentation?), so the thing to do
>> is to fix the indentation code.
>
> Not an indentation bug. The user manually indented the second line,
> hence the misalignment.

Indeed.  The points was whether electric could guess if something is
indented and not try to apply indentation.  Which is not possible.

Thanks,
Rasmus

-- 
What will be next?

bug#20915: 25.0.50; [js-mode] electric annoyances

[Dmitry Gutov]

On 06/29/2015 04:12 AM, Stefan Monnier wrote:

>> plot.scale.y = d3.scale.ordinal()
>>                         .domain(bar.ybins)
>>      .rangeRoundBands([plot.height, 0
>> 		     ], 0.1);
>
> electric-indent-mode presumes indentation works correctly.  In this
> case, I think we clearly have an indentation bug (can someone imagine
> a sane programmer who'd want the above indentation?), so the thing to do
> is to fix the indentation code.

Not an indentation bug. The user manually indented the second line, 
hence the misalignment.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Stefan Monnier]

>> plot.scale.y = d3.scale.ordinal()
>>                         .domain(bar.ybins)
>>      .rangeRoundBands([plot.height, 0
>> 		     ], 0.1);

> Not an indentation bug. The user manually indented the second line, hence
> the misalignment.

FWIW, given the first two lines, the third line's indentation is wrong.
Whether the first two lines where auto-indented or manually indented
does not matter in this regard (IMNSHO).


        Stefan


PS: Actually, I think that the indentation code should probably be able
to decide how to indent by only looking at the immediately preceding
line, in this case.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Dmitry Gutov]

On 06/29/2015 04:18 PM, Stefan Monnier wrote:

> FWIW, given the first two lines, the third line's indentation is wrong.
> Whether the first two lines where auto-indented or manually indented
> does not matter in this regard (IMNSHO).

Not according to the current algorithm (which is based on (nth 1 
parse-status)).

Fixing that might require a rewrite on top of e.g. SMIE. Although that 
might be the point you're making.

bug#20915: 25.0.50; [js-mode] electric annoyances

[Stefan Monnier]

>> FWIW, given the first two lines, the third line's indentation is wrong.
>> Whether the first two lines where auto-indented or manually indented
>> does not matter in this regard (IMNSHO).
> Not according to the current algorithm (which is based on (nth
> 1 parse-status)).

I'm not talking about the current code, but about the behavior we should
strive for.

> Fixing that might require a rewrite on top of e.g. SMIE. Although that might
> be the point you're making.

Kind of: I haven't actually looked at the code, so I have no idea how
easy/hard it would be to make it behave like we want (and AFAIK, using
SMIE for C-style syntaxes is still an open problem, the first hurdle
being the choice of using either "{...}" or "...;" for the branches of
"if").


        Stefan