Re: Intention of verbatim text?

[c.buhtz]

Thanks for all your feedback.

On 2023-01-04 05:58 Tim Cross  wrote:
> argue that =text= should be rendered as text

I did this before but then got them as paragraphs. Not sure how the
correct term of this is in HTML. pre is not inline but handled as an
own paragraph so that you have an extra line in the rendered HTML
output.

> markers/information for =textg=, so wrapping it in a semantic tag
> like  is IMO incorrect as we are imposing a semantic
> interpretation without justification.

I also agree that the current org html export is not specific enough
here.

My current solution is to convert ~code~ to code and
=verbatim= to verbatim.

In that case the user can decide himself how to render them. In my
default CSS I would render the ~code~ in monospace with a light gray
background (different from the whole page background) and =verbatim=
with monospace only but without extra background color.

Kind
Christian

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

[Pedro Andres Aranda Gutierrez]

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).

LoL... My kleines Latinum, though not completely fit right now, tells me
that
indeed it is very, very good Latin :-)

Now seriously, I'm using org for my academic activities (producing lecture
presentations and notes and laboratory scripts) and I'm extremely happy with
what I achieve. There's always a slight grief in that I can't forward
search to
or reverse search from a PDF...

But anyhow, if you need a proofreader, happy to help..
-- 
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: Feature request: "task table" (similar to clock table)

[Marcin Borkowski]

On 2023-01-03, at 19:29, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>> I see.  I think I'll go another route then - in fact, I already started,
>> see https://mbork.pl/2023-01-02_Computing_Org_mode_TODO_stats :-)
>
> That will also work.
>
> But why `plist-get' + `org-element-at-point-no-context'?
>
> You can instead use `org-element-property' + `org-element-at-point'.
> `org-element-property' will be resilient against internal AST
> representation changes and `org-element-at-point' will make use of
> caching.

Yes, thanks - I saw your comment.  I will amend the post today.

Best,

-- 
Marcin Borkowski
http://mbork.pl

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

[David Masterson]

"Fraga, Eric"  writes:

> On Monday,  2 Jan 2023 at 19:23, David Masterson wrote:
>> 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).
>
> it's not the text of the document that matters; it's the popups that
> describe how each visual aspect has been implemented!  E.g. footers,
> headers, justification, lists, etc.

Ah!

-- 
David Masterson

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

[Bastien]

Hi Rudolf,

Rudolf Adamkovič  writes:

> So, my use of Scheme drops from 8 hours per day to effectively 0,
> effective today.  As a result, I would like to kindly ask you to revert
> the change, for without actively using something, I cannot maintain it.

Sure, done.

> That said, if my employer changes their mind during the transition from
> Scheme to Fennel and decides to keep the current code base, I will
> re-volunteer.
>
> Thank you for understanding, and I again apologize for the churn!

No problem, I hope you can re-volunteer at some point!   (Or write
ob-fennel.el?)

Thanks,

-- 
 Bastien

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

[Rudolf Adamkovič]

Bastien Guerry  writes:

> I just added you as the maintainer of ob-scheme.el.

A sudden turn of events:

My employer have just decided that we will convert all Scheme to Fennel,
a zero-runtime Lisp based on Lua, because it has a better bus factor,
meaning that, in the worst-case, the company can continue with Lua, a
language for which one can find programmers more easily than for Scheme.

So, my use of Scheme drops from 8 hours per day to effectively 0,
effective today.  As a result, I would like to kindly ask you to revert
the change, for without actively using something, I cannot maintain it.

That said, if my employer changes their mind during the transition from
Scheme to Fennel and decides to keep the current code base, I will
re-volunteer.

Thank you for understanding, and I again apologize for the churn!

Rudy
-- 
"Be especially critical of any statement following the word
'obviously.'"
-- Anna Pell Wheeler, 1883-1966

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

Re: Intention of verbatim text?

[Tim Cross]

 writes:

> Hi,
>
> in org you can have inline verbatim and code text elements like this.
>
> Example with =verbatim= and ~code~.
>
> I would like to understand what "verbatim" really means. What is the
> semantic behind it? What content should go in there?
>
>
> I'm aware of the separation of content and its presentation.
> I'm also aware of the different renderings in my Emacs. Booth are
> monotype but with different colors.
>
> The org html export to create both with  tag. So in HTML output
> there is no difference between verbatim and code anymore.
>
> I also read a lot about the HTML tags code, pre, kbd and samp.
>
> I wonder that maybe I totally misunderstand the intention of
> "verbatim"?
>
> The background of my question is that I have my own
> org-to-html-converter [1] and try to decide how to treat =verbatim=.
> Which HTML tag should I use.
>
> Thanks
> Christian
>
> [1] -- 

