Hi,
The new document seems much clearer. It makes a nice complement to the
manual and we should definitely lose the (draft). Thank you Timothy
for the work.
Lastly, having spent a while looking at the syntax, I’m wondering if
we should take this opportunity to mark some of the syntactic
A couple of additional remarks.
On 15/01/2022 19:52, Max Nikulin wrote:
On 02/01/2022 20:12, Ihor Radchenko wrote:
Subject: [PATCH] make test: Make failure results more verbose
At first it was not clear to me that only *summary* of test results is
affected.
Should not the variable be
On 02/01/2022 20:12, Ihor Radchenko wrote:
In newer Emacs, ERT is capable of providing more info about FAILED
tests. Maybe we can enable this option by default in the Org test suite?
Thinking more, I have realized that something is wrong.
Behavior of tests in Org should be controlled by
Ihor Radchenko writes:
> Johan Tolö writes:
>
>> If "* Top heading" is the first heading in the buffer with nothing
>> above it, not even a whitespace/newline, then '(org-entry-get nil
>> "id" t)' with point in "* Second heading" will return the id of
>> "Top heading". If there is anything
Hi,
The attached patch adds support for two new babel header arguments:
=:noweb-prefix= and =:noweb-trans=.
=:noweb-prefix= can be set to =no= to disable the noweb prefix
behaviour, where prefix characters are repeated when expanding a
multiline noweb reference.
=:noweb-trans= can be set to
Ihor, I have tried your patch. My opinion is that you can go ahead and
commit it as is. Reaction to my comments is optional.
Subject: [PATCH] make test: Make failure results more verbose
At first it was not clear to me that only *summary* of test results is
affected.
+ifeq
Allen Li writes:
> I see. In my opinion those occurrences should be fixed even if no one
> is reporting issues because it is bad/improper code, and it is not
> especially surprising that no one has reported it yet; there is always a
> first person who reports a bug, and there are always more
>>> "T" == Timothy writes:
Hi Timothy
> Hi Uwe,
>> And every text between @ appears red.
>>
>> Can I have a similar setting when exporting an org file to html via the
>> «normal» html exporter?
> Have a look at the filter functions, such as
> `org-export-filter-final-output-functions'. See
>
>>> "JMM" == Juan Manuel Macías writes:
> Uwe Brauer writes:
>> Thanks very much it works as expected. However I just realized (and
>> this is true also for the org-mime filter that the reg-exp has a flaw.
>>
>> I used the text
>>
>>
>> =email:o...@mat.ucm.es=
>>
>> So there is only one @,
Uwe Brauer writes:
> (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
>
> How could I remove something from a list?
I think this would work:
(setq org-export-filter-plain-text-functions
(remove 'my-html-red org-export-filter-plain-text-functions))
Anyway, I recommend
>>> "JMM" == Juan Manuel Macías writes:
> I think this would work:
> (setq org-export-filter-plain-text-functions
> (remove 'my-html-red org-export-filter-plain-text-functions))
> Anyway, I recommend that you take a look at the documentation on filters
> that Timothy pointed you to, as
Hi Uwe,
> And every text between @ appears red.
>
> Can I have a similar setting when exporting an org file to html via the
> «normal» html exporter?
Have a look at the filter functions, such as
`org-export-filter-final-output-functions'. See
>>> "JMM" == Juan Manuel Macías writes:
> Uwe Brauer writes:
>> Can I have a similar setting when exporting an org file to html via the
>> «normal» html exporter?
> Using a custom filter?
> #+begin_src emacs-lisp
> (defun foo (text backend info)
> (when (org-export-derived-backend-p
Uwe Brauer writes:
> Thanks very much it works as expected. However I just realized (and
> this is true also for the org-mime filter that the reg-exp has a flaw.
>
> I used the text
>
>
> =email:o...@mat.ucm.es=
>
> So there is only one @, nevertheless the exporter translated that to
>
Uwe Brauer writes:
> Can I have a similar setting when exporting an org file to html via the
> «normal» html exporter?
Using a custom filter?
#+begin_src emacs-lisp
(defun foo (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string
Hi Sebastien,
Thanks for your comments, and your thoughts on the proposed deprecation.
It’s worth explicitly considering why we wouldn’t want to steer people away from
the TeX-syntax LaTeX fragments, so I am glad you have brought up some reasons.
I do not find myself agreeing with them however,
Hi
When I use org-mime-htmlize, then I can use the setting
Render text between "@" in red color, you can use =org-mime-html-hook=,
#+begin_src elisp
(add-hook 'org-mime-html-hook
(lambda ()
(while (re-search-forward "@\\([^@]*\\)@" nil t)
(replace-match
I tracked this down to a bug in emacs, which happens only when indirect
buffers are cloned. Reported as bug#53294 with a patch.
On Thu, Jan 13, 2022 at 9:51 PM Andrew Hyatt wrote:
>
> Hi all,
>
> I've been having an odd problem where if I try to change my text
> scale on my org capture buffers,
Hi.
Disclaimer: I am neither plantuml nor ditaa user, so my comments may
have no sense.
On 15/01/2022 13:20, Ihor Radchenko wrote:
Dejan Josifović writes:
Comparing ob-plantuml.el and plantuml-mode.el files I found what is the
problem. plantuml-mode has a customizable variable for
19 matches
Mail list logo