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 18:24:12 +0400 Message-ID: <4FD9F40C.90406@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1339683888 10643 80.91.229.3 (14 Jun 2012 14:24:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 14 Jun 2012 14:24:48 +0000 (UTC) Cc: cyd@gnu.org, lennart.borgman@gmail.com, emacs-devel@gnu.org To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 14 16:24:44 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 1SfAyR-0001Hg-GE for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2012 16:24:35 +0200 Original-Received: from localhost ([::1]:47718 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfAyR-0003HT-8q for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2012 10:24:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfAyJ-0003Fc-L1 for emacs-devel@gnu.org; Thu, 14 Jun 2012 10:24:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfAyD-0001Ft-Eh for emacs-devel@gnu.org; Thu, 14 Jun 2012 10:24:27 -0400 Original-Received: from forward10.mail.yandex.net ([77.88.61.49]:36500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfAy5-0001EC-13; Thu, 14 Jun 2012 10:24:13 -0400 Original-Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward10.mail.yandex.net (Yandex) with ESMTP id 96A0810209C0; Thu, 14 Jun 2012 18:24:10 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1339683850; bh=nSaRp3xaAwjz2avWCRDr6X0NwSajLbTrdH2K5XhMNzs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=bVjlV0h7UfL3qNmdud2OgukdzhpE/YnNe8IbM39cU/LdH1NNy4qbnsMela4JqpWeQ lko9z6cWZMz8Thokl0fCcMzlbnw9n8mkl6+A3t5yq8dddbjqGvciZOkzly4UoJW6nq JRKC2WtPapmp4MvsJberOv+ZhQzStHKvlYvi+qr0= Original-Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id 544121520648; Thu, 14 Jun 2012 18:24:10 +0400 (MSK) Original-Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTP id O7suXDao-OAs8ru86; Thu, 14 Jun 2012 18:24:10 +0400 X-Yandex-Rcpt-Suid: monnier@iro.umontreal.ca X-Yandex-Rcpt-Suid: cyd@gnu.org X-Yandex-Rcpt-Suid: lennart.borgman@gmail.com X-Yandex-Rcpt-Suid: emacs-devel@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1339683850; bh=nSaRp3xaAwjz2avWCRDr6X0NwSajLbTrdH2K5XhMNzs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type:Content-Transfer-Encoding; b=qaGzUJQBjaxSiKa8Xh2bcAC4MXJt+qCjTUiiYHwxFwUVCfrXkm1a5ugxEDDgksPTM LqoblC5MT8efQXh+pgf8SUAzEGY6skbExYRO4n1b0UO9uUK/n67UE5cfpCq23GDtfs T+IjlVffTv2fuH3tmbOMEgCfGkLDS+acNdxdl3ac= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 77.88.61.49 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:150943 Archived-At: 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? 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). 2) sgml-indent-line calls sgml-parse-tag-backward, which does (re-search-backward "[<>]"), finds "<" and performs simple regexp check. Thus, <% if a < 3 %> breaks indentation on following lines, until first closing tag. So it's 3 built-in functions as candidates for special interaction with new syntax-table value. > 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. Did you mean to write "C code" in the first sentence? As far as I can see, enhanced (forward-comment) won't help much with indentation. And crossing two boundaries won't necessarily mean that we're in a chunk in the same mode (or we're limited to supporting only two modes in the same buffer), so that means syntax-table values can't be trivial. Cons cell (mode-above . mode-below), and related code will need to consider movement direction?