IMO (and it is just my opinion, not that of the org developers), the
main use of verbatim (i.e. =text=) is to escape any further
interpolation as org markup. It basically says, when exporting, export
'as is' with no further processing.

Consider a situation where you want to write A_B, but don't want it to
be interpreted as A with a subscript B. There are a number of ways to
handle this. One is to set the #+OPTION to ^:nil and turn off the
behaviour for the whole file or you can use =A_B= to just turn it off
for that use (though this does have other possibly unintended
side-effects, such as a font change, but I'm really just trying to
illustrate the point here).

I would have to look more closely at the output of the HTML export to
verify your assertion that both verbatim and code are rendered the
same. With respect to 'phrases', I guess there is no real difference in
outcome. However, the standard HTML code tag does not preserve line
breaks. Traditionally, for blocks of code, the code tag would also be
wrapped in the pre tag. However, things have evolved and now it is much
more common to see just the code tag with an additional CSS class which
is used to manage the preservation of line breaks and whitespace. From a
purely tecnical 'correctness' standpoint, I would argue that =text=
should be rendered as text and not text. When
exporting data, we don't have any semantic markers/information for
=textg=, so wrapping it in a semantic tag like  is IMO incorrect
as we are imposing a semantic interpretation without justification. .

Re: Feature request: "task table" (similar to clock table)

[Ihor Radchenko]

Marcin Borkowski  writes:

> I see.  I think I'll go another route then - in fact, I already started,
> see https://mbork.pl/2023-01-02_Computing_Org_mode_TODO_stats :-)

That will also work.

But why `plist-get' + `org-element-at-point-no-context'?

You can instead use `org-element-property' + `org-element-at-point'.
`org-element-property' will be resilient against internal AST
representation changes and `org-element-at-point' will make use of
caching.

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

Re: Feature request: "task table" (similar to clock table)

[Marcin Borkowski]

On 2022-12-27, at 08:48, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>>> If you have interest, going through org-colview.el code would be
>>> helpful. It is a bit messy and deserves more cleaning and commenting.
>>
>> Since org-colview is pretty long, I decided to look into the manual
>> instead.  But I couldn't make the column view to do what I wanted, i.e.,
>> count the TODO, DONE etc. items in various subtrees.  (What I want is
>> more or less "select status, count(*) group by status" for every level-1
>> tree.)  And I don't see the equivalent of "count()" among the possible
>> "summary types": https://orgmode.org/manual/Column-attributes.html.
>
> You will likely need to implement a new summary type and add it to
> org-columns-summary-types

I see.  I think I'll go another route then - in fact, I already started,
see https://mbork.pl/2023-01-02_Computing_Org_mode_TODO_stats :-)

Thanks,

-- 
Marcin Borkowski
http://mbork.pl

Re: Intention of verbatim text?

[Daniel Fleischer]

c.bu...@posteo.jp [2023-01-03 Tue 13:20] wrote:

> in org you can have inline verbatim and code text elements like this.
>
> Example with =verbatim= and ~code~.
>
> The org html export to create both with  tag. So in HTML output
> there is no difference between verbatim and code anymore.
>
> I also read a lot about the HTML tags code, pre, kbd and samp.
>
> The background of my question is that I have my own
> org-to-html-converter [1] and try to decide how to treat =verbatim=.

According to https://stackoverflow.com/questions/32284477 they have
different semantics but are rendered the same (by default); they could
be rendered differently, depending on a website's CSS. Maybe use the
semantics for your own org-html converter.

-- 
Daniel Fleischer

on inlinetask's 1st line inserts a star

[Alain . Cochard]

release_9.6-193-g30314c

A  right after 'M-x org-inlinetask-insert-task' adds a star to
the 15 already there; another , another star, and so on.  Same
thing with cursor after a TODO keyword.

The behavior is the same if there is some content inside the
inlinetask (i.e., not on the 1st line).

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Intention of verbatim text?

[c.buhtz]

Hi,

in org you can have inline verbatim and code text elements like this.

Example with =verbatim= and ~code~.

I would like to understand what "verbatim" really means. What is the
semantic behind it? What content should go in there?


