[PATCH] (cosmetic) improving block declaration colors
Hi,
from org 9.5.3-g69c588
PATCH 1/2:
Having several programming books converted to org,
I read a lot of begin/end_src expressions. The
following patch helps lessen the visibility of
those terms: they are syntax tokens and can be
replaced my colors.
So this gives different faces to the language
specifiers and begin_ words, to attenuate
begin_/end_src and emphasize the language selected.
The picture in the attachment shows how source
blocks get rendered then. Don't mind too much
the "begin_quote" on it, as it's intended to
be "begin_src" under normal circumstances.
PATCH 2/2:
org/lisp/org.el::4966
#+begin_src elisp
;; Set face extension as requested. FIXME
;; (org--set-faces-extend '(org-block-begin-line org-block-end-line)
;; org-fontify-whole-block-delimiter-line)
#+end_src
I turned off those two lines otherwise the extend
property of org-block-begin-line and org-block-end-line
would keep coming back even after customizing them
("but I just did untick that box!")
When org-fontify-whole-block-delimiter-line is set to nil,
the block background start after /#+begin_src elisp/.
When it isn't set, an underline will run all over the line.
have a nice day,
Phil
From c6e0bf2b4753608467bf9d545f62cc1d79bda80f Mon Sep 17 00:00:00 2001
From: Phil Estival
Date: Wed, 8 Jun 2022 08:24:00 +0200
Subject: [PATCH 1/2] (cosmetic) distinct faces in block declaration when is
language set
---
lisp/org-faces.el | 12
lisp/org.el | 21 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index d96898372..96e190a17 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -455,6 +455,18 @@ verse and quote blocks are fontified using the `org-verse' and
"Face used for the line delimiting the end of source blocks."
:group 'org-faces)
+(defface org-block-begin-src '((t (:inherit org-block-begin-line)))
+ "Face used for the begin_term of source blocks."
+ :group 'org-faces)
+
+(defface org-block-lang '((t (:inherit org-block-begin-line)))
+ "Face used for the language of source blocks."
+ :group 'org-faces)
+
+(defface org-block-switches '((t (:inherit org-block-begin-line)))
+ "Face used for the switches and headers arguments of source blocks."
+ :group 'org-faces)
+
(defface org-verbatim '((t (:inherit shadow)))
"Face for fixed-with text like code snippets."
:group 'org-faces
diff --git a/lisp/org.el b/lisp/org.el
index 1fc4251a3..c7de64b81 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4964,7 +4964,7 @@ The following commands are available:
(set-face-foreground 'org-hide foreground)))
;; Set face extension as requested.
(org--set-faces-extend '(org-block-begin-line org-block-end-line)
- org-fontify-whole-block-delimiter-line)
+ org-fontify-whole-block-delimiter-line)
(org--set-faces-extend org-level-faces org-fontify-whole-heading-line))
;; Update `customize-package-emacs-version-alist'
@@ -5291,6 +5291,8 @@ by a #."
;; after the end of block content.
(block-start (match-end 0))
(block-end nil)
+(lang-begin (match-beginning 7))
+(lang-end (match-end 7))
(lang (match-string 7)) ; The language, if it is a source block.
(bol-after-beginline (line-beginning-position 2))
(dc1 (downcase (match-string 2)))
@@ -5346,10 +5348,19 @@ by a #."
((string= block-type "verse")
(add-face-text-property
bol-after-beginline beg-of-endline 'org-verse t)))
- ;; Fontify the #+begin and #+end lines of the blocks
- (add-text-properties
- beg (if whole-blockline bol-after-beginline end-of-beginline)
- '(face org-block-begin-line))
+ ;; Fontify the #+begin and #+end lines of the blocks
+ (if (string= lang "")
+ (add-text-properties
+ beg (if whole-blockline bol-after-beginline end-of-beginline)
+ '(face org-block-begin-line))
+ ;; when language is set, fontify separately
+ ;; begin_[src], language and switches
+ (and (add-text-properties beg lang-begin
+'(face org-block-begin-src))
+ (add-text-properties lang-begin lang-end
+'(face org-block-lang))
+ (add-text-properties lang-end bol-after-beginline
+'(face org-block-switches
(unless (eq (char-after beg-of-endline) ?*)
(add-text-properties
beg-of-endline
--
2.31.GIT
From b80d37d57d71a747e113ec56fa10aacb0bd750d4 Mon Sep 17 00:00:00 2001
From: Phil Estival
Date: Wed, 8 Jun 2022 08:26:56 +0200
Subject: [PATCH 2/2] prevent org-fontify-whole-block-delimiter-line to
override extend
---
lisp/or
Re: [DISCUSSION] Refactoring fontification system
[2022-06-03 Wed 11:45] Ihor Radchenko :
>
> I'd like to hear if anyone has any idea on how to interpret the
> following:
>
> 1. org-protecting-blocks is an internal auxiliary variable used to
> determine which blocks should be fontified using different major
> mode.
> It's value is ("src" "example" "export")
> So, #+begin_src lang and #+begin_export lang are fontified according
> to LANG. Makes sense.
> However, what about #+begin_example?
> org-element-example-block-parser does not appear to expect language
> specification in the example blocks. Only switches seems to be
> allowed. Am I missing something and Org actually allows example
> blocks to specify language? Or was it the case in the distant past
> versions of Org?
- org-fontify-meta-lines-and-blocks-1
is looking for begin_
what comes after (src) is optional and can be anything
Next it looks for "language" (match-string 5 to 7
— it could be helpful to have comments indicating
the number matching of the groups next to them).
What gets fontified like a source block turns out to be:
,#+begin_{\w} [ ]
So this is fontified:
#+begin_quote python
def sss(): pass
#+end_quote
and this too:
#+begin_fly awk
BEGIN { woosh }
#+end_fly
Which is nice, but not interpreted like so
by any export backend.
>
> 3. org-fontify-meta-lines-and-blocks-1 creates a special face for
> ("+title:" "+subtitle:" "+author:" "+email:" "+date:")
> The face name is org-document-info.
> But what about, say, +description: or +language:?
> Would it make more sense to fontify all the keywords from
> org-options-keywords instead?
>
Makes more sense, yes.
I would have named them "directives"
rather than "keywords", but it's too late now.
Regards,
Phil
[bug] org-list-struct-apply-struct: insert an item in the end of a list
Hi there - A nasty bug when inserting an item in a list in last position (org 9.5.3-g69c588): - here is a list with a sub list - like here ; and then text x 1) when trying to insert an item in the list above, by suppressing the "x", and hitting M-RET, if there's no text after (like this one) the command gets stuck in org-list-struct-apply-struct org-list.el::1932 #+begin_src elisp (while (< (point) down) ;; should probably check if forward line returns 0 ;; otherwise will keep looping. Something like: ;; (while (and ( < (point) down) (not(> lines-left-to-move 0))) #+end_src org-list.el::1946 #+begin_src (forward-line))) ;; (setq lines-left-to-move (forward-line) #+end_src 2) after a break, C-g, or immediately when there no text following, text gets destroyed (much possibly), the list's structure is disorganized and the next paragraph too. Good luck, Phil
Re: # Comments export
On 29/05/2022 à 02:46, Ypo wrote: > > I wanted to export my # comments so I could > share my notes with more people, using HTML > export. I would export all of them. > Ypo, As it is very close to what you're asking, here I'm suggesting how to export # comments in org, as to the HTML and % comments to the latex backends. Modifying Org sources instead of providing a peripheral mechanism may be considered as unorthodox, but it's not difficult at all and the modifications to remove the censorship over comments are small. ox.el: add a customization option to export comments #+begin_src elisp (defcustom org-export--with-comments nil "Non-nil means provides comments to the backends" :group 'org-export-general :type 'boolean :safe #'booleanp) #+end_src Let comments flow to exporters when this option is active #+begin_src elisp (defun org-export--skip-p (datum options selected excluded) [...] (cl-case (org-element-type datum) ((comment comment-block) (if org-export--with-comments nil ;; do not skip comments and comment blocks. ;; Skip all comments and comment blocks. Make to keep maximum ;; number of blank lines around the comment so as to preserve ;; local structure of the document upon interpreting it back into ;; Org syntax. (let* ((previous (org-export-get-previous-element datum options)) (before (or (org-element-property :post-blank previous) 0)) (after (or (org-element-property :post-blank datum) 0))) (when previous (org-element-put-property previous :post-blank (max before after 0))) t))) [...] #+end_src ox-html.el: modify the backend derivation to add a comment transcoder #+begin_src elisp (org-export-define-backend 'html '(... (clock . org-html-clock) (code . org-html-code) (comment . org-html-comment) ... #+end_src ox-html.el: declare the additional transcoder: #+begin_src elisp Comment (defun org-html-comment (comment _contents info) "Transcode COMMENT from Org to HTML. CONTENTS is nil. INFO is a plist holding contextual information." (concat
Re: [PATCH] ox: fix comment exported as a blank line
Le 01/06/2022 à 13:48, Max Nikulin wrote : On 01/06/2022 12:30, Phil Estival wrote: * lisp/ox.el (org-export--skip-p): no longer export single-line comments as blank lines which did break paragraphs in two. unfortunately, you took a wrong direction If you are interested in other cases when org paragraph is not the same as exported LaTeX one, see the following thread: Max Nikulin. Comments break up a paragraph when writing one-setence-per-line. Sun, 3 Oct 2021 18:34:10 +0700. https://list.orgmode.org/sjc4fk$76r$1...@ciao.gmane.io Max, Right, thanks for the clarifications. A hook at pre-export stage to filter out the line-comments is one correct way to get an output compliant with different backends. Yet the removal of comments may provide an AST different from the one of the emacs buffer. >> However there [are] users in this thread who >> expect that "# " or "#+latex:" should not be >> "element" and should be a part of surrounding >> paragraph. That's an interesting idea. This would add an attribute to the previous element. If we keep speculating on that, the rendering path would change. It would have to consider this property too when showing or hiding elements. And it would require additional function to reallocate this attribute like a node. And this would probably break some conceptual integrity. The org spec is correct to handle the comments the way it does. As I see it now, that's the only possible attempts to reconcile the behaviors of different backends. Still, the writing experience is much improved when comments are allowed inside paragraphs without disrupting the publication, and this definitely worth a few modifications. Phil
[PATCH] test-ox: no superfluous newline in exported comments
* testing/lisp/test-ox.el (test-org-export/comments) test updated according to behavior change when exporting a comment: a single line of comment no longer insert a blank line TINYCHANGE --- testing/lisp/test-ox.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el index 28f950813..42e2a3d44 100644 --- a/testing/lisp/test-ox.el +++ b/testing/lisp/test-ox.el @@ -2049,7 +2049,7 @@ comments removal." Para2" (org-export-as (org-test-default-backend) (should - (equal "Para1\n\nPara2\n" + (equal "Para1\nPara2\n" (org-test-with-temp-text "Para1 # Comment -- 2.31.GIT
[PATCH] ox: fix comment exported as a blank line
* lisp/ox.el (org-export--skip-p): no longer export single-line comments as blank lines which did break paragraphs in two. TINYCHANGE --- lisp/ox.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ox.el b/lisp/ox.el index 9a8e63046..2c50fba0c 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -1756,7 +1756,7 @@ not exported." (before (or (org-element-property :post-blank previous) 0)) (after (or (org-element-property :post-blank datum) 0))) (when previous - (org-element-put-property previous :post-blank (max before after 1 + (org-element-put-property previous :post-blank (max before after 0 t) (clock (not (plist-get options :with-clocks))) (drawer -- 2.31.GIT
