Re: Advice for new feature 'image block` for new `sketch-mode` package

[dalanicolai]

Also, I already looked at the org source to see how to add e.g. a
#+BEGIN_IMAGE block,
but I found the 'api' quite overwhelming. So I am hoping that some
experienced developer
could maybe give some advice/explain (for) how to approach/implement this.

On Mon, 20 Sept 2021 at 20:19, dalanicolai  wrote:

> Hello,
>
> I am developing a new package for quickly sketching svg images, (see, and
> try
> out, sketch-mode at https://elpa.gnu.org/devel/). With the package, I can
> already quickly create a sketch and subsequently quickly save it and
> insert a
> link in some org-mode buffer (using the `b` transient suffix). Also I can
> quickly insert some image (using the `I` suffix), but then unfortunately
> the
> image will not get saved.
>
> As svg is just xml, for small sketches I would prefer to insert directly
> the xml
> into the org-buffer within an image block, in which I can quickly toggle
> showing
> the image using `C-c C-c` (or `org-toggle-inline-images`). Also, exporting
> such
> xml should work perfectly fine when exporting to e.g. html.
>
> I guess a normal source block is not suitable, because I would like to
> create
> the image overlay directly within the block. I am happy to (help)
> implement(ing)
> such a feature, but I thought it would be wise to first discuss and
> 'enquire'
> for suggestions here.
>
> Thanks you!
>

Advice for new feature 'image block` for new `sketch-mode` package

[dalanicolai]

Hello,

I am developing a new package for quickly sketching svg images, (see, and
try
out, sketch-mode at https://elpa.gnu.org/devel/). With the package, I can
already quickly create a sketch and subsequently quickly save it and insert
a
link in some org-mode buffer (using the `b` transient suffix). Also I can
quickly insert some image (using the `I` suffix), but then unfortunately the
image will not get saved.

As svg is just xml, for small sketches I would prefer to insert directly
the xml
into the org-buffer within an image block, in which I can quickly toggle
showing
the image using `C-c C-c` (or `org-toggle-inline-images`). Also, exporting
such
xml should work perfectly fine when exporting to e.g. html.

I guess a normal source block is not suitable, because I would like to
create
the image overlay directly within the block. I am happy to (help)
implement(ing)
such a feature, but I thought it would be wise to first discuss and
'enquire'
for suggestions here.

Thanks you!

Re: Emacs-orgmode Digest, Vol 187, Issue 19

[Max Nikulin]

On 20/09/2021 00:16, Ypo wrote:


Then I think I will behave like grown people and use LaTeX syntax, previewing 
it on HTML exports, cause it gives no errors compared to the problematic PDF 
exports.


I never considered HTML as a viable preview option for LaTeX equation, 
so thanks for the idea. In the past working LaTeX was anyway required 
since otherwise latex2html perl script could not generate images for 
equations. Web changed since that times (some sites created by people 
unaware of LaTeX even required activeX to display math).


Maybe your problem with PDF export is not so serious, e.g. pdflatex 
binary is not in PATH or some LaTeX package is missed. Have you tried to 
export to LaTeX file and to run pdflatex from command line to get error 
messages?

Re: Internal link broken when publishing (was org-id with ox-html)

[chris]

On Monday, 20 September 2021 16:13:24 CEST Max Nikulin wrote:
> On 20/09/2021 07:05, chris wrote:
> > On Tuesday, 14 September 2021 18:33:43 CEST Max Nikulin wrote:
> >> As a kind of summary:
> >> 
> >> During publishing of a project
> >> - "id:" links to headings from the same file are exported as short
> >> generated anchors like #org032777e or as anchors to custom ids when the
> >> latter are available
> >> - "Search heading" links to other files are exported as short generated
> >> anchors or as custom ids.
> >> - "id:" links to headings in external files are exported as ID value
> >> with "ID-" prefix. These links are *broken* currently.
> > 
> > Thanks a lot.
> > Perfectly functional org-id links between two files are broken when
> > published to HTML.
> > I suppose a bug should be opened about that?
> > (I can do that in a few weeks.)
> 
> It is already tracked on https://updates.orgmode.org/ as
> "Inconsistent handling of id: links to other file during publish"

How awesome!

Re: [PATCH] ox.el: add smart quotes for Greek

[Max Nikulin]

On 19/09/2021 23:30, Juan Manuel Macías wrote:


I attach here a tiny patch to add Greek smart quotes. Finally, I apply
the second level quotation marks that Protesilaos Stavrou proposed in this
previous thread:
https://orgmode.org/list/87o89yv1mz@cnu407c2zx.nsn-intra.net/#r


Since the choice of secondary opening quote character was uncertain at 
first, I suppose, it would be nice to have this decision documented 
somewhere in Org source repository for the case that it might be 
revisited later. (Disclaimer: unsure that Org developers have the same 
opinion.)


I mean the citation and the reference to the paper by Yannis Haralambous 
to make clear that such variant was considered, the title of EU 
recommendations since nobody has provided more authoritative reference 
of Greek typography traditions.


Possible options:
- Add the note directly to the .el file. I am afraid, as inline comment 
it could be considered too long.
- To a file in the "doc" directory dedicated to such decisions (there is 
no such file yet however) with a reference from the .el file.
- Commit message. It is acceptable but not apparent for a person who 
reads the code that git log may provide detailed explanation of 
particular choice.


Mail archives are not permanent, e.g. web interface to Gmane was shut 
down due to some problems, the same might happen with public inbox 
mirrors. That is why, I think, a more detailed note should be added to 
Org sources.


By the way, Common Locale Data Repository https://cldr.unicode.org/
defines U+201C () and U+201D () characters as well

ag quotation common/main/el*
common/main/el.xml
1224:   «
1225:   »
1226:   “
1227:   ”

Unfortunately this part of Unicode databases is not available form Emacs.

Re: [PATCH] org-cite: Use citeproc-el to create CSL processor itemgetters

[András Simonyi]

Hi Timothy,

> Regarding the content of this patch and the few you have planned that follow —
> would it be fair to say that overall you’re trying to update `oc-csl' based on
> changes you’ve made to `citeproc-el' since `oc-csl' was written?

yes exactly, basically all of my patches are directed towards keeping
oc-csl in sync with the changes/improvements in citeproc-el.
bes wishes,
András

Re: Internal link broken when publishing (was org-id with ox-html)

[Max Nikulin]

On 20/09/2021 07:05, chris wrote:

On Tuesday, 14 September 2021 18:33:43 CEST Max Nikulin wrote:

As a kind of summary:

During publishing of a project
- "id:" links to headings from the same file are exported as short
generated anchors like #org032777e or as anchors to custom ids when the
latter are available
- "Search heading" links to other files are exported as short generated
anchors or as custom ids.
- "id:" links to headings in external files are exported as ID value
with "ID-" prefix. These links are *broken* currently.


Thanks a lot.
Perfectly functional org-id links between two files are broken when published
to HTML.
I suppose a bug should be opened about that?
(I can do that in a few weeks.)


It is already tracked on https://updates.orgmode.org/ as
"Inconsistent handling of id: links to other file during publish"

Re: [PATCH] org-cite: Use citeproc-el to create CSL processor itemgetters

[Timothy]

Hi  András,

Great to see this patch from you .

> this is the first item in a series of oc-csl patches which I’ve
> accumulated and am planning to send this week. (My first attempt to
> send a patch, so please be patient and forgiving :-) )

This may be your first attempt sending a patch, but it all looks good to me.
Simply attaching a `.patch' file is all that’s needed, and you seem to be
following our commit message guidelines, which is good to see.

Regarding the content of this patch and the few you have planned that follow —
would it be fair to say that overall you’re trying to update `oc-csl' based on
changes you’ve made to `citeproc-el' since `oc-csl' was written?

All the best,
Timothy

[PATCH] org-cite: Use citeproc-el to create CSL processor itemgetters

[András Simonyi]

Dear All,

this is the first item in a series of oc-csl patches which I've
accumulated and am planning to send this week. (My first attempt to
send a patch, so please be patient and forgiving :-) )

