[Top][All Lists]

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

Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss return

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

    <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 -%>

FWIW, I've successfully implemented indentation for ERB (and EJS) files without delegating to ruby-mode and js-mode indentation code:


(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.

reply via email to

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