I'm aware of the separation of content and its presentation.
I'm also aware of the different renderings in my Emacs. Booth are
monotype but with different colors.

The org html export to create both with  tag. So in HTML output
there is no difference between verbatim and code anymore.

I also read a lot about the HTML tags code, pre, kbd and samp.

I wonder that maybe I totally misunderstand the intention of
"verbatim"?

The background of my question is that I have my own
org-to-html-converter [1] and try to decide how to treat =verbatim=.
Which HTML tag should I use.

Thanks
Christian

[1] -- 

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

[Matt]

  On Tue, 03 Jan 2023 05:50:17 -0500  Ihor Radchenko  wrote --- 
 > I was mostly worried about session states affecting subsequent test
 > invocations. But I do agree that it may be better to keep them.

That makes sense.  I tend to run tests one at a time unless I'm about to submit 
patches or push...

 > Feel free to push upstream.

I'm not able to push to git://git.sv.gnu.org/emacs/org-mode.git.

I've read through the following and, as far as I can tell, I've followed the 
directions.

- https://orgmode.org/worg/org-contribute.html
- https://orgmode.org/worg/org-maintenance.html
- https://www.emacswiki.org/emacs/GitForEmacsDevs

Re: Screenshots in ORG-NEWS

[Bastien]

Ihor Radchenko  writes:

> I am afraid that maintaining both etc/ORG-NEWS and also worg/news.org
> will be a bit too much. 

Maintaining etc/ORG-NEWS is the responsability of maintainers.

Adding useful (possibly visual) informations on Worg is the task of
the community.

Of course, the work people like Tim are doing on their blog is also a
"community task" and a very useful one: if we can have some of these
efforts directed toward the community-maintained worg/news.org file,
that'd be good.

> Though maybe one can be a source for another?

etc/ORG-NEWS would definitely be the source for any worg/news.org
file, just as it is for community efforts to promote new (or even
"upcoming") stuff.

-- 
 Bastien

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

[Eduardo Ochs]

On Tue, 3 Jan 2023, 09:23 Max Nikulin,  wrote:

> On 03/01/2023 17:01, Eduardo Ochs wrote:
> >
> > Can you send to me - here to the mailing list - a version of
> > `org-export-dispatch', and also of other functions if needed, in which
> > the parts that call `read-char-exclusive' are replaced by something
> > non-blocking?
>
> Eduardo, I am sorry, but from my opinion it is too much. Perhaps you are
> just not realizing that resources of developers are rather limited.
> Getting rid of `read-char-exclusive' in Org menus requires significant
> amount of work. Nobody argues that it would be a great improvement, but
> it is necessary to make changes that are not obvious at first glance. It
> would lead to confusing behavior otherwise.
>
> Jean might be happy with the posted mock-up. Unfortunately that code is
> too far from been ready to be used for all users. E.g. it does not use
> `org-export-registered-backends', not to mention that all menus in the
> package should be consistent. It is OK to have a bunch of repetitive
> code for a demo, but it can not be taken as is.
>
> Ihor dedicates a lot of time for development and maintaining of Org.
> Other developers are significantly less active last months. Often
> authors of code are not participating in discussions because several
> years have been passed since that time and they are busy with other
> projects. So your questions may noticeable efforts from other persons
> unfamiliar with some code to "read" it for you. Org code is not ideal,
> but it is rarely too obscure. Nobody intentionally adds obstacles that
> hamper readability. Sometimes it is necessary to make decisions not
> realizing actual consequences just to move forward. If you need code
> friendly for beginners then find a friend who can rewrite the code in
> the style you like (of course, it should be maintainable as well).
>
> At first I believed that on your own way you are just avoiding reading
> comments and docstring in ox.el that are helpful to discover actual
> functions in export backends that do the job. E.g. docstring of
> `org-export-define-backend' and its usage in other files is rather
> informative.
>
> I am lost what is your actual needs after your request to rewrite the
> export dispatcher for you.
>
> After all, if you can not figure out which function is called by the
> dispatcher, instrument for debugging some transcoder function and export
> some file. You will get call stack.
>
> Be realistic, time and experience are limited resources, not all code
> deserves blog posts. Source code is a communication channel as well.
>

Hi Max,

sorry, I thought that that would be something like a 5-line change... =(

A few messages again I mentioned that one of my plans for these holidays
was to learn several techniques for debugging elisp that I've postponing
learning for ages. I'll do that and then I'll try solving this problem
again.

  Cheers =/,
Eduardo

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

[Max Nikulin]

On 03/01/2023 17:01, Eduardo Ochs wrote:


Can you send to me - here to the mailing list - a version of
`org-export-dispatch', and also of other functions if needed, in which
the parts that call `read-char-exclusive' are replaced by something
non-blocking?


Eduardo, I am sorry, but from my opinion it is too much. Perhaps you are 
just not realizing that resources of developers are rather limited. 
Getting rid of `read-char-exclusive' in Org menus requires significant 
amount of work. Nobody argues that it would be a great improvement, but 
it is necessary to make changes that are not obvious at first glance. It 
would lead to confusing behavior otherwise.


