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

[Zelphir Kaltstahl]

On 3/8/23 20:38, Bruno Barbier wrote:

Hi Zelphir,

Zelphir Kaltstahl  writes:


On 3/7/23 20:52, Bruno Barbier wrote:
Also thanks for the idea with sessions + separate import source block. I thought
that should work, but apparently that also has the same error, when running for
the first time:

...

Oh, I see. I tested something way simpler :-)

First, one block to open and configure the guile session.

  #+begin_src scheme :session "!guile" :results silent
  (import (except (rnrs base) error vector-map)
   (only (guile)
 lambda*
 λ)
   ;; let-values
   (srfi srfi-11))
  #+end_src

Then, you can get to work and evaluate as many blocks as you like in
that session:

  #+begin_src scheme :session "!guile" :results output replace drawer :var 
x=1 :var y=2
  (let-values ([(a b) (values x y)])
 (simple-format #t "~a ~a\n" a b))
  #+end_src

  #+RESULTS:
  :results:
  1 2
  :end:

Bruno

Hello Bruno and hello mailing list!

I just tested it a little more:

If there is any (import ...) at all in the code block that makes use of the 
(let-values ...), it seems to somehow disturb already imported libraries. For 
example the following also does not work:


START
#+name: scheme-time-imports
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer"
(import
 (except (rnrs base) error vector-map)
 (only (guile)
   lambda*
   λ)
 ;; let-values
 (srfi srfi-11))
#+end_src

#+RESULTS: scheme-time-imports

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer :var x=1 :var y=2
<>
(import (srfi srfi-1))
(let-values ([(a b) (values x y)])
   (simple-format #t "~a ~a\n" a b))
#+end_src
~END~

So that means, even if the import has nothing to do with the actual import which 
would provide the let-values form, it disturbs it.


I am not sure (let ...) is a correct wrapper for noweb included source blocks. 
What, if I write a (define ...) in my source block and want to use that source 
block via noweb in another source block? Expected behavior I think would be to 
be able to access those variables in other source blocks, since they are defined 
on a top level in an earlier source block, but if they are wrapped in a (let 
...), that would make them only available in the (let ...)? It seems to me, that 
the simple wrapping with a (let ...) might not be the right thing to do. Testing 
that:


START
#+name: scheme-defs
#+begin_src scheme :eval query-export :noweb strip-export :session myguile 
:results output replace drawer :var x=1 :var y=2
(define a x)
(define b y)
#+end_src

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session myguile 
:results output replace drawer
<>
(simple-format #t "~a ~a\n" a b)
#+end_src
~END~

Indeed, that also does not work.

I guess I did never hit this problem earlier, because I "oursourced" my imports 
and in imports I do not need any :var header arguments.


I've asked on the Guile IRC channel and something interesting is the case here 
(thanks for clearing it up flatwhatson!) and I understand it as follows:


Imports inside (let ...) work. It is just that let-values is a macro and macros 
are expanded before execution time. However, Guile gets to the body of the 
wrapping (let ...) at execution time. That means, that when Guile gets to 
evaluate the body of the let, it does not expand the let-values, because it is 
already at execution time and no longer at macro expansion time. The import 
might import the let-values form, or might not, but it is already too late to 
expand the (let-values ...).


What is still a bit weird about it is, that in the original example with 
`let-values` I don't get an error about `let-values` not being defined, but only 
about `a` not being defined. And in the example with (define ...) and :var 
above, I get a message about `x` not being defined, instead of `a` not being 
defined.


Probably a good general workaround is to only have imports at the top level, by 
moving them into a source block, which does not have any :var header arguments.


OK, the question is though, whether org should wrap anything in a (let ...) at 
all. During discussion on the Guile IRC, some points against let-wrapping were 
brought up:


(1) The presence of a :var header argument currently determines, whether the 
code in the source block is wrapped with a (let ...). One argument for that was, 
that this way the variables do not leak. But this also decides, whether other 
things leak. For example (import ...) or (define ...). Should :var decide, 
whether bindings created with (define ...) are visible in other source blocks 
including the source block with the :var header arguments? It seems like a 
responsibility :var should not have and definitely is unexpected for the 

Re: visual-line-mode don't play well with org-latex-preview

[chris]

On Wednesday, 8 March 2023 20:14:53 CET Bruno Barbier wrote:
> 
> Hi Chris,
> 
> chris  writes:
> 
> > On Thursday, 2 March 2023 20:00:14 CET Bruno Barbier wrote: 
> >> The behavior looks the same using only text-mode (without using org).
> >> You should probably report this as an Emacs bug (see M-x
> >> report-emacs-bug).
> >
> > What command for latex preview in text mode? (I'll probably figure that 
> > out.)
> >
> 
> org-latex-preview. Why ? :-)
> 
> 
> > Yes, I should definitely report that bug.
> 
> In case it helps you to report the bug, here is the minimal way I found
> to reproduce it (no latex, no org):
> 
>  #+begin_src elisp
>(let ((b (generate-new-buffer "=bug")))
>  (with-current-buffer b
>(dotimes (_ 110) (insert "Hello "))
>(insert-image (svg-image (let ((s (svg-create 250 9)))
>(svg-line s 0 0 250 9 :stroke-color 
> "green")
>s)))
>(org-mode)
>(visual-line-mode 1)
>(pop-to-buffer b)))
>  #+end_src

Amazing,
Chris

> 
> Bruno
> 

Re: [PATCH] org-src: Improve the name of source editing buffers

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> net-utils.el also has "*ftp [host]*". Notably, with space.
> I found no other use of [...] in Emacs sources.

Looking at my buffers, I see:

- e.g. "FILE" from Project.el
- e.g. "*EGLOT (PROJECT/(MODE)) events*" from Eglot
- e.g. "magit-diff(FILE1 -- FILE2): PROJECT" from Magit

All "normal looking" (spacing-wise), unlike e.g. "*Org Src FILE[ MODE ]*".

> Could you list other packages that use Foo[bar] pattern in buffer names?

Most packages use (), but I went with a minimal change, fixing just the weird
use of whitespace.

P.S. <> is for projects, so we should not use that, IMO.

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't.  That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

[Bruno Barbier]

Hi Zelphir,

Zelphir Kaltstahl  writes:

> On 3/7/23 20:52, Bruno Barbier wrote:

> Also thanks for the idea with sessions + separate import source block. I 
> thought 
> that should work, but apparently that also has the same error, when running 
> for 
> the first time:
>
> ...

Oh, I see. I tested something way simpler :-)

First, one block to open and configure the guile session.

 #+begin_src scheme :session "!guile" :results silent
 (import (except (rnrs base) error vector-map)
  (only (guile)
lambda*
λ)
  ;; let-values
  (srfi srfi-11))
 #+end_src

Then, you can get to work and evaluate as many blocks as you like in
that session:

 #+begin_src scheme :session "!guile" :results output replace drawer :var 
x=1 :var y=2
 (let-values ([(a b) (values x y)])
(simple-format #t "~a ~a\n" a b))
 #+end_src

 #+RESULTS:
 :results:
 1 2
 :end:

Bruno

Re: visual-line-mode don't play well with org-latex-preview

[Bruno Barbier]

Hi Chris,

chris  writes:

> On Thursday, 2 March 2023 20:00:14 CET Bruno Barbier wrote: 
>> The behavior looks the same using only text-mode (without using org).
>> You should probably report this as an Emacs bug (see M-x
>> report-emacs-bug).
>
> What command for latex preview in text mode? (I'll probably figure that out.)
>

org-latex-preview. Why ? :-)


> Yes, I should definitely report that bug.

In case it helps you to report the bug, here is the minimal way I found
to reproduce it (no latex, no org):

 #+begin_src elisp
   (let ((b (generate-new-buffer "=bug")))
 (with-current-buffer b
   (dotimes (_ 110) (insert "Hello "))
   (insert-image (svg-image (let ((s (svg-create 250 9)))
   (svg-line s 0 0 250 9 :stroke-color "green")
   s)))
   (org-mode)
   (visual-line-mode 1)
   (pop-to-buffer b)))
 #+end_src

Bruno

Re: how to add special glyphs

[Pedro Andres Aranda Gutierrez]

BTW,

for listings, this seems to help with the backslashes

\usepackage{upquote}
\newcommand{\BSL}{\char`\\}

Best, /PA

On Wed, 8 Mar 2023 at 16:14, Rob Sargent  wrote:
>
>
>
> > On Mar 8, 2023, at 3:09 AM, Pedro Andres Aranda Gutierrez 
> >  wrote:
> >
> > On 3/6/23 Rob Sargent  wrote:
> >
> >> I think I have to decide on one format and stick with it.  I get bitten
> >> by ODT/DOC transformations, not sure I like the default look of
> >> LaTeX/pdf, HTML is pretty reliable but not best for handing out. Maybe
> >> I'll go back to "text" and call it good.
> >
> > If my .2 cents can help:
> >
> > At the end, I bargained with myself and settled for PDF/LaTeX. I'm using
> >
> > #+LATEX_HEADER: \usepackage{helvet}
> > #+LATEX_HEADER: \renewcommand\familydefault{\sfdefault}
> >
> > for SansSerif fonts after some reading about adapted documents. They
> > seem to work well with most LaTeX classes as well as Beamer
> > presentations and handouts.
> >
> > I'm spending time with listing exports because I'm not against some
> > code samples being available for *reliable* copy and paste and the
> > current exporters in LaTeX don't completely please me (but that's the
> > real danger with LaTeX, noone but me to blame for it ;-) )
> >
> > Best, /PA
> > --
> > Fragen sind nicht da um beantwortet zu werden,
> > Fragen sind da um gestellt zu werden
> > Georg Kreisler
> >
> > Headaches with a Juju log:
> > unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
> > run a leader-deposed hook here, but we can't yet
> >
>
> It very much helps. Thank you
>
> rjs



-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

Re: [PATCH] Fix ob-latex.el command injection vulnerability.

[lux]

On Tue, 2023-03-07 at 22:31 +0700, Max Nikulin wrote:
> On 06/03/2023 10:17, lux wrote:
> > On Sat, 2023-02-18 at 11:43 +, Ihor Radchenko wrote:
> > > 
> > > I think should be (rename-file img-out out-file t)
> > 
> > Fixed, thank you.
> 
> There are a couple more mv shell commands in ob-latex.el. It would be
> nice to fix them as well. Sorry, I have not checked it earlier. Are
> you 
> still interested in this topic? I hope, you already have examples
> that 
> can be used to quickly test if modified code works as expected.

Hi, this is a new patch, let me briefly explain this patch:

1. Replaced the `(shell-command "mv BAR NEWBAR")' with `rename-file'.

2. `org-babel-latex-convert-pdf' is not safe, simple test:

(org-babel-latex-convert-pdf ";id;.tex" ";uname;.pdf" "" "")

So, add `shell-quote-argument' to each external parameter.
From 62f9d32decdd078633e51ea9fa30fdb000b6de51 Mon Sep 17 00:00:00 2001
From: Xi Lu 
Date: Wed, 8 Mar 2023 23:28:32 +0800
Subject: [PATCH] * lisp/ob-latex.el: Fix command injection vulnerability

(org-babel-execute:latex): Fix command injection vulnerability
(org-babel-latex-convert-pdf): Add `shell-quote-argument'
---
 lisp/ob-latex.el | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index a2c24b3d9..2315a8b7c 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -218,17 +218,14 @@ This function is called by `org-babel-execute-src-block'."
 	(if (string-suffix-p ".svg" out-file)
 		(progn
 		  (shell-command "pwd")
-		  (shell-command (format "mv %s %s"
-	 (concat (file-name-sans-extension tex-file) "-1.svg")
-	 out-file)))
+  (rename-file (concat (file-name-sans-extension tex-file) "-1.svg")
+   out-file t))
 	  (error "SVG file produced but HTML file requested")))
 	   ((file-exists-p (concat (file-name-sans-extension tex-file) ".html"))
 	(if (string-suffix-p ".html" out-file)
-		(shell-command "mv %s %s"
-			   (concat (file-name-sans-extension tex-file)
-   ".html")
-			   out-file)
-	  (error "HTML file produced but SVG file requested")
+(rename-file (concat (file-name-sans-extension tex-file) ".html")
+ out-file t)
+  (error "HTML file produced but SVG file requested")
 	 ((or (string= "pdf" extension) imagemagick)
 	  (with-temp-file tex-file
 	(require 'ox-latex)
@@ -277,8 +274,10 @@ This function is called by `org-babel-execute-src-block'."
 
 (defun org-babel-latex-convert-pdf (pdffile out-file im-in-options im-out-options)
   "Generate a file from a pdf file using imagemagick."
-  (let ((cmd (concat "convert " im-in-options " " pdffile " "
-		 im-out-options " " out-file)))
+  (let ((cmd (concat "convert " (shell-quote-argument im-in-options) " "
+ (shell-quote-argument pdffile) " "
+		 (shell-quote-argument im-out-options) " "
+ (shell-quote-argument out-file
 (message "Converting pdffile file %s..." cmd)
 (shell-command cmd)))
 
-- 
2.39.2

Re: Key binding in help (was: Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.)

[Max Nikulin]

On 26/02/2023 06:32, Samuel Wales wrote:

i acccomplished this with (define-key org-mode-map (quote [C-tab])
(quote org-next-link)) [kbd would be better].

...

i.e. like m-. on a function name, if that is set up to work, or c-h f
command tab ret to go to the fuction definition, but for keys.


I do not mind to have such feature as well. If you really want to get 
it, you should send a feature request to bug-gnu-emacs.



On 23/02/2023 11:48, Samuel Wales wrote:

[there are probably 300 competing packages that
do exactly that.]


I expect that it should be implemented in Emacs core since updated 
`define-key' should be available rather early during initialization. 
Looking into

https://www.gnu.org/software/emacs/manual/html_node/elisp/Format-of-Keymaps.html
https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Lookup.html
I do not see a ready to use slot for location of key definition. Another 
point is that keymap extension should not noticeably affect performance.

Re: how to add special glyphs

[Rob Sargent]

> On Mar 8, 2023, at 7:59 AM, Max Nikulin  wrote:
> 
> On 08/03/2023 07:29, Rob Sargent wrote:
>>> LuaLaTeX may be instructed to use fallback fonts, see e.g.
> ...
>>> To my taste it is too low level.
>> That I placed the unicode into the text was "too low level"?  I could argue 
>> that "it's a UTF doc", or that "\ding{55}" is bizarrely high level.  Other's 
>> have shown methods which maximize the cross export experience.  I'll 
>> consider those.  I'm not sure LuaLaTex is an option for me.
> 
> I would prefer to use Unicode symbols in UTF-8 encoded documents. While 
> browsers and office software tries to find some substitution when some glyph 
> is not available in requested font, configuration of LaTeX engines is more 
> complicated. Support of Unicode in LuaTeX is much better than in pdfTeX. 
> Unfortunately for characters outside of ~latin-1 set, all fonts must be 
> carefully configured. I consider necessity to specify font per language and 
> fallback fonts as too low level operations for regular users.
> 
> I do not see a robust way to determine fonts available for LaTeX to implement 
> automatic configuration in ox-latex with reasonable amount of code.
> 
> I recommend to consider LuaLaTeX if you are going to use Unicode. 
> Alternatives are PDF export through LibreOffice or through HTML and a browser.
Thank you Max. Another vote for LuaTeX! And for Unicode. 

rjs

Re: how to add special glyphs

[Rob Sargent]

> On Mar 8, 2023, at 3:09 AM, Pedro Andres Aranda Gutierrez  
> wrote:
> 
> On 3/6/23 Rob Sargent  wrote:
> 
>> I think I have to decide on one format and stick with it.  I get bitten
>> by ODT/DOC transformations, not sure I like the default look of
>> LaTeX/pdf, HTML is pretty reliable but not best for handing out. Maybe
>> I'll go back to "text" and call it good.
> 
> If my .2 cents can help:
> 
> At the end, I bargained with myself and settled for PDF/LaTeX. I'm using
> 
> #+LATEX_HEADER: \usepackage{helvet}
> #+LATEX_HEADER: \renewcommand\familydefault{\sfdefault}
> 
> for SansSerif fonts after some reading about adapted documents. They
> seem to work well with most LaTeX classes as well as Beamer
> presentations and handouts.
> 
> I'm spending time with listing exports because I'm not against some
> code samples being available for *reliable* copy and paste and the
> current exporters in LaTeX don't completely please me (but that's the
> real danger with LaTeX, noone but me to blame for it ;-) )
> 
> Best, /PA
> -- 
> Fragen sind nicht da um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
> 
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
> run a leader-deposed hook here, but we can't yet
> 

It very much helps. Thank you

rjs

Re: [BUG] No space after footnote with org-export-with-footnotes set to nil [9.6.1 ( @ /Users/test/.emacs.d/elpa/28.0/develop/org-9.6.1/)]

[Max Nikulin]

On 07/03/2023 20:59, Ihor Radchenko wrote:

I agree about the last example, but what about "Heading [0/1] text"?


Both "Heading" and "[0/1]" have the same :post-blank " ", so when 
stripping the statistics cookie use " " :post-blank for "Heading" 
(retain current value).



Max Nikulin writes:

On 05/03/2023 20:01, Ihor Radchenko wrote:

It might be enough to use spaces if and only if there are no preceding
spaces. Or not. One may think of other edge cases.


An idea: retain :post-blank having more spaces. Newline > tab, tab = 8
spaces.


May you elaborate about "newline > tab, tab = 8 spaces"?


Consider your earlier example:


Text with newline\\
[footnote]  more text.


Line-break has :post-blank "\n" that is greater than the "  " 
:post-blank value of the footnote reference, so when dropping the 
footnote retain "\n" from line break.


 8< 
Text   [footnote]
 next line
 >8 

Use "\n " from "[footnote]" because it is greater than "   " that is 
:post-blank of "Text".

Re: how to add special glyphs

[Max Nikulin]

On 08/03/2023 07:29, Rob Sargent wrote:

LuaLaTeX may be instructed to use fallback fonts, see e.g.

...

To my taste it is too low level.
That I placed the unicode into the text was "too low level"?  I could 
argue that "it's a UTF doc", or that "\ding{55}" is bizarrely high 
level.  Other's have shown methods which maximize the cross export 
experience.  I'll consider those.  I'm not sure LuaLaTex is an option 
for me.


I would prefer to use Unicode symbols in UTF-8 encoded documents. While 
browsers and office software tries to find some substitution when some 
glyph is not available in requested font, configuration of LaTeX engines 
is more complicated. Support of Unicode in LuaTeX is much better than in 
pdfTeX. Unfortunately for characters outside of ~latin-1 set, all fonts 
must be carefully configured. I consider necessity to specify font per 
language and fallback fonts as too low level operations for regular users.


I do not see a robust way to determine fonts available for LaTeX to 
implement automatic configuration in ox-latex with reasonable amount of 
code.


I recommend to consider LuaLaTeX if you are going to use Unicode. 
Alternatives are PDF export through LibreOffice or through HTML and a 
browser.

Re: [PATCH] org-src: Improve the name of source editing buffers

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> Could you elaborate about "more standard"?
>
> Sure.  For example, when I look at my Mode Line now, I see that the major more
> is "Message[Notmuch]".  When I look at the names of the currently open 
> buffers,
> I see "FOO" and "{FOO}" and "[FOO] BAR" and "FOO(BAR)".  All this is 
> "standard"
> in Emacs.  I have yet to see a buffer, or anything else, named `FOO BAR[ BAZ 
> ]'.

net-utils.el also has "*ftp [host]*". Notably, with space.
I found no other use of [...] in Emacs sources.

I can see Message[Notmuch] in notmuch third-party package. But it is not
a buffer name.

Could you list other packages that use Foo[bar] pattern in buffer names?

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> > Here is suggestion:
>> > ---
>> >
>> > 1. Convert local time timestamp to UTC
>> > 2. Add 10024 hours
>> > 3. Provide timestamp in UTC
>> 
>> This will involve converting time, which is prone to errors. I still
>> think that sometimes it is more convenient for human to use familiar
>> time zone and fix the offset for future.
>
> Your answer is not related any more to @UTC time you were mentioning
> as now you are using "familiar time zone". I said, there is no offset
> representation with UTC time but +00. But it can be with other time
> zones.
>
> However, when you say "fix the offset for future" that does not
> work. If you do specify time zone, you are fixing it by time zone, and
> not by UTC offset, because it is less likely that the time zone
> definition changes, but UTC offset can change easier.
>
> The UTC offset is property of the time zone. The future time zone
> definition will know what is it's UTC offset.

UTC offset is indeed a property of the time zone.
However, UTC offset may be a subject of change in some time zones.
I am referring to "fixed" offsets to be specified by users and will
never change. These offsets are convenient to protect timestamp from
regulatory changes in time zones. Effectively, they are simply another,
sometimes convenient, way to represent UTC time.

Consider that you need to put a timestamp exactly 1 year from now, even
if time zone rules change. You are in +04 time zone at
[2023-03-08 14:00 @Asia/Istanbul].

You can write [2024-03-08 11:00 @Z] or you can write
[2024-03-08 14:00 @+03]. The latter is nothing but former, written
without a need to mentally convert back to UTC from your current wall
clock.

> You can introduce something new in Org and say "This is fixed UTC
> offset in time zone @ABC" but that way you are confusing yourself and
> future programmer and users, as it does not comply to already accepted
> international standards.
>
> iCalendar proposes different way of representation of time in future,haw
> that is, it could be UTC time in future, or it could be date, time and
> time zone. Using UTC offset for future is redundant, as in present
> time when you are writing future time stamp, you cannot know the
> future UTC offset.

iCalendar provides just two options: time zone name and UTC. It is ok
when the timestamps are written programmatically, but not ok when the
format should be writable by humans manually. I do not see why we should
force the users to convert to UTC manually in the above scenario.

>> icalendar is _not_ the only time spec around. We can take it into
>> account, but I do not see any reason to follow it blindly.
>
> How about finding reasons why iCalendar specifies it that way?
>
> And then deciding if those reasons, not specification literally,
> should be followed?

Feel free to share the underlying logic if you are aware about it.
 
>> Note that the idea with (optionally) providing two time zones/offsets is
>> also coming from a time spec in
>> https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>
> ...
> Conclusion is that your reference is only partially relevant, as you
> may use it as guide for past timestamps, but not as guide for future
> time representation.

The cited document explicitly talks about timestamps in future. See 3.4.
Inconsistent time-offset/Time-Zone Information

> In my opinion people should be given the extended timestamp function
> in Org where they may choose the time zone.
>
> - no C-u prefix, interactive selection: <2023-02-12 Sun>
>
> - with C-u prefix, interactive, with time: <2023-02-12 Sun 11:09>
>
> - with double, C-u C-u, prefix, non-interactive with time: <2023-02-12 Sun 
> 11:10>
>
> - but then I do not know what with 3 times C-u, some of those prefixes
>   could be used to let user choose the time zone

Sure, though I had a slightly different interface in mind. In any case,
it is too early to talk about interfaces. Let's finalize the syntax
first.

>> > 4. Hypothetical example of clear timestamp for future:
>> >[2024-02-04 12:00! @-08,America/Vancouver]
>> >where the time would be stamped with "!" and that would mean that in 
>> > the time zone, meeting is at 12 o'clock.
>> >It would assume that UTC offset can change in future, but 12:00 clock 
>> > would be authoritative time for future.
>> 
>> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?
>
> The sign "!" is telling "use time, not offset as authoritative". I do
> not say you should implement it this way, but I am saying it is wrong
> putting both the time and offset for future time, while you will not
> know the future offset with certainty.

Ok. I see the problem you referred to. We should then better stick to
the TEC's proposal here:

┌
│ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
│ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
│ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
└

Re: Re: how to add special glyphs

[Pedro Andres Aranda Gutierrez]

On 3/6/23 Rob Sargent  wrote:

> I think I have to decide on one format and stick with it.  I get bitten
> by ODT/DOC transformations, not sure I like the default look of
> LaTeX/pdf, HTML is pretty reliable but not best for handing out. Maybe
> I'll go back to "text" and call it good.

If my .2 cents can help:

At the end, I bargained with myself and settled for PDF/LaTeX. I'm using

#+LATEX_HEADER: \usepackage{helvet}
#+LATEX_HEADER: \renewcommand\familydefault{\sfdefault}

for SansSerif fonts after some reading about adapted documents. They
seem to work well with most LaTeX classes as well as Beamer
presentations and handouts.

I'm spending time with listing exports because I'm not against some
code samples being available for *reliable* copy and paste and the
current exporters in LaTeX don't completely please me (but that's the
real danger with LaTeX, noone but me to blame for it ;-) )

Best, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

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

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> Actually, now that I think about it, the whole problem is gone, when 
> replacing 
> the wrapping let with 2 separate (define ...), which I originally thought org 
> would do:
> ...
> Is there a reason it has to be wrapped in a let, instead of simply define-ing 
> the variables?

Because (define ...) will, AFAIU, define the variables in the whole
session, including subsequent code block calls. Let-binding is safer in
this regard - it only affects a specific code block.

For the problem of (import ...), a similar problem is solved by ob-C
using :includes header argument. See
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html

I am not yet sure if let-binding around (import ...) must never be done
in Guile. It would be helpful of someone more familiar with Guile chimes
in.

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