From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Mon, 06 Apr 2020 11:29:41 -0400 Message-ID: References: <834ku43c61.fsf@gnu.org> <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@ACM> <20200404104553.GA5329@ACM> <07fe3b69-3ab2-3173-0696-cb17809e2b91@gmx.at> <83blo7v68b.fsf@gnu.org> <1845d7aa-9ae4-3d95-6a30-c7b1d8d8adec@gmx.at> <83a73qt6zs.fsf@gnu.org> <97c4254e-ff43-8402-3645-f713c408c245@gmx.at> <83y2r9syby.fsf@gnu.org> <1ac21874-3068-0c58-ce73-3a7297e67823@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="46731"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: acm@muc.de, Eli Zaretskii , rrandresf@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 06 17:32:02 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLTjF-000C0s-UU for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 17:32:01 +0200 Original-Received: from localhost ([::1]:33854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLTjE-0005q6-SK for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 11:32:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42589) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLThL-0003vr-5c for emacs-devel@gnu.org; Mon, 06 Apr 2020 11:30:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLThK-0005Sh-6Z for emacs-devel@gnu.org; Mon, 06 Apr 2020 11:30:03 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33862) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jLTh3-0005JH-Ad; Mon, 06 Apr 2020 11:29:45 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 75EB581148; Mon, 6 Apr 2020 11:29:44 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EB67F80BAF; Mon, 6 Apr 2020 11:29:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1586186982; bh=w6T+9Nn7dWJyBBskdUt+LeJHFQj0U4QLeBoCs+ayow0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=gtcsSehm5EXzbangzxikcjRqrvsJRVaOHLDLohRkmiGcz/UGc9blkyjqfBORSaA2x gP64yreARZliZ8smIt+jwmbz/Kbe21Xl+YF/0Mm/seWtI9DeGOi9JOLkaloYNQK84B qKXMbHXfuLaB+Q6UjzL1ll9THE4yJbNkwhFjFaROKChVdhTkzNmc48IQ39oOHKDQ3h t0Tkqj+JrwVWcPA0vbXH9g1Ak1pzGG+ZTiQVcyp+mh4apwj9SXIOq0EH6MFK5n/DJi MBKJFK+lb3LnsIOWBGE4i0pogB3LXYFyNney/YhUdNSBaSVygA3mgWQnankE2sUiAK qNP38tYWOq1Pg== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9AF9612079C; Mon, 6 Apr 2020 11:29:42 -0400 (EDT) In-Reply-To: <1ac21874-3068-0c58-ce73-3a7297e67823@gmx.at> (martin rudalics's message of "Mon, 6 Apr 2020 11:05:11 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246535 Archived-At: > As long as we are not there (and IMO even after that) Emacs should be > able to do its SMIE parsing in a practical way: Restrict backward and > forward parsing to the smallest reasonable code fragment around point. > And reasonable would mean the smallest enclosing fragment delimited by > two parens in column zero it can find in either direction (which can be > still quite large when viewing functions like redisplay_internal). Could people refrain from "X should do Y" when they have no idea how X currently works? SMIE's indentation works by parsing backward, so that it stops parsing as soon as it found the info needed to determine the indentation to use. It almost always stops long before reaching the nearest "open paren in column 0". Stefan