This particular change removes the itemgetter constructor function
defined in oc-csl.el and uses the one now provided by citeproc-el
which has the same functionality but also supports org-bibtex
bibliographies. In addition to being a bit more featureful this change
also avoids unnecessary code duplication.

best wishes,
András
From 7cc7047516970d9e7da32e23bb11b35c8dbfae6e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Mon, 20 Sep 2021 12:41:20 +0200
Subject: [PATCH] oc-csl: Use citeproc-el to create CSL processor
 itemgetters

* lisp/oc-csl.el (org-cite-csl--processor): Citeproc-el now provides an
itemgetter constructor with all the required functionality and some more, so we
use it to create the itemgetter instead of `org-cite-csl--itemgetter' to avoid
code duplication and make use of the additional features, in particular the
ability to access bibliographies in `org-bibtex' format
(see ).
(org-cite-csl--itemgetter): Is removed since it is no longer used.
---
 lisp/oc-csl.el | 31 ++-
 1 file changed, 2 insertions(+), 29 deletions(-)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index b5074dcf1..645b1c0f9 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -99,6 +99,7 @@
 (declare-function citeproc-append-citations "ext:citeproc")
 (declare-function citeproc-render-citations "ext:citeproc")
 (declare-function citeproc-render-bib "ext:citeproc")
