Re: How to export to the simplest possible HTML?

[Ihor Radchenko]

Marcin Borkowski  writes:

> On 2023-05-30, at 20:45, Marcin Borkowski  wrote:
>
>>> Just use `org-export-as'.
>>
>> Thanks again, I didn't know about that function!
>
> I tried playing around with it, but it has one drawback - I can't use it
> to export a subtree containing a link to another subtree, and that is
> something I will definitely need.  (I can see why it works that way -
> for that to work, I have to somehow make sure that subtrees containing
> targets of those links are also exported at some point in time - but
> I need another behavior...)

AFAIR, ox-hugo implements what you want here.

> My current idea is to go with a custom exporter derived from the HTML
> one, indeed.  Is there a better approach?

You can loop over links in the exported subtree and export any extra if
necessary. For example, in the `org-export-filter-parse-tree-functions'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How to export to the simplest possible HTML?

[Marcin Borkowski]

On 2023-05-30, at 20:45, Marcin Borkowski  wrote:

>> Just use `org-export-as'.
>
> Thanks again, I didn't know about that function!

I tried playing around with it, but it has one drawback - I can't use it
to export a subtree containing a link to another subtree, and that is
something I will definitely need.  (I can see why it works that way -
for that to work, I have to somehow make sure that subtrees containing
targets of those links are also exported at some point in time - but
I need another behavior...)

My current idea is to go with a custom exporter derived from the HTML
one, indeed.  Is there a better approach?

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: org code and error catching

[Michael Heerdegen]

Ihor Radchenko  writes:

> > Though, I think you didn't change the occurrence that this thread
> > started with - `org-eval'.  Does changing this one cause problems?
>
> Tests are passing.
> I originally skipped it because it did not look useful from a brief
> glance to have full backtraces there, and I was unsure if it is truly
> safe.

I don't recall either why I originally needed backtraces for it.  There
was a reason, but I don't remember.

> I see no obvious downsides though.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1cb5de621

Thanks, Ihor.


Michael.

Re: [PATCH] org.el: inline display of attached images in link descriptions

[Steven Allen]

You're right and now I have no idea what I was testing. I'm
apologize for that.

The attached patch should actually work this time. It's not great (setq
in a let), but anything else would likely be a much larger change.

>From 6ca24ca705fc3856c68957cfa50dfce77c9148c9 Mon Sep 17 00:00:00 2001
From: Steven Allen 
Date: Thu, 1 Jun 2023 11:49:19 -0700
Subject: [PATCH] org.el: inline display of attached images in link
 descriptions

* lisp/org.el (org-display-inline-images): inline display of attached
images in link descriptions.

Previously, `org-display-inline-images' only inlined images in link
descriptions when they were explicit "file:" links. This change adds
support for "attachment:" links. E.g.:

[[https://orgmode.org][attachment:emacs-screenshot.png]]
---
 lisp/org.el | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 0e5740412..405cae9a5 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16301,7 +16301,8 @@ defun org-create-formula-image
 
   2. Its description consists in a single link of the previous
  type.  In this case, that link must be a well-formed plain
- or angle link, i.e., it must have an explicit \"file\" type.
+ or angle link, i.e., it must have an explicit \"file\" or
+ \"attachment\" type.
 
 Equip each image with the key-map `image-map'.
 
@@ -16332,7 +16333,7 @@ defun org-create-formula-image
 	   ;; "file:" links.  Also check link abbreviations since
 	   ;; some might expand to "file" links.
 	   (file-types-re
-		(format "\\[\\[\\(?:file%s:\\|attachment:\\|[./~]\\)\\|\\]\\[\\(

Re: [PATCH] float format specifier in ob-C.el

[Leo Butler]

On Fri, Jun 02 2023, Ihor Radchenko  wrote:

> Thanks!
> Applied, onto bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d55a11214

Thanks, Ihor.
Leo

Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Ihor Radchenko  writes:

> Zelphir Kaltstahl  writes:
>
>>> This is expected. Noweb includes the src block code without altering it.
>>> See 16.11 Noweb Reference Syntax
>>>
>>> We may probably clarify this in the manual. Would it be helpful?
>> I think it would be helpful. I merely tried Python, because it was at hand 
>> and 
>> because I did not find ob-racket in M-x package-list RET and did not have 
>> another Scheme installed. Cannot say, whether others find the behavior 
>> confusing 
>> or not, but I imagine I would find it helpful, if it was mentioned in the 
>> docs.
>
> See the attached tentative patch.

Applied, with amendments. I moved the example to a footnote. Otherwise,
the section flow does not read right.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dbb451dc9

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Ihor Radchenko]

Bruno Barbier  writes:

>> I can see that you limited the tests scope to :session blocks.
>> Would it be possible to extend the existing tests to :compile yes case?
>> From a glance, it does not look like you need to change much - Haskell
>> behaviour should be similar with or without ghci.
>
> Except for one line expressions, GHCi inputs and haskell modules are
> two different things.  I doubt there will be much to share; that's why
> I've focused from the start on GHCi only.

Fair point. I thought that the differences are less significant.

>>> +(sleep-for 0.25)
>>> +;; Disable secondary prompt.
>>
>> It would be useful to explain the purpose of disabling the secondary
>> prompt in the source code comment itself, not just in the commit
>> message. It will improve readability.
>
> Are you reviewing your own improvements ? :-)

Sure. Why not :3 Nobody guaranteed that my code is free of errors.

> Fixed. I've copied/pasted your explanation in the code.

Thanks!