Jean might be happy with the posted mock-up. Unfortunately that code is 
too far from been ready to be used for all users. E.g. it does not use 
`org-export-registered-backends', not to mention that all menus in the 
package should be consistent. It is OK to have a bunch of repetitive 
code for a demo, but it can not be taken as is.


Ihor dedicates a lot of time for development and maintaining of Org. 
Other developers are significantly less active last months. Often 
authors of code are not participating in discussions because several 
years have been passed since that time and they are busy with other 
projects. So your questions may noticeable efforts from other persons 
unfamiliar with some code to "read" it for you. Org code is not ideal, 
but it is rarely too obscure. Nobody intentionally adds obstacles that 
hamper readability. Sometimes it is necessary to make decisions not 
realizing actual consequences just to move forward. If you need code 
friendly for beginners then find a friend who can rewrite the code in 
the style you like (of course, it should be maintainable as well).


At first I believed that on your own way you are just avoiding reading 
comments and docstring in ox.el that are helpful to discover actual 
functions in export backends that do the job. E.g. docstring of 
`org-export-define-backend' and its usage in other files is rather 
informative.


I am lost what is your actual needs after your request to rewrite the 
export dispatcher for you.


After all, if you can not figure out which function is called by the 
dispatcher, instrument for debugging some transcoder function and export 
some file. You will get call stack.


Be realistic, time and experience are limited resources, not all code 
deserves blog posts. Source code is a communication channel as well.

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

[Ihor Radchenko]

Tim Cross  writes:

> 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. 

No problem. I just wanted to follow up on this since around 6 months
passed. In case if you need any help.

I did not mean to pressure you.

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

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

[Ihor Radchenko]

Tim Cross  writes:

>> 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?
>
> 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 files which are from unknown
> and therefore untrusted sources - email messages, cloned git
> repositories, Emacs packages, etc. Most people likely don't want these
> executed by default and want to be asked or be able to block by default.

> The point is, we probably need to consider not only what variables are
> required, but also some infrastructure for managing those variables
> based on some form of document classification or trust. You touch on
> this with some of what has been outlined, but it focuses on the original
> data source. That information can be lost once a file has been
> retrieved. However, the trust level of that file likely doesn't change
> just because it now resides 'locally'.

Oops. I think I forgot to describe another point I was thinking about.

