From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pontus Michael Subject: [PATCH] Source block fontification handling indentation Date: Wed, 26 Feb 2014 20:38:28 +0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a11c3462ea218fb04f351d59e Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIhVA-0008PY-8B for emacs-orgmode@gnu.org; Wed, 26 Feb 2014 11:38:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIhV9-0001XS-2p for emacs-orgmode@gnu.org; Wed, 26 Feb 2014 11:38:32 -0500 Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:61922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIhV8-0001X1-Lc for emacs-orgmode@gnu.org; Wed, 26 Feb 2014 11:38:31 -0500 Received: by mail-lb0-f180.google.com with SMTP id 10so801856lbg.39 for ; Wed, 26 Feb 2014 08:38:28 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --001a11c3462ea218fb04f351d59e Content-Type: multipart/alternative; boundary=001a11c3462ea218f704f351d59c --001a11c3462ea218f704f351d59c Content-Type: text/plain; charset=ISO-8859-1 I make a change to function which copies contents of source code block to temporary buffer, applies fontification through the means of relevant major mode and transcribes text-properties back to org-buffer so that they are applied on top of code in affected source code block. Primary reason for this change is to fix the problem which I describe as follows: This function is not 100% compatible with a org-edit-src facility, which provides an option to have indentation added to the code inside the block after using command `org-edit-src-code' to edit it. This command also handles removal of indentation upon insertion of the code in temporary buffer where editing of the code will in relevant major-mode. This behavior indicates presence of indentation to be irrelevant outside the context of org-buffer, and in some instances (e.g. diff-mode) presence of indentation may render the code incompatible with semantics of it's language. Here's a couple of points which guided me to implement the change in this particular way: Section of code which mirrors the fontification from temporary to org-buffer updates variable `start' for each fontified segment, allowing it to remain relevant as a value which, when added to the position of point in temporary buffer, will find position of that point mirrored upon source block in org-buffer. This variable follows same principle if `org-src-preserve-indentation' option is enabled. Segments of text fontified to be spanning several lines are broken in fashion that forces section to end at the newline and continue after the indentation. This approach prevents indentation characters to be colored in chaotic fashion when changes in background are used for fontification, e.g. diff-mode with standard emacs theme. --- lisp/org-src.el | 9 +++++++++ 1 file changed, 9 insertions(+) --001a11c3462ea218f704f351d59c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I make a change to function which copies contents of source code
block to temporary buffer, applies fontification through the means of
relevant major mode and transcribes text-properties back to org-buffer
so that they are applied on top of code in affected source code block.
Primary reason for this change is to fix the problem which = I describe as
follows:

