On 2018-12-02, Nicolas Goaziou wrote:
> Jens Lechtenboerger writes:
>
>> From 068fb45f5276d61e86271988efbcf6c29e08c411 Mon Sep 17 00:00:00 2001
>> From: Jens Lechtenboerger
>> Date: Sun, 2 Dec 2018 20:25:38 +0100
>> Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of
>> h
Nicolas Goaziou writes:
> I think we could do something similar to links, i.e., populate
> a variable (for links, it is `org-link-parameters') with a command
> (`org-link-set-parameters'), so the dispatcher knows what dynamic blocks
> can be provided.
This is an good idea. Nicolas, do you want
Tim Cross writes:
> I think the problem here is that really, project.clj is not a valid
> clojure source file. It is really a clojure data file or clojure
> snippet (I mean in the sense that you cannot execute it or include it as
> a dependency within a clojure program - it is input data for th
> the extension function becomes helpful again: this because the
> #+BEGIN/#+END matcher is incremental and eventually the region to
Well, on a closer inspection it's not that incremental, it's just
ignoring the limit...
(defun org-fontify-meta-lines-and-blocks-1 (limit)
(when (r
Hi all,
I've been adding some improvements to the region extension function
(pasted below) in order to better support nesting, but anyway I'm
convinced that the current approach to org-highlight-latex-and-related
== '(latex) is hopeless except for small fragments and should be
reworked or dropped
Hi Nicolas,
fair enough if you feel it's not worth the hassle.
I'm pasting here a simple filter implementing the rule I described
above (use the special arg if present and if it doesn't conflict with
any ATTR directive for the current backend) for anyone interested, if
any at all:
(defun my-org-
Hello,
Carlos Pita writes:
> One thing the core parser could do is to put the remaining of the
> opening line of a special block into an :args or similar property of
> the special block element, leaving it otherwise unparsed.
I thought about it a long time ago. However, I could not, and still
c
Dear all,
Please find enclosed a proposed patch (against master) to document the
need for babel/polyglossia in order to honor #+language in LaTeX
export.
This is purely a documentation patch. A better solution would be to
detect the use of a non-default #+language: and act accordingly.
Nicolas no
Hello,
Jens Lechtenboerger writes:
> From 068fb45f5276d61e86271988efbcf6c29e08c411 Mon Sep 17 00:00:00 2001
> From: Jens Lechtenboerger
> Date: Sun, 2 Dec 2018 20:25:38 +0100
> Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of
> headline
Thank you.
> * lisp/ox-html.e
On 2018-12-02, at 19:25, Jens Lechtenboerger wrote:
> Dear all,
>
> the attached patch allows to add a class attribute to headline
> elements in HTML export. Is that acceptable for inclusion?
In that patch, "when" should have been "if", sorry. Fixed version
attached.
Best wishes
Jens
>From 06
Hello,
There seems to be a bad interaction between ‘(org-resolve-clocks)’
and ‘org-clock-out-remove-zero-time-clocks’ set to t. Whilst the
right tree is targeted by ‘(org-resolve-clocks)’ to delete the
clock-line and clock-drawer, it adds a new clock-drawer in the
next tree rather than on the
Dear all,
the attached patch allows to add a class attribute to headline
elements in HTML export. Is that acceptable for inclusion?
Best wishes
Jens
P.S. The change is tiny, but I assigned copyright to the FSF in
2015.
>From e8f16b04903bc32c4ea006727c82dbcb40b591a8 Mon Sep 17 00:00:00 2001
Fro
David Arroyo Menendez writes:
> It doesn't run for me. What's the function that you are referring?
It's `org-insert-structure-template', but probably in master branch
only.
> org-toggle-item: It needs a kiss principle. Only turns normal lines to
> items and items to normal lines in another way
Nicolas Goaziou writes:
> Hello,
>
> David Arroyo Menendez writes:
>
>> I've implemented a new file to contrib/lisp.
>
> Is there any reason to favor contrib/lisp instead of some ELPA? I'm
> asking this because I'd like to reduce the number of packages in
> contrib/.
>
>> It's called org-envolve
I would also like to elaborate on another aspect of this.
#+ATTR_xxx serves two purposes:
a. As a syntactical means of attaching extra information to
syntactically constrained elements (as tables or images). For this
purpose the _xxx part is irrelevant, only the affiliation to an
element matters.
Hi Eric,
And this is where the challenge lies! The whole point of special blocks is
> that org knows nothing of their semantics. They are a "black box" and it
> would be difficult to identify export specific elements and general
> elements on this basis.
>
I partially agree with this just becau
On Saturday, 1 Dec 2018 at 16:23, Carlos Pita wrote:
> The idea is that stuff that is very specific to a backend X would be
> in :attrs_X, but stuff that is related to what makes the block
> semantically special could be in :args.
And this is where the challenge lies! The whole point of special
On Saturday, 1 Dec 2018 at 15:41, Carlos Pita wrote:
>> > 1. Allow for special blocks to take an :options argument.
>>
>> Although I agree that this would be nice, I imagine the difficulty
>> would be that it would be difficult to cater for multiple backends.
>
> It's not really difficult, more on
Hello,
David Arroyo Menendez writes:
> I've implemented a new file to contrib/lisp.
Is there any reason to favor contrib/lisp instead of some ELPA? I'm
asking this because I'd like to reduce the number of packages in
contrib/.
> It's called org-envolve.el,
> this file implements functions to h
Hello,
Samuel Wales writes:
> On 11/21/18, Nicolas Goaziou wrote:
>> You can use a zero-width space, like +++.
>
> that trick does not work on ===.
What does not work, exactly?
Regards,
--
Nicolas Goaziou
20 matches
Mail list logo
