From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: highlight-indent-guides in display engine Date: Tue, 16 Jul 2019 09:06:28 +0100 Message-ID: References: <83h87r2wpk.fsf@gnu.org> <20190712185100.omyyovxh5hqzpk5z@Ergus> <83v9w61ktg.fsf@gnu.org> <878st249o1.fsf@fastmail.fm> <83ims61g80.fsf@gnu.org> <87o91xfwfo.fsf@fastmail.fm> <20190714125618.wlmansy26d6nstmy@Ergus> <20190715141107.sygnfsikmyeuzg3w@Ergus> <20190715171024.bourqcythaqnfd4m@Ergus> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="107523"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: K-9 Mail for Android Cc: Joost Kremers To: emacs-devel@gnu.org, Stefan Monnier , Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 16 10:06:41 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hnITx-000RpQ-FV for ged-emacs-devel@m.gmane.org; Tue, 16 Jul 2019 10:06:41 +0200 Original-Received: from localhost ([::1]:46094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hnITw-0006Qn-Db for ged-emacs-devel@m.gmane.org; Tue, 16 Jul 2019 04:06:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57329) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hnITp-0006Qf-G1 for emacs-devel@gnu.org; Tue, 16 Jul 2019 04:06:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hnITo-0007lX-2Q; Tue, 16 Jul 2019 04:06:32 -0400 Original-Received: from 93-97-98-66.zone5.bethere.co.uk ([93.97.98.66]:53155 helo=Samsung-Galaxy-S7.lan) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1hnITm-0001cc-3A; Tue, 16 Jul 2019 04:06:31 -0400 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238608 Archived-At: On July 15, 2019 7:43:24 PM GMT+01:00, Stefan Monnier wrote: > > If it works also for lisp, better then, my concern was that in case > > there are things like: > > > > (setq > > isearch-adjusted nil > > isearch-yank-flag nil) > > > > or `cond', where the indentation is usually one space instead of 2, > it > > may become more confusing than beneficial=2E >=20 > My point is that those same kinds of problem can show up in any > major mode=2E It may work better in some modes than others, but it's > a question of degree, not a binary "works / doesn't work": >=20 > int main () > { > x =3D (3 + > (tmp =3D y + 1, > (4 + > 5 + > 6))); > } >=20 >=20 >=20 > Stefan I'm all for supporting these use cases, of course, and welcome ideas for h= ow to do that without significantly slowing down redisplay by looking far b= ack in the buffer=2E