[PATCH] Re: [BUG] Creating sparse tree with regexp property matches

[Daniel Fleischer]

Attached is a patch with improvement to documentation regarding regular 
expressions.

Best,

Daniel Fleischer
>From d3d1dcbc5f62ea111e7bcd1741114cae6b1280c5 Mon Sep 17 00:00:00 2001
From: Daniel Fleischer 
Date: Tue, 31 Aug 2021 20:01:47 +0300
Subject: [PATCH] org-manual: added section about regular expressions

Telling users it's based on Elisp regular expressions, linking to its
info node and putting some links to this new node in places where regexp
are presented.

Signed-off-by: Daniel Fleischer 
---
 doc/org-manual.org | 80 --
 1 file changed, 49 insertions(+), 31 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 10e0baa28..02eaa10f2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -916,16 +916,16 @@ ** Sparse Trees
   #+kindex: C-c / /
   #+findex: org-occur
   #+vindex: org-remove-highlights-with-change
-  Prompts for a regexp and shows a sparse tree with all matches.  If
-  the match is in a headline, the headline is made visible.  If the
-  match is in the body of an entry, headline and body are made
-  visible.  In order to provide minimal context, also the full
-  hierarchy of headlines above the match is shown, as well as the
-  headline following the match.  Each match is also highlighted; the
-  highlights disappear when the buffer is changed by an editing
-  command, or by pressing {{{kbd(C-c C-c)}}}[fn:8].  When called with
-  a {{{kbd(C-u)}}} prefix argument, previous highlights are kept, so
-  several calls to this command can be stacked.
+  Prompts for a regexp (see [[*Regular Expressions]]) and shows a sparse
+  tree with all matches.  If the match is in a headline, the headline
+  is made visible.  If the match is in the body of an entry, headline
+  and body are made visible.  In order to provide minimal context,
+  also the full hierarchy of headlines above the match is shown, as
+  well as the headline following the match.  Each match is also
+  highlighted; the highlights disappear when the buffer is changed by
+  an editing command, or by pressing {{{kbd(C-c C-c)}}}[fn:8].  When
+  called with a {{{kbd(C-u)}}} prefix argument, previous highlights
+  are kept, so several calls to this command can be stacked.
 
 - {{{kbd(M-g n)}}} or {{{kbd(M-g M-n)}}} (~next-error~) ::
 
@@ -3663,10 +3663,10 @@ ** Search Options in File Links
 
 - =/REGEXP/= ::
 
-  Do a regular expression search for {{{var(REGEXP)}}}.  This uses the
-  Emacs command ~occur~ to list all matches in a separate window.  If
-  the target file is in Org mode, ~org-occur~ is used to create
-  a sparse tree with the matches.
+  Do a regular expression search for {{{var(REGEXP)}}} (see [[*Regular
+  Expressions]]).  This uses the Emacs command ~occur~ to list all
+  matches in a separate window.  If the target file is in Org mode,
+  ~org-occur~ is used to create a sparse tree with the matches.
 
 As a degenerate case, a file link with an empty file name can be used
 to search the current file.  For example, =[[file:::find me]]= does
@@ -4978,8 +4978,9 @@ ** Tag Hierarchy
 
 Furthermore, the members of a group tag can also be regular
 expressions, creating the possibility of a more dynamic and rule-based
-tag structure.  The regular expressions in the group must be specified
-within curly brackets.  Here is an expanded example:
+tag structure (see [[*Regular Expressions]]).  The regular expressions in
+the group must be specified within curly brackets.  Here is an
+expanded example:
 
 #+begin_example
 ,#+TAGS: [ Vision : {V@.+} ]
@@ -5321,7 +5322,7 @@ ** Property Searches
   tree is created with all entries that define this property with the
   given value.  If you enclose the value in curly braces, it is
   interpreted as a regular expression and matched against the property
-  values.
+  values (see [[*Regular Expressions]]).
 
 ** Property Inheritance
 :PROPERTIES:
@@ -8913,8 +8914,9 @@ *** Matching tags and properties
 
 #+cindex: regular expressions, with tags search
 Instead of a tag, you may also specify a regular expression enclosed
-in curly braces.  For example, =work+{^boss.*}= matches headlines that
-contain the tag =:work:= and any tag /starting/ with =boss=.
+in curly braces (see [[*Regular Expressions]]).  For example,
+=work+{^boss.*}= matches headlines that contain the tag =:work:= and
+any tag /starting/ with =boss=.
 
 #+cindex: group tags, as regular expressions
 Group tags (see [[*Tag Hierarchy]]) are expanded as regular expressions.
@@ -8954,7 +8956,7 @@ *** Matching tags and properties
 
 #+begin_example
 +work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
- +With={Sarah|Denny}+SCHEDULED>="<2008-10-11>"
+ +With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
 #+end_example
 
 #+texinfo: @noindent
@@ -8984,7 +8986,7 @@ *** Matching tags and properties
 not =boss=, which also have a priority value =A=, a =Coffee= property
 with the value =unlimited=, an =EFFORT= property that is numerically
 smaller than 2, a =With

Bug: org-agenda-sort-notime-is-late is not correctly handled by timestamp comparison [9.4.6 (9.4.6-12-gdcc3a8-elpaplus @ /Users/charlestam/.emacs.d/elpa/org-plus-contrib-20210830/)]

[Charles Tam]

org-agenda-sorting-strategy claims that scheduled-up (-down) causes
items to be sorted in ascending (descending) order by scheduled
timestamp.

org-agenda-sort-notime-is-late claims that if it is non-nil, the absence
of a timestamp is treated as being maximal.

Instead, when using the scheduled-up (-down) sorting strategy, with
non-nil org-agenda-sort-notime-is-late, the absence of a timestamp is
treated as being minimal. Note that the documentation is not strictly
wrong; the correct behavior is exhibited for time-of-day comparisons,
just not timestamp comparisons.

Steps to Reproduce:

  (setq org-agenda-sorting-strategy '((agenda scheduled-up)
  (todo scheduled-up)
  (tags scheduled-up)
  (search scheduled-up))
org-agenda-sort-notime-is-late t)

  Place the following text in an org agenda file:

  * Reproduce ordering bug
  ** TODO Early item
 SCHEDULED: <1990-01-01 Mon>
  ** TODO Late item
 SCHEDULED: <2020-01-01 Wed>
  ** TODO Unscheduled item

  (Replace TODO with any non-DONE todo state if you need to.)

  Place the point on the "Reproduce" item and `M-x org-agenda < < t`
  (that is, list all TODO items restricted to the "Reproduce" subtree).

Expected:

  TODO Early item
  TODO Late item
  TODO Unscheduled item

Actual:

  TODO Unscheduled item
  TODO Early item
  TODO Late item

Suggested fix:

  Find `defsubst org-cmp-ts` in org-agenda.el. The definition of `def`
  in the `let*` should be something like

  (if org-agenda-sort-notime-is-late  -1)

(In the state dump below, `org-agenda-sort-notime-is-late` is not mentioned
but has its default value of t.)

Thanks,
Charles

Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS
appkit-1671.60 Version 10.14.6 (Build 18G95))
 of 2021-03-27
Package: Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpaplus @
/Users/charlestam/.emacs.d/elpa/org-plus-contrib-20210830/)

current state:
==
(setq
 org-roam-db-location "/Users/charlestam/mise/roam/org-roam.db"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-checklist)
 org-capture-prepare-finalize-hook '(org-roam-capture--install-finalize-h)
 org-link-shell-confirm-function 'yes-or-no-p
 org-expiry-wait "+30d"
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-roam-db-node-include-function #[0 "\300\207" [t] 1]
 org-refile-targets '((nil :maxlevel . 2) (org-agenda-files :maxlevel . 1))
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-pretty-entities t
 org-special-ctrl-a/e t
 org-agenda-files '("~/mise/TODO")
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-reveal-start-hook '(org-decrypt-entry)
 org-modules '(org-expiry org-habit ol-w3m ol-bbdb ol-bibtex ol-docview