>> Also, session may be a killed buffer object. It is still a buffer, but
>> not usable. See `buffer-live-p'.
>
> By construction, if 'session' is a buffer, then, it is a live buffer.

You are probably right. Even though killed buffer objects may appear in
Elisp (28.10 Killing Buffers), their buffer names should be nil, and thus
they cannot be returned by `get-buffer'.

>>> +  (when (bufferp "*haskell*") (error "Conflicting buffer 
>>> '*haskell*', rename it or kill it."))
>>> +  (with-current-buffer session (rename-buffer "*haskell*")))
>>
>> So, you are now renaming the unique session buffer back to "*haskell*".
>> And never rename it back to expected :session . Users might be 
>> confused.
>
> I do rename it back once inf-haskell has initialized the buffer (after
> run-haskell in the last version).

A comment would help to clarify things for the readers.

>>> +(save-window-excursion
>>> +  ;; We don't use `run-haskell' to not popup the buffer.
>>> +  ;; And we protect default-directory.
>>> +  (let ((default-directory default-directory))
>>> +(inferior-haskell-start-process))
>>
>> This is a workaround for a nasty side effect of running
>> `inferior-haskell-start-process'. We should report this to haskell-mode
>> developers, leaving appropriate comment in the code.
>
> About 'run-haskell', I reverted my change: we're inside a
> 'save-window-excursion', which looks like the standard way to get rid
> of unwanted popups (like ob-shell does).
>
> About 'default-directory', I'm not sure. Maybe the side effect is done
> on purpose in inf-haskell.

I can see the haskell-mode overrides default-directory with
`inferior-haskell-root-dir', running ghci in that directory, if it is
non-nil. Even with your let binding, it is calling for trouble when
source block uses :dir header argument.

Maybe we can bind `inferior-haskell-root-dir' to `default-directory'
instead? `default-directory' is modified according to :dir by ob-core.el
when necessary.

> The function 'putStr' output the string without a newline on stdout
> (as opposed to the function putStrLn that does add a newline).
>
> So, in GHCi, entering:
>
> putStr("4")
> 
> outputs "4" on stdout, then GHCi outputs the prompt, so we get:
>
> 4ghci> 
>
> In the end, 'org-babel-comint-with-output' gets this
> 1ghci> 2ghci> 3ghci> 
> ghci> org-babel-haskell-eoe
> ghci> ghci>
> 
> and filters out everything as being GHCi prompts and the EOE.
>
> I'm not really expecting this to be fixed; I just wanted to record the
> fact.

We actually might be able to deal with this if we change the prompt and
update comint-prompt-regexp to something more accurate.

>>> Subject: [PATCH 11/13] lisp/ob-haskell.el: Fix how to use sessions
>>>
>>> +  (org-babel-haskell-with-session
>>
>> This kind of names are usually dedicated to macro calls. But
>> `org-babel-haskell-with-session' is instead a function. I think a macro
>> will be better. And you will be able to get rid of unnecessary lambda.
>
> That looks kind of complicated just to avoid one lambda in one call.
> But, as I couldn't find a better name, I've translated it into a
> macro.

I think you misunderstood what I meant.
See the attached diff on top of your patches that simplifies things a
bit.

diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index cd930266c..a8240d02b 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -77,31 +77,28 @@ (defcustom org-babel-haskell-compiler "ghc"
 (defconst org-babel-header-args:haskell '((compile . :any))
   "Haskell-specific header arguments.")
 
-
-(defun org-babel-haskell-with-session--worker (params todo)
-  "See `org-babel-haskell-with-session'."
-  (let* ((sn (cdr (assq :session params)))
- (session (org-babel-haskell-initiate-session sn params))
- (one-shot (equal sn "none")))
-(unwind-protect
-(funcall todo session)
-  (when (and one-shot (buffer-live-p 

Re: org code and error catching

[Ihor Radchenko]

Michael Heerdegen  writes:

> Michael Heerdegen  writes:
>
>> I reviewed it shortly - looks appropriate.
>
> Though, I think you didn't change the occurrence that this thread
> started with - `org-eval'.  Does changing this one cause problems?

Tests are passing.
I originally skipped it because it did not look useful from a brief
glance to have full backtraces there, and I was unsure if it is truly
safe.

I see no obvious downsides though.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1cb5de621

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org.el: inline display of attached images in link descriptions

[Ihor Radchenko]

Steven Allen  writes:

> * lisp/org.el (org-display-inline-images): inline display of attached
> images in link descriptions.
>
> Previously, `org-display-inline-images' only inlined images in link
> descriptions when they were explicit "file:" links. This change adds
> support for "attachment:" links. E.g.:
>
> [[https://orgmode.org][attachment:emacs-screenshot.png]]

Thanks for the patch, but it does not actually make Org display the
example link from the commit message.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-manual: Mark up nil as ~nil~ [9.6.6 (release_9.6.6 @ /home/blc/.local/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Basil L. Contovounesios via "General discussions about Org-mode."
 writes:

> In emacs.git I noticed some occurrences of 'nil' in the generated
> doc/misc/org.texi were not marked up as @code.
>
> Is this TRT?  (I already have an Emacs CA on file.)

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a00889997

I also marked your copyright status a complete in our records, confirmed
by Emacs commits.
https://git.sr.ht/~bzg/worg/commit/dcd6afb9

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] float format specifier in ob-C.el

[Ihor Radchenko]

Leo Butler  writes:

> Ok, I have made the changes requested. Please see the attached patch.

Thanks!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d55a11214

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at