|
From: | Dmitry Gutov |
Subject: | Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.] |
Date: | Tue, 22 Mar 2016 00:55:30 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 |
On 03/21/2016 06:45 PM, Vitalie Spinu wrote:
Real trouble comes with continuation chunks. You might need to have a completely reversed indentation logic - in outer/host spans MM engine needs to call inner mode for indentation. Consider this example of erb mode taken from https://github.com/fxbois/web-mode/blob/master/tests/demo.erb. <div id='header'> <% if signed_in? -%> <%= link_to t('.sign_out'), sign_out_path, :method => :delete %> <% else -%> <%= link_to t('.sign_in'), sign_in_path %> <% end -%> </div>
FWIW, I've successfully implemented indentation for ERB (and EJS) files without delegating to ruby-mode and js-mode indentation code:
https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-erb.el#L157-L225 (it indents web-mode's example almost identically)It should be easy to add support for similar types of files with almost the same code. But yes, it implies adding support for each new template format manually.
One meaningful approach here is to indent if-else-end block using inner mode rules, right? This is what web-mode seems to be currently doing. Assume you are just in front of `<%= link_to`. This is host hmtl mode. But you need to indent according to inner mode construct. So what do you do? You go to the end of previous code chunk and call prog-indentation-function of inner mode with STRING-BEFORE = "\n" and STRING-AFTER="link_to t('.sign_out'), sign_out_path, :method => :delete". Simple isn't it? That's precisely my proposal.
It's simpler for the caller, but I'm having hard time imagining how to implement it properly on a major mode's side without inserting those strings into the buffer, or using a temporary buffer.
If STRING-BEFORE and STRING-AFTER are not allowed to contain newlines, yes, that becomes easier to handle, but that also loses in generality.
[Prev in Thread] | Current Thread | [Next in Thread] |