+(declare-function citeproc-hash-itemgetter-from-any "ext:citeproc")
 
 (declare-function org-element-interpret-data "org-element" (data))
 (declare-function org-element-map "org-element" (data types fun  info first-match no-recursion with-affiliated))
@@ -336,34 +337,6 @@ or raise an error if the variable is unset."
 (other
  (user-error "Cannot handle relative style file name" other
 
-(defun org-cite-csl--itemgetter (bibliography)
-  "Return Citeproc's \"itemgetter\" function for BIBLIOGRAPHY files.
-The function handles \".bib\", \".bibtex\" and \".json\" files."
-  (let ((cache (make-hash-table :test #'equal)))
-(dolist (file bibliography)
-  (pcase (file-name-extension file)
-("json"
- (let ((json-array-type 'list)
-   (json-key-type 'symbol))
-   (dolist (item (json-read-file file))
- (puthash (cdr (assq 'id item)) item cache
-((and (or "bib" "bibtex") ext)
- (with-temp-buffer
-	   (insert-file-contents file)
-	   (goto-char (point-min))
-	   (bibtex-set-dialect (if (string= ext "bib") 'biblatex 'BibTeX) t)
-	   (bibtex-map-entries
-	(lambda (key  _)
-  (puthash key
-   (citeproc-bt-entry-to-csl (bibtex-parse-entry))
-   cache)
-(ext
- (user-error "Unknown bibliography extension: %S" ext
-(lambda (itemids)
-  (mapcar (lambda (id)
-(cons id (gethash id cache)))
-  itemids
-
 (defun org-cite-csl--locale-getter ()
   "Return a locale getter.
 The getter looks for locales in `org-cite-csl-locales-dir' directory.  If it
@@ -391,7 +364,7 @@ property in INFO."
  (processor
   (citeproc-create
(org-cite-csl--style-file info)
-   (org-cite-csl--itemgetter bibliography)
+   (citeproc-hash-itemgetter-from-any bibliography)
(org-cite-csl--locale-getter)
locale)))
 (plist-put info :cite-citeproc-processor processor)
-- 
2.25.1

Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.con

[Mohsin Kaleem]

Sébastien Miquel  writes:

> Are you using native compilation ? I think this must be the cause, 
> though no one

Yes I was on the native compile branch and now on mainline emacs with
native-compile enabled.

-- 
Mohsin

Re: Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Bump

Am 08.09.2021 um 15:37 schrieb Denis Maier:

Hi,

I think the suffix parsing in oc-biblatex could be improved. Consider 
this example:



#+cite_export: biblatex authoryear

[cite:@doe 4]

[cite:@doe 4, with some more text]
=

This gives us
=
\autocite[4]{doe}

\autocite[4, with some more text]{doe}
=

The problem is  that biblatex will add a label if the suffix consists 
only of a number, a range of numbers, or a list of numbers. So 
\autocite[4]{doe} will result (Doe 2021, p. 4). However, \autocite[4, 
with some more text]{doe} results in (Doe 2021, 4, with some more text). 
In this special case you'd have to help biblatex:

\autocite[\pnfmt{4}, with some more text]{doe}
=> (Doe 2021, p. 4, with some more text)

FWIW, pandoc's citeproc already has some support for this. There you can 
use braces to specify a locator in a complex suffix. Like so:

[cite:@doe {4}, with some more text]

I don't know how complex that is, but that would be a great addition.

Denis

Re: Spurious spaces with oc-biblatex

[Denis Maier]

Bump.


Am 08.09.2021 um 16:36 schrieb Denis Maier:

Update 2:
This also happens with
#+cite_export: csl

Maybe this is useful for tracking this down.

Denis


Am 08.09.2021 um 16:30 schrieb Denis Maier:

Ok, it looks like this also happens with:

.[cite:@doe]
=> . \autocite{doe}

Is that on purpose?

Denis

Am 08.09.2021 um 15:25 schrieb Denis Maier:

Hi,
Elias and I have run into an potential bug in oc-biblatex:

==
#+cite_export: biblatex authoryear

[cite:@doe] => ok

([cite:@doe]) => this generates a space between the opening 
parentheses and the citation.

==

Result:


\autocite{doe}

( \autocite{doe}) => this generates a space between the opening 
parentheses and the citation.

=

Best,
Denis

Re: Switching to new Git repositories

[Eric S Fraga]

Bastien,

thank you.  My bad: I tried to simply change the url in the .git/config
but hadn't realised that the branch information etc. was
different.  I've cloned anew and everything is fine.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-637-gd70f28
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Switching to new Git repositories

[Marco Wahl]

Thanks you both!

Thanks to you I use a suitable reference to the repo now!  My first
tiny commit landed in the new repo AFAICS.

Note that I had wrongly filled out the form for the ssh-key on the
savannah platform.  Clearly this is my fault.  BTW the documentation is
all there on the savannah page (or linked.)

Eli and friends added me to the system a while ago--professional as
always.

Further I'll also try to have a look at the CONTRIBUTE file after it
will have been updated.  Of course!


Thanks again and have a nice day!

Re: Switching to new Git repositories

[Bastien]

Hi Éric,

Eric S Fraga  writes:

> On Monday, 20 Sep 2021 at 11:27, Bastien wrote:
>> You need to create an account on https://savannah.gnu.org and have
>> your username there being accepted in the Emacs group:
>
> What about those of us that do not wish to have write access but do want
> to simply track the development?

You can clone the repo from here:

~$ git clone https://git.savannah.gnu.org/git/emacs/org-mode.git

And subscribe to this RSS feed:

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/atom/?h=main

HTH,

-- 
 Bastien

Re: Switching to new Git repositories

[Eric S Fraga]

On Monday, 20 Sep 2021 at 11:27, Bastien wrote:
> You need to create an account on https://savannah.gnu.org and have
> your username there being accepted in the Emacs group:

What about those of us that do not wish to have write access but do want
to simply track the development?  Neither of the links provided works
for me.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-637-gd70f28
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Switching to new Git repositories

[Bastien]

Hi Marco,

Marco Wahl  writes:

> My first attempt to commit to the new repo
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git failed.

You need to create an account on https://savannah.gnu.org and have
your username there being accepted in the Emacs group:

https://savannah.gnu.org/git/?group=emacs

Please let me know when you are done requesting to join the Emacs
group, so that I can explain Eli and Lars that you are a regular Org
contributor.  (I've sent such instructions to the main committers a
while ago -- I think I've sent them to you, sorry if this was not the
case.)

> Would you mind to describe what preconditions are needed to be able to
> commit?  Is it just a question of using the right URL at clone time?

See the instructions here: https://savannah.gnu.org/git/?group=emacs

> Would you even update file CONTRIBUTE respectively? (Which still refers
> to code.orgmode.org.)

Yes, I'll do that today, thanks for the heads up.

-- 
 Bastien

Re: Switching to new Git repositories

[Timothy]

Hi  Marco,

> My first attempt to commit to the new repo
>  failed.
>
> Would you mind to describe what preconditions are needed to be able to
> commit?  Is it just a question of using the right URL at clone time?
>
> Would you even update file CONTRIBUTE respectively? (Which still refers
> to code.orgmode.org.)

I think for contributors we might want to use this git remote:
┌
│ g...@git.savannah.gnu.org:emacs/org-mode.git
└

Pulling from this seemed to work, and so I will update CONTRIBUTE accordingly.

All the best,
Timothy

Re: Switching to new Git repositories

[Marco Wahl]

Hi Bastien,

Thanks for all!

> from now on, here are the official Org repositories:
>
> - org-mode: https://git.savannah.gnu.org/cgit/emacs/org-mode.git
> - worg: https://git.sr.ht/~bzg/worg
> - orgweb: https://git.sr.ht/~bzg/orgweb
>
> org-contrib will continue to be on https://git.sr.ht/~bzg/org-contrib
> until it disappears, thanks to volunteers taking over maintainance of
> the various packages.
>
> You can forget code.orgmode.org.
>
> If you commit to code.orgmode.org by mistake instead of using the new
> repos, just merge the commit from the old repo that you can set up as
> a remote branch: I won't delete code.orgmode.org until Org 9.6.
>
> If you don't have write access to the new repos and think you should,
> please send me an email.

My first attempt to commit to the new repo
https://git.savannah.gnu.org/cgit/emacs/org-mode.git failed.

Would you mind to describe what preconditions are needed to be able to
commit?  Is it just a question of using the right URL at clone time?

Would you even update file CONTRIBUTE respectively? (Which still refers
to code.orgmode.org.)

Re: [PATCH] Add faces to improve contextuality of agenda views

[Protesilaos Stavrou]

On 2021-09-19, 21:23 +0800, Timothy  wrote:

> Hi  Protesilaos,

Hello Timothy,

> Thanks for sending this patch in, and sorry it’s taken a while for you to hear
> anything back.

No worries.  I understand this is a voluntary effort.

> I see the utility of org-imminent-deadline, but am fairly indifferent
> about the rest.

I can provide examples in case someone needs them.  The basic idea is to
ensure consistency of styling.

Right now, if you increase the height of the 'org-agenda-structure' and
do something like M-x org-agenda followed by 'm' you will get a header
that reads like:

Headlines with TAGS match: admin

The "admin" part is smaller than the rest.  It is this sort of
inconsistency that we wish to address.  We do it in a manner that is
backward-compatible, which means that themes do not have to be updated
for users to benefit from the new design (though users/themes gain the
option to control the presentation with greater precision).

> Hopefully bumping this might prompt some others to give their thoughts on your
> patch.

I am happy to wait for as long as necessary and remain at your disposal
for any further commentary or possible edits to the patch.

Given this opportunity, thank you and the others for your contributions
to Org.

Best regards,
Protesilaos

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: BUG Visibility Cycling with inline tasks

[Ihor Radchenko]

Michael Dauer  writes:

> What I get after the first org-cycle is:
> * Example
> ** heading 1
> ** heading 2
> *  ** TODO Test access with provided credentials
> ** heading 3
> x
> *  ** END
> ** heading 4
> x
>

I cannot reproduce on latest master and with Org 9.4.4. What I am seeing
is:

* Example
** heading 1...
** heading 2
*  ** TODO Test access with provided credentials...
*  ** END
* heading 3...
* heading 4

Another cycle reveals the inlinetask contents:

* Example
** heading 1...
** heading 2
*  ** TODO Test access with provided credentials
x
*  ** END
* heading 3...
* heading 4

Maybe something with your config? Can you reproduce starting from emacs -Q?

Best,
Ihor

version-to-list: Invalid version syntax: ‘9.5-dev’

[Axel Kielhorn]

Hello,

I moved to the new repo and rebuild org.

Now I get the following error message:

version-to-list: Invalid version syntax: ‘9.5-dev’

It seems someone checks for the version number and can’t handle the ´-dev´.

When I change org-version.el to ’9.5’ (which I shouldn’t do) the problem is 
gone.

I’m using Emacs 26.3 and 27.2 with scimax (which requires lots of packages from 
ELPA), both have this problem.

Should I investigate to find the culprit?

And if yes, how?

Greetings Axel

Re: DONE headlines take a different color

[Giovanni Gigante]

Jim Porter wrote:

On 9/19/2021 9:09 AM, Giovanni Gigante wrote:


As per the subject: TODO states mantain the headline color (as 
expected), but DONE states change it (not expected).


As shown in lines 2, 5, 8, 11, 14 of the following screenshot (emacs 
27.2 on MacOS launched with -q,  org mode 9.4.4):


I believe this is the result of `org-fontify-done-headline', which 
defaults to t as of e360cd8f3a from Feb 2020.


- Jim



It is, thanks!

I don't think it is a good default, by the way. It disrupts the visual 
readability of the document structure, which is more important than 
further emphasizing the DONE state.



Giovanni

Re: BUG Visibility Cycling with inline tasks

[Michael Dauer]

What I get after the first org-cycle is:
* Example
** heading 1
** heading 2
*  ** TODO Test access with provided credentials
** heading 3
x
*  ** END
** heading 4
x

So it also shows part of the following heading. This "garbage" can be max
more if the following subtree is more complex.

it stays after the 2nd and 3rd cycle. Cycles 4 to 6 are OK, then the
problem comes again.

Am Mo., 20. Sept. 2021 um 07:01 Uhr schrieb Ihor Radchenko <
yanta...@gmail.com>:

> Michael Dauer  writes:
>
> > Stating collapsed, pressing TAB on the heading 2 already shows the issue.
>
> Could you describe what is the issue you observe and how it differs from
> your expectations? I do not see any problem with visibility on my side.
>
> Best,
> Ihor
>

Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.con

[Sébastien Miquel]

Hi,

Mohsin Kaleem writes:

Hi, just following up. This is still an issue.


I can confirm this. I've run into the same issue and fix.

Are you using native compilation ? I think this must be the cause, 
though no one

else could reproduce. If I byte compile the function instead, things work.

Regards,

--
Sébastien Miquel