From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.] Date: Tue, 22 Mar 2016 10:51:33 -0400 Message-ID: References: <20160311151512.GD2888@acm.fritz.box> <20160311212410.GG2888@acm.fritz.box> <73903215-f94b-e194-7bfe-0d6350c95769@yandex.ru> <20160311221540.GH2888@acm.fritz.box> <2c301ec9-041d-9172-d628-479062314b23@yandex.ru> <20160314151621.GF1894@acm.fritz.box> <874mc2dqtk.fsf@gmail.com> <87egb5cpmg.fsf@gmail.com> <87a8lsd4j3.fsf@gmail.com> <87twk0beuh.fsf@gmail.com> <877fgvgbr1.fsf@gmail.com> <87bn67eq4t.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458658325 25752 80.91.229.3 (22 Mar 2016 14:52:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Mar 2016 14:52:05 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 22 15:51:59 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aiNf3-0008Sk-FA for ged-emacs-devel@m.gmane.org; Tue, 22 Mar 2016 15:51:57 +0100 Original-Received: from localhost ([::1]:37585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiNf2-00049J-Vi for ged-emacs-devel@m.gmane.org; Tue, 22 Mar 2016 10:51:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiNeu-00047x-D3 for emacs-devel@gnu.org; Tue, 22 Mar 2016 10:51:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiNeq-0008QN-6R for emacs-devel@gnu.org; Tue, 22 Mar 2016 10:51:48 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:56948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiNep-0008Q6-Rt for emacs-devel@gnu.org; Tue, 22 Mar 2016 10:51:44 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aiNen-0008KY-It for emacs-devel@gnu.org; Tue, 22 Mar 2016 15:51:41 +0100 Original-Received: from 69-196-182-150.dsl.teksavvy.com ([69.196.182.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2016 15:51:41 +0100 Original-Received: from monnier by 69-196-182-150.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2016 15:51:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 123 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69-196-182-150.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:s4yOedtj2cGQd1ZYhvGdtZDK9MU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202070 Archived-At: > Noweb is not essential here. The story will hold for pretty much all > multi-modes with non-full-line headers. In noweb `< some_arg=4>>=` is a header of a chunk. Polymode places heads and tail > in their own modes because they are not conceptually part of nor host > or sub-mode. You can specify arbitrary parameters in the head which > might even instruct how to indent the chunk. The first code line > `some_call(blabla)` is placed on the same line with the head. This is > uncommon but it's the simplest real case I can think of. OK. > There are two issues here. Haha! > First one is how do you indent the head itself? Let's assume point is > after `foo`. If you follow the naive prog-indentation-context the > indentation should be handled by the mode in the head chunk, right? If it's got its own "chunk", then yes. > Let's call it noweb-head-mode. This mode is the same for many noweb > host-mode/inner-mode combinations and defaults to poly-head-tail-mode. OK. > Host mode is commonly LaTeX but it can be anything. OK. > One reasonable way to indent it is to use the host mode > indentation engine. Right, since the beginning of line is still in latex-mode, the "<>= some_call(blabla)" line would be indented by latex-mode. I.e. the generic code would go to BOL, and call latex-mode's indentation while setting prog-indentation-context with an "end of chunk" that's at point. > Note that this is in contrast of the prog-indentation-context > assumption for which PREVIOUS-CHUNK is assumed to be of the same mode > type as the current type. Not sure what PREVIOUS-CHUNK has to do with it. > The second issue is with respect to the first line immediately after the > header. Since it's not on its own line, I don't see why it would be an issue for indentation. > If you naively call inner mode indentation engine on that line in a > narrowed buffer starting after >>= you will get it indented to FIRST-COLUMN, That's also one of the reasons why I didn't want to impose narrowing in prog-indentation-context. > mode for indentation. Consider this example of erb mode taken from > https://github.com/fxbois/web-mode/blob/master/tests/demo.erb. > > IIUC, we have here a tight interleaving of lots of little chunks, alternating between HTML and ..[according to duckduckgo].. Ruby. > One meaningful approach here is to indent if-else-end block using inner mode > rules, right? Another approach would be to consider it as a sequence of chunks, rather than as chunks of one mode nested in another. So each chunk controls the FIRST-COLUMN of the next chunk. In any case, this seems messy. > 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. Ah, now I see a use of STRING-BEFORE and STRING-AFTER, thanks. This case of STRING-BEFORE being "\n" is very special: in SMIE, the core indentation function (smie-indent-calculate) basically behaves as if it's always called with STRING-BEFORE="\n". IOW, we could define prog-indent-function as always behaving "as if STRING-BEFORE was \n". In the normal case, the foo-calculate-indent function is called at the beginning of line anyway, so adding a STRING-BEFORE="\n" won't affect its behavior. As for STRING-AFTER, the example is compelling, but I don't yet understand really how it would all work out overall. I'm thinking of cases like: <% 3.times do %>
  • some text <% if signed_in? -%> <%= link_to t('.sign_out'), sign_out_path, :method => :delete %> <% else -%> <%= link_to t('.sign_in'), sign_in_path %> <% end -%>
  • <% end %> How should the "generic" code that links HTML and Ruby know when to indent using the HTML indentation code and when to use the Ruby indentation rules? Maybe my suggestion of considering it as a sequence of chunks (where each chunk controls the FIRST-COLUMN of the next chunk) could work, but it's far from obvious. Stefan