bug#38592: 27.0.50; org mode insinuates itself into calendar

2020-02-16 Thread Bastien
Hi Sam,

Sam Steingold  writes:

> Looks like a bug in ein,
> https://github.com/millejoh/emacs-ipython-notebook/issues/668

Thanks for the follow-up.

I looked at ein-notebooklist.el a bit, where I could not understand
why logging in would call org--setup-calendar-bindings but I don't
know ein and cannot go further.

Feel free to close the bug report when you think it is resolved.

-- 
 Bastien





bug#37333: Org-mode python output not working

2020-02-16 Thread Bastien
Hi Michael,

Michael Wu  writes:

> In the following block:
>
> #+BEGIN_SRC python :results value :session
> def f():
>     return 5
> f()
> #+END_SRC
>
> It gives the message
>
> "Code block returned no value"

I cannot reproduce this bug with latest Org from the master branch.
If you can, let me know.  Otherwise, I'll close this bug in a month
or so.

Thanks,

-- 
 Bastien





Re: [PATCH] org-src: Add option to restore window configuration after edit

2020-02-16 Thread Tom Gillespie
Hi Kyle,
Thank you for the pointer. That does indeed solve my issue. I must
have missed it because it wasn't merged into maint. The conversation
in that thread seems to indicate that the old behavior is the correct
default. I imagine that there might be a few other folks with Matt's
use case, but I guess that can wait. Thus, definitely ok to ignore
this patch. Best!
Tom

On Sun, Feb 16, 2020 at 8:16 PM Kyle Meyer  wrote:
>
> Hi Tom,
>
> Tom Gillespie  writes:
>
> > Hi all,
> >   After hours of frustration ending in a realization that I should really
> > just read the change logs, I tracked down the reason why editing
> > source blocks was now destroying my window layout. I restored the
> > old behavior hidden behind a custom variable. Let me know if it looks
> > ok, or if more work is needed. Thanks!
>
> I haven't looked at your proposed change closely, but I think this is
> the same issue that was reported recently [0] and fixed by d833920de
> (org-src: restore windows for some values of org-src-window-setup,
> 2019-12-23).  If you have a chance, please check whether that commit
> resolves the issue for you.
>
> [0]: https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00263.html



Re: [PATCH] org-src: Add option to restore window configuration after edit

2020-02-16 Thread Kyle Meyer
Hi Tom,

Tom Gillespie  writes:

> Hi all,
>   After hours of frustration ending in a realization that I should really
> just read the change logs, I tracked down the reason why editing
> source blocks was now destroying my window layout. I restored the
> old behavior hidden behind a custom variable. Let me know if it looks
> ok, or if more work is needed. Thanks!

I haven't looked at your proposed change closely, but I think this is
the same issue that was reported recently [0] and fixed by d833920de
(org-src: restore windows for some values of org-src-window-setup,
2019-12-23).  If you have a chance, please check whether that commit
resolves the issue for you.

[0]: https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00263.html



bug#38592: 27.0.50; org mode insinuates itself into calendar

2020-02-16 Thread Sam Steingold
Looks like a bug in ein,
https://github.com/millejoh/emacs-ipython-notebook/issues/668

On Fri, 14 Feb 2020 at 05:03, Bastien  wrote:
>
> Hi Sam,
>
> Sam Steingold  writes:
>
> > If you tell me what to do, I would gladly do it.
> > I am afraid I am too busy to investigate it myself...
>
> if you can share your .emacs file (removing private information)
> I can try to bisect and find what causes Org to be loaded: you can
> send it to me in private if you prefer.
>
> But in the meantime, I confirm that with Emacs -q (from latest
> master), Org is *not* loaded and calendar-mode-hook is nil.
>
> Best,
>
> --
>  Bastien



-- 
Sam Steingold  






[PATCH] org-src: Add option to restore window configuration after edit

2020-02-16 Thread Tom Gillespie
Hi all,
  After hours of frustration ending in a realization that I should really
just read the change logs, I tracked down the reason why editing
source blocks was now destroying my window layout. I restored the
old behavior hidden behind a custom variable. Let me know if it looks
ok, or if more work is needed. Thanks!
Tom
From 362a45ff172af3f49050964aa8534d11374934ca Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Sun, 16 Feb 2020 19:21:16 -0800
Subject: [PATCH] org-src: Add option to restore window configuration after
 edit

* lisp/org-src.el: Add an option to restore the previous window
configuration after exiting from editing a source block. The variable
is called `org-src-window-restore' and is only relevant when
`org-src-window-setup' is set to `reorganize-frame'.

