From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id YO+LAbqvo2C+eQEAgWs5BA (envelope-from ) for ; Tue, 18 May 2021 14:14:50 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id yCj5OLmvo2C8XgAA1q6Kng (envelope-from ) for ; Tue, 18 May 2021 12:14:49 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D283611363 for ; Tue, 18 May 2021 14:14:48 +0200 (CEST) Received: from localhost ([::1]:47426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1liycZ-00081B-CY for larch@yhetil.org; Tue, 18 May 2021 08:14:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liyUz-0007ZU-S2 for emacs-orgmode@gnu.org; Tue, 18 May 2021 08:06:58 -0400 Received: from mout02.posteo.de ([185.67.36.66]:56451) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liyUt-00028Z-S8 for emacs-orgmode@gnu.org; Tue, 18 May 2021 08:06:57 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 59067240102 for ; Tue, 18 May 2021 14:06:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.eu; s=2017; t=1621339607; bh=AgM6owf4GsbNguQJxNxRP7Mb6YdkoQ6iLzNMEcX8xCw=; h=Subject:To:Cc:From:Date:From; b=Vg/wKFPv/CeXHsUcPo+tfzu/lq4NDbdl94JLaEoFE2kjzXXAGSkhP/wRk7aw8rIC8 J/LIbqx5qDuiJMdYaCI+IHvFUQrQHpH+9VgnUK9nigFv66iUKOzTTbEQr5TRAKfvwk fcnXj2sJluHYNl/TFXsotxqP41UbWEM3KRmY52MCChlFCvPm+8LK64v3VCYQxHruhT SsvUC9wyZ1Gngd5//LjSucPwL3Pr/ejBRoc6Hcjv01BbzxAk8JzIkpUYa5gbzXNcmm v2tQ7lSs+3Vi8x80bUn78aQuQLODC3c/cJ7U5VEGJogLXs4Ak/LkZ5Fo1qLOT0KBmq lXw+ltwvBdZzg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Fkvqp57vzz9rxG; Tue, 18 May 2021 14:06:46 +0200 (CEST) Subject: Re: [PATCH] Fontification for inline src blocks To: Timothy References: <87pmzf4bd0.fsf@gmail.com> <87pmye51a3.fsf@gmail.com> <87zgxcgaba.fsf@gmail.com> <878s4wtrzx.fsf@gmail.com> <87k0o419uh.fsf@gmail.com> <87o8dgdo7l.fsf@localhost> <87fsys102j.fsf@gmail.com> <87im3odk35.fsf@localhost> <87cztv29ff.fsf@gmail.com> From: =?UTF-8?Q?S=c3=a9bastien_Miquel?= Message-ID: Date: Tue, 18 May 2021 12:06:46 +0000 MIME-Version: 1.0 In-Reply-To: <87cztv29ff.fsf@gmail.com> Content-Type: multipart/alternative; boundary="------------90C822FCD43A48D772CE339F" Content-Language: fr Received-SPF: pass client-ip=185.67.36.66; envelope-from=sebastien.miquel@posteo.eu; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sebastien.miquel@posteo.eu Cc: org-mode-email Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1621340089; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=dz9H/3+4niaTF31mrYotgYUKMDW2uphb1NoKjHqOI10=; b=WQLaEep9UcwHp8ujMKUWWlrjkRzfCMFVLx5U7j0dn0iNCG7tM/SqeJLrup36b5l8CPBQPz NUaniyjsYUVR++OZ6Y3zNv1t9xYMET75da7kpthiNmgmSdi+isqFWvhZt49jKAHQQNE223 k9KruVaLbygl5V+6zLCf/dkMhE35Y1Ec6U4pysJ8VAbks5OPbKhPrBWe390o79KxL1IjYq ji2ZAX9t7nKsFxISAmWQy+zE8RRms+guRKGzLir3jN2Zwo+QxCZxaUuns/d/AA4cHribI8 aYrlPEKrRuT4dZOw3AyKCTC14Z7Kp2sF5yXxOc9ZyN8jeuTGJz/Pnf0p41Z5Hw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1621340089; a=rsa-sha256; cv=none; b=lCS16GRQRDBIt1eIPbzvf7jNI7V0oKzNP1qSVlnpYBjDNLG9X9dFJW8nDe8PQlKK4OLpZq +qOLrFfaECWCBCoIPtYXTXJdgODzD6N5p3+ieVw+7q+r6DSX8Je+nYkLMnxbSUpxWeNMZ3 dlPns/z1bK58tzaYFGyx/hEkJInbXmKTRuIWTcfMMkHPIzdgd9q6YtXn18bjieE5Hn4SxQ K+KUs7QpCYCvuCRAHI0UCFGekE2Futo5Uai98fiPgENIT7lYCV1OiN3zfzt7GUsRExaYAS 1xbYHTC1yPZZf94IDJfC/UjmXh4pPAinfEmUAxDyBZ5u340F4avlJSvIwavJwQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.eu header.s=2017 header.b="Vg/wKFPv"; dmarc=pass (policy=none) header.from=posteo.eu; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -3.14 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.eu header.s=2017 header.b="Vg/wKFPv"; dmarc=pass (policy=none) header.from=posteo.eu; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: D283611363 X-Spam-Score: -3.14 X-Migadu-Scanner: scn0.migadu.com X-TUID: BfWYjKmbLcT/ This is a multi-part message in MIME format. --------------90C822FCD43A48D772CE339F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Timothy, Thanks for your work. I hope this can be merged. Here are a few comments. Doesn't this line in ~org-toggle-inline-results-display~ throw the configured delimiters away when called twice ? : (setq org-inline-src-prettify-results (not org-inline-src-prettify-results)) I think the =org-block= face should only be applied to the actual code, note the =src_lang= part, nor the result. For normal src blocks, it is only used inside the block. The ~org-src-font-lock-fontify-block~ function could be modified to take an optional =inline= argument. When =t=, it should not set the =multiline= font property. Although this is very minor, it would allow one to easily advice this function to behave differently in inline src blocks. For example, to not use the =org-block= face in this case. I think the default parenthesis pair around results are bad. I much preferred your original brackets. Yes, as Tom said, they look alien, but alien is appropriate for use of ~prettify-symbols~. Since ~prettify-symbols~ seems to be raising some usability concerns, perhaps ~org-inline-src-prettify-results~ should default to ~nil~. It'd be unlike org to hide things from the user in the default configuration. As Tom points out, the two faces used (for the =src_= and bracket and the language part) should be customizable. The default value you chose are fine IMO. Perhaps the language one could also be used to highlight the language of normal src blocks, though It might be easier to use a single face. Timothy writes: >> P.S. Nitpick: You do not need to run fontification in while loops. Just >> fontifying next match before limit should be enough. Font-lock will call >> the function again if needed. > I'm guessing for this to work I'd need to return the final char > fortified? Or is the moving of point enough? > > Maybe related - I've noticed this doesn't seem to work with multiple > src_ blocks per line, might you have any insight here? You need only return =t= if some fontification has been done (and set point after the fontified part). If your function returns =t=, it will be called again. A case can be made for keeping the loop though. It works fine and is clearer since the aforementioned fontlock behaviour is poorly documented. Really, the only downside is the loss of consistency, since the function ~org-fontify-meta-lines-and-blocks-1~ doesn't loop. Regards, -- Sébastien Miquel --------------90C822FCD43A48D772CE339F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Timothy,

Thanks for your work. I hope this can be merged.

Here are a few comments.

Doesn't this line in ~org-toggle-inline-results-display~ throw the
configured delimiters away when called twice ?
: (setq org-inline-src-prettify-results (not org-inline-src-prettify-results))

I think the =org-block= face should only be applied to the actual
code, note the =src_lang= part, nor the result. For normal src blocks,
it is only used inside the block.

The ~org-src-font-lock-fontify-block~ function could be modified to
take an optional =inline= argument. When =t=, it should not set the
=multiline= font property. Although this is very minor, it would allow
one to easily advice this function to behave differently in inline src
blocks. For example, to not use the =org-block= face in this case.

I think the default parenthesis pair around results are bad. I much
preferred your original brackets. Yes, as Tom said, they look alien,
but alien is appropriate for use of ~prettify-symbols~.

Since ~prettify-symbols~ seems to be raising some usability concerns,
perhaps ~org-inline-src-prettify-results~ should default to ~nil~.
It'd be unlike org to hide things from the user in the default
configuration.

As Tom points out, the two faces used (for the =src_= and bracket and
the language part) should be customizable. The default value you chose
are fine IMO. Perhaps the language one could also be used to highlight
the language of normal src blocks, though It might be easier to use a
single face.

Timothy writes:
P.S. Nitpick: You do not need to run fontification in while loops. Just
fontifying next match before limit should be enough. Font-lock will call
the function again if needed.

I'm guessing for this to work I'd need to return the final char
fortified? Or is the moving of point enough?

Maybe related - I've noticed this doesn't seem to work with multiple
src_ blocks per line, might you have any insight here?

You need only return =t= if some fontification has been done (and set
point after the fontified part). If your function returns =t=, it will
be called again.

A case can be made for keeping the loop though. It works fine and is
clearer since the aforementioned fontlock behaviour is poorly
documented. Really, the only downside is the loss of consistency, since
the function ~org-fontify-meta-lines-and-blocks-1~ doesn't loop.

Regards,
-- 
Sébastien Miquel
--------------90C822FCD43A48D772CE339F--