Re: Broken numerical ordered list when exported to latex

[Ihor Radchenko]

Sharon Kimble  writes:

> Could the manual be amended to show how to use it with an example like the 
> one you showed above please?  

Sure. Feel free to propose what to add.

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

Re: LaTeX tutorial (focused on what Org exports) ??

[David Masterson]

David Masterson  writes:

> "Fraga, Eric"  writes:
>
>> On Sunday,  1 Jan 2023 at 13:43, Ihor Radchenko wrote:
>>> I think that it is not very clear how to use it.
>>> Abstract says that it is self-explaining, but it appears that not every
>>> pdf viewer supports showing the explanations.
>>
>> Yes, that's true.  The PDF viewer has to support popups.  I normally use
>> zathura to view PDF documents but that's one example of a viewer that
>> doesn't work with this document.  In cases like this, I switch to evince
>> (others also work).
>>
>> But I find this document very useful.
>
> Um, when I viewed it in my Emacs pdfviewer, it appeared to look fine
> *EXCEPT* that it appeared to be in Latin (good Latin, I think, but I
> don't read Latin).

Or maybe I viewed it in Brave...

-- 
David Masterson

Re: LaTeX tutorial (focused on what Org exports) ??

[David Masterson]

"Fraga, Eric"  writes:

> On Sunday,  1 Jan 2023 at 13:43, Ihor Radchenko wrote:
>> I think that it is not very clear how to use it.
>> Abstract says that it is self-explaining, but it appears that not every
>> pdf viewer supports showing the explanations.
>
> Yes, that's true.  The PDF viewer has to support popups.  I normally use
> zathura to view PDF documents but that's one example of a viewer that
> doesn't work with this document.  In cases like this, I switch to evince
> (others also work).
>
> But I find this document very useful.

Um, when I viewed it in my Emacs pdfviewer, it appeared to look fine
*EXCEPT* that it appeared to be in Latin (good Latin, I think, but I
don't read Latin).

-- 
David Masterson

Re: LaTeX tutorial (focused on what Org exports) ??

[David Masterson]

William Denton  writes:

> On 30 December 2022, Thomas S. Dye wrote:
>
>> Org's latex exporter is exceptionally capable.  AFAICT, it doesn't
>> have practical limits on the LaTeX it produces, at least for my
>> academic use case. I'm able to use all of the LaTeX packages I've
>> ever wanted to use.
>
> Me too, and the more I use Org with LaTeX, the more I'm seeing how I
> can use Org as a way to organize a large publishing project: use
> literate programming and export the LaTeX piece by piece, documenting
> what I'm doing; use source blocks to run necessary code to prepare
> images or files before inclusion; and so on.
>
> Using Org (simple markup plus some +latex_header lines) and exporting
> to LaTeX is straightforward enough ... managing a project, with the
> LaTeX as code to be generated, can get a lot more complicated, but on
> the other hand, Org makes that kind of thing simpler.  (Of course,
> anything involving LaTeX is bound to get complicated pretty soon.)
>
> I've learned a lot from several regulars on this mailing list,
> including Juan Manuel Macías, who does remarkable work on dictionaries
> and translations. Here's an example:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00348.html
>
> Along with all the other recommendations, it's worth looking at the
> user guide for the memoir class, which is great for books:
>
> https://www.ctan.org/pkg/memoir
>
> It'll be somewhere on your system as memman.pdf.  I learned a lot
> about page design and LaTeX from it.

I'll have to make time for this.  Thanks.

-- 
David Masterson

Re: [BUG] worg-setup.org is outdated

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> First step is to get a working local copy so that I have something to
>> work with. AFter that and a bit of exploring, I should have a better
>> understanding and idea how to go forward. 
>
> Hi Tim,
>
> May I know if you got a chance to continue working on this?
> Let us know if you need any help from us.

Hi Ihor,

sorry, no real progress.

I did get a working local copy and started looking into what needed to
be done to improve things. Unfortunately, the more I understood, the
more it became obvious that simple tweaking was unlikely to consistently
improve the situation. Each little improvement I made just caused or
exposed other issues and it quickly spiralled down.

Unfortunately, other commitments then took over and I've been too busy
to focus on org stuff for some months now. Even participation in the ML
has been challenging.

A significant re-design of the worg styling is required in order to get
a presentation which both looks good and which works with respect to
accessibility requirements. I don't believe the current styles are
workable. Someone with greater CSS fu than me might do better, but from
what I could tell, the basic underlying premise for the existing styles
is flawed. I suspect it would be possible to 'fix' things, but it would
be a major style re-working. 

I would still like to get back to this, but right now, don't know where
things are likely to be in the short term. There are some job related
things which will be eitehr completed or stepped up to the next stage by
mid Feb and I may have a clearer picture by then. For now though, I have
limited resources to dedicate to org. 

Re: [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable)

[Tim Cross]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> P.S. Considering intense discussion around the topic, what about
>> reverting my commit from the release? We can then re-consider the whole
>> design and apply something more elaborate later.
>
> I now reverted the discussed commit.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=345402148
>
> We need to come up with a uniform security system where all the code
> evaluation is (1) easy to control via variables and user queries; (2)
> not too annoying for users; (3) provides the necessary context for users
> to decide if a code is safe to run.
>
> Before we continue the discussion, I will try to summarize the current
> state of Org manual and code wrt code evaluation of the code coming from
> Org documents (including downloaded Org files).
>
> In the manual we now have
> 17.13 Code Evaluation and Security Issues
>
> This section talks about
>
> 1. Source block bodies and `org-confirm-babel-evaluate'
> 2. shell/elisp links and `org-link-shell-confirm-function' +
>`org-link-elisp-confirm-function'.
>
>Notably, `org-link-elisp-skip-confirm-regexp' is not mentioned in the
>manual.
>
> 3. Table cells, with no way to query or disable execution.
>
> In reality, we have many more places in the code where arbitrary text
> from Org files can be evaluated.
>
> I have marked some places in the above commit with FIXME.
>
> From my audit of Org sources the following scenarios may lead to
> arbitrary code execution:
>
> 1. Code block bodies
> 2. Elisp sexps in header args. Notably, not only `org-babel-read' is
>responsible for evaluating header args. :results and :exports are
>evaluated independently.
> 3. Table cells
> 4. "eval" macros during expansion
> 5. Diary sexps
>
> To the best of my knowledge, this list should be complete. Though I
> would appreciate someone double-checking.
>
> 
> According to the above:
>
> - `org-confirm-babel-evaluate' allows either using
>   `org-babel-confirm-evaluate' prompt (when t), not asking at all (when
>   nil), or using arbitrary prompt function.
> - `org-link-shell-confirm-function' + `org-link-elisp-confirm-function'
>   are similar, except defaulting to `yes-or-no-p'.
> - `org-link-elisp-skip-confirm-regexp' extends indiscriminate function
>   queries to also skip certain (single) regexp.
>
> The situation is not ideal.
>
> We have similar, but more detailed system for downloading remote files:
>
> - `org-safe-remote-resources' allows users to define certain files/urls
>   that are known to be safe
> - `org-resource-download-policy' provides choice between "always query",
>   "query unless safe", "never download", and "always download"
>
> Also, `org--confirm-resource-safe', unlike `org-babel-confirm-evaluate'
> allows manipulating `org-safe-remote-resources' interactively by marking
> current URL or URL domain safe for future.
>
> 
> What we can do
>
> 1. Introduce a new customization `org-confirm-evaluate-safe-regexps'
>listing regexps that are considered safe or cons cells
>(src-body/header-arg/table/macro/diary . regexp)
>
> 2. Introduce a new customization `org-confirm-evaluate' that can be set
>to t/nil/prompt/safe/[function]/[alist]:
>- t/safe :: to display default prompt unless the code block in buffer is
>marked safe
>- prompt :: always ask (the prompt will then not display options to
>add current sexp to safe list)
>- [function] :: custom function that returns t/safe/prompt/[alist]
>- [alist] :: (src-body/header-arg/table/macro/diary/t .
>  t/safe/prompt/function)
>  (t . ) stands for default value.
>
> 3. The default prompt will mimic `org--confirm-resource-safe',
>additionally accepting Y/N to accept/decline all the evaluation in
>current command.
>
> This system will be used across Org for code evaluation. Old variables
> will be supported, but obsoleted.
>
> WDYT?

Hi Ihor,

this looks promising. However, there is a lot to be considered here and
it requires some thought before any meaningful feedback can be provided.

The big challenge here will be in getting sufficient fine grained
control that all use cases can be catered for while also providing a
high level interface suitable for the 'general' case which is both
reasonably easy to understand at the user level and flexible enough for
a default configuration.

For many users who don't share org files, who work on a single user
desktop and who implicitly trust the files they are working with, it is
unlikely they want to be bothered by any of this. It should 'just
work'. I suspect this is the majority. Others will have some sharing of
documents - perhaps in a work group, a class or some form of team
activity. The trust here is likely fairly high but perhaps not
absolute. There is probably a need for some choice on execution on a per
file basis. Finally, there are those org 

Re: LaTeX tutorial (focused on what Org exports) ??

[William Denton]

On 30 December 2022, Thomas S. Dye wrote:

Org's latex exporter is exceptionally capable.  AFAICT, it doesn't have 
practical limits on the LaTeX it produces, at least for my academic use case. 
I'm able to use all of the LaTeX packages I've ever wanted to use.


Me too, and the more I use Org with LaTeX, the more I'm seeing how I can use Org 
as a way to organize a large publishing project: use literate programming and 
export the LaTeX piece by piece, documenting what I'm doing; use source blocks 
to run necessary code to prepare images or files before inclusion; and so on.


Using Org (simple markup plus some +latex_header lines) and exporting to LaTeX 
is straightforward enough ... managing a project, with the LaTeX as code to be 
generated, can get a lot more complicated, but on the other hand, Org makes that 
kind of thing simpler.  (Of course, anything involving LaTeX is bound to get 
complicated pretty soon.)


I've learned a lot from several regulars on this mailing list, including Juan 
Manuel Macías, who does remarkable work on dictionaries and translations. 
Here's an example:


https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00348.html

Along with all the other recommendations, it's worth looking at the user guide 
for the memoir class, which is great for books:


https://www.ctan.org/pkg/memoir

It'll be somewhere on your system as memman.pdf.  I learned a lot about page 
design and LaTeX from it.



Cheers,

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: [PATCH][WORG] replaces broken javascript with link

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien, may you take a look?

Applied, thanks Gerard.

-- 
 Bastien

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Matt]

  On Mon, 02 Jan 2023 04:47:10 -0500  Ihor Radchenko  wrote --- 
 > They will not be reliable when tests are executed interactively.
 > If the `should' condition fails, `kill-buffer' will never be executed
 > leaving dirty state, especially for sessions.

>From my perspective, that's the point and a good thing.  That "dirty state" 
>information may be crucial to understanding why the failure happened.

Can you explain why you would want a failed test to remove failure related 
information?

Re: [MAINTENANCE] Org orphanage?

[Bastien]

Ihor Radchenko  writes:

> I do not really expect much interest as long as the orphaned packages
> keep working. And, more importantly, as long as the original package
> source (like Github) does not direct users to Org ML.
>
> Package users are the most likely people who will be interested to take
> over the maintenance.

Agreed for all the above.

To be sure that we are not miscommunicating, my point is that we can
advertize https://orgmode.org/worg/org-orphanage.html as a place where
anyone can document orphan Org packages, then once there are enough
packages on this page, we can try solving the other problem, that of 
providing a new shelter for these packages.  Does that make sense?

-- 
 Bastien

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> We may, however, make `org-confirm-babel-evaluate' function value accept
>> an extra third argument - context ('code or 'vars). This will retain the
>> required flexibility without introducing an extra variable.
>
> Yes, this is an interesting possibility.

See my other email where I suggested a more elaborate approach.


>> P.S. Considering intense discussion around the topic, what about
>> reverting my commit from the release? We can then re-consider the whole
>> design and apply something more elaborate later.
>
> I see you did the revert already: this is fine by me.



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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Bastien]

Hi Tom,

thanks a lot for the detailed explanations: I get your point and I
understand the need.  I think the revert is a good move, though, as
the solution was not really good enough.

Thanks!

-- 
 Bastien

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Bastien Guerry]

Ihor Radchenko  writes:

> We may, however, make `org-confirm-babel-evaluate' function value accept
> an extra third argument - context ('code or 'vars). This will retain the
> required flexibility without introducing an extra variable.

Yes, this is an interesting possibility.

> P.S. Considering intense discussion around the topic, what about
> reverting my commit from the release? We can then re-consider the whole
> design and apply something more elaborate later.

I see you did the revert already: this is fine by me.

Thanks,

-- 
 Bastien

Re: [MAINTENANCE] Org orphanage?

[Ihor Radchenko]

Bastien  writes:

> Ihor Radchenko  writes:
>
>> I do not think that it is a good idea:
>
> Fair enough.  There seems to be very little interest in contributing
> to https://orgmode.org/worg/org-orphanage.html with abandoned Org
> packages so far: I suggest we worry on enhancing this page once there
> is enough contributions there.

I do not really expect much interest as long as the orphaned packages
keep working. And, more importantly, as long as the original package
source (like Github) does not direct users to Org ML.

Package users are the most likely people who will be interested to take
over the maintenance.

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

Re: Screenshots in ORG-NEWS

[Bastien]

Ihor Radchenko  writes:

> I mostly had https://orgmode.org/Changes.html in mind here.
> Considering the success of https://blog.tecosaur.com/tmio/, I was hoping
> to provide some more elaborate NEWS file for users.
>
> Of course, we need to keep text-only version whenever possible for
> accessibility reasons, but some new features are really better received
> when there is a screenshot or screencast attached to the news. (see
> https://emacssurvey.org/results/3425413930 "What documentation do you
> wish package authors would more often provide?")

I understand, and of course, images are an efficient way to promote
new features.

Still, etc/ORG-NEWS should stick to being text only.

What about a new worg/news.org file with a timeline with new stuff,
along with pictures?

-- 
 Bastien

Re: [MAINTENANCE] Org orphanage?

[Bastien]

Ihor Radchenko  writes:

> I do not think that it is a good idea:

Fair enough.  There seems to be very little interest in contributing
to https://orgmode.org/worg/org-orphanage.html with abandoned Org
packages so far: I suggest we worry on enhancing this page once there
is enough contributions there.

-- 
 Bastien

Re: [WORG] Re: 0e6cdacc publish.sh: never publish the archive/ subdirectory

[Bastien]

Ihor Radchenko  writes:

> -(dolist (org-file (directory-files-recursively default-directory "\\.org$"))
> +(dolist (org-file (directory-files-recursively
> +default-directory "\\.org$"
> +nil (lambda (n) (not (string-match-p "archive" n)
>
> Won't it also discard all the files with word "archive" in them?

Yes, you're right, hopefully this is better:
https://git.sr.ht/~bzg/worg/commit/a0f10380

Thanks!

-- 
 Bastien

Re: Broken numerical ordered list when exported to latex

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ihor Radchenko  writes:

> Sharon Kimble  writes:
>
>> My org file is attached, and the original source was a web-page, a straight 
>> copy and paste, so its inheriting the same list structure as the original. 
>
> This is expected. Lists are numbered from 1. all the time unless you
> explicitly state otherwise. See
> https://orgmode.org/manual/Plain-Lists.html
>
> You need something like
>
> 10. [@10] Life and/or death. There's little else of such significance. Have 
> you had a near-death experience? What is your experience of witnessing birth 
> or death?
>
> in your Org source.

Brilliant, thank you Ihor, it works a treat!

Could the manual be amended to show how to use it with an example like the one 
you showed above please?  

Thanks
  Sharon.  
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11.5, fluxbox 1.3.7, emacs 29.0.60, org 9.5.5 
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmOy1JcdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1t5xQ//YQbbox9yMN35KxBB
lq7OuA7BVozedxhI8QtjFOdkViF5qiCl+IL7Ge/DW8UccOpQn7FeV/PEHaKS9Zc9
TXbI787WoseimfCB3M6mHyDUFt+ty+xKEcEu2GZFYjlFjBoF5ixgwAlbVHA95EeT
GxU3lWOLGQa56c5KqLIE+H/UiUkJw1tSr89FD6IBeX/VDomsGKQcMDEtduSMcKp1
9Rmuo47xgW3WiY+w5xUvPutRA9G9UHEeVLmx0mC/beuBjA9c6zs4iQyCucVXsXbb
jiiVMGHMDp86yd9xeGdC+jUIo+bSEGCbPiUx5VnfaJcmmTkCMO59N/DD73mKBBs7
RB5+Dw8k2EPJU43etgzkXq5C6dgjVX0vEiVJgb9+tGtazQn83JCXgkEWHzkqDmow
JrDw4ZiamIGD/xsdSkMz19TzmLVDF2AGuHdYybl6+0/1olPQxi5CZ6g5DzkKfWxF
63yPavbjgwtNZH148+OdCLjjys6PhCb33TRRsHhKUyGv+4e6RRm2PYPuCMAE0rMW
7HJ01u6NUWAdobd/tQL0wCDaqjt0kSJEr0qqjFkRN3r6H0yKavinRelRd+HJagpj
WznRYr906mrFoadR9UAfQyssSUxklILVCNvzPEPPRYhSREWW/Yby/FQ7m2z5NP32
pNclfAeiqvUePpGbHgPNuvF1qQw=
=Ajfl
-END PGP SIGNATURE-

Re: LaTeX tutorial (focused on what Org exports) ??

[Fraga, Eric]

On Sunday,  1 Jan 2023 at 13:43, Ihor Radchenko wrote:
> I think that it is not very clear how to use it.
> Abstract says that it is self-explaining, but it appears that not every
> pdf viewer supports showing the explanations.

Yes, that's true.  The PDF viewer has to support popups.  I normally use
zathura to view PDF documents but that's one example of a viewer that
doesn't work with this document.  In cases like this, I switch to evince
(others also work).

But I find this document very useful.

-- 
: Eric S Fraga, with org release_9.6-124-g036cc0 in Emacs 30.0.50

Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Jean Louis]

I was reading about Orgdown, Karl, please keep the name, and don't
mind the group.

* Eduardo Ochs  [2023-01-02 09:01]:
> (3) _is_ my experience with the Org mailing list.
> 
> What I meant by "the developers like your questions" was roughly:
> "recognizing that that person deserves help, and giving him tools that
> would let him solve his problems in hours instead of in months or
> years".
> 
> For example, in this thread
> 
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html
> 
> no one considered that if I was asking that then maybe it would be a
> good idea to make `org-export-dispatch' more hackeable by
> beginners...

By the way, I have idea to make Org Export in 3 different ways more,
one that is very hackable and introspective and one that can be edited
as plain text file how users wish and want, then they can reuse the
file to have their menu. Imagine.

> For example, someone could have said "can you try this? Copy that
> function to other file, replace its lines foo and bar by the lines
> plic and bletch, and use the ideas in these two blog posts to debug
> and inspect its data structures"... but no, that didn't happen - I've
> asked lots of technical questions here over the years and never got
> detailed answers like that, only answers whose technical details _were
> kept as short as possible_, and whose explanations were much closer to
> "in English" than to "in Lisp".

The Org manual is there with pointers. Let me know links to your
questions, maybe we find some more pointers to it.

> A few days ago I added subtitles to my video about "Org for
> Non-Users". The links are here,
> 
>   http://angg.twu.net/2021-org-for-non-users.html

Where is the eev file of the page?

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [SECURITY] Arbitrary code evaluation security in Org

[Greg Minshall]

Ihor,

thanks for this.

one additional item (i don't *think* we discussed this before; apologies
if i'm forgetting): tangling.  if one is prompted to "merely" tangle ...

#+begin_src sh :tangle /var/tmp/foo.org.tangled
  echo 'hi!'
#+end_src


one could imagine more sinister scenarios for destination, content.

i don't really know what, how much, to do.  possibly just an option,
defaulting to =nil=, allowing tangle to write a file outside the subtree
that holds the .org file being tangled.

cheers, Greg

Re: [BUG] worg-setup.org is outdated

[Ihor Radchenko]

Tim Cross  writes:

> First step is to get a working local copy so that I have something to
> work with. AFter that and a bit of exploring, I should have a better
> understanding and idea how to go forward. 

Hi Tim,

May I know if you got a chance to continue working on this?
Let us know if you need any help from us.

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

Re: Babel (scheme): Evaluation errors are not shown

[Marc Nieper-Wißkirchen]

Am Mo., 2. Jan. 2023 um 10:38 Uhr schrieb Ihor Radchenko :
>
> Marc Nieper-Wißkirchen  writes:
>
> > Fixed.
>
> Thanks!
> Note that your patch does not apply onto main.

Rebased against the latest main.  Please see the appended patch.

>
> > -   (setq result (if output
> > +  (let ((err (geiser-eval--retort-error ret)))
> > +(setq result (cond
> > +  (err nil)
>
> We may still provide output, if any. Even in the case of error. Not sure
> if it makes sense for ob-scheme though.

I switched the two cases, "err" and "output," in the attached patch.
For a value result, providing a result in case of an error does not
make sense.

Thanks for your patience,

Marc


0001-lisp-ob-scheme.el-Do-not-hide-Scheme-evaluation-erro.patch
Description: Binary data

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Ihor Radchenko]

Matt  writes:

> If this set of patches look good, I can push them to main.

Just one more comment.
You are using constructs like

(if (should ...)
 (kill-buffer ...))

They will not be reliable when tests are executed interactively.
If the `should' condition fails, `kill-buffer' will never be executed
leaving dirty state, especially for sessions.

You can instead use

(unwind-protect
 (should ...)
 (kill-buffer ...))

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

Re: Babel (scheme): Evaluation errors are not shown

[Ihor Radchenko]

Marc Nieper-Wißkirchen  writes:

> Fixed.

Thanks!
Note that your patch does not apply onto main.

> -   (setq result (if output
> +  (let ((err (geiser-eval--retort-error ret)))
> +(setq result (cond
> +  (err nil)

We may still provide output, if any. Even in the case of error. Not sure
if it makes sense for ob-scheme though.

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

Re: org-up-element does not the same for all structural blocks

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> With an org file like
>
>* h
>#+begin_export ascii
>foo
>#+end_export
>
> putting the cursor on 'foo' and doing
>
>M-x org-up-element
>
> brings the cursor on '* h'.  Same with the following blocks:
>
> ‘#+begin_comment’ ... ‘#+end_comment’
> ‘#+begin_example’ ... ‘#+end_example’
> ‘#+begin_export’ ... ‘#+end_export’
> ‘#+begin_export html’ ... ‘#+end_export’
> ‘#+begin_export latex’ ... ‘#+end_export’
> ‘#+begin_src’ ... ‘#+end_src’ (I tried org and lisp)
> ‘#+begin_verse’ ... ‘#+end_verse’
>
> But for those two blocks:
>
> ‘#+begin_center’ ... ‘#+end_center’
> ‘#+begin_quote’ ... ‘#+end_quote’
>
> the cursor is moved to the beginning of the block instead, which I
> find strange.

This is to be expected. Center blocks, Quote blocks, and special blocks
are "greater elements", which can directly contain other Org elements
inside. Thus,

#+begin_center
Text
#+end_center

is interpreted as

(center-block (paragraph))

So, `org-up-element' with point at paragraph will move to parent
center-block.

In contrast, comment/example/export/src/verse are "lesser blocks", which
cannot contain other Org elements inside - their contents is taken
verbatim:

#+begin_comment
Text
#+end_comment

is interpreted as

(comment-block)

with point at "Text", current element is comment-block, and its parent
is headline in your example.

> Incidentally, is there a definition understandable for the basic user
> of what an "org element" is?  I could not find one after a (quick)
> Internet search, not even in

https://orgmode.org/worg/org-syntax.html#orgb8e0d51

Also, see https://orgmode.org/worg/org-syntax.html#Greater_Elements

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

Re: Shouldn't #+EXP> complete to '#+EXPORT_FILE_NAME:'

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> The manual (in 17.1) says that 
>
>After ‘#+’, [‘M-’] complete[s] the special keywords [...]
>
> but if I do it after '#+EXP', it does not complete to 
>
>#+EXPORT_FILE_NAME:
>
> Do I understand the manual incorrectly?

Fixed on bugfix.
Thanks for reporting!
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ce6f1799c

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

Re: [BUG] Checkbox item is broken in html export with table content [9.6 (9.6-??-bed47b437 @ /Users/hw/.emacs.d/.local/straight/build-28.1/org/)]

[Ihor Radchenko]

Max Nikulin  writes:

> On 31/12/2022 21:08, Ihor Radchenko wrote:
>> nunnery-09-bayside writes:
>> 
>>> a. [ ] foo
>>> b. [ ] bar
>>>
>>> | a | b | c |
>> 
>> [] foo
>> [] bar
>
> I would expect e.g.
>
>  [] bar
>
>>> frame="hsides">
>
>> Probably, the reason is  tag in the first paragraph of the item.
>> I am not sure, however, if it is safe to drop it.
>
> If an item contains block-level element then text paragraphs should be 
> wrapped with ..., however there is no reason to put checkboxes 
> outside of first paragraphs.

Timothy, may you take a look?
This is a bit non-trivial because paragraph is transcoded before the
containing list item. So, we may need to pair parent lookup and child
lookup in the transcoders - not ideal.

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

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>>> There is a race condition between writing the contents of the graphics
>>> file to disk and emacs checking the file size. My guess is that this is
>>> causing the problem (and that the same failure applies for emacs-2{6,7},
>>> since only the emacs-28 reports the exact test failure).
>>
>> Maybe we can just add several `sleep-for' calls to the test?
>
> I just did this. Let's see if CI errs again.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e5c45358a

Apparently, `sleep-for' 1 second was not enough, and I decided to remove
checking file size completely.

Upon doing this, another failure popped up. This time, it looks like an
actual Elisp issue:

https://builds.sr.ht/~bzg/job/914954
2 unexpected results:
   FAILED  ob-octave/graphics-file  ((should-not (get-buffer "*Org-Babel
   Error Output*")) :form (get-buffer "*Org-Babel Error Output*") :value
   #) 
   FAILED  ob-octave/graphics-file-space  ((should-not (get-buffer
   "*Org-Babel Error Output*")) :form (get-buffer "*Org-Babel Error
   Output*") :value #) 

As you can see *Org-Babel Error Output* buffer does not exist when
running the test.

Leo, could you please take a look?

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

[SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable)

[Ihor Radchenko]

Ihor Radchenko  writes:

> P.S. Considering intense discussion around the topic, what about
> reverting my commit from the release? We can then re-consider the whole
> design and apply something more elaborate later.

I now reverted the discussed commit.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=345402148

We need to come up with a uniform security system where all the code
evaluation is (1) easy to control via variables and user queries; (2)
not too annoying for users; (3) provides the necessary context for users
to decide if a code is safe to run.

Before we continue the discussion, I will try to summarize the current
state of Org manual and code wrt code evaluation of the code coming from
Org documents (including downloaded Org files).

In the manual we now have
17.13 Code Evaluation and Security Issues

This section talks about

1. Source block bodies and `org-confirm-babel-evaluate'
2. shell/elisp links and `org-link-shell-confirm-function' +
   `org-link-elisp-confirm-function'.

   Notably, `org-link-elisp-skip-confirm-regexp' is not mentioned in the
   manual.

3. Table cells, with no way to query or disable execution.

In reality, we have many more places in the code where arbitrary text
from Org files can be evaluated.

I have marked some places in the above commit with FIXME.

>From my audit of Org sources the following scenarios may lead to
arbitrary code execution:

1. Code block bodies
2. Elisp sexps in header args. Notably, not only `org-babel-read' is
   responsible for evaluating header args. :results and :exports are
   evaluated independently.
3. Table cells
4. "eval" macros during expansion
5. Diary sexps
   
To the best of my knowledge, this list should be complete. Though I
would appreciate someone double-checking.


According to the above:

- `org-confirm-babel-evaluate' allows either using
  `org-babel-confirm-evaluate' prompt (when t), not asking at all (when
  nil), or using arbitrary prompt function.
- `org-link-shell-confirm-function' + `org-link-elisp-confirm-function'
  are similar, except defaulting to `yes-or-no-p'.
- `org-link-elisp-skip-confirm-regexp' extends indiscriminate function
  queries to also skip certain (single) regexp.

The situation is not ideal.

We have similar, but more detailed system for downloading remote files:

- `org-safe-remote-resources' allows users to define certain files/urls
  that are known to be safe
- `org-resource-download-policy' provides choice between "always query",
  "query unless safe", "never download", and "always download"

Also, `org--confirm-resource-safe', unlike `org-babel-confirm-evaluate'
allows manipulating `org-safe-remote-resources' interactively by marking
current URL or URL domain safe for future.


What we can do

1. Introduce a new customization `org-confirm-evaluate-safe-regexps'
   listing regexps that are considered safe or cons cells
   (src-body/header-arg/table/macro/diary . regexp)

2. Introduce a new customization `org-confirm-evaluate' that can be set
   to t/nil/prompt/safe/[function]/[alist]:
   - t/safe :: to display default prompt unless the code block in buffer is
   marked safe
   - prompt :: always ask (the prompt will then not display options to
   add current sexp to safe list)
   - [function] :: custom function that returns t/safe/prompt/[alist]
   - [alist] :: (src-body/header-arg/table/macro/diary/t .
 t/safe/prompt/function)
 (t . ) stands for default value.

3. The default prompt will mimic `org--confirm-resource-safe',
   additionally accepting Y/N to accept/decline all the evaluation in
   current command.

This system will be used across Org for code evaluation. Old variables
will be supported, but obsoleted.

WDYT?

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