This function is not 100% compatible with a org-edit-src facility, which provides an option to have indentation added to the code inside
the block after using command `org-edit-src-code' to edit it. This
command also handles removal of indentation upon insertion of the code
in temporary buffer where editing of the code will in relevant
major-mode.

This behavior indicates presence of indentation to be irrelevant
outside the context of org-buffer, and in some instances
(e.g. diff-mode) presence of indentation may render the code
incompatible with semantics of it's language.

Here's a couple of points which guided me to implement the change= in
this particular way:

Section of code which mirrors the fontification from temporary to
org-buffer updates variable `start' for each fontified segment, allowin= g
it to remain relevant as a value which, when added to the position of=
point in temporary buffer, will find position of that point mirrored
upon source block in org-buffer. This variable follows same principle if `org-src-preserve-indentation' option is enabled.

Segments of text fontified to be spanning several lines are broken in
fashion that forces section to end at the newline and continue after = the
indentation. This approach prevents indentation characters to be colored in chaotic fashion when changes in background are used for
fontification, e.g. diff-mode with standard emacs theme.
---
=A0lisp/org-src.el | 9 +++++++++
=A01 file changed, 9 insertions(+)


--001a11c3462ea218f704f351d59c-- --001a11c3462ea218fb04f351d59e Content-Type: text/x-patch; charset=US-ASCII; name="0001-Source-block-fontification-handeling-indentation.patch" Content-Disposition: attachment; filename="0001-Source-block-fontification-handeling-indentation.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: d4b70c72a4daa4a8_0.1 ZGlmZiAtLWdpdCBhL2xpc3Avb3JnLXNyYy5lbCBiL2xpc3Avb3JnLXNyYy5lbA0KaW5kZXggZDFm Njg3OS4uZGQzZjNjMiAxMDA2NDQNCi0tLSBhL2xpc3Avb3JnLXNyYy5lbA0KKysrIGIvbGlzcC9v cmctc3JjLmVsDQpAQCAtOTIyLDEwICs5MjIsMTkgQEAgZm9udGlmaWNhdGlvbiBvZiBjb2RlIGJs b2NrcyBzZWUgYG9yZy1zcmMtZm9udGlmeS1ibG9jaycgYW5kDQogCSAgICAgICAoY29uY2F0ICIg b3JnLXNyYy1mb250aWZpY2F0aW9uOiIgKHN5bWJvbC1uYW1lIGxhbmctbW9kZSkpKQ0KIAkgICAg KGRlbGV0ZS1yZWdpb24gKHBvaW50LW1pbikgKHBvaW50LW1heCkpDQogCSAgICAoaW5zZXJ0IHN0 cmluZyAiICIpIDs7IHNvIHRoZXJlJ3MgYSBmaW5hbCBwcm9wZXJ0eSBjaGFuZ2UNCisJICAgICh1 bmxlc3Mgb3JnLXNyYy1wcmVzZXJ2ZS1pbmRlbnRhdGlvbiAob3JnLWRvLXJlbW92ZS1pbmRlbnRh dGlvbikpDQogCSAgICAodW5sZXNzIChlcSBtYWpvci1tb2RlIGxhbmctbW9kZSkgKGZ1bmNhbGwg bGFuZy1tb2RlKSkNCiAJICAgIChmb250LWxvY2stZm9udGlmeS1idWZmZXIpDQogCSAgICAoc2V0 cSBwb3MgKHBvaW50LW1pbikpDQogCSAgICAod2hpbGUgKHNldHEgbmV4dCAobmV4dC1zaW5nbGUt cHJvcGVydHktY2hhbmdlIHBvcyAnZmFjZSkpDQorCSAgICAgICh1bmxlc3Mgb3JnLXNyYy1wcmVz ZXJ2ZS1pbmRlbnRhdGlvbg0KKwkJKGxldCAoKGVvbCAoc2F2ZS1leGN1cnNpb24gKGdvdG8tY2hh ciBwb3MpDQorCQkJCQkgICAobGluZS1lbmQtcG9zaXRpb24pKSkpDQorCQkgICh3aXRoLWN1cnJl bnQtYnVmZmVyIG9yZy1idWZmZXINCisJCSAgICAoZ290by1jaGFyICgrIHN0YXJ0ICgxLSBwb3Mp KSkNCisJCSAgICAoc2V0cSBzdGFydCAoLSAobGluZS1lbmQtcG9zaXRpb24pICgxLSBlb2wpKSkp DQorCQkgICh3aGVuICg8IGVvbCBuZXh0KQ0KKwkJICAgIChzZXRxIG5leHQgKDErIGVvbCkpKSkp DQogCSAgICAgIChwdXQtdGV4dC1wcm9wZXJ0eQ0KIAkgICAgICAgKCsgc3RhcnQgKDEtIHBvcykp ICgxLSAoKyBzdGFydCBuZXh0KSkgJ2ZhY2UNCiAJICAgICAgIChnZXQtdGV4dC1wcm9wZXJ0eSBw b3MgJ2ZhY2UpIG9yZy1idWZmZXIpDQo= --001a11c3462ea218fb04f351d59e--