Re: [BUG] Org mode donation page is marked in French, but it is actually in English

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> Liberapay provides options to have team description in multiple
> languages. We only provide English, but the description is marked as if
> it were French. See the text near "Edit" button at the top right part of
> https://liberapay.com/org-mode/
>
> I guess we should rather mark the page as English at
> https://liberapay.com/org-mode/edit/statement (see "switch to other
> language").

Done - I also added a French description.

> We may also add appropriate translations, though I have no idea how
> useful it is.

I don't know either...

Thanks,

-- 
 Bastien

Re: on picking diary-style timestamps or normal timestamps when adding agenda entries (was: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/s

[Ihor Radchenko]

andrés ramírez  writes:

> The only missing part from the given example was the message. The given
> example was:
> , [  ]
> | ** PE 
> :DAVID:
> | :PROPERTIES:
> | :CATEGORY: da.santi
> | :END:
> | %%(diary-block 10 1 2022 10 1 2022) 9:00-11:00 retiro.espiritual 
> {collaborator.family}
> `
> which one would the place for 'retiro.espiritual {collaborator.family}'?

** PE etiro.espiritual {collaborator.family} :DAVID:
:PROPERTIES:
:CATEGORY: da.santi
:END:
<2022-09-24 Sat 9:00-11:00>

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

on picking diary-style timestamps or normal timestamps when adding agenda entries (was: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share

[andrés ramírez]

Hi. Ihor.

> "Ihor" == Ihor Radchenko  writes:


[...]

Ihor> What about
--8<---cut here---start->8---
** PE :DAVID:
:PROPERTIES:
:CATEGORY: da.santi
:END:
<2022-10-01 Sat>
--8<---cut here---end--->8---


The only missing part from the given example was the message. The given
example was:
, [  ]
| ** PE :DAVID:
| :PROPERTIES:
| :CATEGORY: da.santi
| :END:
| %%(diary-block 10 1 2022 10 1 2022) 9:00-11:00 retiro.espiritual 
{collaborator.family}
`
which one would the place for 'retiro.espiritual {collaborator.family}'?

Ihor> The long file name you are seeing in agenda is dictated by category in
Ihor> org-agenda-prefix-format:

Ihor>%c the category of the item, "Diary" for entries from the 
diary, or as given by the
Ihor> CATEGORY keyword or derived from the file name

I started using org-mode on emacs-23. So I remember from that year until
now. Once I needed to reformat my agenda files (because CATEGORY was
needed for trying to mimic my previous behaviour of org-agenda). After
settle on that I have not examined that part of my workflow anymore. But
this is emacs 'trying to shave things of our workflow and improve our
daily tasks routines'. I am reviewing it now with You guys.

Best Regards

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

Max Nikulin  writes:

> On 23/09/2022 10:05, Ihor Radchenko wrote:
>> 
>> I added caching of `org-diary-sexp-entry' results in
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4075662c298da7fa7e2ba19e0b8b36c58852cc0f
>
> Sorry for the noise. I am unsure concerning exact effect of the commit, 
>   I hope, if agenda is rebuilt after several days since first call, 
> actual timestamps are used. Maybe my note makes no sense since I am 
> completely ignorant concerning generation of agenda.

The cache keys are the function arguments. And agenda date is one of
those arguments:

"Process a SEXP diary ENTRY for date D."

The only real concern I can think about is cache size that may grow over
a very long Emacs sessions. But I am unsure if this is something we
really need to worry about in practice.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: refresh not working for org-mode from git

[Ihor Radchenko]

Colin Baxter  writes:

> Recently, if I use C-c C-x ! to refresh org-mode after a git pull, I get an
> error. I then have to close down emacs and launch again. This rather
> defeats the object of C-c C-x !. This appears to have happened only recently

Does it help if you run make after git pull?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> I see. Thanks for the clarification. Then I think I saw it in the past. But 
> when You do it. the agenda
> filename appears on the agenda buffer (the agenda filename is large on my 
> case) . So I prefer
> give to the entry a short category.
>
> This is my use case:
> --8<---cut here---start->8---
> ** PE :DAVID:
> :PROPERTIES:
> :CATEGORY: da.santi
> :END:
> %%(diary-block 10 1 2022 10 1 2022) 9:00-11:00 retiro.espiritual 
> {collaborator.family}
> --8<---cut here---end--->8---
>
> so. the short label 'da.santi' is what appears on my agenda.

What about

** PE :DAVID:
:PROPERTIES:
:CATEGORY: da.santi
:END:
<2022-10-01 Sat>

The long file name you are seeing in agenda is dictated by category in
org-agenda-prefix-format:

   %c the category of the item, "Diary" for entries from the diary, or as
   given by the CATEGORY keyword or derived from the file name

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Ihor Radchenko]

Timothy  writes:

>> My impression is that this change is against Timothy’s attempt to make the 
>> top
>> banner cleaner.
>
> For what it’s worth, I personally consider stuffing lines of “important!” text
> into that “what is Org?” banner ultimately counterproductive. I think it fails
> to provide the information with enough context (e.g. `M-x 
> org-submit-bug-report
> RET' doesn’t provide the information provided on the Feedback.html page), and 
> it
> also muddies the structure of the page while making it appear more cluttered.

I am slightly in favour of reducing the clutter.

Also, Bastien mentioned (AFAIU) an idea to have a badge for source
code. Maybe instead of git clone? I was previously reluctant to use
savannah link instead of copy-pasteable "git clone ..." text, but I now
notice that https://git.savannah.gnu.org/cgit/emacs/org-mode.git/ works
with git clone and the page even lists tarballs for the Org releases.

So, we may create a badge with an icon representing src code (maybe
" | source code"?) that will point to
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: IM dev discussions?

[Mark Barton]

> On Sep 23, 2022, at 6:44 PM, Tim Cross  wrote:
> 
> You will likely find more young people
> who use Emacs and org will also use email more, but I don't know if that
> is because the types of people attracted to Emacs and org mode are also
> the types of people more attracted to email for comms.


My trend has been moving from GUI to the benefit that text based solutions 
provide: reproducibility, version control, and documentation. 
In my case, email is much easier to extract into my task management system than 
most IM type solutions. IM is good for short conversations, but really has a 
problem with organizing more historic data that may be needed for much tougher 
topics that cannot be answered in a single session. Slack threads really drive 
me crazy, because I have a hard time finding them again after a day or so. This 
is where I use DEVONthink to associate different forms of data into the related 
projects and use DEVONthink links in org mode for my notes and task management.

Re: [PATCH] Babel evaluation: location and timing information (v2)

[Ihor Radchenko]

Timothy  writes:

> * lisp/ob-core.el (org-babel-execute-src-block,
> org-babel-format-result): Record the babel execution time, and then
> supplement the "Code block evaluation complete." (etc.) messages with
> the execution time when >0.05s.

I'd also mention the new optional arguments.

> -(defun org-babel-execute-src-block ( arg info params)
> +(defun org-babel-execute-src-block ( arg info params executor)
>"Execute the current source code block and return the result.
>  Insert the results of execution into the buffer.  Source code
>  execution and the collection and formatting of results can be
> @@ -729,13 +729,31 @@ (defun org-babel-execute-src-block ( arg info 
> params)
>  
>  Optionally supply a value for PARAMS which will be merged with
>  the header arguments specified at the front of the source code
> -block."
> +block.
> +
> +EXECUTOR is the type of the org element responsible for the
> +execution of the source block.  If not provided then this is
> +inferred to be a source block or inline source block, inspecting
> +the buffer content at the block location to determine which."

This argument name executor sounds awkward. Why not something like 
src-block-type?

> + (executor
> +  (or executor
> +  ;; If `executor' is unset, then this cannot be a babel
> +  ;; call (as `org-babel-lob-execute-maybe' provides the
> +  ;; type of the execution triggering element) and so this
> +  ;; must be an inline src block or src block.  We can
> +  ;; easily pick between the two by just looking at the
> +  ;; first character of each case.  In case something
> +  ;; strange happens, this can be set to unknown.

This comment is confusing. From my reading of it, you only consider
internal usage of `org-babel-execute-src-block' in Org code. But
`org-babel-execute-src-block' is not an internal function and hence we
cannot assume the callers.

I think that it is sufficient to stick to what the docstring says about
nil EXECUTOR value.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] Width property in columnview dynamic blocks [9.5.5]

[Ihor Radchenko]

Ypo  writes:

> In columnview dynamic blocks, the Width property doesn't seem to work
>
> In this example the first column width is the same if I write ~%5ITEM~
> than ~%ITEM~
>
> * PROYECTO EMACS
> :PROPERTIES:
> :COLUMNS:  %5ITEM(PROJECT)
> :END:
>
> #+BEGIN: columnview
> #+END:

Confirmed.
Unlike `org-columns' command (C-c C-x C-c), dynamic column blocks are
ignoring the width specs. Handling specs is simply not implemented. This
is not explicitly stated in the manual though.

One can just add column width specs in `org-dblock-write:columnview'.
Or we may document the current behaviour.

Patches welcome :)

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org-beamer improvement?

[Ihor Radchenko]

Guillaume MULLER  writes:

> The only thing I miss in org lies in org-beamer: it is the ability to use the 
> star '*' in BEARMER_ACT, with something like:
> * my block1
> :PROPERTIES:
> :BEAMER_ACT: *<1>
> :BEAMER_ENV: block
> :END:
> ...
> I know block do not natively accept *<1> notation, but it would be great if 
> org would detect the * in BEAMER_ACT directive and translate that into some 
> code similar to the one I generate manually (#+LATEX + onslide* + shadow 
> "ignoreheading "closing block).
>
> Any thoughts on this?

What you are proposing is basically to wrap the environment into
\onslide+ \onslide* or \onslide commands.

These commands are only part of the available generic overlay
specifications in Beamer.

What about allowing something like

:BEAMER_ACT: \command

that will make Beamer wrap the exported environment like
\command{exported beamer block}?

Also, note that we are currently discussing a more general way to wrap
elements during export in
https://orgmode.org/list/87czbna4e4.fsf@localhost

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: IM dev discussions?

[Timothy]

Hi Tim,

> I observe the same behaviour. My kids (27, 24) both have email accounts,
> but only have them and use them for places which insist on an email
> address (like government services, universities etc). They use email
> only when they have to and check it only when they are expecting a
> message. For them, it is IM services (even there, the ones used will
> also depend on your age within the <30 - seems to be a trend from FB
> messenger, snapchat, discord, whatsapp, tiktok - and even there FB
> messenger is probably just to IM with their parents!). From their
> perspective, FB is what their parents use and email is what their
> grandparents use! No way will they use a mail list.
>
> Of course there are exceptions. You will likely find more young people
> who use Emacs and org will also use email more, but I don’t know if that
> is because the types of people attracted to Emacs and org mode are also
> the types of people more attracted to email for comms.
>
> These days, when I want interactive chat, I actually prefer to go with
> real chat rather than text based chat. There are so many choices for
> voice chat these days, you may as well have real interaction and just
> talk! This is where the technology really blows my mind now. A little
> while ago, I was collaborating with someone where we were talking using
> a voice chat app. It was a bug squashing collaboration where we worked
> through a bunch of bugs together and got a heap fixed in a 2 hours
> intensive session. I was in Australia and they were in South America AND
> travelling on a bus! While there was a couple of instances where we lost
> voice comms briefly, it was remarkably successful and it still blows my
> mind that I was live coding with someone half way around the world,
> travelling on a bus while we coded and chatted in real time! 30 years
> ago, we would both need to be in stable locations with land-lines and
> IRC would be the most interaction we could hope for - voice definitely
> not!

I find that very interesting to hear. It reminds me that the bcachefs matrix
room (which I hang out in),which has a Jitsi widget. Over there it seems that
occasionally the lead developer and the main other contributor seem to hang out
there while working on the project.

Doing something similar for Org development is an interesting idea. Something
similar probably could be set up with the Org room, or a dedicated Org-dev room
(I’m aware of Bastien’s thoughts on wanting development and help to not be
separated, but while I like the idea of them living in the same space, I’m
personally a big fan of categorisation. For instance, we could make an org-mode
space with a few different rooms: org-dev, org-help, org-showcase, org-chat,
etc.).

With regards to accessibility, I think Matrix is also reaching a rather good
point. The current state of affairs includes an Emacs client, a host of
dedicated apps, in-browser web clients, and more. While the ability to peruse
archives has not yet been developed, it is also possible to copy a link to a
particular message, and so a conversation can be transferred from Matrix to the
ML with a link to the initial conversation, e.g.


All the best,
Timothy

Re: IM dev discussions?

[Tim Cross]

Bastien  writes:

> Of course, time and skills (and other psychological traits) are the
> main parameters deciding whether someone can participate to these
> discussions: but the more they take place on the mailing list, the
> more inclusive they are IMHO.
>
> (I know this opinion is debatable: most <30yo (<35yo) hackers out
> there will say that relying on a mailing list for such discussions
> wards them off, insisting we should go on GitHub... but *anyone* can
> send an email to a list, while only registered GitHub users can open
> an issue. We certainly don't want to encourage anyone to register on
> GitHub.)

I observe the same behaviour. My kids (27, 24) both have email accounts,
but only have them and use them for places which insist on an email
address (like government services, universities etc). They use email
only when they have to and check it only when they are expecting a
message. For them, it is IM services (even there, the ones used will
also depend on your age within the <30 - seems to be a trend from FB
messenger, snapchat, discord, whatsapp, tiktok - and even there FB
messenger is probably just to IM with their parents!). From their
perspective, FB is what their parents use and email is what their
grandparents use! No way will they use a mail list.

Of course there are exceptions. You will likely find more young people
who use Emacs and org will also use email more, but I don't know if that
is because the types of people attracted to Emacs and org mode are also
the types of people more attracted to email for comms.

These days, when I want interactive chat, I actually prefer to go with
real chat rather than text based chat. There are so many choices for
voice chat these days, you may as well have real interaction and just
talk! This is where the technology really blows my mind now. A little
while ago, I was collaborating with someone where we were talking using
a voice chat app. It was a bug squashing collaboration where we worked
through a bunch of bugs together and got a heap fixed in a 2 hours
intensive session. I was in Australia and they were in South America AND
travelling on a bus! While there was a couple of instances where we lost
voice comms briefly, it was remarkably successful and it still blows my
mind that I was live coding with someone half way around the world,
travelling on a bus while we coded and chatted in real time! 30 years
ago, we would both need to be in stable locations with land-lines and
IRC would be the most interaction we could hope for - voice definitely
not! 

Re: Opening of links

[Ihor Radchenko]

Guillaume MULLER  writes:

> + [[file:~/test.pdf][PDF 1]]
> --
>
> When I click on the link with mouse1, the document is opened in Calibre. When 
> I use mouse3, the document is opened in Emacs. I get a similar behavior with 
> org-attached PDF documents: using 'o' will open them in Calibre, 'O' in Emacs.
>
> Such a behavior for mouse1/'o' raises 2 questions:
>
> - My OS settings are configured so that PDFs are opened in Evince. I 
> configured this with "xfce4-settings-manager > Default Applications" (which 
> runs "xfce4-mime-settings" under the hood) and it can be verified with 
> "xdg-open test.pdf" or by opening Thunar and clicking on "test.pdf".
>So, where in the world does org-mode/Emacs finds that it should use 
> Calibre instead of Evince?
>
> - Now, I would like to circumvent this global OS behavior, so that Emacs 
> itself would be used specifically to open PDF links in files I open in Emacs. 
> When I was using Vanilla Emacs, I was advised to use pdf-tools, and given a 
> config that was working. I translated that into my DoomEmacs config.org as 
> follows:
>(use-package! pdf-tools
>  :magic ("%PDF" . pdf-view-mode)
>  :config
>(pdf-tools-install :no-query)
>  )
>But apparently it does not override org's (default) behavior of opening 
> PDF file with external tools.
>Is there

See https://orgmode.org/manual/Handling-Links.html#Handling-Links
(search org-open-at-point). The app selection is controlled by
org-file-apps customization.

> Sorry for these (probably very) basic questions, but I could not find 
> anything relevant on the web (or I haven't found the correct keywords...). I 
> would be very grateful of any help!

No problem. This mailing list is open to all Org-related staff,
including basic questions. Do not hesitate to participate in the
discussion or ask anything.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Suggestion: add org-latex-preview to org-ctrl-c-ctrl-c

[Ihor Radchenko]

Akira Kyle  writes:

> I recently thought to add ~org-latex-preview~ to 
> ~org-ctrl-c-ctrl-c~ and it has been quite the productivity 
> booster! Two arguments as to why this should be done:
> - ~org-ctrl-c-ctrl-c~ currently does nothing when inside 
>   latex-fragment or latex-environment so why not make it 
>   ~org-latex-preview~?
> - This intuitively matches my muscle memory from using 
>   babel. LaTeX is code after all, and I'm often making mistakes, 
>   so I want the fastest "edit-compile-edit" loop possible.

Yes, it is indeed a good idea.
Alternatively, we may also use  for this.
Also, there is https://github.com/awth13/org-appear/

> Here's what I currently have to achieve this in case anyone wants 
> to give it a try right now :)
>
> #+begin_src emacs-lisp
> (defun my-org-ctrl-c-ctrl-c-latex-preview-hook ()
>   (let ((element (car (org-element-context

It will be more reliable to use `org-element-type' instead of `car'. The
latter is relying on internal implementation detail.

> (if (or (eq element 'latex-fragment) (eq element 
> 'latex-environment))

Can simply use (memq element-type '(latex-fragment latex-environment))

Would you be interested to submit a patch?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] Face attribute customization is ignored [9.5.5 (9.5.5-gbe2246 @ /home/dav/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

David Vicente  writes:

> The attribute customization of org-block-begin-line and 
> org-block-end-line is ignored, i.e, the :extend attribute gets 
> overwritten when we start org-mode and ends up with value t.
>
> After inspecting the source code I suspect that it might have something 
> to do with org-fontify-whole-block-delimiter-line...

Yes, it does. Just set it to nil, and you will be good to go.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

[BUG] Org mode donation page is marked in French, but it is actually in English

[Ihor Radchenko]

Hi,

Liberapay provides options to have team description in multiple
languages. We only provide English, but the description is marked as if
it were French. See the text near "Edit" button at the top right part of
https://liberapay.com/org-mode/

I guess we should rather mark the page as English at
https://liberapay.com/org-mode/edit/statement (see "switch to other
language").

We may also add appropriate translations, though I have no idea how
useful it is.

Best,
Ihor

Re: refresh not working for org-mode from git

[Tim Cross]

Colin Baxter  writes:

> Recently, if I use C-c C-x ! to refresh org-mode after a git pull, I get an
> error. I then have to close down emacs and launch again. This rather
> defeats the object of C-c C-x !. This appears to have happened only recently
>
> The Backtrace is
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (error "Org version mismatch.  Make sure that 
> correct `loa...")
>   (signal error ("Org version mismatch.  Make sure that correct `loa..."))
>   (error "Org version mismatch.  Make sure that correct `loa...")
>   (byte-code "\300\301!\210\302 
> \303\232\204\23\0\304\305!\210\306\307!\210\300\301!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\300\315!\210\300\316!..."
>  [require org-macs org-git-version "release_9.5.5-821-g9bd8a9" warn "Org 
> version mismatch.  Make sure that correct `loa..." error "Org version 
> mismatch.  Make sure that correct `loa..." org-compat org-keys ob-eval 
> ob-core ob-comint ob-exp ob-table ob-lob ob-ref ob-tangle provide ob] 2)
>   (load "/home/redknight/git/org-mode/lisp/ob" noerror nil nil mustsuffix)
>   (#f(compiled-function (f) #) "ob")
>   (mapcar #f(compiled-function (f) #) ("ob" "ob-C" 
> "ob-R" "ob-awk" "ob-calc" "ob-comint" "ob-core" "ob-ditaa" "ob-dot" 
> "ob-emacs-lisp" "ob-eshell" "ob-eval" "ob-exp" "ob-fortran" "ob-gnuplot" 
> "ob-latex" "ob-lisp" "ob-lob" "ob-org" "ob-perl" "ob-plantuml" "ob-python" 
> "ob-ref" "ob-ruby" "ob-shell" "ob-sql" "ob-sqlite" "ob-table" "ob-tangle" 
> "obarray" "oc" "oc-basic" "oclosure" "ol" "ol-bbdb" "ol-bibtex" "ol-docview" 
> "ol-eshell" "ol-eww" "ol-gnus" "ol-info" "ol-irc" "ol-mhe" "ol-rmail" 
> "ol-w3m" "org-agenda" "org-capture" "org-collector" "org-compat" "org-crypt" 
> ...))
>   (org-reload nil)
>   (funcall-interactively org-reload nil)
>   (call-interactively org-reload)
>   (popup-menu (keymap "Global Menu" ... ... ... ... ... ... ... "menu-bar" 
> keymap "Org Mode Menu" ... keymap ...) f10)
>   (x-menu-bar-open nil)
>   (menu-bar-open nil 1)
>   (funcall-interactively menu-bar-open nil 1)
>   (call-interactively menu-bar-open nil nil)
>   (command-execute menu-bar-open)
> --8<---cut here---end--->8---
>
>
> I also receive a warning, copied below. I do not use 'packages' but use
> org-mode from a git repository and have done so with no previous issues.
>
> --8<---cut here---start->8---
> ⛔ Warning (emacs): Org version mismatch.  Make sure that correct `load-path' 
> is set early in init.el
> This warning usually appears when a built-in Org version is loaded
> prior to the more recent Org version.
>
> Version mismatch is commonly encountered in the following situations:
> 1. Emacs is loaded using literate Org config and more recent Org
>version is loaded inside the file loaded by `org-babel-load-file'.
>`org-babel-load-file' triggers the built-in Org version clashing
>the newer Org version attempted to be loaded later.
>
>It is recommended to move the Org loading code before the
>`org-babel-load-file' call.
>
> 2. New Org version is loaded manually by setting `load-path', but some
>other package depending on Org is loaded before the `load-path' is
>configured.
>This "other package" is triggering built-in Org version, again
>causing the version mismatch.
>
>It is recommended to set `load-path' as early in the config as
>possible.
>
> 3. New Org version is loaded using straight.el package manager and
>other package depending on Org is loaded before straight triggers
>loading of the newer Org version.
>
>It is recommended to put
> (straight-use-package 'org)
>early in the config.  Ideally, right after the straight.el
>bootstrap.  Moving `use-package' :straight declaration may not be
>sufficient if the corresponding `use-package' statement is
>deferring the loading.
> --8<---cut here---end--->8---
>

I wasn't aware that command even existed. However, I suspect it will
cause issues in your use case. I'm not sure it is a good command to
actually have given the complexities associated with getting a clean org
build.

In many cases, you may not run into issues - especially if you do a git
pull frequently. However, I can see various scenarios which will lead to
inconsistent builds. I suspect the error you are seeing is the result of
recent work to try and identify builds which are likely to result in an
inconsistent 'mixed' version build. Detecting such scenarios is
difficult and relies on a number of heuristics, one of which is to flag
a problem if the loaded version and the target build version don't
match.  

A lot would depend on how you build (re-compile) org mode after doing a
git pull. If you compile it in a separate Emacs instance, you should
have less issues and reloading after the build will likely
work. However, if your trying to build org 

refresh not working for org-mode from git

[Colin Baxter]

Recently, if I use C-c C-x ! to refresh org-mode after a git pull, I get an
error. I then have to close down emacs and launch again. This rather
defeats the object of C-c C-x !. This appears to have happened only recently

The Backtrace is

--8<---cut here---start->8---
Debugger entered--Lisp error: (error "Org version mismatch.  Make sure that 
correct `loa...")
  (signal error ("Org version mismatch.  Make sure that correct `loa..."))
  (error "Org version mismatch.  Make sure that correct `loa...")
  (byte-code "\300\301!\210\302 
\303\232\204\23\0\304\305!\210\306\307!\210\300\301!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\300\315!\210\300\316!..."
 [require org-macs org-git-version "release_9.5.5-821-g9bd8a9" warn "Org 
version mismatch.  Make sure that correct `loa..." error "Org version mismatch. 
 Make sure that correct `loa..." org-compat org-keys ob-eval ob-core ob-comint 
ob-exp ob-table ob-lob ob-ref ob-tangle provide ob] 2)
  (load "/home/redknight/git/org-mode/lisp/ob" noerror nil nil mustsuffix)
  (#f(compiled-function (f) #) "ob")
  (mapcar #f(compiled-function (f) #) ("ob" "ob-C" "ob-R" 
"ob-awk" "ob-calc" "ob-comint" "ob-core" "ob-ditaa" "ob-dot" "ob-emacs-lisp" 
"ob-eshell" "ob-eval" "ob-exp" "ob-fortran" "ob-gnuplot" "ob-latex" "ob-lisp" 
"ob-lob" "ob-org" "ob-perl" "ob-plantuml" "ob-python" "ob-ref" "ob-ruby" 
"ob-shell" "ob-sql" "ob-sqlite" "ob-table" "ob-tangle" "obarray" "oc" 
"oc-basic" "oclosure" "ol" "ol-bbdb" "ol-bibtex" "ol-docview" "ol-eshell" 
"ol-eww" "ol-gnus" "ol-info" "ol-irc" "ol-mhe" "ol-rmail" "ol-w3m" "org-agenda" 
"org-capture" "org-collector" "org-compat" "org-crypt" ...))
  (org-reload nil)
  (funcall-interactively org-reload nil)
  (call-interactively org-reload)
  (popup-menu (keymap "Global Menu" ... ... ... ... ... ... ... "menu-bar" 
keymap "Org Mode Menu" ... keymap ...) f10)
  (x-menu-bar-open nil)
  (menu-bar-open nil 1)
  (funcall-interactively menu-bar-open nil 1)
  (call-interactively menu-bar-open nil nil)
  (command-execute menu-bar-open)
--8<---cut here---end--->8---

I also receive a warning, copied below. I do not use 'packages' but use
org-mode from a git repository and have done so with no previous issues.

--8<---cut here---start->8---
⛔ Warning (emacs): Org version mismatch.  Make sure that correct `load-path' is 
set early in init.el
This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.

Version mismatch is commonly encountered in the following situations:
1. Emacs is loaded using literate Org config and more recent Org
   version is loaded inside the file loaded by `org-babel-load-file'.
   `org-babel-load-file' triggers the built-in Org version clashing
   the newer Org version attempted to be loaded later.

   It is recommended to move the Org loading code before the
   `org-babel-load-file' call.

2. New Org version is loaded manually by setting `load-path', but some
   other package depending on Org is loaded before the `load-path' is
   configured.
   This "other package" is triggering built-in Org version, again
   causing the version mismatch.

   It is recommended to set `load-path' as early in the config as
   possible.

3. New Org version is loaded using straight.el package manager and
   other package depending on Org is loaded before straight triggers
   loading of the newer Org version.

   It is recommended to put
(straight-use-package 'org)
   early in the config.  Ideally, right after the straight.el
   bootstrap.  Moving `use-package' :straight declaration may not be
   sufficient if the corresponding `use-package' statement is
   deferring the loading.
--8<---cut here---end--->8---

Best wishes,

[BUG] Face attribute customization is ignored [9.5.5 (9.5.5-gbe2246 @ ~/.emacs.d/straight/build/org/)]

[David Vicente]

Starting with:
    $ emacs -Q


and evaluating

(require 'org)

(set-face-attribute 'org-block nil :extend nil :background "snow2")
(set-face-attribute 'org-block-begin-line nil :extend nil :background 
"snow2")

(set-face-attribute 'org-block-end-line nil :extend nil :background "snow2")

(org-mode)

If we now write something like:


#+BEGIN_SRC
(+ 1 2)
#+END_SRC

The attribute customization of org-block-begin-line and 
org-block-end-line is ignored, i.e, the :extend attribute gets 
overwritten when we start org-mode and ends up with value t.


After inspecting the source code I suspect that it might have something 
to do with org-fontify-whole-block-delimiter-line...


Thanks

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.33, cairo version 1.17.6)

 of 2022-04-27
Package: Org mode version 9.5.5 (9.5.5-gbe2246 @ 
~/.emacs.d/straight/build/org/)

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[andrés ramírez]

Hi. Eric.
My comments below.

> "Fraga," == Fraga, Eric  writes:

[...]

Fraga,> This would be simply be something along these lines:

--8<---cut here---start->8---
* retiro espiritual {collaborator.family}
  <2022-08-01 Mon 09:00-11:00> 
--8<---cut here---end--->8---

Fraga,> You only need to use diary block entries if you want to block out a 
specific range of
Fraga,> dates but even then it is often easier to use multiple time stamps 
instead.

I see. Thanks for the clarification. Then I think I saw it in the past. But 
when You do it. the agenda
filename appears on the agenda buffer (the agenda filename is large on my case) 
. So I prefer
give to the entry a short category.

This is my use case:
--8<---cut here---start->8---
** PE :DAVID:
:PROPERTIES:
:CATEGORY: da.santi
:END:
%%(diary-block 10 1 2022 10 1 2022) 9:00-11:00 retiro.espiritual 
{collaborator.family}
--8<---cut here---end--->8---

so. the short label 'da.santi' is what appears on my agenda.

Best Regards

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Timothy]

Hi Max,

>> Agreed – I removed this mailto: link as suggestion in a previous
>> reply to Tim…
>
> I am not against mailto: link, my intention was to improve message template.

Looking at , that seems like it’s much
better than just a mailto link or `M-x org-submit-bug-report RET' as it gives 
some
(IMO, rather crucial) surrounding information/instructions.

I think we’d want people to see this, and so I’d actually be inclined to make
the “bug report” button link to this page, and the feedback button just be a
`mailto:' link.

> My impression is that this change is against Timothy’s attempt to make the top
> banner cleaner.

For what it’s worth, I personally consider stuffing lines of “important!” text
into that “what is Org?” banner ultimately counterproductive. I think it fails
to provide the information with enough context (e.g. `M-x org-submit-bug-report
RET' doesn’t provide the information provided on the Feedback.html page), and it
also muddies the structure of the page while making it appear more cluttered.

All the best,
Timothy

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Fraga, Eric]

On Friday, 23 Sep 2022 at 16:14, andrés ramírez wrote:
> %%(diary-block 8 1 2022 8 1 2022) 9:00-11:00 retiro.espiritual 
> {collaborator.family}

This would be simply be something along these lines:

* retiro espiritual {collaborator.family}
  <2022-08-01 Mon 09:00-11:00> 

You only need to use diary block entries if you want to block out a
specific range of dates but even then it is often easier to use multiple
time stamps instead.

-- 
: Eric S Fraga, with org release_9.5.5-815-gae2140 in Emacs 29.0.50

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Max Nikulin]

On 23/09/2022 00:23, Bastien wrote:

Max Nikulin writes:


The updated page has

 alt="Install from ELPA"

that likely should be "Install from GNU ELPA".


Fixed, thanks.


However Firefox does not show tooltips (unlike for the Librepay link)
when mouse cursor is over new SVG images. I have no idea if
screenreaders will use value of the alt attributes.


I added title="" properties.


"Install from ELPA" without "GNU".


I expect that some fraction of messages at this list will have "[BUG]
" subject literally. Perhaps "=..." may be
added with a template like "Org version: ___, Emacs version: ___" with
a note requesting subject more specific to the particular
problem. Some people still will not read it.


Agreed -- I removed this mailto: link as suggestion in a previous
reply to Tim...


I am not against mailto: link, my intention was to improve message template.


An unrelated to the latest changes question. What is the supposed way
to reach https://orgmode.org/manual/Feedback.html from site main page
(to become aware of M-x `org-submit-bug-report'?


... and placed the https://orgmode.org/manual/Feedback.html link as
the target of the "feedback" svg icon.

I also added the M-x org-submit-bug-report RET exlpicitely, as it is
something we want users to discover very soon.


My impression is that this change is against Timothy's attempt to make 
the top banner cleaner. I would consider adding a paragraph with 
org-submit-bug-reports and Feedback.html link close to the "Joining the 
mailing list" section and would make "report bug" badge leading to this 
paragraph. "Feedback" badge link may point to "Joining the mailing list".

Re: [PATCH] Babel evaluation: location and timing information (v2)

[Timothy]

Hi All,

Ihor raised a concern about the time needed to determine element type. This
information is now passed on from other parts of Org, so there’s no overhead
from this any more.

Since this also applies to inline types, I’ve switched to showing the point
position instead of the line number. As a side effect, that renders concerns
about the performance of `line-number-at-pos' moot.

So, I think this set of patches should be good to go. Let me know if you can
spot anything else that looks like it should be tweaked.

All the best,
Timothy
>From 81c5cf82cffd2b01fac39eaaf7a1a6ee58802e25 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sat, 17 Sep 2022 17:53:01 +0800
Subject: [PATCH 3/3] ob-core: Display babel execution time

* lisp/ob-core.el (org-babel-execute-src-block,
org-babel-format-result): Record the babel execution time, and then
supplement the "Code block evaluation complete." (etc.) messages with
the execution time when >0.05s.
---
 lisp/ob-core.el | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index c2f5eccfd..e6802e739 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -791,7 +791,7 @@ (defun org-babel-execute-src-block ( arg info params executor)
 		   (make-directory d 'parents)
 		   d
 		 (cmd (intern (concat "org-babel-execute:" lang)))
-		 result)
+		 result exec-start-time)
 	(unless (fboundp cmd)
 	  (error "No org-babel-execute function for %s!" lang))
 	(message "executing %s %s %s..."
@@ -806,7 +806,8 @@ (defun org-babel-execute-src-block ( arg info params executor)
 		   (if name
(format "(%s)" name)
  (format "at point %d" (nth 5 info)
-	(setq result
+	(setq exec-start-time (current-time)
+  result
 		  (let ((r (funcall cmd body params)))
 		(if (and (eq (cdr (assq :result-type params)) 'value)
 			 (or (member "vector" result-params)
@@ -849,7 +850,8 @@ (defun org-babel-execute-src-block ( arg info params executor)
 	  (if (member "none" result-params)
 		  (message "result silenced")
 	(org-babel-insert-result
-	 result result-params info new-hash lang)))
+	 result result-params info new-hash lang
+ (time-subtract (current-time) exec-start-time
 	(run-hooks 'org-babel-after-execute-hook)
 	result)))
 
@@ -2260,7 +2262,7 @@ (defun org-babel-format-result (result  sep)
   ;; scalar result
   (funcall echo-res result
 
-(defun org-babel-insert-result (result  result-params info hash lang)
+(defun org-babel-insert-result (result  result-params info hash lang exec-time)
   "Insert RESULT into the current buffer.
 
 By default RESULT is inserted after the end of the current source
@@ -2268,7 +2270,8 @@ (defun org-babel-insert-result (result  result-params info hash lang)
 wrapped inside a `results' macro and placed on the same line as
 the inline source block.  The macro is stripped upon export.
 Multiline and non-scalar RESULTS from inline source blocks are
-not allowed.  With optional argument RESULT-PARAMS controls
+not allowed.  When EXEC-TIME is provided it may be included in a
+generated message.  With optional argument RESULT-PARAMS controls
 insertion of results in the Org mode file.  RESULT-PARAMS can
 take the following values:
 
@@ -2573,11 +2576,18 @@ (defun org-babel-insert-result (result  result-params info hash lang)
 			   (not (and (listp result)
  (member "append" result-params
 		  (indent-rigidly beg end indent))
-		(if (null result)
-		(if (member "value" result-params)
-			(message "Code block returned no value.")
-		  (message "Code block produced no output."))
-		  (message "Code block evaluation complete.")))
+(let ((time-info
+   ;; Only show the time when something other than
+   ;; 0s will be shown, i.e. check if the time is at
+   ;; least half of the displayed precision.
+   (if (and exec-time (> (float-time exec-time) 0.05))
+   (format " (took %.1fs)" (float-time exec-time))
+ "")))
+  (if (null result)
+  (if (member "value" result-params)
+  (message "Code block returned no value%s." time-info)
+(message "Code block produced no output%s." time-info))
+(message "Code block evaluation complete%s." time-info
 	(set-marker end nil)
 	(when outside-scope (narrow-to-region visible-beg visible-end))
 	(set-marker visible-beg nil)
-- 
2.37.1

>From 753d441ea9c190055566a53f88dc0d687ee72808 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sat, 17 Sep 2022 17:39:16 +0800
Subject: [PATCH 2/3] ob-core: Display type of element babel executes

* lisp/ob-core.el (org-babel-execute-src-block): The babel execute
function is run 

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Max Nikulin]

On 23/09/2022 10:05, Ihor Radchenko wrote:


I added caching of `org-diary-sexp-entry' results in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4075662c298da7fa7e2ba19e0b8b36c58852cc0f


Sorry for the noise. I am unsure concerning exact effect of the commit, 
 I hope, if agenda is rebuilt after several days since first call, 
actual timestamps are used. Maybe my note makes no sense since I am 
completely ignorant concerning generation of agenda.

line-number-at-pos performance and cache-long-scans

[Max Nikulin]

On 23/09/2022 09:22, Ihor Radchenko wrote:

Max Nikulin writes:


Despite improvements since Emacs-26 in line counting, still I believe
that the `line-number-at-pos' function may still be excessively
expensive in real live when unconditionally used just for a bit nicer
logging.


May I ask if other Org operations are also slow in that problematic file
with many markers? If so, I do not think that we need to worry about
performance of `line-number-at-pos'. Rather we just wait for Emacs to
fix problems with markers. See the discussion in 
https://yhetil.org/emacs-devel/jwvsfntduas.fsf-monnier+em...@gnu.org


Thank you for the link. It would be great if that branch were merged. My 
primary complain concerning line numbers is that there is no way to 
disable the feature.


Ihor, the following is not answer to your question. I am impressed by 
such observation, however it is not latest Emacs version and built-in 
Org that uses overlays, not text properties.


It seems, in the case of `line-number-at-pos' another "optimization" 
causes performance degradation by orders of magnitude, not markers as 
for conversion between byte offset and position in buffers. I have found 
a discussion of a change in Emacs-28 (So it is not clear for me why I 
see performance difference between Emacs-26 and 27, maybe more optimal 
code generated by newer gcc)

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22763
25.1.50; Feature Request -- A faster method to obtain line number at 
position.


I noticed `cache-long-scans' and tried to disable it.

If my document (4Mb, 100k lines) is open as .txt file in Emacs-26
getting line number at the end takes 0.03…0.04 s. If I enable org-mode 
the same operation requires 6s, but after


   (setq cache-long-scans nil)

0.006 s is enough to get the same line number. Enabling the cache again 
causes performance degradation by 3 orders of magnitude. Cache works to 
some extent because first call takes 12 s while following ones "only" 6 s.


I have not tried if disabling newline cache causes problems with other 
operation.

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[andrés ramírez]

Hi. Ihor.

> "Ihor" == Ihor Radchenko  writes:

[...]

Ihor> You appear to have a large number of diary-style timestamps. This is 
not common. Normal
Ihor> timestamps are generally much faster because we can construct a 
matching regexp based on
Ihor> current agenda date instead of checking every single sexp.

I started using the org-agenda several years ago. When I add a new entry which 
is
probably weekly. I just kill the previous line and yank and update the
new one on my agenda files. This is a tipical example of one of my
entries. 

--8<---cut here---start->8---
%%(diary-block 8 1 2022 8 1 2022) 9:00-11:00 retiro.espiritual 
{collaborator.family}
--8<---cut here---end--->8---

Pardon my ignorance. How could You translate it to a normal timestamp?.

Ihor> Having said that, I now have an idea how to avoid the overheads in 
such scenarios. Just
Ihor> pushed the change upstream. Can you check? It should bypass most of 
the slow checks in
Ihor> your use case.

Neat. Now it took 25s. It is really very near to emacs-27
performance. Congrats.

[...]

Ihor> We have a whole dedicated section in the manual: "A.8 Speeding Up 
Your Agendas". Agenda
Ihor> performance is a well-known problem since years back.  The coming 
release (the current
Ihor> main branch) will have major improvements to performance in this 
area, although I have
Ihor> mostly optimized it for timestamp-based agendas and todo agendas 
before your report.

Thanks for the work.

Best Regards

org-beamer improvement?

[Guillaume MULLER]

Hi again,

While writing my previous email, I just thought of another thing. As it is 
unrelated to the other one, I'm creating a second email...

The only thing I miss in org lies in org-beamer: it is the ability to use the 
star '*' in BEARMER_ACT, with something like:
* my block1
:PROPERTIES:
:BEAMER_ACT: *<1>
:BEAMER_ENV: block
:END:
 + my content1
* my block2
:PROPERTIES:
:BEAMER_ACT: *<2>
:BEAMER_ENV: block
:END:
 + my content2
which would make the 2nd block appear "in place" of the 1rst one.
I end up doing things like:
#+LATEX: \onlide*<1>{
* my block1
* @@l:@@
:PROPERTIES:
:BEAMER_ENV: ignoreheading
:END:
 + my content1
#+LATEX: }
#+LATEX: \onlide*<2>{
* my block2
* @@l:@@
:PROPERTIES:
:BEAMER_ENV: ignoreheading
:END:
 + my content2
#+LATEX: }
Its works but it makes my org files look very ugly :{

I know block do not natively accept *<1> notation, but it would be great if org would 
detect the * in BEAMER_ACT directive and translate that into some code similar to the one I 
generate manually (#+LATEX + onslide* + shadow "ignoreheading "closing block).

Any thoughts on this?

--
Guillaume MULLER



OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Opening of links

[Guillaume MULLER]

Hi,

Thanks for org, "the best tool in the world"! ;) (*)

I have a simple org file (Linux / Emacs 27.1 + Doom):

--
#+TITLE: Test pdf links

+ [[file:~/test.pdf][PDF 1]]
--

When I click on the link with mouse1, the document is opened in Calibre. When I 
use mouse3, the document is opened in Emacs. I get a similar behavior with 
org-attached PDF documents: using 'o' will open them in Calibre, 'O' in Emacs.

Such a behavior for mouse1/'o' raises 2 questions:

- My OS settings are configured so that PDFs are opened in Evince. I configured this with "xfce4-settings-manager 
> Default Applications" (which runs "xfce4-mime-settings" under the hood) and it can be verified with 
"xdg-open test.pdf" or by opening Thunar and clicking on "test.pdf".
  So, where in the world does org-mode/Emacs finds that it should use Calibre 
instead of Evince?

- Now, I would like to circumvent this global OS behavior, so that Emacs itself 
would be used specifically to open PDF links in files I open in Emacs. When I 
was using Vanilla Emacs, I was advised to use pdf-tools, and given a config 
that was working. I translated that into my DoomEmacs config.org as follows:
  (use-package! pdf-tools
:magic ("%PDF" . pdf-view-mode)
:config
  (pdf-tools-install :no-query)
)
  But apparently it does not override org's (default) behavior of opening PDF 
file with external tools.
  Is there

Sorry for these (probably very) basic questions, but I could not find anything 
relevant on the web (or I haven't found the correct keywords...). I would be 
very grateful of any help!

Have a nice Week end

--
Guillaume MULLER



OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: svg file from tikz picture

[Akira Kyle]

I've been using the attached patch for the last few years and I've meaning to 
send it here/start a discussion about ob-latex.el since I used it pretty much 
daily to write tikz figures in org mode. So I'm glad to see this discussion has 
been started!

I've found it to be incredibly productive to use babel to develop tikz diagrams 
as I can make come changes and quickly `org-ctrl-c-ctrl-c` to render them in 
the same buffer.

I think when I made this patch I had been caught by some of the quirks of the 
svg export. For example, sometimes I would have some latex equation which I use 
~org-latex-preview~ on as I was writing it, but then it would fail to render as 
mathjax upon html export since I would use some latex package that isn't 
available under mathjax. So by using ob-latex I could easily fix this by using 
the ~:file .svg~ header and get a nice html export. However due to the 
different way of assembling the ~.tex~ file sometimes ~org-latex-preview~ would 
work but ob-latex wouldn't. I think my use case may be fairly common and so I 
think ob-latex really should be updated so svg uses the ~org-latex-preview~ 
code. o

Also I think the ~.tikz~ extension doesn't really make any sense since one 
really can but arbitrary tex code in such a block, and I think that's why I 
renamed it in my patch. However I'm now realizing that this evaluation method 
probably doesn't make much since `:tangle` will already do this, with the added 
benefit of handling noweb references correctly. So perhaps this should be 
removed and document using tangling in lieu of ~:file *.tikz~?

PS: I'm not currently subbed to this mailing list, so please try to cc me

>From 5d94745dfbe0858d4fd7d6530b821445b06d5013 Mon Sep 17 00:00:00 2001
From: Akira Kyle 
Date: Tue, 4 Jan 2022 14:33:05 -0700
Subject: [PATCH] ob-latex: Create svg images the same way as png images

Also some cleanup of generation .html and .pdf files
---
 lisp/ob-latex.el | 161 +++
 1 file changed, 50 insertions(+), 111 deletions(-)

diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index a86699e22..71b01058c 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -39,7 +39,7 @@
 
 (declare-function org-create-formula-image "org" (string tofile options buffer  type))
 (declare-function org-latex-compile "ox-latex" (texfile  snippet))
-(declare-function org-latex-guess-inputenc "ox-latex" (header))
+(declare-function org-latex-make-preamble "ox-latex" (info  template snippet?))
 (declare-function org-splice-latex-header "org" (tpl def-pkg pkg snippets-p  extra))
 (declare-function org-at-heading-p "org" ( _))
 (declare-function org-back-to-heading "org" ( invisible-ok))
@@ -115,12 +115,6 @@ exporting the literal LaTeX source."
   :group 'org-babel
   :type 'string)
 
-(defcustom org-babel-latex-htlatex-packages
-  '("[usenames]{color}" "{tikz}" "{color}" "{listings}" "{amsmath}")
-  "Packages to use for htlatex export."
-  :group 'org-babel
-  :type '(repeat (string)))
-
 (defun org-babel-expand-body:latex (body params)
   "Expand BODY according to PARAMS, return the expanded body."
   (mapc (lambda (pair) ;; replace variables
@@ -142,132 +136,82 @@ This function is called by `org-babel-execute-src-block'."
 	 (extension (file-name-extension out-file))
 	 (tex-file (org-babel-temp-file "latex-" ".tex"))
 	 (border (cdr (assq :border params)))
-	 (imagemagick (cdr (assq :imagemagick params)))
-	 (im-in-options (cdr (assq :iminoptions params)))
-	 (im-out-options (cdr (assq :imoutoptions params)))
 	 (fit (or (cdr (assq :fit params)) border))
 	 (height (and fit (cdr (assq :pdfheight params
 	 (width (and fit (cdr (assq :pdfwidth params
 	 (headers (cdr (assq :headers params)))
 	 (in-buffer (not (string= "no" (cdr (assq :buffer params)
+	 (imagemagick (cdr (assq :imagemagick params)))
+	 (im-in-options (cdr (assq :iminoptions params)))
+	 (im-out-options (cdr (assq :imoutoptions params)))
 	 (org-latex-packages-alist
-	  (append (cdr (assq :packages params)) org-latex-packages-alist)))
+	  (append (cdr (assq :packages params)) org-latex-packages-alist))
+	 (org-format-latex-header
+	  (concat org-format-latex-header
+		  (mapconcat #'identity (cdr (assq :headers params)) "\n")
+		  (if fit "\n\\usepackage[active, tightpage]{preview}\n" "")
+		  (if border
+			  (format "\\setlength{\\PreviewBorder}{%s}" border) "")
+		  (if height
+			  (concat "\n" (format "\\pdfpageheight %s" height)) "")
+		  (if width
+			  (concat "\n" (format "\\pdfpagewidth %s" width)) "")))
+	 (body (if fit 
+		   (concat "\n\\begin{preview}\n" body "\n\\end{preview}\n")
+		 body)))
 (cond
  ((and (string-suffix-p ".png" out-file) (not imagemagick))
   (let ((org-format-latex-header
 		 (concat org-format-latex-header "\n"
 			 (mapconcat #'identity headers "\n"
-	(org-create-formula-image
-  

Suggestion: add org-latex-preview to org-ctrl-c-ctrl-c

[Akira Kyle]

I recently thought to add ~org-latex-preview~ to 
~org-ctrl-c-ctrl-c~ and it has been quite the productivity 
booster! Two arguments as to why this should be done:
- ~org-ctrl-c-ctrl-c~ currently does nothing when inside 
 latex-fragment or latex-environment so why not make it 
 ~org-latex-preview~?
- This intuitively matches my muscle memory from using 
 babel. LaTeX is code after all, and I'm often making mistakes, 
 so I want the fastest "edit-compile-edit" loop possible.


Here's what I currently have to achieve this in case anyone wants 
to give it a try right now :)


#+begin_src emacs-lisp
(defun my-org-ctrl-c-ctrl-c-latex-preview-hook ()
 (let ((element (car (org-element-context
   (if (or (eq element 'latex-fragment) (eq element 
   'latex-environment))

   (org-latex-preview

(add-hook 'org-ctrl-c-ctrl-c-final-hook
 'my-org-ctrl-c-ctrl-c-latex-preview-hook)
#+end_src

Re: Do not show a TODO item in the global TODO list until certain date?

[Angel de Vicente]

Hello,

Bastien  writes:

>> As per the example I was giving, I don't want that entry to be scheduled
>> for October 16 (and thus clutter my agenda view), I just want it to be
>> visible in my Global TODO list from that date, so then, depending on how
>> busy I'm around that date, then I can decide when to schedule it for.
>
> Another option is to define an agenda view that only shows TODO items
> for today, with `org-agenda-span' set to 1 --- something like this:

thanks. I tried, but that doesn't seem to be what I was looking for (or
perhaps I missed something). In my case I have many TODO items without a
date, and I don't want to assign a specific date to them. I simply want
that they are hidden from the Global TODO list until a specific date.

[I can assign a date to them, but then it will look like I have to do
them on that date. Ideally I would like them to be without a date, so
they don't show up in the agenda, only in the global TODO list, but have
a field =skip_until= or similar, so they will be hidden until then]

Thanks,
-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Tel.: +34 922-605-747
 Web.: http://research.iac.es/proyecto/polmag/
-
AVISO LEGAL: Este mensaje puede contener información confidencial y/o 
privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido 
por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no 
autorizadas del contenido de este mensaje está estrictamente prohibida. Más 
información en: https://www.iac.es/es/responsabilidad-legal
DISCLAIMER: This message may contain confidential and / or privileged 
information. If you are not the final recipient or have received it in error, 
please notify the sender immediately. Any unauthorized use of the content of 
this message is strictly prohibited. More information:  
https://www.iac.es/en/disclaimer

[BUG] Face attribute customization is ignored [9.5.5 (9.5.5-gbe2246 @ /home/dav/.emacs.d/straight/build/org/)]

[David Vicente]

Starting with:
$ emacs -Q


and evaluating

(require 'org)

(set-face-attribute 'org-block nil :extend nil :background "snow2")
(set-face-attribute 'org-block-begin-line nil :extend nil :background 
"snow2")

(set-face-attribute 'org-block-end-line nil :extend nil :background "snow2")

(org-mode)

If we now write something like:


#+BEGIN_SRC
(+ 1 2)
#+END_SRC

The attribute customization of org-block-begin-line and 
org-block-end-line is ignored, i.e, the :extend attribute gets 
overwritten when we start org-mode and ends up with value t.


After inspecting the source code I suspect that it might have something 
to do with org-fontify-whole-block-delimiter-line...


Thanks

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.33, cairo version 1.17.6)

 of 2022-04-27
Package: Org mode version 9.5.5 (9.5.5-gbe2246 @ 
/home/dav/.emacs.d/straight/build/org/)

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> Ihor> Can you update and try the profiling again?
>
> Done.

Thanks! I can now see that matching sexp entries is properly cached.

> Ihor> (If this last change works, I am out of ideas about easy ways to 
> improve performance
> Ihor> further. The only one is a significant change in 
> org-element-at-point internals, but it
> Ihor> will need to be tested carefully, and I do not plan to upstream it 
> before the next Org
> Ihor> release).
>
> Do not worry. You have done more than enough. I have notice this delay
> from a long time. But nobody else reported it, which is weird. I am
> going to wait until emacs-29, for those changes.

You appear to have a large number of diary-style timestamps. This is not
common. Normal timestamps are generally much faster because we can
construct a matching regexp based on current agenda date instead of
checking every single sexp.

Having said that, I now have an idea how to avoid the overheads in such
scenarios. Just pushed the change upstream. Can you check? It should
bypass most of the slow checks in your use case.

> Is there any workaround or recomendacion for the emacs-28 users with the
> built-in org mode?.
>
> Or that should be mentioned on PROBLEMS?

We have a whole dedicated section in the manual: "A.8 Speeding Up Your
Agendas". Agenda performance is a well-known problem since years back.
The coming release (the current main branch) will have major
improvements to performance in this area, although I have mostly
optimized it for timestamp-based agendas and todo agendas before your
report.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [O] Plantuml w/ noweb and cached results

[Ken Mankoff]

Hi Ihor,

Thank you for your reply. I apologize for not doing a more thorough test with 
'-Q'. I'll try to find the problem in my setup.

  -k.

On 2022-09-22 at 22:02 -04, Ihor Radchenko  wrote:
> Ken Mankoff  writes:
>
>> #+BEGIN_SRC plantuml :noweb yes :file cache-yes.png
>> @startjson
>> <>
>> @endjson
>> #+END_SRC
>>
>> #+RESULTS:
>> [[file:cache-yes.png]]
>>
>> The above graphic is an error message. It states,
>>
>> "Your data does not sound like JSON data".
>
> I tried your example it is working just fine on my side.
> I suggest you to try reproducing starting from Emacs -Q.
> See https://orgmode.org/manual/Feedback.html. You may also find
> https://github.com/alphapapa/with-emacs.sh useful to install packages
> into a temporary clean Emacs instance.

[BUG] Width property in columnview dynamic blocks [9.5.5]

[Ypo]

In columnview dynamic blocks, the Width property doesn't seem to work

In this example the first column width is the same if I write ~%5ITEM~
than ~%ITEM~

* PROYECTO EMACS
:PROPERTIES:
:COLUMNS:  %5ITEM(PROJECT)
:END:

#+BEGIN: columnview
#+END:




Emacs  : GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13
Package: Org mode version 9.5.5 (release_9.5.5 @ 
z:/emacs-i686/share/emacs/28.2/lisp/org/)


current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-export-before-parsing-hook '(org-attach-expand-links)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-hide-drawers org-cycle-show-empty-lines 
org-optimize-window-after-visibility-change)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-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-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-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) ("id" :follow org-id-open) ("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) ("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) ("file+sys") 
("file+emacs") ("shell" :follow org-link--open-shell) ("news" :follow 
#[514 "\301\300\302%4Q%2\"\207" ["news" browse-url ":"] 6 "\n\n(fn URL 
ARG)"])
       ("mailto" :follow #[514 "\301\300\302%4Q%2\"\207" 
["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]) ("https" :follow #[514 
"\301\300\302%4Q%2\"\207" ["https" browse-url ":"] 6 "\n\n(fn URL 
ARG)"]) ("http" :follow #[514 "\301\300\302%4Q%2\"\207" ["http" 
browse-url ":"] 6 "\n\n(fn URL ARG)"])
       ("ftp" :follow #[514 "\301\300\302%4Q%2\"\207" ["ftp" 
browse-url ":"] 6 "\n\n(fn URL ARG)"]) ("help" :follow 
org-link--open-help :store org-link--store-help) ("file" :complete 
org-link-complete-file) ("elisp" :follow org-link--open-elisp))

 org-metaup-hook '(org-babel-load-in-session-maybe)
 )

Re: [FR] Display heading alongside id in org-insert-link completion

[Max Nikulin]

On 22/09/2022 23:49, Max Nikulin wrote:

On 22/09/2022 21:20, Sterling Hooten wrote:


When trying to insert a stored 'id' link with org-insert-link the
candidates are just the 'id' numbers themselves. This doesn't help
when trying to determine what the 'id' actually points to. Is there a
way for org-insert-link to display headings or other information
(maybe the tags or other heading properties) wih a completion
framework like Ivy?


I have tried release version ("bugfix" branch) and the "main" branch. In 
both cases `org-store-link' saves heading description and it is 
displayed in the stored link list. In the development ("main") branch 
completion by link description for `org-insert-link' was recently fixed.


Sterling, you sent response off list.

I have tried release_9.5.2-434-gbebf0b, but I still can not reproduce 
your issue.


emacs -Q -L ~/src/org-mode/lisp/ test.org
M-: to evaluate
(require 'org-id)
(setq org-id-link-to-org-use-id t)
M-x org-store-link
C-c C-l (org-insert-link) creates a buffer with the heading title and 
id: link


Do you use some 3rd party package like org-roam? `org-store-link' should 
call `org-id-store-link' that sets description of the stored link.


Do you mean some Emacs completion issue that is used by ivy but not 
implemented in Org?

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[andrés ramírez]

Hi. Ihor.

> "Ihor" == Ihor Radchenko  writes:


[...]

Ihor> Now, I see what went wrong.  Just pushed a patch that should reduce 
the time taken by
Ihor> `org-diary-sexp-entry' during rebuild.

Thanks.

Ihor> Can you update and try the profiling again?

Done.
<>

Ihor> (If this last change works, I am out of ideas about easy ways to 
improve performance
Ihor> further. The only one is a significant change in org-element-at-point 
internals, but it
Ihor> will need to be tested carefully, and I do not plan to upstream it 
before the next Org
Ihor> release).

Do not worry. You have done more than enough. I have notice this delay
from a long time. But nobody else reported it, which is weird. I am
going to wait until emacs-29, for those changes.

Is there any workaround or recomendacion for the emacs-28 users with the
built-in org mode?.

Or that should be mentioned on PROBLEMS?

Best Regards

Re: IM dev discussions?

[Ihor Radchenko]

Bastien  writes:

>> Sure. It is always nice to have historical records on why certain
>> decisions have been made.
>
> It is not just to be able to keep track of discussions that led to
> decisions: it is also to be able to be as *inclusive* as possible.
>
> Of course, time and skills (and other psychological traits) are the
> main parameters deciding whether someone can participate to these
> discussions: but the more they take place on the mailing list, the
> more inclusive they are IMHO.
>
> (I know this opinion is debatable: most <30yo (<35yo) hackers out
> there will say that relying on a mailing list for such discussions
> wards them off, insisting we should go on GitHub... but *anyone* can
> send an email to a list, while only registered GitHub users can open
> an issue. We certainly don't want to encourage anyone to register on
> GitHub.)

I do agree that email is the most accessible option from technical
perspective.

However, something being accessible _technically_ does not mean that it
is accessible psychologically. People used to GitHub workflows will be
(and are) reluctant to use email. Not because they can't, but simply
because it requires stepping aside the developed habits (yes, it is how
GitHub and other social platforms catch us [1]).

Familiarity is important. It does not matter if the discussion is done
via mailing list or any other means under the hood. People just want
familiar navigation and front-end logic. Ideally, it would be nice to
have ML front-end that looks similar to GitHub issues. I recall the
latest versions of mailman had somewhat familiar look. Sourcehut is also
trying to implement a web-based front-end (though is it not familiar at
all, unfortunately).

Note that the opposite to the above is not true. We should not prefer
familiar front-ends at the cost of sacrificing technical accessibility.

[1] https://www.goodreads.com/book/show/40672036-digital-minimalism

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: You can now support Org-mode through https://liberapay.com/org-mode/

[Sébastien Rey-Coyrehourcq]

Done !

Thanks for all your work !

Le 21/09/2022 à 08:34, Bastien a écrit :

Thanks for all you do – donation forthcoming!

Re: IM dev discussions?

[Bastien]

Thanks for your answers.

Ihor Radchenko  writes:

>> In general, Org contributors with push access can fix bugs directly,
>> without announcing this on the mailing list.  But *all other changes*
>> should be submitted and discussed on this mailing list.
>
> Sure. It is always nice to have historical records on why certain
> decisions have been made.

It is not just to be able to keep track of discussions that led to
decisions: it is also to be able to be as *inclusive* as possible.

Of course, time and skills (and other psychological traits) are the
main parameters deciding whether someone can participate to these
discussions: but the more they take place on the mailing list, the
more inclusive they are IMHO.

(I know this opinion is debatable: most <30yo (<35yo) hackers out
there will say that relying on a mailing list for such discussions
wards them off, insisting we should go on GitHub... but *anyone* can
send an email to a list, while only registered GitHub users can open
an issue. We certainly don't want to encourage anyone to register on
GitHub.)

-- 
 Bastien

Re: Matrix (was Re: IM dev discussions?)

[Bastien]

Tim Cross  writes:

> One thing I do find frustrating these days is the fracturing of
> communications across so many different solutions.

+100.  

I believe this is real plague for the Free Software movement.

Many projects use Slack, Discord, other unfair services or private IM
applications for "collaboration", while pretending to be inclusive by
just throwing a code of conduct.

I cannot predict the future but I sure hope mailing lists and IRC will
keep being functional for another 50 years (for emails) and 35 years
(for IRC).

I'm glad we have https://list.orgmode.org (thanks to Eric Wong's
https://public-inbox.org/README.html and Kyle's servers) and that
people at SourceHut are putting efforts in making IRC more usable:

https://sourcehut.org/blog/2021-11-29-announcing-the-chat.sr.ht-public-beta/

-- 
 Bastien

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Bastien]

Ihor Radchenko  writes:

> Bastien  writes:
>
>> Would it be okay to
>>
>> 1. replace both "report bug" and "feedback" buttons by a "feedback"
>>button, pointing to manual https://orgmode.org/manual/Feedback.html ?
>
> I feel like it is good idea to keep both "report bug" and "feedback"
> buttons, even if they point to the same link. 

Done.

I'd also argue that a button with a link to
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/ would be good.

Timothy, what do you think?

Would you be able to provide a svg associated with the idea of "source
code" (or browsing the source code)?

-- 
 Bastien

Re: [BUG] orgmode.org translations are not consistent; multi-language export [9.5.4 (release_9.5.4-834-g6a5f67 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> I noticed that https://orgmode.org/, https://orgmode.org/fr/index.html,
> and https://orgmode.org/ja/index.html are not consistent.

FWIW, I think we should get rid of these translations altogether.

Hopefully Org is well-known enough now that people know how to install
it in various countries.

I'd rather direct the community energy on translating the quickstart
page (https://orgmode.org/quickstart.html). 

I will try to translate this quickstart guide into French as a start.

2 cts,

-- 
 Bastien

Re: bug#45915: 28.2; delete-char deletes two letters

[Eli Zaretskii]

> Date: Fri, 23 Sep 2022 06:36:58 +0900 (JST)
> Cc: yanta...@gmail.com, homeros.mis...@gmail.com, 45...@debbugs.gnu.org,
>  emacs-orgmode@gnu.org, t...@misasa.okayama-u.ac.jp
> From: Tak Kunihiro 
> 
> >>> One other possibility is to use a slightly different :relative-width
> >>> factor for the two spaces in a table cell: one with the value of 1,
> >>> the other with 1.001 (say).  They will be indistinguishable on
> >>> display, but since the values are not equal, both stretch gfyphs will
> >>> be displayed, not just one.
> >> 
> >> This is a good idea. I used it to fix the reported issue.
> >> 
> >> Fixed on main.
> > 
> > Great.  So I guess this bug report can be closed?
> 
> Nice. Yes, please close this bug report.

Thanks, done.