REGEXP in `org-confirm-evaluate-safe-regexps' may also be a cons cell
(SOURCE . REGEXP). SOURCE can be a file path, a directory containing the
file, or file contents hash. This way, we can mark whole files or
directories as safe. Or just specific code blocks in files or
directories.

> I do wonder if the idea of a document classification model and some form
> of heuristic algorithms to handle default document classification might
> be useful.

I do not think that we need to go in this direction.
I doubt that we are qualified to get the heuristics right.
Such things should either be maintained in Emacs core or not provided at
all to not create false sense of security.

Look at Emacs' approach to file-local variables.
There are no heuristics there.

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

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

[Ihor Radchenko]

Matt  writes:

>   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.

Fair point.

I was mostly worried about session states affecting subsequent test
invocations. But I do agree that it may be better to keep them.
Feel free to push upstream.

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

Re: [MAINTENANCE] Org orphanage?

[Ihor Radchenko]

Bastien  writes:

> 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?

I am not sure why we need to wait with an optional offer.
Merely announcing an orphan package without moving to sr.ht is also ok,
I think.

-- 
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

[Ihor Radchenko]

Bastien  writes:

> 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?

I am afraid that maintaining both etc/ORG-NEWS and also worg/news.org
will be a bit too much. Though maybe one can be a source for another?

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

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

[Eduardo Ochs]

On Tue, 3 Jan 2023 at 06:47, Ihor Radchenko  wrote:
>
> Eduardo Ochs  writes:
>
> > (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
>
> To be fair, your another message copy got some replies:
> https://list.orgmode.org/cads++6j+opnsa8po7_sbctmhog5v_bezkr6vbb1ecfhbprk...@mail.gmail.com/
>
> > 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...
>
> In any case, we are here now, after the discussion resurfaced.
>
> > 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".
>
> I recommend following up on the replies if you find them incomplete.
>
> There are no guarantees that exhaustive detailed replies will be given -
> they take a lot of time to write and are often not necessary.
>
> > 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
> >
> > and some people will prefer to just read this:
> >
> >   http://angg.twu.net/eev-videos/2021-org-for-non-users.vtt
> >   http://angg.twu.net/SUBTITLES/2021-org-for-non-users.lua.html
> >
> > It explains with examples how a "non-user" thinks, and it shows what I
> > mean by "explanations in Lisp".
>
> I get it, but you cannot force me to reply like this. I simply do not
> think this way - when I try to reply to questions on ML, I do it the way
> I can. I cannot adapt the explanation style that is foreign to me.
>
> If you find something in mine (or other's) replies not clear, just ask
> to clarify.

Ok, let me try something else.

Can you send to me - here to the mailing list - a version of
`org-export-dispatch', and also of other functions if needed, in which
the parts that call `read-char-exclusive' are replaced by something
non-blocking?

  Thanks in advance =),
Eduardo Ochs

[SECURITY] Tangling can overwrite arbitrary tangling targets, including important user files (was: [SECURITY] Arbitrary code evaluation security in Org)

[Ihor Radchenko]

Greg Minshall  writes:

> 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.

Good point. Though not directly related to code execution.

In this particular case, we might be able to utilize Emacs' file
dialogues. For example, `write-file' can ask about overwriting an
existing file.

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

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

[Ihor Radchenko]

Eduardo Ochs  writes:

