unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: cyd@gnu.org, lennart.borgman@gmail.com, emacs-devel@gnu.org
Subject: Re: web-mode.el
Date: Fri, 15 Jun 2012 05:40:13 +0400	[thread overview]
Message-ID: <4FDA927D.50306@yandex.ru> (raw)
In-Reply-To: <jwv7gv97qne.fsf-monnier+emacs@gnu.org>

On 14.06.2012 21:28, Stefan Monnier wrote:
>> 1) js-mode uses (widen) at the beginning of js-indent-line, and then calls
>> (syntax-ppss).
>
> Depending on how multi-major-mode works, widen is not necessarily
> a problem.  Clearly, it would need to hook into syntax-ppss.

That's good.

>> 2) sgml-indent-line calls sgml-parse-tag-backward, which does
>> (re-search-backward "[<>]"), finds "<" and performs simple regexp check.
>> Thus,<% if a<  3 %>  breaks indentation on following lines, until first
>> closing tag.
>
> I think we can treat this as a bug in sgml-indent-line, which should try
> and use syntax-ppss or something like that instead of regexps.

I wonder how that could be fixed exactly. parse-partial-sexp doesn't 
look helpful, because it works with single characters, and sgml is 
concerned with full tags. It also has to handle unclosed tags like <br>, 
some closing tags are optional, and HTML 4 has self-closing tags.

>>> Of course, tweaking some parts of the C mode might help.  E.g. we could
>>> maybe extend syntax-tables slightly so that chunk boundaries are marked
>>> with a special syntax-table value which then makes forward-comment skip
>>> over "other language" chunks, so that any indentation code which
>>> consistently ignores comments would then work in multi-major-mode.

>> As far as I can see, enhanced (forward-comment) won't help much with
>> indentation.
>
> It would, if you combine it with parse-sexp-ignore-comments.

If parse-partial-sexp just starts from (point-min), and then skips over 
"comments", it will never visit submode regions this way, no?

Another thing to consider - having "visibility" into previous chunks of 
the same submode may be more harmful than useful in some cases.
For example, when indenting the chunk in the middle,

   <% if true %>
     <div><%=
       some_text
     %></div>
   <% end %>

the chunk will see the "if" statement, and decide that it should be 
indented only 2 spaces from. And since it does do some indenting, I 
can't with my current heuristic decide that it should be instead 
indented relative to the line 2.

This is kinda handwavy, the example is contrived, the heuristic could be 
improved (suggestions welcome), but this could become more important for 
some other combinations of modes.

Also, if I have an extra paren inside some <script> tag, I, as a user, 
might be surprised to see JS code code inside another <script> tag down 
below indent weirdly.

>> And crossing two boundaries won't necessarily mean that we're in a chunk
>> in the same mode (or we're limited to supporting only two modes in the
>> same buffer), so that means syntax-table values can't be trivial.
>> Cons cell (mode-above . mode-below), and related code will need
>> to consider movement direction?
>
> Something like (mode-above . mode-below) is what I had in mind, yes.
>
>
>          Stefan
>
>




  reply	other threads:[~2012-06-15  1:40 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-14 14:24 web-mode.el Dmitry Gutov
2012-06-14 16:54 ` web-mode.el Lennart Borgman
2012-06-15  3:24   ` web-mode.el Dmitry Gutov
2012-06-16  1:43     ` web-mode.el Lennart Borgman
2012-06-16 13:19       ` web-mode.el Dmitry Gutov
2012-06-16 13:30         ` web-mode.el Lennart Borgman
2012-06-19  1:18           ` web-mode.el Dmitry Gutov
2012-06-19  1:56             ` web-mode.el Lennart Borgman
2012-06-19 16:04               ` web-mode.el Dmitry Gutov
2012-06-14 17:28 ` web-mode.el Stefan Monnier
2012-06-15  1:40   ` Dmitry Gutov [this message]
2012-06-16  6:17     ` web-mode.el Stefan Monnier
2012-06-16 10:55       ` web-mode.el Lennart Borgman
2012-06-16 13:27       ` web-mode.el Dmitry Gutov
2012-06-16 13:32         ` web-mode.el Lennart Borgman
2012-06-18  1:49         ` web-mode.el Stefan Monnier
2012-06-19  1:00           ` web-mode.el Dmitry Gutov
2012-06-19  3:09             ` web-mode.el Stefan Monnier
2012-06-19 10:39               ` web-mode.el Lennart Borgman
2012-06-20  2:01               ` web-mode.el Dmitry Gutov
2012-07-31  8:46                 ` web-mode.el Lennart Borgman
  -- strict thread matches above, loose matches on Subject: below --
2012-06-14  0:33 web-mode.el Dmitry Gutov
2012-06-14  1:49 ` web-mode.el Lennart Borgman
2012-06-14  2:13   ` web-mode.el Dmitry Gutov
2012-06-14  3:23 ` web-mode.el Stefan Monnier
2012-06-15  8:34   ` web-mode.el Vitalie Spinu
2012-06-15  9:23     ` web-mode.el Lennart Borgman
2012-06-15  9:41       ` web-mode.El Vitalie Spinu
2012-06-16  1:37         ` web-mode.El Lennart Borgman
2012-06-11 22:24 web-mode.el Bois Francois-Xavier
2012-06-12 11:37 ` web-mode.el Lennart Borgman
2012-06-12 13:23   ` web-mode.el Bois Francois-Xavier
     [not found]   ` <CAK1xyPN=7To8ZsznHdjhDO=pd_8MocAqWXzSSrFJNe=uHRwp9g@mail.gmail.com>
2012-06-12 13:24     ` web-mode.el Lennart Borgman
2012-06-12 13:45       ` web-mode.el Bois Francois-Xavier
2012-06-13  7:45 ` web-mode.el Chong Yidong
2012-06-13  8:39   ` web-mode.el Bois Francois-Xavier
2012-07-31  8:41     ` web-mode.el Steinar Bang
2012-06-13 10:36   ` web-mode.el Lennart Borgman
2012-06-13 10:49     ` web-mode.el Bois Francois-Xavier
2012-06-13 10:55       ` web-mode.el Lennart Borgman
2012-06-13 11:43         ` web-mode.el Bois Francois-Xavier
2012-06-13 11:52           ` web-mode.el Lennart Borgman
2012-06-13 12:30     ` web-mode.el Stefan Monnier
2012-06-13 12:37       ` web-mode.el Lennart Borgman
2012-06-13 10:37   ` web-mode.el Dmitry Gutov
2012-06-13 10:46     ` web-mode.el Lennart Borgman
2012-06-13 10:26 ` web-mode.el Dmitry Gutov
2012-06-13 14:18 ` web-mode.el Richard Riley

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=4FDA927D.50306@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=cyd@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /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).