GNU bug report logs -
#8576
23.2; js-mode doesn't support multi-line variable declarations
Previous Next
Reported by: "Felix H. Dahlke" <fhd <at> ubercode.de>
Date: Thu, 28 Apr 2011 11:31:02 UTC
Severity: normal
Found in version 23.2
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8576 in the body.
You can then email your comments to 8576 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Thu, 28 Apr 2011 11:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Felix H. Dahlke" <fhd <at> ubercode.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 28 Apr 2011 11:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The problem can be reproduced as follows:
1. Open a JavaScript file or load js-mode
2. Insert the following code:
var i = 1,
j = 2;
3. Observe that "j" is not highlighted and that pressing TAB on the
second line doesn't indent it correctly.
Highlighting works correctly if both variables are declared on the
same line:
var i = 1, j = 2;
In GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.21.6)
of 2010-09-01 on rhenium, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10900000
configured using `configure '--build' 'i686-linux-gnu' '--build'
'i686-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim'
'--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
'build_alias=i686-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g'
'CPPFLAGS=''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.utf8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Javascript
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x j s - m o <tab> <return> C-x C-f . e m <tab> <tab>
/ <tab> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> P r o <tab> a l <tab> <tab> s e r <tab>
<return> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-p <tab> C-_ M-x e m a <tab> r e <tab> p o <tab> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> r e
p o <tab> r t - e m <tab> <return>
Recent messages:
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/50slime.el (source)...
Error while loading 50slime: Cannot open load file:
/usr/share/emacs23/site-lisp/slime/slime-autoloads
For information about GNU Emacs and the GNU system, type C-h C-a.
Fontifying *GNU Emacs*... (syntactically...)
Making completion list... [2 times]
Fontifying server.js... (syntactically...)
Loading vc-git...done
Undo!
Making completion list...
Load-path shadows:
/usr/share/emacs/23.2/site-lisp/auctex/tex-fold hides
/usr/share/emacs/site-lisp/auctex/tex-fold
/usr/share/emacs/23.2/site-lisp/auctex/tex-fptex hides
/usr/share/emacs/site-lisp/auctex/tex-fptex
/usr/share/emacs/23.2/site-lisp/auctex/context-en hides
/usr/share/emacs/site-lisp/auctex/context-en
/usr/share/emacs/23.2/site-lisp/auctex/tex-buf hides
/usr/share/emacs/site-lisp/auctex/tex-buf
/usr/share/emacs/23.2/site-lisp/auctex/font-latex hides
/usr/share/emacs/site-lisp/auctex/font-latex
/usr/share/emacs/23.2/site-lisp/auctex/tex-mik hides
/usr/share/emacs/site-lisp/auctex/tex-mik
/usr/share/emacs/23.2/site-lisp/auctex/tex-jp hides
/usr/share/emacs/site-lisp/auctex/tex-jp
/usr/share/emacs/23.2/site-lisp/auctex/tex-bar hides
/usr/share/emacs/site-lisp/auctex/tex-bar
/usr/share/emacs/23.2/site-lisp/auctex/context-nl hides
/usr/share/emacs/site-lisp/auctex/context-nl
/usr/share/emacs/23.2/site-lisp/auctex/tex hides
/usr/share/emacs/site-lisp/auctex/tex
/usr/share/emacs/23.2/site-lisp/auctex/multi-prompt hides
/usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/share/emacs/23.2/site-lisp/auctex/tex-font hides
/usr/share/emacs/site-lisp/auctex/tex-font
/usr/share/emacs/23.2/site-lisp/auctex/tex-style hides
/usr/share/emacs/site-lisp/auctex/tex-style
/usr/share/emacs/23.2/site-lisp/auctex/bib-cite hides
/usr/share/emacs/site-lisp/auctex/bib-cite
/usr/share/emacs/23.2/site-lisp/auctex/context hides
/usr/share/emacs/site-lisp/auctex/context
/usr/share/emacs/23.2/site-lisp/auctex/latex hides
/usr/share/emacs/site-lisp/auctex/latex
/usr/share/emacs/23.2/site-lisp/auctex/toolbar-x hides
/usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/share/emacs/23.2/site-lisp/auctex/texmathp hides
/usr/share/emacs/site-lisp/auctex/texmathp
/usr/share/emacs/23.2/site-lisp/auctex/tex-info hides
/usr/share/emacs/site-lisp/auctex/tex-info
/usr/share/emacs/23.2/site-lisp/cmake-data/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs/23.2/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs23/site-lisp/dictionaries-common/flyspell hides
/usr/share/emacs/23.2/lisp/textmodes/flyspell
/usr/share/emacs23/site-lisp/dictionaries-common/ispell hides
/usr/share/emacs/23.2/lisp/textmodes/ispell
Features:
(shadow sort mail-extr message sendmail ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug vc-git help-mode view js byte-opt
bytecomp byte-compile json thingatpt etags ring imenu newcomment cc-mode
cc-fonts easymenu cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs regexp-opt devhelp preview-latex tex-site auto-loads tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind system-font-setting
font-render-setting gtk x-toolkit x multi-tty emacs)
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Sun, 19 Jun 2011 20:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Felix,
Thanks for the bug report.
On 4/28/11 12:22 AM, Felix H. Dahlke wrote:
> The problem can be reproduced as follows:
>
> 1. Open a JavaScript file or load js-mode
> 2. Insert the following code:
> var i = 1,
> j = 2;
> 3. Observe that "j" is not highlighted and that pressing TAB on the
> second line doesn't indent it correctly.
>
> Highlighting works correctly if both variables are declared on the
> same line:
> var i = 1, j = 2;
>
After looking at what would be required to address this bug, I'd like to
leave it unfixed for now:
The machinery required to implement the tracking necessary to handle
this construct in a generic way would be quite complex. Simple cases
could perhaps be recognized more quickly, but such a solution would fail
in hard to predict ways. Long-range effects are notoriously difficult to
recognize in font-lock, and reliably rehighlighting them after a change
is even trickier.
Additionally, this construct is relatively rare; if you're going to
split variable declarations across several lines, you might as well use
another "var". Also, the existing highlighting has no ill effects: the
second declaration is just interpreted as an assignment, and the worst
part is a lack of font-lock-variable-name-face, not syntactic incoherence.
I'll take patches, but for now, I think we should defer a solution to
this issue until we have a more sophisticated and general highlighting
scheme.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iEYEARECAAYFAk3+XiwACgkQ17c2LVA10VvACwCdHD38OsUrXWLaCt3prK4BQ+3a
SqUAoLdQ+C8nVvLXJkvcza3d2JyTXtXs
=58ua
-----END PGP SIGNATURE-----
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Sun, 19 Jun 2011 20:39:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Wed, 15 Feb 2012 17:09:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/19/2011 10:38 PM, Daniel Colascione wrote:
> Hi Felix,
>
> Thanks for the bug report.
Hi Daniel,
sorry for getting back so terribly late, I somehow failed to notice the
email and didn't use Emacs for JS much in the past year. But I'm using
js-mode intensively again from now on, so the issue has become important
for me again.
> Additionally, this construct is relatively rare; if you're going to
> split variable declarations across several lines, you might as well use
> another "var".
I disagree, it's a very popular style and I'm using it all the time.
Many others do, look e.g. at the jQuery code:
https://github.com/jquery/jquery/blob/master/src/core.js
> Also, the existing highlighting has no ill effects: the
> second declaration is just interpreted as an assignment, and the worst
> part is a lack of font-lock-variable-name-face, not syntactic incoherence.
True, but it's still very irritating to have Emacs indent it incorrectly
every time you insert/edit such a statement and having to manually fix
the indentation. That's why I used other editors for JS in the past
year, but I really want to use Emacs, so I'm back.
> > I'll take patches, but for now, I think we should defer a solution to
> this issue until we have a more sophisticated and general highlighting
> scheme.
I did have a look at the code, but I'm not familiar with font-lock, so I
couldn't fix it. But I'd be very happy to help with the more general
highlighting scheme.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Wed, 15 Feb 2012 19:01:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 8576 <at> debbugs.gnu.org (full text, mbox):
>> Also, the existing highlighting has no ill effects: the
>> second declaration is just interpreted as an assignment, and the worst
>> part is a lack of font-lock-variable-name-face, not syntactic incoherence.
> True, but it's still very irritating to have Emacs indent it incorrectly
> every time you insert/edit such a statement and having to manually fix
Agreed: it's OK for the highlighting to be a bit off, but indentation
is more irritating. Luckily, we can afford to work harder during
indentation than during highlighting, so it should be fixable.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Wed, 15 Feb 2012 19:07:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 8576 <at> debbugs.gnu.org (full text, mbox):
I don't know what this issue is supposed to have to do with bug#8584
("erc: New response handler"). Fortunately that bug is archived, so it
isn't having any effect, but please stop cc'ing it anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Wed, 15 Feb 2012 19:28:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 8576 <at> debbugs.gnu.org (full text, mbox):
On 2/15/2012 10:58 AM, Stefan Monnier wrote:
>>> Also, the existing highlighting has no ill effects: the
>>> second declaration is just interpreted as an assignment, and the worst
>>> part is a lack of font-lock-variable-name-face, not syntactic incoherence.
>> True, but it's still very irritating to have Emacs indent it incorrectly
>> every time you insert/edit such a statement and having to manually fix
>
> Agreed: it's OK for the highlighting to be a bit off, but indentation
> is more irritating. Luckily, we can afford to work harder during
> indentation than during highlighting, so it should be fixable.
I'll work on a fix, at least for indentation. The trouble is that the
fix involves a potentially unbounded amount of backward parsing. We'll
see how it goes.
Stefan, is this something that should be in 24.1?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Wed, 15 Feb 2012 20:44:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 8576 <at> debbugs.gnu.org (full text, mbox):
> I'll work on a fix, at least for indentation. The trouble is that the
> fix involves a potentially unbounded amount of backward parsing.
AFAIK all indentation algorithms involve some unbounded amount of
backward parsing, except for some rare exceptions where the language's
syntax is sufficiently limited/redundant (and line-oriented).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Fri, 24 Feb 2012 02:27:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 8576 <at> debbugs.gnu.org (full text, mbox):
Here is a function I wrote to properly indent multiline declarations in
another package:
https://github.com/mooz/js2-mode/blob/master/js2-mode.el#L9917
It is kinda ugly, but it's been working reliably for me for some time
now, and it doesn't rely on anything specific to js2-mode.
I have a CA signed, so it's fair game.
Dmitry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Sat, 03 Mar 2012 02:06:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 8576 <at> debbugs.gnu.org (full text, mbox):
Hello Emacs people,
Daniel Colascione in message 8 said:
"Additionally, this construct is relatively rare; if you're going to
split variable declarations across several lines, you might as well use
another "var"."
Actually the format required by JSLint, for good reason, is that one
single var statement per function, at the very start of the function, i.e.:
var name, another-name, another-name;
When you have more than 80 characters worth of variable declarations,
you need to start a new line:
var first-name, second-name, third-name,
fourth-name, fifth-name;
The first-name and fourth-name above should align (i.e. the second and
subsequent lines should be indented by 4 characters).
Emacs does not highlight the second and subsequent lines correctly, and
it does not indent them correctly either.
This is a shame because in all other respects, Emacs indents and
highlights in the way you would expect when following the demands of JSLint.
(JSLint demands this behaviour to avoid making hoisting and scoping
mistakes, i.e. those used to other languages with block scope might
believe the placement of var statements further down in a function
implies that a variable is not defined yet, when actually it is.)
Best Wishes,
Zeth
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Sat, 03 Mar 2012 04:53:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/2/12 5:46 PM, Zeth wrote:
> When you have more than 80 characters worth of variable declarations,
> you need to start a new line:
>
> var first-name, second-name, third-name,
> fourth-name, fifth-name;
>
> (JSLint demands this behaviour to avoid making hoisting and scoping
> mistakes, i.e. those used to other languages with block scope might
> believe the placement of var statements further down in a function
> implies that a variable is not defined yet, when actually it is.)
>
I'll be able to put some time into fixing this issue this weekend.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Wed, 04 Apr 2012 11:27:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 8576 <at> debbugs.gnu.org (full text, mbox):
On Feb 15, 2012, at 8:25 PM, Daniel Colascione wrote:
> I'll work on a fix, at least for indentation. The trouble is that the
> fix involves a potentially unbounded amount of backward parsing. We'll
> see how it goes.
I fixed this locally in the js.el that comes with Emacs 23.4, based on Dmitry's work. Have you already started on this or would you be interested in a patch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Fri, 01 Jun 2012 07:33:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Okay, I've prepared a patch for this, based on Dimitriv's work. I've
been using this for a while now and haven't run into any problems.
The attached patch is against the latest revision in the emacs-23
branch. I can provide a patch for emacs-24 or trunk if that's desirable.
Here's the patched version if you'd like to try it out:
https://gist.github.com/2849799
And here's one that should work in Emacs 24:
https://gist.github.com/2849595
There's still one thing that I'd like to behave differently, but I
thought I'd best discuss this first.
The patched js.el will indent the following code like this:
var foo = 5,
bar = function() {
};
That's fine. But if a function or an object literal come first, it
indents it like this:
var bar = function() {
},
foo = 5;
Which I consider somewhat ugly. I'd like to make it indent as follows:
var bar = function() {
},
foo = 5;
That should only happen for multi var declarations, single declarations
should indent just like before:
var bar = function() {
};
Would that be acceptable? It'll make the code a bit more complicated,
but I think it's worth it.
[Message part 2 (text/html, inline)]
[indent-multiline-var-statements.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Thu, 07 Jun 2012 23:07:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 8576 <at> debbugs.gnu.org (full text, mbox):
> There's still one thing that I'd like to behave differently, but I
> thought I'd best discuss this first.
...
> Would that be acceptable? It'll make the code a bit more complicated,
> but I think it's worth it.
Personally, I think that's the desirable behavior, but you should keep
in mind that this will require the indentation engine to look ahead in
the buffer and account for the case when there's no text after the
point, for example.
Suppose the first value function actually has a non-empty body, and
we're just typing the code for the first time.
Even if we're using a snippet package that inserted "function() {}" for
us, we will type the important comma after "}" only when the function
body is written, and then we'll have to go back to reindent the body again.
I think that's acceptable, but that's not how indentation functions in
Emacs usually work.
-- Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Fri, 08 Jun 2012 03:17:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 8576 <at> debbugs.gnu.org (full text, mbox):
On 06/08/2012 01:04 AM, Dmitry Gutov wrote:
> Personally, I think that's the desirable behavior, but you should keep
> in mind that this will require the indentation engine to look ahead in
> the buffer and account for the case when there's no text after the
> point, for example.
> Suppose the first value function actually has a non-empty body, and
> we're just typing the code for the first time.
> Even if we're using a snippet package that inserted "function() {}"
> for us, we will type the important comma after "}" only when the
> function body is written, and then we'll have to go back to reindent
> the body again.
>
> I think that's acceptable, but that's not how indentation functions in
> Emacs usually work.
You're right, it's harder than I thought. I'm currently looking for
similar problems in other modes and see how they handle it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Thu, 05 Jul 2012 15:55:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 8576 <at> debbugs.gnu.org (full text, mbox):
On Friday, 1 June 2012 13:00:21 UTC+5:30, Felix H. Dahlke wrote:
> Okay, I've prepared a patch for this, based on Dimitriv's work. I've
> been using this for a while now and haven't run into any problems.
>
>
>
> The attached patch is against the latest revision in the emacs-23
> branch. I can provide a patch for emacs-24 or trunk if that's
> desirable.
>
>
>
> Here's the patched version if you'd like to try it out:
>
>
> <a href="https://gist.github.com/2849799" target="_blank">https://gist.github.com/<WBR>2849799</a>
>
>
>
> And here's one that should work in Emacs 24:
>
>
> <a href="https://gist.github.com/2849595" target="_blank">https://gist.github.com/<WBR>2849595</a>
>
>
>
> There's still one thing that I'd like to behave differently, but I
> thought I'd best discuss this first.
>
>
>
> The patched js.el will indent the following code like this:
>
>
>
> var foo = 5,
>
> bar = function() {
>
> };
>
>
>
> That's fine. But if a function or an object literal come first, it
> indents it like this:
>
>
>
> var bar = function() {
>
> },
>
> foo = 5;
>
>
>
> Which I consider somewhat ugly. I'd like to make it indent as
> follows:
>
>
>
> var bar = function() {
>
> },
>
> foo = 5;
>
>
>
> That should only happen for multi var declarations, single
> declarations should indent just like before:
>
>
>
> var bar = function() {
>
> };
>
>
>
> Would that be acceptable? It'll make the code a bit more
> complicated, but I think it's worth it.
>
>
When the first var is staring with an offset, like inside a nested function or something, this is failing. It feels like the second line is indented wrt to coloumn 0 and not wrt to the "var" statement.
This is what I expect
\t \t var a = "foo",
\t \t \t b = "bar";
but it becomes
\t \t var a = "foo",
\t ..b = "bar";
I might be wrong, Im a noob with emacs. Reporting the behavior because the issue is bugging me a lot. I tried with the gist for v24 on v24.1.1.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Thu, 05 Jul 2012 23:08:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 8576 <at> debbugs.gnu.org (full text, mbox):
> When the first var is staring with an offset, like inside a nested
> function or something, this is failing. It feels like the second line
> is indented wrt to coloumn 0 and not wrt to the "var" statement.
I don't see the behavior you describe. With the gist for 24 loaded, this
indents fine in js-mode:
function() {
function() {
var a = "foo",
b = "bar";
}
}
-- Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Fri, 06 Jul 2012 00:58:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> When the first var is staring with an offset, like inside a nested
> function or something, this is failing. It feels like the second line
> is indented wrt to coloumn 0 and not wrt to the "var" statement.
Reproduced when `indent-tabs-mode' is t.
Here's the updated patch for trunk.
-- Dmitry
[js-multiline-decls.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Fri, 06 Jul 2012 01:29:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 8576 <at> debbugs.gnu.org (full text, mbox):
On Friday, 6 July 2012 06:22:23 UTC+5:30, Dmitry Gutov wrote:
> > When the first var is staring with an offset, like inside a nested
> > function or something, this is failing. It feels like the second line
> > is indented wrt to coloumn 0 and not wrt to the "var" statement.
>
> Reproduced when `indent-tabs-mode' is t.
>
> Here's the updated patch for trunk.
>
> -- Dmitry
>
>
> diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
> index 2e943be..98883a9 100644
> --- a/lisp/progmodes/js.el
> +++ b/lisp/progmodes/js.el
> @@ -1680,6 +1680,9 @@ This performs fontification according to `js--class-styles'."
> (js--regexp-opt-symbol '("in" "instanceof")))
> "Regexp matching operators that affect indentation of continued expressions.")
>
> +(defconst js--declaration-keyword-re
> + (regexp-opt '("var" "let" "const") 'words)
> + "Regular matching variable declaration keywords.")
>
> (defun js--looking-at-operator-p ()
> "Return non-nil if point is on a JavaScript operator, other than a comma."
> @@ -1759,6 +1762,42 @@ nil."
> (list (cons 'c js-comment-lineup-func))))
> (c-get-syntactic-indentation (list (cons symbol anchor)))))
>
> +(defun js--multiline-decl-indentation ()
> + "Returns the declaration indentation column if the current line belongs
> +to a multiline declaration statement. All declarations are lined up vertically:
> +
> +var a = 10,
> + b = 20,
> + c = 30;
> +"
> + (let (at-opening-bracket)
> + (save-excursion
> + (back-to-indentation)
> + (when (not (looking-at js--declaration-keyword-re))
> + (when (looking-at js--indent-operator-re)
> + (goto-char (match-end 0)))
> + (while (and (not at-opening-bracket)
> + (not (bobp))
> + (let ((pos (point)))
> + (save-excursion
> + (js--backward-syntactic-ws)
> + (or (eq (char-before) ?,)
> + (and (not (eq (char-before) ?\;))
> + (and
> + (prog2
> + (skip-chars-backward "[[:punct:]]")
> + (looking-at js--indent-operator-re)
> + (js--backward-syntactic-ws))
> + (not (eq (char-before) ?\;))))
> + (and (>= pos (point-at-bol))
> + (<= pos (point-at-eol)))))))
> + (condition-case err
> + (backward-sexp)
> + (scan-error (setq at-opening-bracket t))))
> + (when (looking-at js--declaration-keyword-re)
> + (goto-char (match-end 0))
> + (1+ (current-column)))))))
> +
> (defun js--proper-indentation (parse-status)
> "Return the proper indentation for the current line."
> (save-excursion
> @@ -1769,6 +1808,7 @@ nil."
> ((js--ctrl-statement-indentation))
> ((eq (char-after) ?#) 0)
> ((save-excursion (js--beginning-of-macro)) 4)
> + ((js--multiline-decl-indentation))
> ((nth 1 parse-status)
> ;; A single closing paren/bracket should be indented at the
> ;; same level as the opening statement. Same goes for
In the mean while, I tried js2-mode. Reported the same issue there.
Fixed it here : https://github.com/mooz/js2-mode/commit/3ee849316253121ec4ee51268bc814ab60d63b2f
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 03:23:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I tried some things but couldn't really make it work like I wanted. So I
decided to just improve the patch a bit. I am now using the proper
indentation which also fixes the issue reported by jaseemabid.
I've attached the patch for Emacs 24 and updated the Gists:
https://gist.github.com/2849595 (Emacs 24)
https://gist.github.com/2849799 (Emacs 23)
The problem with my desired behaviour is indeed that it requires forward
parsing. So when you're indenting a full statement like this, it works:
var x = {
num: 5
},
y = 6;
However, when you're initially typing this (pressing TAB on each line),
it ends up like this:
var x = {
num: 5
},
y = 6;
You'd have to go back and indent the whole thing again after adding the
closing brace followed by a comma. That's actually pretty annoying in
practice and would probably lead to highly inconsistent indendation, so
I decided to leave it out for now.
The only solution I can think of would be to go back up after typing a
closing brace followed by a comma and indent the preceeding lines. Some
modes do that, but it would require drastic changes to js.el. I'd rather
get this patch in first and see if the issue annoys me (or anyone else)
enough to work further on this.
[indent-multi-line-var-statements.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 04:29:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 8576 <at> debbugs.gnu.org (full text, mbox):
"Felix H. Dahlke" <fhd <at> ubercode.de> writes:
> I tried some things but couldn't really make it work like I wanted.
> So I decided to just improve the patch a bit. I am now using the
> proper indentation which also fixes the issue reported by jaseemabid.
Yes, that's a bit better than my fix.
You shouldn't add the `js--indent-operator-re' constant, though, it's
already present in js-mode.
> The only solution I can think of would be to go back up after typing a
> closing brace followed by a comma and indent the preceeding lines.
> Some modes do that, but it would require drastic changes to js.el.
> I'd rather get this patch in first and see if the issue annoys me (or
> anyone else) enough to work further on this.
I don't think this will be much of a problem.
There is an alternative approach, though: one js2-mode user requested
that when the first value in the declaration is a function/object/array,
it should always be indented: https://github.com/mooz/js2-mode/issues/3
That option probably won't be very popular.
--Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 04:44:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/17/2012 06:21 AM, Dmitry Gutov wrote:
> You shouldn't add the `js--indent-operator-re' constant, though, it's
> already present in js-mode.
Oh, you're right, thanks. I've updated the gists and attached a new patch.
>> The only solution I can think of would be to go back up after typing a
>> closing brace followed by a comma and indent the preceeding lines.
>> Some modes do that, but it would require drastic changes to js.el.
>> I'd rather get this patch in first and see if the issue annoys me (or
>> anyone else) enough to work further on this.
>
> I don't think this will be much of a problem.
Probably not, but I fear it's going to be a lot of work - at least when
I do it.
> There is an alternative approach, though: one js2-mode user requested
> that when the first value in the declaration is a function/object/array,
> it should always be indented: https://github.com/mooz/js2-mode/issues/3
>
> That option probably won't be very popular.
Yes, I thought about suggesting that. But considering that that makes
single variable declarations of functions/object literals look weird, I
figured that wouldn't be desirable. I saw that you can configure this in
j2-mode, perhaps that's an option. But I'd personally prefer the clever
solution.
[indent-multi-line-var-statements.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 05:07:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 8576 <at> debbugs.gnu.org (full text, mbox):
"Felix H. Dahlke" <fhd <at> ubercode.de> writes:
> On 07/17/2012 06:21 AM, Dmitry Gutov wrote:
> I've updated the gists and attached a new patch.
I'm sorry, I spoke too soon. Now I see that your patch relies on the
value of `js-indent-level' being 4. And what if the keyword is "const"?
Unless you're fine with the following indentation, the patch I posted
earlier is better:
const a = 5,
b = 6;
>>> The only solution I can think of would be to go back up after
>>> typing a closing brace followed by a comma and indent the
>>> preceeding lines.
>>> Some modes do that, but it would require drastic changes to js.el.
>>> I'd rather get this patch in first and see if the issue annoys me
>>> (or anyone else) enough to work further on this.
>>
>> I don't think this will be much of a problem.
>
> Probably not, but I fear it's going to be a lot of work - at least
> when I do it.
I meant that nobody will care, most likely. But the implementation
shouldn't be too hard either - add a function to `post-command-hook'
which would check if the command is `self-insert-command', check if we
inserted a comma, skip backward to the previous non-whitespace char, see
if it's } or ], etc.
--Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 06:39:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 8576 <at> debbugs.gnu.org (full text, mbox):
> const a = 5,
> b = 6;
Yup, that'd be a bug.
>>>> The only solution I can think of would be to go back up after
>>>> typing a closing brace followed by a comma and indent the
>>>> preceeding lines.
>>>> Some modes do that, but it would require drastic changes to js.el.
>>>> I'd rather get this patch in first and see if the issue annoys me
>>>> (or anyone else) enough to work further on this.
>>> I don't think this will be much of a problem.
>> Probably not, but I fear it's going to be a lot of work - at least
>> when I do it.
> I meant that nobody will care, most likely. But the implementation
> shouldn't be too hard either - add a function to `post-command-hook'
> which would check if the command is `self-insert-command', check if we
> inserted a comma, skip backward to the previous non-whitespace char, see
> if it's } or ], etc.
Rather than a post-command-hook, that would be a post-self-insert-hook.
And that would need to be conditional on some js-electric-foo variable
(or better yet, be made to work with electric-indent-mode).
Note that looking forward during indentation, while occasionally
annoying, is not that big of a problem in practice: contrary to popular
belief, we don't write code quite as linearly as one might think.
We at least as frequently edit code in place.
BTW, rather than a post-self-insert-hook, you could put a special
text-property `js--indent-depends-on-next-line' on the line, and then
when indenting a line, you could check if the previous line has that
property and if so indent both lines. I'm not claiming it's a better
approach, just an alternative one.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 08:31:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Quoting Stefan Monnier <monnier <at> IRO.UMontreal.CA>:
> Thank you for your efforts trying to find a good fix for this problem.
> I'd like to install your changes (or some future version of them once
> the wrinkles are worked out), but it's sufficiently non-trivial that
> we need you to sign some copyright paperwork.
I already sent a signed CA to the FSF, it should arrive shortly.
>> const a = 5,
>> b = 6;
>
> Yup, that'd be a bug.
Depends, IMO. Do we want to indent on the column, or by the configured
indentation level? I personally want to indent on column, so that
would indeed be a problem for me (never noticed because I use a tab
size of 4 and no const keyword). Should this be configurable?
If we don't make it configurable, I'd vote for going with Dmitry's
variant, as that seems to be the more popular style.
>> I meant that nobody will care, most likely. But the implementation
>> shouldn't be too hard either - add a function to `post-command-hook'
>> which would check if the command is `self-insert-command', check if we
>> inserted a comma, skip backward to the previous non-whitespace char, see
>> if it's } or ], etc.
>
> Rather than a post-command-hook, that would be a post-self-insert-hook.
> And that would need to be conditional on some js-electric-foo variable
> (or better yet, be made to work with electric-indent-mode).
>
> Note that looking forward during indentation, while occasionally
> annoying, is not that big of a problem in practice: contrary to popular
> belief, we don't write code quite as linearly as one might think.
> We at least as frequently edit code in place.
>
> BTW, rather than a post-self-insert-hook, you could put a special
> text-property `js--indent-depends-on-next-line' on the line, and then
> when indenting a line, you could check if the previous line has that
> property and if so indent both lines. I'm not claiming it's a better
> approach, just an alternative one.
Thanks for the hints Dmitry and Stefan, as you undoubtly noticed, I am
quite new to Emacs development, but willing to learn :)
But I'd rather get this patch in in the simple form first, and enhance
the behaviour with another one.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 09:57:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 8576 <at> debbugs.gnu.org (full text, mbox):
>>> const a = 5,
>>> b = 6;
>> Yup, that'd be a bug.
> Depends, IMO. Do we want to indent on the column, or by the configured
> indentation level?
The user already has the choice (without even a config-var) by choosing
between
const a = 5,
b = 6;
and
const
a = 5,
b = 6;
> Should this be configurable?
I don't think that's needed.
> But I'd rather get this patch in in the simple form first, and enhance the
> behaviour with another one.
Agreed,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 09:58:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Okay, I'll incorporate Dmitry's fix when I get home then.
Quoting Stefan Monnier <monnier <at> IRO.UMontreal.CA>:
>>>> const a = 5,
>>>> b = 6;
>>> Yup, that'd be a bug.
>> Depends, IMO. Do we want to indent on the column, or by the configured
>> indentation level?
>
> The user already has the choice (without even a config-var) by choosing
> between
>
> const a = 5,
> b = 6;
> and
> const
> a = 5,
> b = 6;
>
>> Should this be configurable?
>
> I don't think that's needed.
>
>> But I'd rather get this patch in in the simple form first, and enhance the
>> behaviour with another one.
>
> Agreed,
>
>
> Stefan
>
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Tue, 17 Jul 2012 17:40:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 8576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Okay, I've updated the gists and attached the modified patch as discussed.
[indent-multi-line-var-statements.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Thu, 10 Jan 2013 03:49:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 8576 <at> debbugs.gnu.org (full text, mbox):
So, it's been a while. Anything I can do to help get this merged?
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility.
(Fri, 11 Jan 2013 23:27:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Felix H. Dahlke" <fhd <at> ubercode.de>:
bug acknowledged by developer.
(Fri, 11 Jan 2013 23:27:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 8576-done <at> debbugs.gnu.org (full text, mbox):
> So, it's been a while. Anything I can do to help get this merged?
Sending such a `ping' is a great way to help ;-)
Installed, thank you, and sorry for the delay,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8576; Package
emacs.
(Sat, 12 Jan 2013 03:00:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 8576-done <at> debbugs.gnu.org (full text, mbox):
On 1/12/13 12:25 AM, Stefan Monnier wrote:
>> So, it's been a while. Anything I can do to help get this merged?
> Sending such a `ping' is a great way to help ;-)
> Installed, thank you, and sorry for the delay,
Nevermind, could have done so earlier :) Thanks for merging!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 09 Feb 2013 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.