> (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

To be fair, your another message copy got some replies:
https://list.orgmode.org/cads++6j+opnsa8po7_sbctmhog5v_bezkr6vbb1ecfhbprk...@mail.gmail.com/

> 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...

In any case, we are here now, after the discussion resurfaced.

> 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".

I recommend following up on the replies if you find them incomplete.

There are no guarantees that exhaustive detailed replies will be given -
they take a lot of time to write and are often not necessary.

> 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
>
> and some people will prefer to just read this:
>
>   http://angg.twu.net/eev-videos/2021-org-for-non-users.vtt
>   http://angg.twu.net/SUBTITLES/2021-org-for-non-users.lua.html
>
> It explains with examples how a "non-user" thinks, and it shows what I
> mean by "explanations in Lisp".

I get it, but you cannot force me to reply like this. I simply do not
think this way - when I try to reply to questions on ML, I do it the way
I can. I cannot adapt the explanation style that is foreign to me.

If you find something in mine (or other's) replies not clear, just ask
to clarify.

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

Re: Refactor org-babel-shell-initialize? (was Re: ob-shell intentions and paperwork (was Bash results broken?))

[Ihor Radchenko]

Matt  writes:
>   On Sat, 31 Dec 2022 07:56:10 -0500  Ihor Radchenko  wrote --- 
>  > As for being a macro, there will be not much gain - the convention is
>  > mostly designed for things like `cl-defun' aimed to be used in the code.
>  > `org-babel-shell-initialize' is only used by `org-babel-shell-names'.
>
> I'm not sure what you mean by "to be used in code".  Do you mean called 
> within the global scope?

There are certain conventions about indentation of macros with "defun" in
them. They are automatically applied in emacs-lisp-mode.

Also, some heuristics for imenu looks for "defun" top-level forms, AFAIR.

In all these scenarios, it is assumed that "defun" macros are used in
the source code to define functions during compile time. Not on runtime.

> 1. The source is not explicit for a given `org-babel-execute:some-shell', 
> making it difficult to debug
>
> The benefit of using a macro is clarity of the defined functions.  Here's the 
> core `org-babel-shell-initialize' functionality as a macro.  Note that it 
> doesn't loop through `org-babel-shell-names'.
> ...
> You can expand to see the definitions:
>
> (pp-macroexpand-expression '(define-babel-shell-1 "csh"))
>
> Is there a way to see the definition of`org-babel-execute:csh' using the 
> current `org-babel-shell-initialize', that is, when generated by a function?

https://github.com/Wilfred/helpful displays the function code in such
scenario. Probably, I need to raise this problem on emacs-devel.

> Looking at the expansion, I see what appears to be an error:
>
> (alist-get "csh" org-babel-shell-set-prompt-commands)
>
> `org-babel-shell-set-prompt-commands' is an alist keyed by string shell names 
> and whose values are shell commands to set the prompt.  `alist-get' uses `eq' 
> by default which always returns nil for string comparisons.  That is, 
> (alist-get "csh" org-babel-shell-set-prompt-commands) returns nil, not 
> because the corresponding alist value is nil.  Rather, because the (eq "csh" 
> "csh") comparison evaluates as nil.  The TESTFN probably should be `equal' or 
> `string=':
>
> (alist-get "csh" org-babel-shell-set-prompt-commands nil nil 'equal)
>
> Then, it will return the prompt associated with "csh".

Good point. Would you mind making a patch?

> 2. Source navigation gets confused when looking up help for a generated 
> function.  For example, `C-h f org-babel-execute:sh' goes to the top of 
> ob-shell.el

This is indeed to be expected.

> Generating the execute functions with a macro also has this problem.  I'm not 
> sure there's a way around it other than defining each function with `defun'.  
> Doing that would be a bad idea because of the massive code 
> duplication/maintenance it would create.

Yup.

> 3. It does not adhere to the coding convention.
>
> I'll requote the convention here for convenience.
>
>> (elisp) Coding Conventions says,
>>
>> "• Constructs that define a function or variable should be macros, not
>> functions, and their names should start with ‘define-’. The macro
>> should receive the name to be defined as the first argument. That
>> will help various tools find the definition automatically. Avoid
>> constructing the names in the macro itself, since that would
>> confuse these tools."
>
> It's not clear to me why the convention exists, beyond consistency (a valid 
> reason).  I suspected it was to make the code clearer (points 1) and to "help 
> various tools find the definition automatically" (point 2).  
>
> I'm biased by my experience into thinking a macro actually addresses point 1. 
>  I could be wrong about it, though. It could just have been luck and personal 
> preference, and I may be overlooking some hidden complexity, a common problem 
> with macros.  Is there anything you see that I might be overlooking?

Nothing substantial, AFAIK.

> AFAICT, a macro doesn't help with finding the definition of the generated 
> function.  Any idea what tools it's talking about?

See above.

> Also, the way I defined `define-babel-shell-1' doesn't fit the convention.  
> Something like this would:
>
> (defmacro define-babel-execute-shell-2 (name)
>   "Define functions and variables needed by Org Babel to execute a shell.
>
> NAME is a symbol of the form `org-babel-execute:my-shell'."
>   (declare (indent nil) (debug t))
>   (let ((shell-program (cadr (split-string (symbol-name name) ":"

Symbol argument will create awkward back-and-forth conversion between
string and a symbol here.

> 4. Except for using the customize interface, changing `org-babel-shell-names' 
> requires reevaluating the function generator (`org-babel-shell-initialize' or 
> some variant of `define-babel-shell-1' )
>
> A macro would not solve the need to re-evaluate the function generation when 
> a change is made to `org-babel-shell-names'.  Either way, we need to loop/map 
> over the list of shells.
>
> I'm curious your thoughts about removing the `:set' function from 
> `org-babel-shell-names' and using 

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

[Fraga, Eric]

On Monday,  2 Jan 2023 at 19:23, David Masterson wrote:
> 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).

it's not the text of the document that matters; it's the popups that
describe how each visual aspect has been implemented!  E.g. footers,
headers, justification, lists, etc.

-- 
: Eric S Fraga, with org release_9.6-190-g82cc6f in Emacs 30.0.50

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

[Ihor Radchenko]

Marc Nieper-Wißkirchen  writes:

>> Thanks!
>> Note that your patch does not apply onto main.
>
> Rebased against the latest main.  Please see the appended patch.

Hmm.
Not sure what is going on here, but I am getting

128 git … am --3way -- 
/tmp/0001-lisp-ob-scheme.el-Do-not-hide-Scheme-evaluation-erro.patch
Applying: lisp/ob-scheme.el: Do not hide Scheme evaluation errors.
Using index info to reconstruct a base tree...
error: patch failed: lisp/ob-scheme.el:194
error: lisp/ob-scheme.el: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Patch failed at 0001 lisp/ob-scheme.el: Do not hide Scheme evaluation errors.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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