From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: web-mode.el Date: Fri, 15 Jun 2012 07:24:10 +0400 Message-ID: <4FDAAADA.1030609@yandex.ru> References: <4FD9F40C.90406@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1339730665 1425 80.91.229.3 (15 Jun 2012 03:24:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2012 03:24:25 +0000 (UTC) Cc: cyd@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 15 05:24:22 2012 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 1SfN92-0005AR-DQ for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2012 05:24:20 +0200 Original-Received: from localhost ([::1]:52733 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfN92-0000TH-98 for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2012 23:24:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfN8z-0000T9-98 for emacs-devel@gnu.org; Thu, 14 Jun 2012 23:24:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfN8w-0003Dl-F3 for emacs-devel@gnu.org; Thu, 14 Jun 2012 23:24:16 -0400 Original-Received: from forward8.mail.yandex.net ([77.88.61.38]:60011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfN8s-0003D9-Px; Thu, 14 Jun 2012 23:24:11 -0400 Original-Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward8.mail.yandex.net (Yandex) with ESMTP id 64235F61717; Fri, 15 Jun 2012 07:24:08 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1339730648; bh=lA+vKXsYVWvf7rr4d4bs2CUtIRiwMRhcrYI1W4GUQCI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=R/T5pVfpVgdxi+Ytk1I7btGs1PbR1RqA2taXvcIS9QVUAlw3vh4mhBrQd7LVfJCWk zOK39nbMGNDHpBz4H4RIvBDXMKN1+soBPOLhfDTgOX4BREqVKHW04it/7fANyksO3e aOr4jBjYBn2YsJZ1vbHpmm8eDVatox5zWXqQnzuw= Original-Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id 2268A1B6033A; Fri, 15 Jun 2012 07:24:08 +0400 (MSK) Original-Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTP id O7c027mV-O7c0i2ve; Fri, 15 Jun 2012 07:24:07 +0400 X-Yandex-Rcpt-Suid: lennart.borgman@gmail.com X-Yandex-Rcpt-Suid: monnier@iro.umontreal.ca X-Yandex-Rcpt-Suid: cyd@gnu.org X-Yandex-Rcpt-Suid: emacs-devel@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1339730648; bh=lA+vKXsYVWvf7rr4d4bs2CUtIRiwMRhcrYI1W4GUQCI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gXI/Mj8XepYQw9M/N4lLxfVbseWWg2Fz76k4m/dmtCfkWp0njzq/oZj98Ca/RVBDi nwBY24V+C/3PjRzdmbZ5VL8SwHGKQj4tDl/8aVLO2gledMZIqkjfwabM1N19IfScml zRwMHTneasewSpEfnmtqO1Tao6RuvHxobBi5DXu0= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 77.88.61.38 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:150956 Archived-At: On 14.06.2012 20:54, Lennart Borgman wrote: > On Thu, Jun 14, 2012 at 4:24 PM, Dmitry Gutov wrote: >> Stefan Monnier writes: >>>> I'm also using narrowing during indentation, but some modes (like js) >>>> use (widen) in indent-line-function. It should be somewhat fixable by >>> >>> I don't think it's worthwhile trying to make a "multi-major-mode" that >>> works with any major mode, no matter what wicked thing it does. >>> So it's OK to impose a few conventions that the major mode needs >>> to obey. The important and difficult part is to figure what those >>> conventions need to be. >> >> I agree in principle. And since fontification of chunks can already be >> done reliably enough (if not with best performance), I think indentation >> function conventions would be more important. Shall we start with >> collecting cases? > > I am not sure I agree. The way I have proposed to do it is to change > the low level functions reading the buffer so that you can lie to them > and say that the chunks in other major modes are just whitespace+line > feeds. It would be reliable (I think), but it requires much effort so > it still may not be worth it. Fully isolating the chunks might not be the best course of action, even if it were not too hard to do. For example, if we want to adjust indentation inside <% if %> <% end%> blocks, we need to be able to actually look inside them while we're in the primary mode chunk (between those two). > I took a look at what I had done so far (it was some time ago now). I > have not touched the C code. I have only made some changes in > mumamo.el towards this goal. > > As Dmitry says, fontification is rather simple (but you have to be > careful to make it fast). Indentation is harder. > > First of all I have tried to write down the logic to use. I have > rewritten that part a few times. Even this was harder then I expected. > You can see my current comments here in mumamo-indent-line-function-1 > (at line 7915 currently): > > http://bazaar.launchpad.net/~nxhtml/nxhtml/main/view/head:/util/mumamo.el > > Second I have moved towards doing indentation the way it should have > been done if the changes in the C code were done. I do this by copying > the code to a mirror buffer, replacing everything in "other" chunks > with whitespace+line feeds. > > It is easy to get things a bit wrong when you do this of course. I am > not sure if the problem you have seen, Dmitry, is because (1) failed > to copy correctly, (2) the idea is somehow buggy, or (3) I just did > not implement all cases or did not finish implementing them. I don't think I understand the code enough to answer that, but I'm inclined to fault implementation (not necessarily of the stage you described above). For example, one of the problems shows that indentation function behaves differently, depending on where inside the (same) line the point is. As an aside, this bit from the docstring sounds not very useful, maybe even harmful: "- However first non-empty line indentation in a chunk when going in is special if prev-prev chunk is on same mumamo-depth and have the same major mode. Then indent relative last non-empty line in prev-prev chunk." >> So far I have two problems without obvious solutions: >> >> 1) js-mode uses (widen) at the beginning of js-indent-line, and then calls >> (syntax-ppss). > > There are several modes for javascript. And of course for html too; > nxml-mode is one. Stopping nxml-mode from crossing the chunks > boundaries is not easy. js2-mode's indentation function is very similar to js-mode, since they're both derived from an javascript-mode. It doesn't work in multi-mode context, though, and while fixing that shouldn't be too hard, I'm not sure it's worth spending time on, because js2-mode's advantages over js-mode are most evident with larger files, not small snippets. I have yet to look into using nxml as primary mode. Do you have any suggestions how that could be made easier? >>> 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. > > I have tried to implement something like that in mumamo.el, but I > think it is not working correctly anymore. Something might have > changed since I did that. Could you show where this is implemented?