This commit retains the default behavior in version 9.3 while
restoring the old behavior behind a custom variable, it
effectively reverts 819e98afd018cad3c13fd58bfcbd979ab36dfbc7
and adds an option to reenable the old behavior.
---
 lisp/org-src.el | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 7876deaba..f8f236ebd 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -169,6 +169,12 @@ other-frameUse `switch-to-buffer-other-frame' to display edit buffer.
 	  (const other-window)
 	  (const reorganize-frame)))
 
+(defcustom org-src-window-restore nil
+  "Non-nil means that org mode will restore the layout of the windows
+that was present before the org-src window was initially opened. This
+option is only involved if `org-src-window-setup' is set to
+`reorganize-frame'")
+
 (defvar org-src-mode-hook nil
   "Hook run after Org switched a source code snippet to its Emacs mode.
 \\
@@ -276,6 +282,9 @@ issued in the language major mode buffer."
 (defvar-local org-src--remote nil)
 (put 'org-src--remote 'permanent-local t)
 
+(defvar-local org-src--saved-temp-window-config nil)
+(put 'org-src--saved-temp-window-config 'permanent-local t)
+
 (defvar-local org-src--source-type nil
   "Type of element being edited, as a symbol.")
 (put 'org-src--source-type 'permanent-local t)
@@ -469,6 +478,9 @@ When REMOTE is non-nil, do not try to preserve point or mark when
 moving from the edit area to the source.
 
 Leave point in edit buffer."
+  (when (and (eq org-src-window-setup 'reorganize-frame)
+	 org-src-window-restore)
+(setq org-src--saved-temp-window-config (current-window-configuration)))
   (let* ((area (org-src--contents-area datum))
 	 (beg (copy-marker (nth 0 area)))
 	 (end (copy-marker (nth 1 area) t))
@@ -1182,7 +1194,12 @@ Throw an error if there is no such buffer."
(write-back (org-src--goto-coordinates coordinates beg end
 ;; Clean up left-over markers and restore window configuration.
 (set-marker beg nil)
-(set-marker end nil)))
+(set-marker end nil)
+  (when (and (eq org-src-window-setup 'reorganize-frame)
+	 org-src-window-restore
+	 org-src--saved-temp-window-config)
+(set-window-configuration org-src--saved-temp-window-config)
+(setq org-src--saved-temp-window-config nil
 
 
 (provide 'org-src)
-- 
2.24.1



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Samuel Wales
On 2/16/20, Bastien  wrote:
> I'm willing to spend as much time as needed on a MCE, but I'm waiting
> for this MCE before interpreting comments on code and possible bugs.

i see.

fyi i was not specifically trying to report a bug or supply an mce.

instead, i was hoping only to contribute to understanding of the code
that is currently mystifying in this thread with a concrete 1-line fix
that wfm that i hoped would jog somebody's ideas to fix any issues
that are under discussion, such as the trailing slashes.

then you asked for more details so i tried to supply what i could.

if that is not useful, apologies for the noise.  i was not in a
position to get into the details, and am not, but i wanted to mention
something that might help.

as it has been many years, and for various reasons, i will not be able
to create an mce for you at this time.  in addition, even if such did
not apply, i have since changed my org refile settings and ido
settings, and cannot use master or recent maint.

i hope that i have not disrupted the thread.  my fix fixed trailing
slashes and duplicates, is all.

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html



Re: patch: add custom latex->html conversion command

2020-02-16 Thread Bastien
Hi Matt,

Matt Huszagh  writes:

> Thanks for the feedback. I've filled out the form you sent and sent it
> to the email listed.

Thanks!  It looks good.

Let me know when you get the answer from the FSF.

If you don't in four weeks, please ping them again cc'ing me.

-- 
 Bastien



Re: patch: add custom latex->html conversion command

2020-02-16 Thread Matt Huszagh
Will do, thanks!

On Sun, Feb 16, 2020 at 5:10 PM Bastien  wrote:

> Hi Matt,
>
> Matt Huszagh  writes:
>
> > Thanks for the feedback. I've filled out the form you sent and sent it
> > to the email listed.
>
> Thanks!  It looks good.
>
> Let me know when you get the answer from the FSF.
>
> If you don't in four weeks, please ping them again cc'ing me.
>
> --
>  Bastien
>


Re: patch: add custom latex->html conversion command

2020-02-16 Thread Matt Huszagh
Thanks for the feedback. I've filled out the form you sent and sent it
to the email listed.

Adjusted patch below. I didn't add a value to the customization. I'm
honestly not very familiar with the customize interface since I never
use it. Is that a default value if the user selects string from the
customize interface? If it is I think it's probably best to leave it
blank since this is really meant to be open-ended. For instance, I doubt
the example I give would work on windows, so that might be more
confusing than helpful in that case. What do you think? Happy to set it
to whatever.

Matt

>From 6b2495c8aef0b67fd00ad27a0056e79f42c23c06 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Sun, 16 Feb 2020 16:52:02 -0800
Subject: [PATCH] add custom command option when converting latex fragments to
 html

* lisp/org.el (org-latex-to-html-convert-command): Add custom command
option to convert a latex fragment directly into HTML.
(org-format-latex): Add condition for this command to org-format-latex.
(org-format-latex-as-html): Command that ultimately does the
conversion work. It uses the user-specified command and applies to
the latex fragment. It then returns the resulting HTML.
* lisp/ox-html.el (org-html-with-latex): Document 'html symbol.
(org-html-format-latex): This custom HTML conversion, like mathjax,
doesn't require preprocessing.
(org-html-latex-fragment): Add condition to org-html-latex-fragment
for html symbol.

This allows you to set a custom command
`org-latex-to-html-convert-command' that will take as input a latex
fragment and use it to generate html for export. This is very
open-ended in the sense that you can use any shell-command you
want. I've added the ability in order to use latexml, but you could
use any other tool that generates HTML output text.
---
 lisp/org.el | 29 +
 lisp/ox-html.el |  9 +++--
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 97ce7ec43..7cc9e8687 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3203,6 +3203,22 @@ When using LaTeXML set this option to
 	  (const :tag "None" nil)
 	  (string :tag "\nShell command")))
 
