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: Thu, 14 Jun 2012 06:13:58 +0400 Message-ID: <4FD948E6.4010701@yandex.ru> References: <4FD9313D.70303@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 1339640057 17328 80.91.229.3 (14 Jun 2012 02:14:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 14 Jun 2012 02:14:17 +0000 (UTC) Cc: cyd@gnu.org, emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 14 04:14:14 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 1SezZX-0007lY-Cg for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2012 04:14:07 +0200 Original-Received: from localhost ([::1]:41666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SezZX-0000f2-6G for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2012 22:14:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SezZT-0000eq-EI for emacs-devel@gnu.org; Wed, 13 Jun 2012 22:14:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SezZR-0000sF-D2 for emacs-devel@gnu.org; Wed, 13 Jun 2012 22:14:02 -0400 Original-Received: from forward6.mail.yandex.net ([77.88.60.125]:42062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SezZN-0000r3-VY; Wed, 13 Jun 2012 22:13:58 -0400 Original-Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55]) by forward6.mail.yandex.net (Yandex) with ESMTP id B3CC011219F6; Thu, 14 Jun 2012 06:13:55 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1339640035; bh=aGPTlU4gikICMG0bYsu70vPuW/7JASr/NQLnfdEWlJw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fNxutM2L1lLZnrCHoMxgFXikC9rsfZ445t/LcMw889eeH9b+ukdkX4cfQthBKjQgy cCweF0MZLHEgf1R9WXorszrf8SqD0O91GyLHMAQHGCr4iCLBlPl0ntn6Tdjc1DwZGn Ufx7+hYYNJrpVCeHMPlfJCJmZq/EI9mp3Bjt5k5k= Original-Received: from smtp7.mail.yandex.net (localhost [127.0.0.1]) by smtp7.mail.yandex.net (Yandex) with ESMTP id 8529C15806FD; Thu, 14 Jun 2012 06:13:55 +0400 (MSK) Original-Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTP id DsemxjWQ-DteGkUaN; Thu, 14 Jun 2012 06:13:55 +0400 X-Yandex-Rcpt-Suid: lennart.borgman@gmail.com 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=1339640035; bh=aGPTlU4gikICMG0bYsu70vPuW/7JASr/NQLnfdEWlJw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OAUTRSiEn1xRpiMIK8ZX9SGq0+F2cYgJAvLCiuBj8FGfpzGNOTPkvpt0DBNmwhsje 8kuSoV1AL2vFgZNLylwFu52w9qbCJzWV+aXulM5MuYRvYqw4DqHIS0gNidYrfXRKT4 kLNXgKEFnRYvJXmOOCp8TU5IPx6OuxYn6P3F0XcE= 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.60.125 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:150940 Archived-At: On 14.06.2012 5:49, Lennart Borgman wrote: > On Thu, Jun 14, 2012 at 2:33 AM, Dmitry Gutov wrote: >> >> Lennart Borgman writes: >> >> >>> However it might not be worth the trouble. The real problem lies in >>> the Emacs C core. Parsing functions can currently not be stopped from >>> parsing things outside of the major mode chunk they belong too. >>> (mumamo.el goes a long way to try to address this problems as far as >>> possible. That makes the code quite complicated. A rewrite of the C >>> core makes things very simple. In addition to this rewrite of the >>> scheduling functions to add suitable tools for handling chunk finding >>> might be necessary, but that is much simpler.)=C2=A7 >> >> From what I know, mmm-mode counteracts this problem effectively enough, >> narrowing buffer to chunks during fontification, binding >> font-lock-dont-widen to t, etc. > > I am afraid that is a total misunderstanding. Narrowing etc does not > help because it does not affect all the functions involved. I must've mixed it up with multi-mode. mmm-mode does not indeed call narrow-to-region there, and instead calls respective font-lock-fontify-region-function's with chunk start and end positions. https://github.com/purcell/mmm-mode/blob/master/mmm-region.el#L793 >> Anyway, you've seen the list of my immediate gripes about how MuMaMo >> works for ERB, and I'm inclined to fault chunk detection > > Chunk detection must logically be done from the start of the file. In > the first version of MuMaMo I tried to do chunk detection from > anywhere in the file. That worked for simple cases but not for more > complicated cases so I rewrote this several years ago. > > I have no idea about what trouble you have had. Perhaps you could > describe them? (Maybe there are still pieces of code I have forgotten > to rewrite?) https://bugs.launchpad.net/nxhtml/+bug/946464 >> and indentation logic in your code > > Indentation is surpricingly hard actually. One problem is that you > have to do some language specific parsing (which the major mode > normally does). Another problem is getting this to work with chunks > and across chunks. There are several alternatives for this in > mumamo.el - and unfortunately I think there might some trouble there. One important thing that I'm almost certain your code doesn't do is set indent-line-function in all chunks to the same value. This function, when called, should save (- (current-column) (current-indentation)) value, to restore it after indentation if it's positive. Then it should go (back-to-indentation), look in what chunk the point is now, and act accordingly. > I suspect you have been looking at some of the easier cases. Please > take a look at the test cases. There should be more, but I think I > have written test cases for some of the troublesome cases. I posit that I've managed to make the examples from the bug above work better then they do with eruby-html-mumamo-mode, using lesser (I think?) amount of code. Nothing is perfect, of course, but all templates in my current projects I've tried yet have shown no problems.