Re: Best way to extract info from C files?

[Stefano Ghirlanda]

Thanks! I'm looking into tree-sitter now just to learn how it works :)

On Tue, Feb 20, 2024 at 3:01 AM Ihor Radchenko  wrote:
>
> Stefano Ghirlanda  writes:
>
> > I'm trying to build a simple code documentation tool for org-mode, so
> > I'm looking for ways to get information from C files (to begin with,
> > ideally it will be easy to add other languages). Things like function
> > prototypes, struct definitions, etc. What would be the best tool for
> > this? My search has come up with things like lsp-mode, semantic, etags
> > but I have no experience with any of these. What would be easiest to
> > work with / setup, and have the necessary functionality? Or should I
> > just write my own parsing code?
>
> tree-sitter or lsp might work. Or xrefs. Or TAGS.
>
> > More specifically, my initial goal is to be able to parse things in a
> > format similar naturaldocs.org, for example:
> >
> > // Function: This is a brief description.
> > // Parameters:
> > // - x: The first parameter
> > // - y: The second parameter
> > // Return: A value
> > int my_function( int x, int y );
>
> This simple scenario might be parsed with custom regexps.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



-- 
Stefano Ghirlanda
CTO, DataWorks - https://dataworks.consulting
Guest Professor - Stockholm University Centre for Cultural Evolution

Re: [BUG] beamer export

[Leo Butler]

On Mon, Feb 19 2024, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>>> What about not adding BEAMER_FRAME, but instead adding org-lint checker
>>> that will detect when frame text contains the problematic \end{orgframe}?
>>
>> Ok, thanks for your feedback. I have modified the patch along the lines
>> you suggested. It is attached.
>
> Thanks!
> It looks like you left over some parts from the previous patch version.
>
>> (org-beamer--format-frame): Introduce the new property, :BEAMER_FRAME.
>
> ... like this.
>
>> (org-beamer--frame-environments): New variable and function.  The
>> variable holds a list of names of frame environments found while
>> formatting frames.  The function generates the LaTeX code to define
>> each new frame environment.
>> (org-beamer-template): Add a call to `org-beamer--frame-environments'
>> to insert the environment definitions into the beamer document.
>
> And since we only have a single alternative environment in this version
> of the patch, `org-beamer--frame-environments' does not appear to be
> necessary.
>
>> +(defcustom org-beamer-frame-environment "orgframe"
>> +  "Name of the beamer frame environment."
>> +  :group 'org-export-beamer
>> +  :type '(string :tag "Beamer frame"))
>
> It would be nice to provide a mode detailed explanation about the
> purpose of this custom option.
>
>> +(defun org-lint-beamer-frame (ast)
>> +  "Check for occurrences of begin or end frame."
>> +  (org-with-point-at ast
>> +(goto-char (point-min))
>> +(let (result)
>> +  (while (re-search-forward
>> +  (concat "\\(begin\\|end\\){" org-beamer-frame-environment 
>> "}") nil t)
>> +(push (list (match-beginning 0) "Beamer frame name may cause error 
>> when exporting.") result))
>> +  result)))
>
> ... and to link this org-lint warning to the
> `org-beamer-frame-environment' docstring.

Thanks for your comments.

I think the attached patch addresses each of your points. It's not clear
to me what you mean by "link(ing) this org-lint warning to the
`org-beamer-frame-environment' docstring", but I have expanded the
warning include mention of this variable.

Leo

From 70262bc2469536eeb3aaec926ec71530cfaeca79 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Thu, 25 Jan 2024 09:48:20 -0600
Subject: [PATCH] lisp/ox-beamer.el:  customize the beamer frame environment
 name

* lisp/ox-beamer.el (org-beamer-frame-environment): A new customize
variable.  It contains the name of an environment that serves as an
alias for the beamer frame environment.

(org-beamer-template): Add a call to `org-beamer--frame-environments'
to insert the environment definitions into the beamer document.

* lisp/org-lint.el (org-lint-beamer-frame): Check the body of each
frame for an occurrence of \begin{orgframe} or \end{orgframe}, or
whatever environment name is in `org-beamer-frame-environment' [4].
The warning includes advice to see `org-beamer-frame-environment'.

Rationale: Code with \begin{frame} or \end{frame} cannot be embedded
in a verbatim environment inside a beamer frame due to a design
decision made by the beamer developers [1].  As suggested in that
report, defining an alias for the beamer frame environment will allow
such verbatim examples to compile correctly [2].

This solution also works with instances of \againframe.

Refs:
[1] https://github.com/josephwright/beamer/issues/360
[2] https://github.com/josephwright/beamer/issues/360#issuecomment-708705250
[3] https://list.orgmode.org/orgmode/87le8eg1hs.fsf@localhost/T/
[4] https://list.orgmode.org/orgmode/87il38i5tb.fsf@localhost/T/
---
 lisp/org-lint.el  | 15 +++
 lisp/ox-beamer.el | 28 
 2 files changed, 35 insertions(+), 8 deletions(-)

diff --git a/lisp/org-lint.el b/lisp/org-lint.el
index 4d2a55d15..91ee2eb2a 100644
--- a/lisp/org-lint.el
+++ b/lisp/org-lint.el
@@ -1507,6 +1507,17 @@ AST is the buffer parse tree."
  ((memq (org-element-property :type deadline) '(inactive inactive-range))
   (list (org-element-begin planning) "Inactive timestamp in DEADLINE will not appear in agenda."))
  (t nil))
+
+(defun org-lint-beamer-frame (ast)
+  "Check for occurrences of begin or end frame."
+  (org-with-point-at ast
+(goto-char (point-min))
+(let (result)
+  (while (re-search-forward
+  (concat "\\(begin\\|end\\){" org-beamer-frame-environment "}") nil t)
+(push (list (match-beginning 0) "Beamer frame name may cause error when exporting.  See `org-beamer--frame-environment'.") result))
+  result)))
+
 
 ;;; Checkers declaration
 
@@ -1787,6 +1798,10 @@ AST is the buffer parse tree."
   "Report $ that might be treated as LaTeX fragment boundary."
   #'org-lint-LaTeX-$-ambiguous
   :categories '(markup) :trust 'low)