ol-gnus ol-info ol-irc ol-mhe ol-rmail
   ol-eww)
 org-startup-folded 'showall
 org-archive-location "%s_archive::datetree/"
 org-mode-hook '((lambda nil (font-lock-add-keywords nil '(("{{{.+}}}" 0
'org-macro-face))) (set-fill-column 92))
 #[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 #[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2] turn-on-font-lock
 auto-fill-mode org-eldoc-load)
 org-tags-match-list-sublevels nil
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-expiry-handler-function 'org-toggle-archive-tag
 org-agenda-deadline-faces '((1.0 . org-warning) (0.8 .
org-imminent-deadline) (0.5 . org-upcoming-deadline)
 (0.0 . org-upcoming-distant-deadline))
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-hide-leading-stars t
 org-babel-load-languages '((python . t))
 org-log-done 'time
 org-roam-capture-preface-hook '(org-roam-dailies--override-capture-time-h)
 org-hide-emphasis-markers t
 org-export-backends '(ascii html latex md)
 org-roam-completion-everywhere t
 org-roam-capture-templates '(("d" "default" plain "%?" :target
   (file+head "%<%Y%m%d%H%M%S>-${slug}.org"
"#+title: ${title}\n#+filetags: \n")
   :unnarrowed t)
  ("t" 

Support for tabularray in LaTeX export

[Vikas Rawal]

tabularray (CTAN: Package tabularray )
provides longtblr environment that is called as

---
\begin{longtblr}[various-table-options]{column and row specifications}

\end{longtblr}
---

Adding something like the following to orgmode tables makes them export
nicely as longtblr

---
#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align
width=0.8\textwidth,colspec={lX[2,r]X[3,r]X[r,bg=gray9]}
#+ATTR_LATEX: :booktabs t
---

Everything seems to work very well with orgmode except that I cannot figure
out how to pass [various table options] from orgmode. These table options
include, most importantly, table notes.

I normally use threeparttable for table notes, but longtblr does not seem
to work with threeparttable and has its own syntax for table notes.

Any advice on how to pass [table-options] to longtblr environment?

Vikas

Re: New source block results option for attaching file to node

[Ryan Scott]

I hadn't thought about input directories much as my usage of
graphviz/gnuplots is through [essentially] DSLs that I made for them, so
the blocks are actually elisp.
Perhaps a convenient way of setting the working directory to the attachment
directory per-block makes sense?

My own personal coding style doesn't include a hard line limit, so it just
wasn't on my mind.

I'll get my patch updated and submitted shortly. Thanks for the help!

On Wed, Sep 1, 2021 at 7:44 AM Ihor Radchenko  wrote:

> Ryan Scott  writes:
>
> The patch looks fine for me except a typo:
>
> > +  by the source block to the nodes attachmen directory (as
>   ^attachment
>
> > org-attach-dir is a function for me (latest org pulled using straight.el)
> > org/lisp/org-attach.el:327.
>
> Timothy probably does not have (require 'org-attach) in his personal
> config. However, it should not be an issue for your patch with the
> autoload you added.
>
> > The primary use case is src blocks that generate files, in my case
> usually
> > gnuplot or graphviz, and return a file path. With a collection of org
> files
> > in a directory, organization can get messy, and creating an
> organizational
> > scheme essentially recreates the attachment directory design.
>
> I am also using attach directories for gnuplot output. Your approach is
> fine, but what about input directory? I find it a bit awkward to store
> input files alongside with the main .org file, while keeping the output
> images as attachments.
>
> I personally prefer to set the working dir for gnuplot like
>
> #+begin_src gnuplot :dir (org-attach-dir)
>
> With my approach, both the input and output files are going to be in the
> attach dir.
>
> I even go as far as making attach dir my default directory of all the
> code blocks.
>
> Though your patch may be useful when input directory is read-only or
> even remote.
>
> > Another approach would be to instead only modify org to have hooks (or
> any
> > other callback mechanism really) that are run on link insertion and have
> > access to the result-params for the block. The rest of this could then
> be a
> > separate package easily enough. Would that be a better approach as it
> would
> > allow the org core to not be so tightly coupled to org-attach?
>
> org-attach is in the Org core. It should not be a problem supporting
> org-attach in org babel.
>
> > I'm using magit; I just don't normally restrain myself to the line
> length.
> > I'll make sure to do that for submitted patches here.
>
> You may find flycheck-mode useful to hint things like line length.
>
> > In terms of this mailing list and overall contribution process, how best
> to
> > remedy things for the patch? Just modify it and reply with the modified
> > patch as an attachment?
>
> Yep. Just submit the updated patch. Preferably, also add [PATCH] at the
> beginning of the message topic. Then, the patch will also be shown in
> updates.orgmode.org
>
> Best,
> Ihor
>

Need absolute org-attach-id-dir to attach in buffers without filename

[Nick Anderson]

I have an org-mode file that contains headings with attachments. When I
`org-mime-org-buffer-htmlize' I get an error, `"Need absolute
`org-attach-id-dir' to attach in buffers without filename"'.
`org-attach-id-dir' has the value `data/'. I get this error even when I
am in the buffer for the file, not simply a capture buffer. This seems
to come [from org-attach].

The buffer name is name of the file, but not named using the absolute
path to the file, is that why I am getting the error?

Looking at `buffer-file-name' while visiting the file indicates that the
value is the full path, but local in buffer it's not the full path and
the global value is nil.

Thanks


[from org-attach]

--
Nick Anderson

Re: Bug: "DEFINITION NOT FOUND" for footnote in Org manual

[Maxim Nikulin]

On 21/07/2021 22:26, Timothy wrote:

Maxim Nikulin writes:


It seems, the footnote was unintentionally lost in the merge commit with a lot
of conflicts due to renumbering in both branches:

https://code.orgmode.org/bzg/org-mode/commit/9410fbe0606a53b0582cc175b2cc525d556b23fe#diff-6498bd2213e2e527d904942bb214768a1913776L21749


Many thanks for tracking that down! I'm inclined to just add back the
text lost in that merge unless you'd recommend anything else.


I think, it is better to restore the footnote text than to leave it in 
its current state "DEFINITION NOT FOUND".

Re: org-cite: enable inserting citation (org-cite-insert) after list bullet [9.5 (9.5-7c78aca @ /home/yuu/.config/emacs/straight/build/org/)]

[Yuu Yin]

Thank you! Would it also be feasible to enable inserting citations after list 
checkboxes? For example

- [ ] [cite:@author-2021-title]
- [X] [cite:@author-2021-title]
  + [X] [cite:@author-2021-title]

This is super useful for marking which works/documents the user did read and 
took notes for e.g. a literature review.

Yuu Yin

‐‐‐ Original Message ‐‐‐

On Tuesday, August 31st, 2021 at 7:24 AM, Timothy  wrote:

> Yuu Yin yuu...@protonmail.com writes:
>
> > Invoking ~org-cite-insert~ after list bullets (e.g. ~-~ and ~1.~ )
> >
> > doesn't work.
>
> I did a little test myself, and can confirm that it's not currently
>
> possible to insert a citation immediately after a bullet and space.
>
> This can be checked with `org-cite--allowed-p'. Thinking about this 
> situation, inserting citations should be fine as long as the` point' isn't 
> before or immediately after the bullet itself
>
> (i.e. no space).
>
> I've prepared a patch that fixes this (attached). This is the test case
>
> that I'm adding:
>
> -   ((eq type 'item)
>
>
> -(> (point) (+ (org-element-property :begin context)
>
>
> -  (org-get-indentation)
>
>
> -  1)))
>
>
>
> As this is so simple, if nobody has any comments I'll push this in a
>
> week or so.
>
> 
>
> Timothy

Re: A small bug in org-file-url-p

[Timothy]

Hi Peder,

Thanks for reporting this bug 🙂, and explaining the issue well. I’ve just
pushed a fix in fbfcd79f8.

All the best,
Timothy

Re: New source block results option for attaching file to node

[Ihor Radchenko]

Ryan Scott  writes:

The patch looks fine for me except a typo:

> +  by the source block to the nodes attachmen directory (as
  ^attachment

> org-attach-dir is a function for me (latest org pulled using straight.el)
> org/lisp/org-attach.el:327.

Timothy probably does not have (require 'org-attach) in his personal
config. However, it should not be an issue for your patch with the
autoload you added.

> The primary use case is src blocks that generate files, in my case usually
> gnuplot or graphviz, and return a file path. With a collection of org files
> in a directory, organization can get messy, and creating an organizational
> scheme essentially recreates the attachment directory design.

I am also using attach directories for gnuplot output. Your approach is
fine, but what about input directory? I find it a bit awkward to store
input files alongside with the main .org file, while keeping the output
images as attachments.

I personally prefer to set the working dir for gnuplot like

#+begin_src gnuplot :dir (org-attach-dir)

With my approach, both the input and output files are going to be in the
attach dir.

I even go as far as making attach dir my default directory of all the
code blocks.

Though your patch may be useful when input directory is read-only or
even remote.

> Another approach would be to instead only modify org to have hooks (or any
> other callback mechanism really) that are run on link insertion and have
> access to the result-params for the block. The rest of this could then be a
> separate package easily enough. Would that be a better approach as it would
> allow the org core to not be so tightly coupled to org-attach?

org-attach is in the Org core. It should not be a problem supporting
org-attach in org babel.

> I'm using magit; I just don't normally restrain myself to the line length.
> I'll make sure to do that for submitted patches here.

You may find flycheck-mode useful to hint things like line length.

> In terms of this mailing list and overall contribution process, how best to
> remedy things for the patch? Just modify it and reply with the modified
> patch as an attachment?

Yep. Just submit the updated patch. Preferably, also add [PATCH] at the
beginning of the message topic. Then, the patch will also be shown in
updates.orgmode.org

Best,
Ihor

[PATCH] Re: Bug: `org-fill-paragraph' relies on M-q being bound to `fill-paragraph' [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/mwj/.emacs.d/elpa/org-20210809/)]

[Ihor Radchenko]

Timothy  writes:

> With regards to triggering M-q in the edit buffer,
> considering that different modes can have different fill commands, might
> you have any suggestions on what command this could be replaced by?

I think simply calling `fill-paragraph' (bound to "M-q" by default)
should do. From it's docstring, it should take care about mode-specific
fill functions:

>> If fill-paragraph-function is non-nil, we call it (passing our
>> argument to it), and if it returns non-nil, we simply return its value.

Also, the docstring says that fill-paragraph-function is expected to
return non-nil when the filling is done there. For some reason, it is
not done in org-fill-paragraph.

The attached is patch solving the "M-q" problem and making sure the
org-fill-paragraph returns non-nil.

Beware that I am not very familiar with fill.el. It would be great if
someone more knowledgeable take a look at the patch.

Best,
Ihor

>From 2ff317ece235890da5e1f8246dba08d585b0fbaa Mon Sep 17 00:00:00 2001
Message-Id: <2ff317ece235890da5e1f8246dba08d585b0fbaa.1630500712.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Wed, 1 Sep 2021 20:42:05 +0800
Subject: [PATCH] Do not rely on M-q binding for filling src-block

* lisp/org.el (org-fill-element): Use `fill-paragraph' instead of
simulating "M-q" binding.
(org-fill-paragraph): Return t as described in `fill-paragraph'
docstring.

Fixes https://orgmode.org/list/cah7lot0po3js6_+cbinm6eynx0kfvpfiss7dwc1exsfhfhk...@mail.gmail.com/
---
 lisp/org.el | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ce68f4692..601526e84 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19486,7 +19486,9 @@ (defun org-fill-element (&optional justify)
   ;; the buffer.  In that case, ignore filling.
   (cl-case (org-element-type element)
 	;; Use major mode filling function is source blocks.
-	(src-block (org-babel-do-key-sequence-in-edit-buffer (kbd "M-q")))
+	(src-block (org-babel-do-in-edit-buffer
+(mark-whole-buffer)
+(funcall-interactively #'fill-paragraph justify 'region)))
 	;; Align Org tables, leave table.el tables as-is.
 	(table-row (org-table-align) t)
 	(table
@@ -19621,7 +19623,9 @@ (defun org-fill-paragraph (&optional justify region)
 ;; previously unmodified), then flip the modification status back
 ;; to "unchanged".
 (when (and hash (equal hash (org-buffer-hash)))
-  (set-buffer-modified-p nil
+  (set-buffer-modified-p nil))
+;; Return non-nil.
+t))
 
 (defun org-auto-fill-function ()
   "Auto-fill function."
-- 
2.31.1

Re: ob-R: Error about longer than max-lines even with :result silent

[Yasushi SHOJI]

Hi Timothy,

On Tue, Aug 31, 2021 at 10:40 PM Timothy  wrote:
> Thanks for going to the effort to document this Yasushi. I’ve taken a look at
> your patches and they look quite good and straightforward to me. I’ve taken 
> the
> liberty of pushing them to master.

Thank you for taking your time for this. :-)  I really appreciate it.

Best,
-- 
   yashi

A small bug in org-file-url-p

[Peder Stray]

Hi

Just wanted to report a small bug in org-file-url-p, regarding its use of
ffap-url-regexp.

The documentation for ffap-url-regexp states:
Regexp matching the beginning of a URI, for ffap.
If the value is nil, disable URL-matching features in ffap.

I have it set to nil in my setup, to disable url-matching, and this causes
org-file-url-p to pass on nil in (string-match-p ffap-url-regexp file),
thus causing string-match-p do die with an error.

Othe code in ffap uses and to test the value of ffap-url-regexp before
passing it on as in:
(and ffap-url-regexp (string-match-p ffap-url-regexp file))

-- 
  Peder Stray

Re: [BUG] Creating sparse tree with regexp property matches

[Daniel Fleischer]

Timothy [2021-09-01 Wed 18:28]  wrote:

> Hi Daniel,
>
> Thanks Daniel, I’ve just had a quick read and it looks good to me. If anyone
> else has comments this would be a great time to jump in :)
>
> I haven’t seen `' links before, it seems like there’s one
> other in the manual. Do you know if they work well with the exported forms of
> the manual?
>

There's actually another link with a bit different format:
 

Testing it: in the PDF it doesn't do anything but in the compiled HTML
file it leads to the right section. In Emacs obviously it will jump
correctly to the info node.

I did "discover" Emacs regular expression node which I think is
friendlier than Elisp's (and contains it) so I'll replace the link; see
Daniel Fleischer

Re: [BUG] Creating sparse tree with regexp property matches

[Timothy]

Hi Daniel,

Thanks Daniel, I’ve just had a quick read and it looks good to me. If anyone
else has comments this would be a great time to jump in :)

I haven’t seen `[[info:elisp::page]]' links before, it seems like there’s one
other in the manual. Do you know if they work well with the exported forms of
the manual?

Daniel Fleischer  writes:

> Hi Timothy,
>
> Attached is my patch.
>
> Best,
>
> *Daniel Fleischer*
>
> [2. text/x-patch; 
> 0001-org-manual-added-section-about-regular-expressions.patch]…

All the best,
Timothy

org-mime-html and smileys

[Uwe Brauer]

Hi

I noticed that org-mime-html does not convert textual smiley
;-)
to its UTF8 chars.

Any idea how that can be achieved?

Regards

Uwe Brauer