Re: keep intermediary tex from latex preview

[Karthik Chikmagalur]

>> By the way, using Ihor's suggestion, I was able to debug the issue.
>> There is nothing wrong with my configuration. The issue is that the
>> font cannot deal with that symbol, and LaTeX just skips it. Still, it
>> would be convenient not to have to create a separate .tex to debug
>> the preview. Thanks!
>
> AFAIR, the new preview system will record possible issues with previews
> and mark them appropriately in a tooltip.

In this specific case, it was recognized as an error.  Here is an image
of the result and the tooltip message with the new LaTeX preview system.

I typed \(μp + 1\) because getting a screenshot of the tooltip with just
the rendered `p' was tricky.

Karthik

[BUG] make cursor visible in calendar [9.6.7 ( @ /Users/eugenekim/.emacs.d/elpa/org-9.6.7/)]

[eugene kim]

--text follows this line--

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


I'd like to see the cursor when using keyboard to select a date from the
calendar when I use
org's schedule or deadline.

It can be done with keyboard, but the cursor is not visible.

I've tracked down the cause to the following line in org.el

Line13728:
   (org-eval-in-calendar '(setq cursor-type nil) t)

I've also found an issue which the line was trying to solve.
https://list.orgmode.org/87d36uip6p@gnu.org/

I'd like to see the cursor when I move date in the calendar window (with
shift-arrow)





Emacs  : GNU Emacs 29.1 (build 1, x86_64-apple-darwin18.7.0, NS
appkit-1671.60 Version 10.14.6 (Build 18G9323))
 of 2023-07-30
Package: Org mode version 9.6.7 ( @
/Users/eugenekim/.emacs.d/elpa/org-9.6.7/)

org-bibtex-yank failing with error Wrong type argument: stringp, nil

[J. G.]

Hi, I'm trying to figure out why I'm getting consistent failures using 
org-bibtex-yank. This appears to be identical to the problem posted here:

https://stackoverflow.com/questions/31174281/org-bibtex-yank-fails-with-wrong-type-argument-stringp-nil

On my system I am using a fresh Ubuntu 23.04 VM with the following emacs and 
org-mode build info:

GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo 
version 1.16.0) of 2023-08-11

Org mode version 9.7-pre (release_9.6.7-652-gcfea24 @ /home/test/org-mode/lisp/)

My backtrace is very similar to that posted in the stackoverflow thread:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  looking-at(nil)
  bibtex-parse-entry()
  org-bibtex-read()
  org-bibtex-yank()
  funcall-interactively(org-bibtex-yank)
  call-interactively(org-bibtex-yank record nil)
  command-execute(org-bibtex-yank record)
  execute-extended-command(nil "org-bibtex-yank" nil)
  funcall-interactively(execute-extended-command nil "org-bibtex-yank" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

My steps to reproduce, with this as my init.el file:

(add-to-list 'load-path "~/org-mode/lisp")
(require 'org-loaddefs)

1. Open test.org in emacs.

2. Copy a bibtex entry in Firefox, for example this entry from Google Scholar:

@article{dominik2004org,
  title={Org Mode Manual},
  author={Dominik, Carsten},
  year={2004}
}

3. In the org file call M-x org-bibtex-yank.

After that I experience the failure above 100% of the time.

Attempts to troubleshoot:

One of the comments in the stackoverflow thread mentioned that a reason this 
could have failed was that the variable "bibtex-dialect" wasn't set. C-h v 
confirms it was set in my case (to "BibTeX"), but the problem was still 
present. I added a line in my init.el file "(setq bibtex-dialect 'biblatex)" 
just to double check and the problem was still present.

As described in the same comment, with my original 2 line init.el file above,

1. simply opening a new file "dummy.bib" (doing nothing with it),

2. then opening "test.org",

3. copying a bibtex entry in Firefox,

4. calling org-bibtex-yank

caused org-bibtex-yank to correctly function. I did not need to call 
bibtex-set-dialect as the comment described.

[BUG] Warning (org-element-cache)

[Carmen Shea]

The following Warning message appeared while I was entering text into an 
Org-Roam file.


 [BUG] Warning (org-element-cache): org-elemt--cache: Org parser error 
in 2023073121272-student_reports_august_2023.org::7669. Resetting. The 
error was: (wrong-type-argument integer-or-marker-p nil) Backtrace: nil 
[9.6.7 (N/A @ 
/gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]







Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.37, cairo version 1.16.0)
Package: Org mode version 9.6.7 (N/A @ 
/gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)


current state:
==
(setq
 org-agenda-prefix-format '((dashboard-agenda . " %i %-12:c %s ")
            (agenda . " %i %-12:c%?-12t% s") (todo . " %i %-12:c")
            (tags . " %i %-12:c") (search . " %i %-12:c"))
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-roam-mode-hook '((lambda nil (display-line-numbers-mode 0)))
 org-agenda-files '("~/OrgAgenda" "~/RoamNotes/daily")
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
            org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-show-empty-lines

      org-cycle-optimize-window-after-visibility-change
      org-cycle-display-inline-images)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(toc-org-enable (lambda nil (display-line-numbers-mode 0))
     (lambda nil (org-superstar-mode 1)) org-indent-mode
     #[0 "\300\301\302\303\304$\207"
       [add-hook change-major-mode-hook org-fold-show-all append local]
       5]
     #[0 "\300\301\302\303\304$\207"
       [add-hook change-major-mode-hook org-babel-show-result-all
        append local]
       5]
     org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-link-translation-function 'toc-org-unhrefify
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
     org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate
          org-babel-speed-command-activate)
 org-fold-core-isearch-open-function 'org-fold-core--isearch-reveal
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
      org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
        org-attach-complete-link)
       ("eww" :follow org-eww-open :store org-eww-store-link)
       ("rmail" :follow org-rmail-open :store org-rmail-store-link)
       ("mhe" :follow org-mhe-open :store org-mhe-store-link)
       ("irc" :follow org-irc-visit :store org-irc-store-link
        :export org-irc-export)
       ("info" :follow org-info-open :export org-info-export :store
        org-info-store-link :insert-description
        org-info-description-as-command)
       ("gnus" :follow org-gnus-open :store org-gnus-store-link)
       ("docview" :follow org-docview-open :export
        org-docview-export :store org-docview-store-link)
       ("bibtex" :follow org-bibtex-open :store
        org-bibtex-store-link)
       ("bbdb" :follow org-bbdb-open :export org-bbdb-export
        :complete org-bbdb-complete-link :store org-bbdb-store-link)
       ("w3m" :store org-w3m-store-link)
       ("doi" :follow org-link-doi-open :export 
org-link-doi-export)

       ("id" :follow org-id-open) ("file+sys") ("file+emacs")
       ("shell" :follow org-link--open-shell)
       ("news" :follow
        #[514 "\301\300\302Q\"\207" ["news" browse-url ":"] 6
          "\n\n(fn URL ARG)"]
        )
       ("mailto" :follow
        #[514 "\301\300\302Q\"\207" ["mailto" browse-url ":"] 6
          "\n\n(fn URL ARG)"]
        )
       ("https" :follow
        #[514 "\301\300\302Q\"\207" ["https" browse-url ":"] 6
          "\n\n(fn URL ARG)"]
        )
       ("http" :follow
        #[51

Re: org-bibtex-yank failing with error Wrong type argument: stringp, nil

[J. G.]

On Friday, August 11, 2023 at 09:34:31 AM PDT, J. G.  
wrote: 
> Hi, I'm trying to figure out why I'm getting consistent failures using 
> org-bibtex-yank. This appears to be identical to the problem posted here:
On further investigation I have pinpointed the precise error as referenced by 
the comment in the Stackoverflow thread. One of the nested function calls 
stemming from org-bibtex-yank is to bibtex-parse-entry in bibtex.el, and that 
in turn attempts to make use of the internal variable 
bibtex-entry-maybe-empty-head. That variable, among others, has documentation 
that they are nil until initialized by bibtex-set-dialect, which sets a number 
of other internal variables along with bibtex-dialect. That default nil value 
bubbles up to cause the error I am experiencing. The solution in my original 
email of opening a dummy.bib file works because it calls bibtex-mode and that 
calls bibtex-set-dialect.
Adding the following two lines to my init fixes the error in my case:
(require 'bibtex)(bibtex-set-dialect 'biblatex nil)
where the first line seems to be necessary in my barebones case because bibtex 
isn't yet loaded, and the second line sets my dialect of choice (biblatex) and 
sets the internal variables for bibtex globally (nil), not locally (t).
Given the disconnect between the error and the solution (as I understand it at 
least), and the absence of this necessity in the documentation (I have read 
through at least ol-bibtex.el), perhaps a small mention of this in the 
documentation in ol-bibtex.el is in order, and I can submit a patch for review?

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

may i post a few notes?

i've had tehse previously.

1.

i rely on org-mouse for accessibility, as i often cannot use keyboard
at all, so there is a personal stake in having it be part of org so
that it is fully integrated.  of course i have no problem with having
to enable it instead of only load it.

it has /minor/ limbo status in that, for example, you can't set a
specific todo kw with the mouse, but that does not disturb me as much
as code rot.  see below.

2.

i don't use org-inlinetask enough to have a personal stake [in my case
i could make them siblings], but it seemed to me that it was never
sufficiently integrated into org, or had bugs, at least before parsers
became common.

if anybody does have a strong personal stake in them, like i do in 1.,
it might be desirable to make inline tasks, even breakingly, part of
org, merely to make sure that they fully integrate and test, as
opposed to limbo or code rot.

i would apply that principle to org-mouse, which being smallish and
about bindings is probably not too disruptive to be part of org.  i
defer the measurement of the disruptiveness of inline tasks to the
experts/stakeholders.

3.

istr loading org-id is or was what enables org-ids?  i'd rather have
org-id work by default.  OR maybe require activating.

4.

idk if related, but some settings in org must be done before loading.
i'd want a guideline in which, where possible, settings can be done
after loading.  this is because the user might need to go through
contortions in .emacs.  a user can do with-eval-after-load, but
with-eval-before-load sounds radically grotesque.


On 8/12/23, Bastien Guerry  wrote:
> Ihor Radchenko  writes:
>
>> Yes, org-mouse modifies the behavior of certain key bindings. Not
>> directly, but by advising `org-open-at-point'.
>
> IIRC Emacs core libraries should not advise functions.
> This is something we should fix.
>
> Also, I'm not sure org-mouse.el has its place in Org's core nowadays.
>
>> It changes the very notion of that is a headline - the syntax definition
>> is altered. Very deeply nested headlines may become inlinetasks upon
>> loading org-inlinetask, touching all aspects of Org, not just editing.
>
> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
>> And it is not clear how to fix this. We did not make inlinetasks into
>> standard Org syntax in the past and now it is in the weird state when we
>> have (featurep 'org-inlinetask) sprinkled across the code just to
>> accommodate for this conditional syntax.
>
> Yes, this is ugly.
>
>> Inlinetasks are too similar in syntax with headlines, so it is
>> impossible to make the change backwards-compatible.
>>
 With the current state of affairs, it is often enough to
 (require 'org-library) to get things work. If we get rid of all the
 possible side effects, users will have to adapt their configurations
 and we will thus violate "I won't force you to update your
 configuration."
>>>
>>> Defining new functions is a desirable "side-effect" of all Elisp
>>> library, I don't think we should worry abou this.
>>
>> Defining new functions by itself is not a big deal. But there are parts
>> of Org that alter their behavior depending on whether a feature is
>> loaded (like org-inlinetask) or depending whether certain function
>> symbol is defined (babel). Similarly, loading new link types re-defines
>> Org syntax in all the documents, affecting editing of everything that
>> looks like the loaded link type (org-ctags).
>
> I feel like the stakes are not the same for features like org-mouse.el
> and org-inlinetask.el and for core features like Babel libs and links.
> For the former, a decision should be made relatively to the usefulness
> of the feature; for the latter, loading libs (with side-effects on the
> syntax) is required by the design of the core feature at hand (Babel
> and links).
>
> I'd focus on solving the problem with org-mouse and org-inlinetasks
> first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ?
>
> --
>  Bastien Guerry
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] Testing: Ensure 'org-id-locations-file' is set before updating

[Max Nikulin]

On 12/08/2023 16:29, Ihor Radchenko wrote:

Morgan Smith writes:


Hello!  This fix allows me to run the tests without giving it access to the
filesystem outside of the repository.  I have no clue what org-id-locations are
and I'm hoping someone else does so I don't have to learn.  I'm not sure if
this is the best fix, but it works.


In the absence of clear understanding what went wrong, I cannot accept
this patch, unfortunately.


mkdir ~/hide
mv -i ~/.emacs* ~/hide
make test-dirty BTEST_RE=test-org-link

Finding ID locations (26/26 files): 
/home/ubuntu/src/org-mode/testing/examples/agenda-file.org
Opening output file: No such file or directory, 
/home/ubuntu/.emacs.d/.org-id-locations

make: *** [mk/targets.mk:100: test-dirty] Error 255

I have not looked closely into the proposed patch, but I find it 
reasonable expectation that tests should not write to ~/.emacs.d/

Re: how can I get the output of a =#+begin_src org= in the current buffer?

[Edgar Lux]

Thanks!!!

Regarding the typo, it does not show here. But in the info buffer, the =(see 
*note...= becomes (see see ...).

See (:P) attachment

On Aug 12, 2023 at 1:07 PM, Ihor Radchenko  wrote:Edgar 
Lux  writes:

> #+begin_src org
>   #+latex_header: \usepackage{nil}
> #+end_src
>
> What I want is to get =#+latex_header: \usepackage{nil}= in the current
buffer. The documentation (Org-info and the docstring of
=org-babel-execute-src-block=) says that this command would
> #+begin_quote
> Insert the results of execution into the buffer
> #+end_quote
>
> Tips, advice? Thank you!

See https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-org.html
You need

#+begin_src org :results replace
  #+latex_header: \usepackage{nil}
#+end_src

> - There is a typo in the info pages (parses as see see; remove see from
below):
>   (org) Results of Evaluation
>   #+begin_quote
>The ‘file-desc’ header argument defines the description (see *note
>  Link Format::) for the link
>   #+end_quote

May you elaborate?

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

-- 
Sent with https://mailfence.com  
Secure and private email

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> Yes, org-mouse modifies the behavior of certain key bindings. Not
> directly, but by advising `org-open-at-point'.

IIRC Emacs core libraries should not advise functions.
This is something we should fix.

Also, I'm not sure org-mouse.el has its place in Org's core nowadays.

> It changes the very notion of that is a headline - the syntax definition
> is altered. Very deeply nested headlines may become inlinetasks upon
> loading org-inlinetask, touching all aspects of Org, not just editing.

Same here, I'd be tempted to deny Org citizenship to inline tasks: it
always felt like a nice hack for a niche use-case, but a hack anyway.

If it modifies Org syntax in surprising ways, this is another argument
for removing org-inlinetask.el from Org's core.  Remember: this is not
to say that inline tasks are forbidden, it's just a message for users
that inline tasks are something not maintained by Org's core team.

> And it is not clear how to fix this. We did not make inlinetasks into
> standard Org syntax in the past and now it is in the weird state when we
> have (featurep 'org-inlinetask) sprinkled across the code just to
> accommodate for this conditional syntax.

Yes, this is ugly.

> Inlinetasks are too similar in syntax with headlines, so it is
> impossible to make the change backwards-compatible.
>
>>> With the current state of affairs, it is often enough to
>>> (require 'org-library) to get things work. If we get rid of all the
>>> possible side effects, users will have to adapt their configurations
>>> and we will thus violate "I won't force you to update your
>>> configuration."
>>
>> Defining new functions is a desirable "side-effect" of all Elisp
>> library, I don't think we should worry abou this.
>
> Defining new functions by itself is not a big deal. But there are parts
> of Org that alter their behavior depending on whether a feature is
> loaded (like org-inlinetask) or depending whether certain function
> symbol is defined (babel). Similarly, loading new link types re-defines
> Org syntax in all the documents, affecting editing of everything that
> looks like the loaded link type (org-ctags).

I feel like the stakes are not the same for features like org-mouse.el
and org-inlinetask.el and for core features like Babel libs and links.
For the former, a decision should be made relatively to the usefulness
of the feature; for the latter, loading libs (with side-effects on the
syntax) is required by the design of the core feature at hand (Babel
and links).

I'd focus on solving the problem with org-mouse and org-inlinetasks
first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ?

-- 
 Bastien Guerry

Re: how can I get the output of a =#+begin_src org= in the current buffer?

[Ihor Radchenko]

Edgar Lux  writes:

> #+begin_src org
>   #+latex_header: \usepackage{nil}
> #+end_src
>
> What I want is to get =#+latex_header: \usepackage{nil}= in the current 
> buffer. The documentation (Org-info and the docstring of 
> =org-babel-execute-src-block=) says that this command would
> #+begin_quote
> Insert the results of execution into the buffer
> #+end_quote
>
> Tips, advice? Thank you!

See https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-org.html
You need

#+begin_src org :results replace
  #+latex_header: \usepackage{nil}
#+end_src

> - There is a typo in the info pages (parses as see see; remove see from 
> below):
>   (org) Results of Evaluation
>   #+begin_quote
>The ‘file-desc’ header argument defines the description (see *note
>  Link Format::) for the link
>   #+end_quote

May you elaborate?

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

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:

>> + (vwidth (if (not lit)
>> + (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" 
>> versewidth) "")
>> +   ""))
>
> Can just do (if (and versewidth (not lit)) (format ...) "")
>
>> + (linreset (if (not lit)
>> +   (if lin "\n\\poemlines{0}" "")
>> + "")))
>
> (if (and lin (not lit)) ...)

Thanks for the suggestions. Yes, it's simpler that way.

>>  (concat
>>   (org-latex--wrap-label
>>verse-block
>>;; In a verse environment, add a line break to each newline
>>;; character and change each white space at beginning of a line
>> -  ;; into a space of 1 em.  Also change each blank line with
>> -  ;; a vertical space of 1 em.
>> -  (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> +  ;; into a normal space, calculated with `\fontdimen2\font'.
>> +  ;; One or more blank lines between lines are exported as a
>> +  ;; single blank line.  If the `:literal' attribute is used,
>> +  ;; CONTENTS is exported as is, with no environment, preserving
>> +  ;; line breaks and vertical and horizontal spaces.
>> +  (format (if (not lit)
>> +  "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> +"%s%s\n%s%s")
>
> In the case of lit vwidth and attr are always empty. So, you are
> inserting an extra newline in front. Is it intentional?

I used that procedure because an extra blank line before (in the LaTeX
code) it has no effect in LaTeX compilation. And in case the :literal
attribute is present, vertical spaces are achieved by explicit
\vspace*{}. One or more empty lines before it just marks the beginning
of a new paragraph.

Naturally, if :literal is used the rest of attributes are meaningless
because they are intended for the verse environment. They can even give
some error in the compilation. So I opted to disable them with the mere
presence of :literal, leaving them 'empty' (so as not to manipulate the
function further).

>> +(concat "\\("
>> +(regexp-quote org-latex-line-break-safe)
>> +"\n\\)"
>> +"\\(^[ \t]*"
>> +(regexp-quote org-latex-line-break-safe)
>> +"\n"
>> +"\\)+")
>> +  (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) 
>> "$"))
>
> May also use rx for better readability.

I remember that I tried rx a while ago and found it very useful and
comfortable, but then I haven't done anything with it. The fact is that
over time I have ended up getting used to suffering from the classic
regexp and it is hard for me to get out of there :-). Of course, with rx
it would be clearer but I would have to refresh my memory.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

how can I get the output of a =#+begin_src org= in the current buffer?

[Edgar Lux]

Hello, how can I get the output of a =#+begin_src org= in the current buffer?

#+begin_src emacs-lisp
  (org-babel-do-load-languages 
 'org-babel-load-languages 
 '((shell   . t)
   (latex   . t)
   (emacs-lisp  . t)
   (org . t)
   ))
#+end_src

#+caption: This shows the contents of the block in the mini-buffer with =C-c 
C-v e= (=org-babel-execute-maybe=)
#+begin_src org
  #+latex_header: \usepackage{nil}
#+end_src

What I want is to get =#+latex_header: \usepackage{nil}= in the current buffer. 
The documentation (Org-info and the docstring of =org-babel-execute-src-block=) 
says that this command would
#+begin_quote
Insert the results of execution into the buffer
#+end_quote

Tips, advice? Thank you!

Org 9.4.6
Emacs 28.2
Linux

P.S.
- I saw this, but it is unrelated (a src block inside another src block).
https://emacs.stackexchange.com/questions/35489/babel-src-block-inside-src-block
- There is a typo in the info pages (parses as see see; remove see from below):
  (org) Results of Evaluation
  #+begin_quote
   The ‘file-desc’ header argument defines the description (see *note
 Link Format::) for the link
  #+end_quote

-- 
Sent with https://mailfence.com  
Secure and private email

Re: [PATCH] ob-sqlite: Use a transient in-memory database by default

[Max Nikulin]

On 06/08/2023 07:22, Rudolf Adamkovič wrote:

* lisp/ob-sqlite.el (org-babel-execute:sqlite): Default ':db' to
":memory:" instead of throwing an error.


This commit message entry does not reflect changed approach clearly 
enough. Not passing :db is a bit different from default :memory:. Sorry 
that I have not noticed it earlier. Since the commit has been pushed, I 
do not expect any further action in response.



@@ -97,7 +96,7 @@ This function is called by `org-babel-execute-src-block'."
  (member :html others) separator)
  ""
"-csv"))
- (cons "db " db)))
+  (cons "db" (or db ""


My expectation was that sqlite3 should print a warning, but actually it 
does not.


echo "select 1" | sqlite3
1

sqlite3
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

In this sense I would prefer the previous version of the patch, but I 
admit, it is my fault that I did not tried it despite a week passed.

Re: [PATCH] Testing: Ensure 'org-id-locations-file' is set before updating

[Ihor Radchenko]

Morgan Smith  writes:

> Hello!  This fix allows me to run the tests without giving it access to the
> filesystem outside of the repository.  I have no clue what org-id-locations 
> are
> and I'm hoping someone else does so I don't have to learn.  I'm not sure if
> this is the best fix, but it works.

In the absence of clear understanding what went wrong, I cannot accept
this patch, unfortunately.
Canceled.

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

Re: [PATCH] org-macs.el: Fix Emacs-26 compatibility

[Max Nikulin]

On 11/08/2023 23:27, Ihor Radchenko wrote:

Max Nikulin writes:


Loading /home/ubuntu/src/org-mode/lisp/org-compat.el (source)...
Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 6)


That failure does not really point to where it happened... I am
wondering how you managed to find out the cause.


This time I decided that it is becoming a recurring issue (despite the 
comment in the function performing expansion) and I should not be first 
person faced it. A search engine gave me


https://emacs.stackexchange.com/questions/54455/how-to-get-a-stack-trace-for-eager-macro-expansion-failure


(setq debug-on-signal t))