+(org-lint-add-checker 'beamer-frame
+  "Report that frame text contains beamer frame environment."
+  #'org-lint-beamer-frame
+  :categories '(export) :trust 'low)
 (org-lint-add-checker 'timestamp-syntax
 

[proof of concept] inline language blocks

[Juan Manuel Macías]

Hi,

I'm dedicating a local branch to developing this proof of concept and
testing it in my workflow, so far with good results. The basic idea is
to provide Org with multilingual features and various methods for
selecting languages.

The inline-language-block is intended for small segments of text in a
language other than the main language. They can span several lines but
not more than a paragraph. They can be used for in-line textual quotes,
glosses, etc. They are constructions equivalent to, for example, LaTeX
\foreignlanguage{french}{text} or HTML text.

I have thought of a syntax that is as least intrusive as possible, so as
not to make reading uncomfortable. I have tried the following:

:fr{some text in French} :it{some text in Italian} :la{some text in Latin}

You can also use a literal term instead of a language code:

:klingon!{some text in Klingon}

The blocks can be nested:

:klingon!{Some text in Klingon with :it{some text in Italian}}

And they may include other elements:

:el{Some text in Greek with a {{{macro}}} and a [[link]]}

To this end, I have defined the following element:

#+begin_src emacs-lisp
(defun org-element-inline-language-block-parser ()
  "Parse inline language block at point.

When at an inline language block, return a new syntax node of
`inline-language-block' type containing `:begin', `:end',
`:type', `:contents-begin', `:contents-end' and `:post-blank' as
properties.  Otherwise, return nil.

Assume point is at the beginning of the block."
  (save-excursion
(when (looking-at ":\\([A-Za-z!]+\\){")
  (goto-char (match-end 0))
  (let* ((begin (match-beginning 0))
 (contents-begin (match-end 0))
 (type (org-element--get-cached-string
(match-string-no-properties 1)))
 (contents-end
  (progn
(goto-char (- contents-begin 1))
(org-element--parse-paired-brackets ?\{)
(- (point) 1)))
 (post-blank (skip-chars-forward " \t"))
 (end (point)))
(when contents-end
  (org-element-create
   'inline-language-block
   (list :type type
 :contents-begin contents-begin
 :contents-end contents-end
 :begin begin
 :end end
 :post-blank post-blank)))

(defun org-element-inline-language-block-interpreter (inline-language-block 
contents)
  "Interpret INLINE LANGUAGE BLOCK object as Org syntax."
  (format ":%s{%s}"
  (org-element-property :type inline-language-block)
  contents))
#+end_src

And, for now, this function for ox-latex:

#+begin_src emacs-lisp
(defun org-latex-inline-language-block (inline-language-block contents info)
  "Transcode an INLINE LANGUAGE BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block.  INFO is a plist
holding contextual information."
  (let ((type (org-element-property :type inline-language-block)))
(if (string-match-p "!" type)
(format "\\foreignlanguage{%s}{%s}"
(replace-regexp-in-string "!" "" type)
contents)
  (let* ((plist (cdr
 (assoc type org-latex-language-alist)))
 (language (plist-get plist :babel))
 (language-ini-only (plist-get plist :babel-ini-only))
 (language-ini-alt (plist-get plist :babel-ini-alt))
 (lang (or language language-ini-only language-ini-alt)))
(format "\\foreignlanguage{%s}{%s}" lang contents)
#+end_src

Opinions, suggestions, feedback, ideas?

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Jack Kamm]

Matt  writes:

> AFAIK, aside from appending "&", =make-process= is the only way.  It would 
> probably make sense to continue using =shell= though.  If I understand 
> correctly, you (and others) jump between the Org buffer block and the comint 
> buffer?

Yes, I typically use ob-R and ob-python in this way. Aside from the
convenience of interacting directly with the REPL, the comint mode may
provide other useful facilities, for example in ob-R the inferior ESS
mode provides completion that is aware of the objects in the current
session.

However I think modifying `org-babel-eval' will mainly be useful to
provide async to the nonsession users. Comint-based sessions mainly use
functionality from ob-comint.el, not ob-eval.el, and I think that the
use cases are different enough that they shouldn't be merged into a
single implementation.

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[tomas]

On Tue, Feb 20, 2024 at 11:00:28AM +, Ihor Radchenko wrote:
>  writes:

[...]

> > You "just" [1] need a way of stating dependencies :-)

[...]

> Let's not jump into this rabbit hole yet before we have async code
> working for less complicated scenarios.

:-)