+(defcustom org-latex-to-html-convert-command nil
+  "Command to convert LaTeX fragments to HTML.
+This command is very open-ended: the output of the command will
+directly replace the latex fragment in the resulting HTML.
+Replace format-specifiers in the command as noted below and use
+`shell-command' to convert LaTeX to HTML.
+%i: The latex fragment to be converted.
+
+For example, this could be used with LaTeXML as
+\"latexmlc 'literal:%i' --profile=math --preload=siunitx.sty 2>/dev/null\"."
+  :group 'org-latex
+  :package-version '(Org . "9.5")
+  :type '(choice
+	  (const :tag "None" nil)
+	  (string :tag "\nShell command")))
+
 (defcustom org-preview-latex-default-process 'dvipng
   "The default process to convert LaTeX fragments to image files.
 All available processes and theirs documents can be found in
@@ -15613,6 +15629,10 @@ Some of the options can be changed using the variable
 		(if (string= (match-string 0 value) "$$")
 			(insert "\\[" (substring value 2 -2) "\\]")
 		  (insert "\\(" (substring value 1 -1) "\\)"
+		 ((eq processing-type 'html)
+		  (goto-char beg)
+		  (delete-region beg end)
+		  (insert (org-format-latex-as-html value)))
 		 ((assq processing-type org-preview-latex-process-alist)
 		  ;; Process to an image.
 		  (cl-incf cnt)
@@ -15778,6 +15798,15 @@ inspection."
   ;; Failed conversion.  Return the LaTeX fragment verbatim
   latex-frag)))
 
+(defun org-format-latex-as-html (latex-frag)
+  "Convert latex to html with a custom conversion command.
+`LATEX-FRAG' is the latex fragment
+Set the custom command with `org-latex-to-html-convert-command'."
+  (let ((cmd (format-spec org-latex-to-html-convert-command
+			  `((?i . ,latex-frag)
+(message "Running %s" cmd)
+(setq shell-command-output (shell-command-to-string cmd
+
 (defun org--get-display-dpi ()
   "Get the DPI of the display.
 The function assumes that the display has the same pixel width in
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index ea6aa63c3..b5cbf4cfc 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -776,6 +776,8 @@ e.g. \"tex:mathjax\".  Allowed values are:
   `verbatim'Keep everything in verbatim
   `mathjax', t  Do MathJax preprocessing and arrange for MathJax.js to
 be loaded.
+  `html'Use `org-latex-to-html-convert-command' to convert
+LaTeX fragments to HTML.
   SYMBOLAny symbol defined in `org-preview-latex-process-alist',
 e.g., `dvipng'."
   :group 'org-export-html
@@ -2776,12 +2778,13 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
 (defun org-html-format-latex (latex-frag processing-type info)
   "Format a LaTeX fragment LATEX-FRAG into HTML.
 PROCESSING-TYPE designates the tool used for conversion.  It can
-be `mathjax', 

Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Gustavo Barros

Hi Bastien,

On Sun, Feb 16 2020, Bastien wrote:


Hi Gustavo,

Gustavo Barros  writes:


But the fact that
'completing-read-default' returns the refile location with a double
trailing slash makes me think there is still something to be fixed in
'org-refile-get-location'.


if you're not tired of the hunt, please tell us when you find what
needs to be fixed--since there is no bug attached to this, I'll set
this aside for now.


I'm afraid I have broken proper sequence of this thread unintentionally.
This strip you quote comes from a message I eventually sent 14/Feb 
12:33, right after a message of yours at 12:29 in which you concluded:



From what I understand, this is not a bug in Org.  I hope you can fix
this somehow, maybe upstream.


The fact is that I was writing mine when yours came, and I didn't see 
yours until later. And when I did, the reply was:


I don't claim a problem persists in Org, and I was just trying to be 
thorough

in the testing you requested. And did so with pleasure. So...


From what I understand, this is not a bug in Org.


... if you are satisfied, I'm happy with that too.

Thank you very very much!


So, with the messages in proper order, I was taken the issue as settled.

If, however, you do think in my message of 12:29 I hit something which 
might be relevant, I'd be happy to pursue this further. I'm "not tired 
of the hunt", but I fear the issue might well be out of my league, so 
there is a real risk of me wasting your time and increasing the noise on 
the list. Besides, as reported before, it appears not to impact 
functionality. But, if knowing that, you would like me to do so, I'll be 
glad to try. In this case, let me know. Otherwise just:



set this aside for now.


And thanks again!

Best,
Gustavo.



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Bastien
Hi Samuel,

sorry to insist, but what I really need is a *fiable and easy* way to
reproduce a bug.  Other comments (like code analysis) are only useful
when I do have a reproducible bug.

I'm willing to spend as much time as needed on a MCE, but I'm waiting
for this MCE before interpreting comments on code and possible bugs.

Thanks for your understanding,

-- 
 Bastien



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Samuel Wales
i found a note that says that there isa nother disticnitont hat was
causing the bugs: a distinction between the current file and
non-current file.

it wreaks havoc to make that distinction.

* REF this works around the bugs
=this is in my personal patches

vvv
Modified   lisp/org.el
diff --git a/lisp/org.el b/lisp/org.el
index ec74314..695305c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11737,7 +11737,7 @@ this is used for the GOTO interface."
 (tbl (mapcar
   (lambda (x)
 (if (and (not (member org-refile-use-outline-path
-  '(file full-file-path)))
+  '(nil file full-file-path)))
  (not (equal filename (nth 1 x
 (cons (concat (car x) extra " ("
   (file-name-nondirectory (nth 1 x)) ")")

also, the line after the + line is clearly related to the
duplicate olpath and pointless current file vs. other file
distinction.

the workaround works because there is no olpath and no
filename now, so flex matching cannot screw with assuming
the default as easily.

ideally, however, we would show the filename but not match
on it in ido.
^^^

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html



Re: patch: add custom latex->html conversion command

2020-02-16 Thread Bastien
Hi Matt,

Matt Huszagh  writes:

> From 056d23d9e5caa6fc22907014e0128519fcc84b6e Mon Sep 17 00:00:00 2001
> From: Matt Huszagh 
> Date: Sat, 15 Feb 2020 18:42:11 -0800
> Subject: [PATCH] add custom command option when converting latex fragments to
>  html
>
> This allows you to set a custom command
> `org-latex-to-html-convert-command' that will take as input a latex
> fragment and use it to generate html for export. This is very
> open-ended in the sense that you can use any shell-command you want. I
> envisioned this for use with latexml, but there's nothing preventing
> you from using something else.

The commit message needs to be formatted using the Emacs changelog
format.  See `add-change-log-entry-other-window' on how to add a
changelog entry from a patch (or from magit's diff view).

> ---
>  lisp/org.el | 30 ++
>  lisp/ox-html.el |  9 +++--
>  2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 97ce7ec43..94557bf86 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -3203,6 +3203,22 @@ When using LaTeXML set this option to
> (const :tag "None" nil)
> (string :tag "\nShell command")))
>  
> +(defcustom org-latex-to-html-convert-command nil
> +  "Command to convert LaTeX fragments to HTML.
> +This command is very open-ended: the output of the command will
> +directly replace the latex fragment in the resulting HTML.
> +Replace format-specifiers in the command as noted below and use
> +`shell-command' to convert LaTeX to HTML.
> +%i: The latex fragment to be converted.
> +
> +For example, this could be used with LaTeXML as
> +\"latexmlc 'literal:%i' --profile=math --preload=siunitx.sty 2>/dev/null\"."
> +  :group 'org-latex
> +  :version "26.1"

No need for :version "26.1" (which is false).

Better add :package-version '(Org . "9.5") for when this will be in 9.5.

> +  :type '(choice
> +   (const :tag "None" nil)
> +   (string :tag "\nShell command")))
^ missing value ?

> +(defun org-format-latex-as-html (latex-frag)
> +  "Convert latex to html with a custom conversion command.
> +`LATEX-FRAG' is the latex fragment
> +Set the custom command with `org-latex-to-html-convert-command'."
> +  (let ((cmd (format-spec
> +   org-latex-to-html-convert-command
> +   `((?i . ,latex-frag)
  ^ indentation looks weird.

Otherwise it looks good.  Thanks!

-- 
 Bastien



Re: patch: add custom latex->html conversion command

2020-02-16 Thread Bastien
Matt Huszagh  writes:

> Thanks for the reply. I’ll look into it. However, I’d initially ruled
> that out because the final output is meant to be an image. So, to get
> just text insertion into the html output I imagine would be a bit of
> a hack. For instance what to set image-converter to etc.

Oh, I misunderstood what latexml does, it looks nice.  I'll comment on
your patch.

In the meantime, can you fill this form?
https://orgmode.org/request-assign-future.txt

You'll need this to contribute this patch, which will surely make its
way after 9.4, but still.

Thanks,

-- 
 Bastien



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Samuel Wales
your quote is from a many years old report.  i was providing it in
case it was useful historically.

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Samuel Wales
non-leaf olpaths are not usefully considered to be directories in my
opinion.  all olpaths should be equal in status.


On 2/16/20, Samuel Wales  wrote:
> On 2/14/20, Bastien  wrote:
>> What was the problem when refiling with ido?
>
> idk if the following will be useful but here goes.
>
> bear in mind this was a while back.  this is partly from memory.
>
> i don't know if the fix fixed all of them, but it definitely seemed
> to, at least with my ido settings.
>
> i tried ido settings.  but i recall thinking none of them worked.  it
> took years to fix it.  my computer use is limited.
>
> - the default was screwed up (more below) causing misfiling
> - there was distracting, inconsistent (sometimes appearing and
> sometimes not), and possibly redundant (i.e. extra olpaths in list)
> information in parentheses
> - similar, except with trailing slashes (this one might have had
> redundancy and inconsistency properties, the latter perhaps caused by
> the former, as in: you don't know which version of the olpath you will
> get in the default)
>
> the mechanism seemed to be designed for fs paths, not olpaths.  fs
> paths have a directory/nondirectory distinction, and this might have
> been related.  that distinction is bad for olpaths.
>
> i do not deal with files when refiling.  even if i did, there would
> still be no need for olpath directories for ido/ivy refiling.
>
> my olpaths when refiling are bare header lines.
>
> i think some but not all, olpaths got trailing slashes appended.
>
> i realize that's all vague.
>
> however, the fix made refiling change from dangerous and iffy and
> annoying to safer, more reliable, and fast (ido-clever-paths and
> ido-hacks also helped).
>
> i will not be able to retrace the problem less vaguely.
>
>
> as for the issues with the default, i reported at least one to the
> mailing list in some detail.  it provides repro instructions.
>
> i suspect trailing slash also caused a default problem.
>
> please note that i am using an old version of maint because i can't
> fix a capture bug that was introduced a while back.  it has perhaps
> been fixed since then, dunno.
>
>
> here is the report, for what it is worth:
>
> vvv
> ido and org-refile are a superb combination that enhances
> Org significantly.  It is a killer feature IMO.
>
> However, in my usage there is a substantial risk of
> misfiling:
>
>   1) If I start from a fresh Emacs, "myorg" is sufficient to
>  select "computer/emacs/org/myorg/".  Good.
>
>   2) If I refile something to
>  "computer/emacs/org/myorg/strategy and examples/various
>  todo kw and maybe some tags/", "various" is enough to
>  select it.  Note that this is below "myorg".  Good.
>
>   3) (Just as an aside, if I then refile something else to
>  the same entry, I don't even need to enter "various".
>  It is the default.  Good.)
>
>   4) Now suppose I want to refile something to "myorg".  I
>  enter "myorg" but I get "various".
>
> Detail on this subtle issue is below:
>
>
> My expectation is that if "myorg" selects "myorg" once, it
> should always do so no matter what my refile history is.
> This expectation is violated.
>
> It violates a sort of referential transparency.  The same
> narrowing inputs should produce the same narrowed outputs
> (in my expectation at least).
>
>
> I suspect the reason for the behavior is the defaulting in
> 3, which is useful.  However, the false defaulting in 4 is
> not useful in any obvious way.
>
>
> Proposed solution:
>
> I think that as soon as the user starts selecting something,
> the default should be discarded.
>
>
> With my expectation, it is never necessary to check the
> offered olpaths except as a confirmation.
>
> With the current behavior, checking is always necessary
> because in edge cases, there will be a guaranteed misfile.
>
> Here is why: the only reason that default showed up at all
> is that the narrowing input matched both
> headlines.  Otherwise the default would have been discarded.
>
> So it is an edge case that allowed the offer to misfile.  In
> other cases, the correct default would be provided.  If I
> wanted "various", RET would be sufficient.
>
> User checking is significantly more error-prone because one
> olpath is a substring of the other.
>
> Likewise, the requirement to navigate in the list is
> burdensome as 4 is never useful as far as I can tell.
>
>
> I tried looking at ido
> variables and got lost.
>
> If you can't reproduce witn your ido settings, I'll try to
> provide an MCE at some point.
>
> Thanks.
>
> Samuel
> ^^^
>
> --
> The Kafka Pandemic
>
> What is misopathy?
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Bastien
Hi Samuel,

Samuel Wales  writes:

> If you can't reproduce witn your ido settings, I'll try to
> provide an MCE at some point.

I don't use ido-mode, so I don't have any ido setting and It's
difficult for me to both understand and chase the bug.

I suggest you start by checking the bug is still here in latest
maint *and* latest master, then (only then) propose a MCE.

Thanks!

-- 
 Bastien



Re: patch: add custom latex->html conversion command

2020-02-16 Thread Matt Huszagh
Bastien,

Thanks for the reply. I’ll look into it. However, I’d initially ruled that
out because the final output is meant to be an image. So, to get just text
insertion into the html output I imagine would be a bit of a hack. For
instance what to set image-converter to etc.

Matt

On Sun, Feb 16, 2020 at 4:06 PM Bastien  wrote:

> Hi Matt,
>
> Matt Huszagh  writes:
>
> > The patch below allow's you to provide your own shell command the
> > generates HTML from a latex fragment and places the output directly in
> > the exported HTML file.
>
> Can you get the same output by configuring a new symbol in
> `org-preview-latex-process-alist' then setting `org-html-with-latex'
> to this new symbol?
>
> I've not tested it, so perhaps it does not work.
>
> But any patch about adding latexmlc support should surely look in this
> direction first.
>
> HTH,
>
> --
>  Bastien
>


Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Samuel Wales
On 2/14/20, Bastien  wrote:
> What was the problem when refiling with ido?

idk if the following will be useful but here goes.

bear in mind this was a while back.  this is partly from memory.

i don't know if the fix fixed all of them, but it definitely seemed
to, at least with my ido settings.

i tried ido settings.  but i recall thinking none of them worked.  it
took years to fix it.  my computer use is limited.

- the default was screwed up (more below) causing misfiling
- there was distracting, inconsistent (sometimes appearing and
sometimes not), and possibly redundant (i.e. extra olpaths in list)
information in parentheses
- similar, except with trailing slashes (this one might have had
redundancy and inconsistency properties, the latter perhaps caused by
the former, as in: you don't know which version of the olpath you will
get in the default)

the mechanism seemed to be designed for fs paths, not olpaths.  fs
paths have a directory/nondirectory distinction, and this might have
been related.  that distinction is bad for olpaths.

i do not deal with files when refiling.  even if i did, there would
still be no need for olpath directories for ido/ivy refiling.

my olpaths when refiling are bare header lines.

i think some but not all, olpaths got trailing slashes appended.

i realize that's all vague.

however, the fix made refiling change from dangerous and iffy and
annoying to safer, more reliable, and fast (ido-clever-paths and
ido-hacks also helped).

i will not be able to retrace the problem less vaguely.


as for the issues with the default, i reported at least one to the
mailing list in some detail.  it provides repro instructions.

i suspect trailing slash also caused a default problem.

please note that i am using an old version of maint because i can't
fix a capture bug that was introduced a while back.  it has perhaps
been fixed since then, dunno.


here is the report, for what it is worth:

vvv
ido and org-refile are a superb combination that enhances
Org significantly.  It is a killer feature IMO.

However, in my usage there is a substantial risk of
misfiling:

  1) If I start from a fresh Emacs, "myorg" is sufficient to
 select "computer/emacs/org/myorg/".  Good.

  2) If I refile something to
 "computer/emacs/org/myorg/strategy and examples/various
 todo kw and maybe some tags/", "various" is enough to
 select it.  Note that this is below "myorg".  Good.

  3) (Just as an aside, if I then refile something else to
 the same entry, I don't even need to enter "various".
 It is the default.  Good.)

  4) Now suppose I want to refile something to "myorg".  I
 enter "myorg" but I get "various".

Detail on this subtle issue is below:


My expectation is that if "myorg" selects "myorg" once, it
should always do so no matter what my refile history is.
This expectation is violated.

It violates a sort of referential transparency.  The same
narrowing inputs should produce the same narrowed outputs
(in my expectation at least).


I suspect the reason for the behavior is the defaulting in
3, which is useful.  However, the false defaulting in 4 is
not useful in any obvious way.


Proposed solution:

I think that as soon as the user starts selecting something,
the default should be discarded.


With my expectation, it is never necessary to check the
offered olpaths except as a confirmation.

With the current behavior, checking is always necessary
because in edge cases, there will be a guaranteed misfile.

Here is why: the only reason that default showed up at all
is that the narrowing input matched both
headlines.  Otherwise the default would have been discarded.

So it is an edge case that allowed the offer to misfile.  In
other cases, the correct default would be provided.  If I
wanted "various", RET would be sufficient.

User checking is significantly more error-prone because one
olpath is a substring of the other.

Likewise, the requirement to navigate in the list is
burdensome as 4 is never useful as far as I can tell.


I tried looking at ido
variables and got lost.

If you can't reproduce witn your ido settings, I'll try to
provide an MCE at some point.

Thanks.

Samuel
^^^

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html



Re: patch: add custom latex->html conversion command

2020-02-16 Thread Bastien
Hi Matt,

Matt Huszagh  writes:

> The patch below allow's you to provide your own shell command the
> generates HTML from a latex fragment and places the output directly in
> the exported HTML file.

Can you get the same output by configuring a new symbol in
`org-preview-latex-process-alist' then setting `org-html-with-latex'
to this new symbol?

I've not tested it, so perhaps it does not work.

But any patch about adding latexmlc support should surely look in this
direction first.

HTH,

-- 
 Bastien



Re: Load Org Babel Languages on Demand

2020-02-16 Thread Bastien
Hi Uros,

Uros Perisic  writes:

> I think this would make the org-mode literate programming experience
> significantly smoother.
>
> Any thoughts on including this in org-mode?

This looks like a good idea.  We are close to releasing 9.4, so it too
late for this release, but feel free to send a patch for this, we can
apply it later on.

Please read https://orgmode.org/worg/org-contribute.html if you want
to contribute a patch.

Thanks,

-- 
 Bastien



Re: attachment: link type export to HTML invalid attach dir

2020-02-16 Thread Bastien
Hi Nicolas,

Nicolas Goaziou  writes:

> That is subconscious, actually. I considered removing them,
> then hesitated, and it all ended up in an intermediate state. Removing
> it properly would require to remove :application property in the parser,
> too. At some point, this functionality needs to go, but it is not
> necessarily now.

FWIW, I'm for delaying the removal for 9.5, not 9.4.

-- 
 Bastien



Re: attachment: link type export to HTML invalid attach dir

2020-02-16 Thread Bastien
Hi Nicolas,

Nicolas Goaziou  writes:

> This is the first part of the suggested changes. These do not touch
> attachment modifications, but rather improve the tooling in "ol.el".

Thanks for working on this--and Kyle for the careful review.

> `org-link-parameters' accepts a new property, :open, which is
> like :follow, but function installed there is called with a universal
> prefix argument.

I'm not sure why the distinction between :open and :follow is needed
in the context of the discussion for exporting attachments: is it
because attachment need to be "open", not just followed?

> Also, :export function is called with a fourth argument, the export info
> channel. I updated the export back-ends to handle the new signature, and
> provided a compatibility layers for link libraries in the wild, which
> may still use three arguments.
>
> There are two new tools: `org-link-open-as-file' and
> `org-export-link-as-file'. They can be used as helper functions for,
> respectively, :open and :export functions.

> WDYT?

LGTM, feel free to go ahead when you want.

Thanks,

-- 
 Bastien



Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface

2020-02-16 Thread Bastien
Tim Cross  writes:

> Thanks for the response and work Bastien. I will check out the updated
> version when I get a chance.

Thanks.

> One point possibly relevant with regards to Clojurescript. I suspect
> there could be a reasonable use case when you consider clojurescipt in
> the context of node rather than just as a browser language. In
> particular, people have been using clojurescript to develop NPM packages
> that can be used in various ways for javascript projects. However, the
> right tool for doing this is likely shadow-cljs rather than clojure CLI
> tools - though it should also be possible just using the CLI tools.

Yes, I understand the need.  But the Clojure ecosystem is so rich in
tools that we need to get direct contributions from people using those
tools *and* Org babel.  Or at least make tests on how it could work.

I hope volunteers can help!

Cheers,

-- 
 Bastien



Re: Org agenda -- checking for invisible tasks after filtering...

2020-02-16 Thread Bastien
Hi Christian,

you might want to have a look at org-agenda-finalize-hook, though I'm
not sure it can help, I'm not familiar with org-super-agenda enough.

HTH,

-- 
 Bastien



Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface

2020-02-16 Thread Tim Cross


Thanks for the response and work Bastien. I will check out the updated
version when I get a chance.

One point possibly relevant with regards to Clojurescript. I suspect
there could be a reasonable use case when you consider clojurescipt in
the context of node rather than just as a browser language. In
particular, people have been using clojurescript to develop NPM packages
that can be used in various ways for javascript projects. However, the
right tool for doing this is likely shadow-cljs rather than clojure CLI
tools - though it should also be possible just using the CLI tools.

Tim

Bastien  writes:

> Hi Tim,
>
> thanks for your email.
>
> Tim Cross  writes:
>
>> I wonder if it would make sense to use shadow-cljs rather than cider as
>> a back end for evaluating clojurescript?
>
> I am inclined to question the usefulness of evaluating ClojureScript
> code *at all*.
>
>> More generally, I wonder if there would be any benefit in considering a
>> Clojure CLI Tools back end integration and bypassing CIDER altogether?
>
> Yes, I agree this would be better.
>
> I implemented (in master now) the support of inf-clojure.el to
> evaluate Clojure blocks.
>
> Inf-clojure is more lightweight than cider.
>
> Also, with (setq org-babel-clojure-backend 'inf-clojure) you can now
> add a :alias header arg to the src block and "clojure -Aalias" will
> then be called to launch the repl.
>
>> While I love CIDER, I'm not sure it is the right tool for a org-babel
>> type environment. I've recently been moving my projects from being lein
>> based to Clojure CLI tools based and while I still use CIDER for larger
>> development work, find the CLI great for basic execution of code. For
>> me, CIDER has a lot of additional overhead and complexity which is often
>> of little benefit to what I want via babel and I've found it to be a
>> very fragile environment.
>
> Yep, I agree again.
>
>> Sean Corfield has a great example deps.edn file at
>> https://github.com/seancorfield/doc-clojure and it shows how you can
>> hook in various different REPLs - for example, a basic socket based
>> REPL, which might provide a cleaner and more stable back end interface
>> for evaluating Clojure (and potentially clojurescript) for babel.
>
> I am not sure it is worth getting rid of inf-clojure.el altogether,
> but relying on tools.deps seems the way to go.
>
>> As I said, this is an initial and immature idea, but I think it could
>> provide a back end which was a little more like other babel back ends
>> and may be less fragile than one based on CIDER (plus I suspect it would
>> be faster). What do people think? Is this something worth investigating
>> further?
>
> Definitely!  Thanks for sharing these idea.
>
> Please try the latest ob-clojure.el from master and let me know what
> can be improved to better fit your (and others') needs.
>
> Thanks,


-- 
Tim Cross



Re: [PATCH] ob-plantuml: Support for plantuml as well as the current java+jar solution

2020-02-16 Thread Bastien
Hi Terje,

Terje Larsen  writes:

> You are welcome, I have never gotten around to sign the FSF papers as
> I thought it was a
> bit of a hassle, but with those clear instructions I have now started
> the process.

Thanks!

> I guess I have to wait until the process is done until I can
> resubmit?

Yes, exactly.  Thanks for contributing,

-- 
 Bastien



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-16 Thread Bastien
Hi Gustavo,

Gustavo Barros  writes:

> But the fact that 
> 'completing-read-default' returns the refile location with a double 
> trailing slash makes me think there is still something to be fixed in 
> 'org-refile-get-location'.

if you're not tired of the hunt, please tell us when you find what
needs to be fixed--since there is no bug attached to this, I'll set
this aside for now.

Thanks,

-- 
 Bastien



Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface

2020-02-16 Thread Bastien
Hi Tim,

thanks for your email.

Tim Cross  writes:

> I wonder if it would make sense to use shadow-cljs rather than cider as
> a back end for evaluating clojurescript?

I am inclined to question the usefulness of evaluating ClojureScript
code *at all*.

> More generally, I wonder if there would be any benefit in considering a
> Clojure CLI Tools back end integration and bypassing CIDER altogether?

Yes, I agree this would be better.

I implemented (in master now) the support of inf-clojure.el to
evaluate Clojure blocks.

Inf-clojure is more lightweight than cider.

Also, with (setq org-babel-clojure-backend 'inf-clojure) you can now
add a :alias header arg to the src block and "clojure -Aalias" will
then be called to launch the repl.

> While I love CIDER, I'm not sure it is the right tool for a org-babel
> type environment. I've recently been moving my projects from being lein
> based to Clojure CLI tools based and while I still use CIDER for larger
> development work, find the CLI great for basic execution of code. For
> me, CIDER has a lot of additional overhead and complexity which is often
> of little benefit to what I want via babel and I've found it to be a
> very fragile environment.

Yep, I agree again.

> Sean Corfield has a great example deps.edn file at
> https://github.com/seancorfield/doc-clojure and it shows how you can
> hook in various different REPLs - for example, a basic socket based
> REPL, which might provide a cleaner and more stable back end interface
> for evaluating Clojure (and potentially clojurescript) for babel.

I am not sure it is worth getting rid of inf-clojure.el altogether,
but relying on tools.deps seems the way to go.

> As I said, this is an initial and immature idea, but I think it could
> provide a back end which was a little more like other babel back ends
> and may be less fragile than one based on CIDER (plus I suspect it would
> be faster). What do people think? Is this something worth investigating
> further?

Definitely!  Thanks for sharing these idea.

Please try the latest ob-clojure.el from master and let me know what
can be improved to better fit your (and others') needs.

Thanks,

-- 
 Bastien



Re: ox-html: Bug or feature for export of title and meta information?

2020-02-16 Thread Jens Lechtenboerger
Hi there!

On 2020-02-15, at 15:02, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> the W3C Markup Validator [1] disagrees with this output from
>> ox-html (which I reduced to the essential parts):
>
> OK. I was talking about the Org syntax. I misread your initial report.
>
> I won't comment about the generated HTML. If needed, the HTML exporter
> can prevent parsing TITLE keyword.

I do not know what is needed.  Function org-html--build-meta-info
should return valid XHTML (also in case of HTML5, I believe that
Org syntax is preferable over ignored [1] HTML tags).

Based on the treatment of meta elements for author and description
in that function, alternatives might use org-element-interpret-data
(author) or not (description).  I do not understand the role of
org-element-interpret-data to generate author information.  Which
“non exportable objects” can be skipped by that function (as
mentioned in a comment in org-html--build-meta-info)?  Should they
also be skipped for description or title?

Best wishes
Jens

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title



Re: [PATCH] ob-plantuml: Support for plantuml as well as the current java+jar solution

2020-02-16 Thread Terje Larsen
Thank you Bastien,

You are welcome, I have never gotten around to sign the FSF papers as
I thought it was a
bit of a hassle, but with those clear instructions I have now started
the process. I guess
I have to wait until the process is done until I can resubmit?

On Wed, Feb 12, 2020 at 6:31 PM Bastien  wrote:
>
> Hi Terje,
>
> Terje Larsen  writes:
>
> > I have been missing this feature for a while and noticed it had already
> > been requested before (2014), See:
> > https://lists.gnu.org/archive/html/emacs-orgmode/2016-08/msg00105.html
> >
> > With this patch you can switch between using jar or plantuml. The idea
> > partly stemmed from plantuml-mode and my inability to use the default
> > implementation. You can see the implementation for plantuml-mode here:
> > https://github.com/skuro/plantuml-mode/pull/102/files
> >
> > My patch is available here:
> > https://code.orgmode.org/terlar/org-mode/commit/fbe245c0b09513ee5a6d3b189e112708b9d08da0
>
> Thanks for the patch -- I see you're already on the list of committers
> with TINYCHANGE: https://orgmode.org/worg/org-contribute.html#orgcd077ac
>
> Would you like to sign the FSF papers and resubmit your patch on top
> of current master?
>
> https://orgmode.org/request-assign-future.txt
>
> Thanks a lot,
>
> --
>  Bastien



-- 
// Terje Larsen



Re: Step by step tutorial on Worg on how to create a new export backend

2020-02-16 Thread Bastien
Hi Stig, Marcin, Jean-Christophe and Robert,

Stig Brautaset  writes:

> The primary source of `ox-jira.el' was once[1] an Org tutorial (to
> myself) for creating an Org export backend. If this is broadly what you
> had in mind, I can dig that out of Git history and put it on Worg.

Yes, I think that would be a good start:

> https://github.com/stig/ox-jira.el/blob/c4b8fd30c3bc48621759c9d128644d2d386e591e/ox-jira.org

Then, after you commit an edited version of these instructions, maybe
Robert and Marcin can help reviewing and enhancing it to ensure it is
self-sufficient and explicit enough?

Let me know if you don't already have push access to worg.git.

Thanks!

-- 
 Bastien



Re: ox-html: Bug or feature for export of title and meta information?

2020-02-16 Thread Bastien
Hi Nicolas,

Nicolas Goaziou  writes:

> I don't think so. It is a constant, which may only matter when you write
> an export-backend. Its value is not even particularly important since
> any back-end can ignore it. Only its syntax really matters, as pointed
> out in, e.g., `org-export-define-derived-backend' docstring. To sum it
> up, I see it is an implementation detail.

I see, thanks.

> The manual might, however, be more rigorous about what keywords each
> back-end really interprets. I don't know how, and where, it could fit,
> tho.

I guess a tutorial on how to write a new export backend will give us a
hint on where and how to mention this. I am not sure it belongs to the
manual.

Best,

-- 
 Bastien



Re: Bug: refiling gobbles a newline and absorbs the next heading [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

2020-02-16 Thread Bastien
Hi Miguel,

Miguel Morin  writes:

> I have no compelling reason to delete those lines, it just sometimes
> happens that I do delete when I do a quick capture, and then they
> wreak havoc in my main org buffer. No longer, thanks to you!

Glad the change can still whatever habits you have.

Best,

-- 
 Bastien



Re: Org agenda -- checking for invisible tasks after filtering...

2020-02-16 Thread Christian Schwarzgruber
Hi Bastien,

Bastien  writes:

> Christian Schwarzgruber  writes:
>
>> The question is now, is it possible to further reduce the advised
>> functions to just one advised function.
>
> I am sorry, I don't understand what change does it imply on Org's
> side.  Can you explain us a bit more?

Nothing need to be changed on Org's side (I guess). I'm just wondering if there
is a single spot where I can hook in (advice) to achieve the same as with the
currently two advice I use.

The project org-super-agenda advices `org-agenda-finalize-entries` and groups
the entries. However, when one uses the org filter functionality some groups
might be empty, which looks ugly. My implementation to handle that case is to
advice the following functions `org-agenda-filter-apply` and
`org-agenda-finalize`. Both will call the same function
`org-super-agenda--hide-or-show-groups`. If all tasks inside a group have the
invisible property set the group gets hidden as well, and vica versa.

The author of `org-super-agenda` doesn't like my implementation which uses
two advice. But I couldn't find a single spot where I can hook in, and check if
all tasks are hidden...


Thanks!

Christian



Re: attachment: link type export to HTML invalid attach dir

2020-02-16 Thread Nicolas Goaziou
Hello,

Kyle Meyer  writes:

> It looks like a good direction to go.

Thank you for the feedback!

I fixed the various typos you mentioned.

> As far as I can see (by looking at the diff and quickly testing), the
> file+{sys,emacs} functionality is being removed.  That's probably
> okay/intended, given that it was marked as deprecated in 9.0.  But
> perhaps it's worth mentioning in ORG-NEWS that this functionality has
> now been removed entirely.

Good catch! That is subconscious, actually. I considered removing them,
then hesitated, and it all ended up in an intermediate state. Removing
it properly would require to remove :application property in the parser,
too. At some point, this functionality needs to go, but it is not
necessarily now. I can add it back if needed. Otherwise, I will remove
it completely in a subsequent patch.

Removing this feature may not break existing documents, however. Indeed,
with the suggested tooling, we may simply make "file+sys" and
"file+emacs" aliases for "file" in "org-compat.el". IOW, they would do
nothing more than regular file links, except maybe send an obnoxious
message to the user (linter already does this).

I didn't write the required ORG-NEWS entry because we are not settled on
the final design. I agree all the changes discussed here have to be
mentioned in that file.

Regards,

-- 
Nicolas Goaziou



Re: Step by step tutorial on Worg on how to create a new export backend

2020-02-16 Thread Stig Brautaset
Bastien  writes:

> We have a good reference documentation for creating export backends:
> https://orgmode.org/worg/dev/org-export-reference.html
>
> But we *badly* need a step by step tutorial on Worg.
>
> Anyone would like to volunteer for writing such a tutorial?

The primary source of `ox-jira.el' was once[1] an Org tutorial (to
myself) for creating an Org export backend. If this is broadly what you
had in mind, I can dig that out of Git history and put it on Worg. I
won't be able to do substantial edits or updates, as I made it 4 years
ago and it is still my only attempt at creating a backend. (So I have
forgotten most of it.) I still use it and it does pretty much what I
need it to, however.

https://github.com/stig/ox-jira.el/blob/c4b8fd30c3bc48621759c9d128644d2d386e591e/ox-jira.org

Stig

[1] Contributors got confused about the tangle step, probably because
melpa required me to commit the tangled .el as well as the .org source
file, so to make it simpler for them I since changed to shipping only
the tangled file. 



Re: Step by step tutorial on Worg on how to create a new export backend

2020-02-16 Thread Jean-Christophe Helary



> On Feb 16, 2020, at 17:05, Marcin Borkowski  wrote:
> 
> 
> On 2020-02-16, at 01:46, Jean-Christophe Helary 
>  wrote:
> 
>>> On Feb 16, 2020, at 2:55, Marcin Borkowski  wrote:
>>> 
>>> 
>>> On 2020-02-14, at 21:48, Bastien  wrote:
>>> 
 We have a good reference documentation for creating export backends:
 https://orgmode.org/worg/dev/org-export-reference.html
 
 But we *badly* need a step by step tutorial on Worg.
 
 Anyone would like to volunteer for writing such a tutorial?
>>> 
>>> I might try to at least start it, though I'll need some time.  When is
>>> that needed?  (I assume that the sooner, the better, so if there is
>>> anyone who would beat me to it, go on.  I might do some proofreading
>>> then.)
>> 
>> Marcin,
>> 
>> Aren't you supposed to write a book about Emacs already ? ;)
> 
> Yep, point taken.

I'm really not picking on you or anything :) I just realized that I would have 
written *exactly* the same thing in other contexts knowing that my plate is 
already over-full.

> But the tutorial is a much smaller thing, and
> I already did a similar thing (the Emacs Conf 2015 talk on creating
> derived exporters), so much of the work is already done.

And I'd love to read that.


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune





Re: Step by step tutorial on Worg on how to create a new export backend

2020-02-16 Thread Marcin Borkowski


On 2020-02-16, at 01:46, Jean-Christophe Helary 
 wrote:

>> On Feb 16, 2020, at 2:55, Marcin Borkowski  wrote:
>>
>>
>> On 2020-02-14, at 21:48, Bastien  wrote:
>>
>>> We have a good reference documentation for creating export backends:
>>> https://orgmode.org/worg/dev/org-export-reference.html
>>>
>>> But we *badly* need a step by step tutorial on Worg.
>>>
>>> Anyone would like to volunteer for writing such a tutorial?
>>
>> I might try to at least start it, though I'll need some time.  When is
>> that needed?  (I assume that the sooner, the better, so if there is
>> anyone who would beat me to it, go on.  I might do some proofreading
>> then.)
>
> Marcin,
>
> Aren't you supposed to write a book about Emacs already ? ;)

Yep, point taken.  But the tutorial is a much smaller thing, and
I already did a similar thing (the Emacs Conf 2015 talk on creating
derived exporters), so much of the work is already done.

Best,

--
Marcin Borkowski
http://mbork.pl