Fortunately other signals (a lot of them) are emitted later. Sometimes 
debugging facilities in Emacs are rather disappointing.

Re: [PATCH] ob-sqlite: Use a transient in-memory database by default

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> From 34f28236366affb510bfdb70a3577e765d9e0abb Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
> Date: Wed, 3 May 2023 14:59:03 +0200
> Subject: [PATCH] ob-sqlite: Use a transient in-memory database by default
>
> * etc/ORG-NEWS (New features): Add a news entry.
> * lisp/ob-sqlite.el (org-babel-execute:sqlite): Default ':db' to
> ":memory:" instead of throwing an error.
> * testing/lisp/test-ob-sqlite.el (ob-sqlite/in-file): Test the old behavior.
> * testing/lisp/test-ob-sqlite.el (ob-sqlite/in-memory): Test the new behavior.

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

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

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Ihor Radchenko]

Juan Manuel Macías  writes:

> How about this (pre-)patch? With the `:literal' attr., the content of the
> block is exported "as is", with all manual formatting preserved.

Looks reasonable in general.
Of course, we will also need to document the new attribute.

> I have made some modifications in the horizontal and vertical spaces (in
> case :literal is used)...

Makes sense to me.

> + (vwidth (if (not lit)
> +  (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" 
> versewidth) "")
> +""))

Can just do (if (and versewidth (not lit)) (format ...) "")

> + (linreset (if (not lit)
> +(if lin "\n\\poemlines{0}" "")
> +  "")))

(if (and lin (not lit)) ...)

>  (concat
>   (org-latex--wrap-label
>verse-block
>;; In a verse environment, add a line break to each newline
>;; character and change each white space at beginning of a line
> -  ;; into a space of 1 em.  Also change each blank line with
> -  ;; a vertical space of 1 em.
> -  (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
> +  ;; into a normal space, calculated with `\fontdimen2\font'.
> +  ;; One or more blank lines between lines are exported as a
> +  ;; single blank line.  If the `:literal' attribute is used,
> +  ;; CONTENTS is exported as is, with no environment, preserving
> +  ;; line breaks and vertical and horizontal spaces.
> +  (format (if (not lit)
> +   "%s\\begin{verse}%s\n%s\\end{verse}%s"
> + "%s%s\n%s%s")

In the case of lit vwidth and attr are always empty. So, you are
inserting an extra newline in front. Is it intentional?

> + (concat "\\("
> + (regexp-quote org-latex-line-break-safe)
> + "\n\\)"
> + "\\(^[ \t]*"
> + (regexp-quote org-latex-line-break-safe)
> + "\n"
> + "\\)+")
> +   (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) 
> "$"))

May also use rx for better readability.

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