My take is: it's never too early to *think* about it (and to have
a look what others are doing), but it might yet be too early to
design something.

Other than that... rabbit holes is what makes things interesting.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Best way to extract info from C files?

[Ihor Radchenko]

Stefano Ghirlanda  writes:

> I'm trying to build a simple code documentation tool for org-mode, so
> I'm looking for ways to get information from C files (to begin with,
> ideally it will be easy to add other languages). Things like function
> prototypes, struct definitions, etc. What would be the best tool for
> this? My search has come up with things like lsp-mode, semantic, etags
> but I have no experience with any of these. What would be easiest to
> work with / setup, and have the necessary functionality? Or should I
> just write my own parsing code?

tree-sitter or lsp might work. Or xrefs. Or TAGS.

> More specifically, my initial goal is to be able to parse things in a
> format similar naturaldocs.org, for example:
>
> // Function: This is a brief description.
> // Parameters:
> // - x: The first parameter
> // - y: The second parameter
> // Return: A value
> int my_function( int x, int y );

This simple scenario might be parsed with custom regexps.

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

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Ihor Radchenko]

 writes:

>> Doing everything asynchronously is not always desired.
>> Consider, for example,
>> 
>> #+begin_src bash
>> echo "Contents" > /tmp/tmpfile
>> #+end_src bash
>> 
>> #+begin_src bash
>> cat /tmp/tmpfile # I must run after /tmp/tmpfile is created!
>> #+end_src
>
> You "just" [1] need a way of stating dependencies :-)
>
> Cheers
>
> [1] In quotes, because this opens a vast space of interesting
>and strange worlds. The functional folks have their monads,
>the compiler backend builders have their dependency graphs.
>Definitely doable, but treading with care will be helpful
>to not step into a mess :-)

Let's not jump into this rabbit hole yet before we have async code
working for less complicated scenarios.

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

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[tomas]

On Tue, Feb 20, 2024 at 10:28:06AM +, Ihor Radchenko wrote:
> Matt  writes:
> 
> > The blub implementation has the same shortcomings, at least for shells, as 
> > the current shell implementation.  It has a few ideas, such as everything 
> > being asynchronous and completely removing the prompt, that may prove 
> > useful for improving Babel generally.  The blub implementation is also 
> > simpler than related parts of Babel and may be useful for figuring out ways 
> > to solve the currently known shortcomings.  If you run into an error during 
> > execution, you will need to call (setq my-org-babel-comint--async-uuid nil).
> 
> Doing everything asynchronously is not always desired.
> Consider, for example,
> 
> #+begin_src bash
> echo "Contents" > /tmp/tmpfile
> #+end_src bash
> 
> #+begin_src bash
> cat /tmp/tmpfile # I must run after /tmp/tmpfile is created!
> #+end_src

You "just" [1] need a way of stating dependencies :-)

Cheers

[1] In quotes, because this opens a vast space of interesting
   and strange worlds. The functional folks have their monads,
   the compiler backend builders have their dependency graphs.
   Definitely doable, but treading with care will be helpful
   to not step into a mess :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Ihor Radchenko]

Matt  writes:

> The blub implementation has the same shortcomings, at least for shells, as 
> the current shell implementation.  It has a few ideas, such as everything 
> being asynchronous and completely removing the prompt, that may prove useful 
> for improving Babel generally.  The blub implementation is also simpler than 
> related parts of Babel and may be useful for figuring out ways to solve the 
> currently known shortcomings.  If you run into an error during execution, you 
> will need to call (setq my-org-babel-comint--async-uuid nil).

Doing everything asynchronously is not always desired.
Consider, for example,

#+begin_src bash
echo "Contents" > /tmp/tmpfile
#+end_src bash

#+begin_src bash
cat /tmp/tmpfile # I must run after /tmp/tmpfile is created!
#+end_src

Also, using "print" statements to create output delimiters might
sometimes be tricky.
If I remember correctly Ruby repl is asynchronous and sometimes produces
unexpected artefacts when you send multiple commands in quick
succession. The commands may be executed in different order than you may expect.

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

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Ihor Radchenko]

Matt  writes:

> - Anything I could help with?  

https://github.com/tecosaur/org-latex-preview-todos/issues/21
It looks like the main remaining blocker is the lack of LaTeX snippet
export for ox-odt.

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

Re: [BUG]: elusive vertical white-space errors in engraved source block export

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> attached you'll find a pdf file showing the elusive vertical white-space 
> errors
> using the engraved source block export backend that I demonstrated 
> yesterday
> evening.

Confirmed.
Easier steps to reproduce (with engraved installed):

1. In Org git repo, make repro REPRO_ARGS="-L 
~/.emacs.d/straight/build/engrave-faces /tmp/any-backend.org"
2. M-: (require 'ob-latex)
3. M-: (setq org-latex-src-block-backend 'engraved)
4. C-c C-e l o
5. Observe Listing 1 having extra spaces with narrow horizontal lines -
   look like a single engraved box consists of multiple.

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