Re: Orgdown: negative feedback & attempt of a root-cause analysis

[Eric S Fraga]

On Wednesday,  1 Dec 2021 at 22:17, M. ‘quintus’ Gülker wrote:
> There is Git, of course, but unless you are a programmer, using Git is
> pretty much arcane. I was not yet successful to explain Git to MS Word
> users, who are actually happy with the change tracking tooling Word
> has built in. Though that might be more of a topic for the
> emacs-humanities mailing list rather than this list.

It's more widespread than that; in engineering, almost all (but not
all!) of my colleagues do the same and it's difficult to get them to
listen about the advantages of proper version control.

> Am Dienstag, dem 30. November 2021 schrieb Karl Voit:
>> People do not seem to realize what it took to get there - which is
>> partly understandingly because I had to learn by doing what it takes
>> to get the idea into a coherent and consistent form.

Karl, I tweeted soon after your presentation at EmacsConf 2021 that
although my use of org relies on much more than just the simple markup
(I use babel and citations extensively), the idea of a standard for the
markup was welcome.  Do not give up.  Okay, the name might be
contentious... ;-)

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Formal syntax for org-cite

[Timothy]

Hi Nicolas,

Thanks you for your feedback and clarifications. They were most helpful.
Thomas, I've also made a few tweaks based on your reply.
I've revised the draft in light of your comments, see below.

Citations follow the pattern
#+begin_example
[cite CITESTYLE: GLOBALPREFIX KEYCITES GLOBALSUFFIX]
#+end_example
where "cite" and =CITESTYLE=, =KEYCITES= and =GLOBALSUFFIX= are /not/
separated by whitespace. Whitespace after the leading colon or before
the closing square bracket is not significant. All other whitespace is
significant.

The only mandatory component, =KEYCITES= consists of one or more
instances of the following pattern, separated by semicolons,
#+begin_example
KEYPREFIX @KEY KEYSUFFIX
#+end_example
where =KEYPREFIX=, =@KEY=, and =KEYSUFFIX= are /not/ separated by
whitespace.

=KEY= can be made of any word-constituent character, =-=, =.=, =:=, =?=,
=!=, =`=, ='=, =/=, =*=, =@=, =+=, =|=, =(=, =)=, ={=, =}=, =<=, =>=,
=&=, =_=, =^=, =$=, =#=, =%=, or =~=.

=KEYPREFIX= and =KEYSUFFIX= are optional and can contain any characters
other than a semicolon (=;=), so long as square brackets are balanced.
=KEYPREFIX= cannot contain any subsequence that forms a =KEY=.

Hence, a minimal citation is formed by the pattern ~[cite:@KEY]~.

=CITESTYLE= consists of a main =STYLE= and optionally a =VARIANT=​.
Both the =STYLE= and =VARIANT= are prefixed by a forwards slash.
#+begin_example
/STYLE/VARIANT
#+end_example
=STYLE= and =VARIANT= can be made of any alphanumeric character, =_=, or
=-=.  Additionally, =VARIANT= can itself contain forward slashes (=/=) .

=GLOBALPREFIX= and =GLOBALSUFFIX= can contain the same characters as
=KEYPREFIX= and =KEYSUFFIX=. In the same manner as instances of the
=KEYCITES= pattern, =KEYCITES=, =GLOBALPREFIX=, and =GLOBALSUFFIX= must
be separated by semicolons.

--
Timothy

Re: Orgdown: negative feedback & attempt of a root-cause analysis

[Tim Cross]

Karl Voit  writes:

> Hi,
>
> I've summarized my current state of mind about the whole Orgdown
> fiasco into a blog article:
> https://karl-voit.at/2021/12/02/Orgdown-feedback/
>
> Don't worry, I tried to analyze my own faults as well so that others
> might be able to learn from this unfortunate situation.


Hi Karl,

thanks for writing up your experiences. I'm not surprised about the
reaction you got from reddit. I gave up on reddit some time back due to
the toxic nature of too many threads. I don't know why it is so often
toxic, but it really isn't worth the hassle.

Starting up a project is difficult. I have an open source JS library
which has turned out to be far more popular than I expected (averages
over 150k downloads each week). I'm not sure I was ready for the
commitment maintaining such a project involves - especially the long
term nature of it. At times, I ahve had problems with rather 'entitled'
users who demand ridiculous things from a free bit of software and who
can become extremely rude and somewhat nasty when I don't do what they
want. I've learnt to just ignore them.

The best advice I can give is to suggest you just put the whole thing on
the back burner for a month or so and then come back to it. During that
time, other comments are bound to come through and I find the later
comments are often far more considered and less emotional than initial
responses. Stepping back gives the subconscious part of your brain time
to process everything and will likely provide additional clarity once it
has had time to percolate. 

Re: Orgdown: negative feedback & attempt of a root-cause analysis

[George Mauer]

Thank you for writing all this down Karl. Thank you for your efforts and I
truly am sorry for everything you've been put through emotionally. I know
very well how a few particularly nasty comments can sap your energy as the
brain cycles on them over and over.

I hope you come out of this the stronger and so does the project

On Wed, Dec 1, 2021, 17:44 Karl Voit  wrote:

> Hi,
>
> I've summarized my current state of mind about the whole Orgdown
> fiasco into a blog article:
> https://karl-voit.at/2021/12/02/Orgdown-feedback/
>
> Don't worry, I tried to analyze my own faults as well so that others
> might be able to learn from this unfortunate situation.
>
> --
> get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
>> get Memacs from https://github.com/novoid/Memacs <
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/
>
>
>

Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

[Ihor Radchenko]

Max Nikulin  writes:

>> Well... I added yet another exception on main. Note that this special
>> case is also just in older Emacs versions.
>
> Ihor, have you pushed the change? I still can reproduce the issue with 
> Emacs-26.3

Oops. I fixed Emacs 27, but apparently not Emacs 26. Should be fixed
now.

>> (and I secretly hope that this kind of
>> patch will be implemented by someone else as a part of tree-sitter
>> integration).
>
> A piece of friendly trolling: it would be tree-sitter module for Org syntax.

tree-sitter is comparable with org-element. org-element
parser is fairly fast and also uses incremental parsing ;)

tree-sitter vs. org-element on 15M Org file
org-element-parse-buffer
(16.090262757 1 0.736568360962)

org-element-parse-buffer 'element granularity
(7.688000744 0 0.0)
8sec

tree-sitter via https://github.com/milisims/tree-sitter-org
parsed down to 58% of the buffer in 5.3sec and exited with error
extrapolates to ~9sec

Racket's brack via https://github.com/tgbugs/laundry
failed to finish parsing in reasonable time. Cancelled at 10m11.436s

Clojure parser via https://github.com/200ok-ch/org-parser
failed to finish parsing with java.lang.OutOfMemoryError: GC overhead limit 
exceeded
Running time 8m28.078s

So, tree-sitter may be faster, but not that much faster and we will have
communication overheads when using tree-sitter module.

>> The most problematic
>> is the case triggered by self-insert-command, but it will not trigger
>> cache reset.
>
> I mean namely this case of just typing text somewhere in a large file.

My data is for 15M file. Indeed, things will be worse for even larger
files, but let's hope that people's Org files are not yet that large and
we can wait until Emacs 28 is released.

Best,
Ihor

Re: frustrations

[Ihor Radchenko]

Jan Ulrich Hasecke  writes:

> Today I discovered that pamparam does not work anymore with an error
> message mentioned here:
> https://github.com/nobiot/org-transclusion/issues/105

This most likely indicates that some third-party packages you use are
implementing risky Elisp practices known to break Org. The were also a
source of (pretty bad) issues in the past, but Org now shows the warning
explicitly.

If you can hunt down to the problematic package, I advice to report this
as a bug in there. If you think that third-party packages are fine and
Org is the cause, please open a separate thread.

> There are some more issues. Startup time of my emacs is more than 30
> seconds even after optimizing something with esup. I have 10.000+ files
> in my org-roam and fear that I hit some limitation either of org-roam or
> my hardware.

Such problem has been observed a few weeks ago. An update might help.
If not, you can try to set org-element-cache-persistent to nil. It can
theoretically improve loading Org if your hard drive is very slow.

> How do you configure your emacs using current versions like org 9.5 but
> at the same time avoiding problems with incompatible packages or newly
> introduced bugs?

>From straight.el readme:

>> We support :branch, but not :commit or :version-regexp. To lock a package to 
>> a specific commit, use a lockfile. See also #246 for discussion of 
>> extensions to the recipe to support package pinning, which is a planned 
>> feature.

Best,
Ihor

Re: [BUG] Orgmode error prompted to submit [9.6 (9.6-??-27edae8 @ /home/chris/.emacs.d/.local/straight/build-27.2/org/)]

[Ihor Radchenko]

"christopher.pingitore" via "General discussions about Org-mode."
 writes:

> Warning (emacs): org-element--cache: Cache corruption detected in 
> 2021-08-08--Org File Test for Sharing--TECH.org. Resetting.
> The error was: (error "rx ‘**’ range error")
> Backtrace:
> nil
> Please report this to Org mode mailing list (M-x org-submit-bug-report).

Thanks for reporting! We have made some progress toward fixing this in
recent commits (1593d3148). Can you update your Org and let us know if
you are still seeing the warning?

Best,
Ihor

Re: Orgdown: negative feedback & attempt of a root-cause analysis

[Karl Voit]

Hi,

I've summarized my current state of mind about the whole Orgdown
fiasco into a blog article:
https://karl-voit.at/2021/12/02/Orgdown-feedback/

Don't worry, I tried to analyze my own faults as well so that others
might be able to learn from this unfortunate situation.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: frustrations

[Tim Cross]

Jan Ulrich Hasecke  writes:

> Hi all,
>
> after happily using straight for quite a while I am currently frustrated by a
> couple of problems.
>
> In a different thread I asked about exporting citations, which does not
> work for me at all.
>
> Today I discovered that pamparam does not work anymore with an error
> message mentioned here:
> https://github.com/nobiot/org-transclusion/issues/105
>
> Even to get to this error, as pamparam didn't start at all, I had to
> manually fix something in worf.el
> https://github.com/leotaku/worf/commit/38e901d3888e3a245a5cba14a061bffa1c5fd20b
>
> If I understand correctly, straight uses the bleeding of packages from
> github. Maybe this is not what I want. Maybe in the past I just was
> lucky not to hit a bug or an incompatible change. 
>
> There are some more issues. Startup time of my emacs is more than 30
> seconds even after optimizing something with esup. I have 10.000+ files
> in my org-roam and fear that I hit some limitation either of org-roam or
> my hardware.
>
> How do you configure your emacs using current versions like org 9.5 but
> at the same time avoiding problems with incompatible packages or newly
> introduced bugs?
>
> In a few days I'll get a new computer and I have serious doubt whether
> to copy my settings.org to the new one, because there are too many
> problems in the last couple of weeks.
>

As mentioned by others, this is really a general Emacs and software
maintenance issue. However, I'll add a couple of points to what has
already been said (most of which is good advice).

- Don't use straight. I've never used it primarily because installing
  directly from git is high risk. There is no guarantee that a git
  repository is stable or if the head of a branch is fully tested etc.
  Instead, stick with package.el and in particular, the GNU ELPA and
  NONGNU repositories.

  One reason for this is that when an updated package gets into one of
  the repositories, it does so because the maintainer has released a new
  version. This is not necessarily the case when you install directly
  from a git repository (either using straight or git directly).

- Often it is useful to steal (borrow) ideas from others. In particular,
  some of the curated 'canned' emacs setups, like spacemacs and doom
  implement a package rollback facility. You can upgrade packages and if
  you find they break your workflow in some way, you can rollback to a
  previous version.

  You may not want to use one of these curated configurations. However,
  this doesn't stop you from taking the ideas (and in most cases, even
  the code as it is typically GPL'd). These days, I use spacemacs and
  one reason is because I'm not interested in having to constantly tweak
  and review my packages and additional libraries. I now just leave that
  to spacemacs and enjoy the time it saves me.


With updates and stability, I think there are two approaches

- Update regularly - at least once a week if not more often. Doing this
  tends to result in only small changes and when things do break, it
  usually isn't too hard to fix. However, you are more likely to have
  small breakage more often. I tend to do my updates on Sunday so taht I
  ahve time to fix any problems before work on Monday.

- Only update when you encounter problems and need recent bug fixes or
  when a package you use has released a new version which has features
  you want. This results in far fewer instances of things breaking.
  However, the downside is that when you do upgrade, lots will likely
  change and tracking down the cause of problems can be more difficult.
  This approach often requires more planning and takes longer, but you
  do it less frequently. This I would do during a week off or over a
  holiday period etc.

One trick which I've used in the past is to

- Ensure all my library and package dependencies are located under
  .emacs.d
- Use something like use-package to manage installation of additional
  packages (via the :enable stanza).

Before doing an update/upgrade, I make a copy of .emacs.d called
emacs.d-mmdd (i.e. emacs.d with the date appended to the name). I
then do the update/upgrade. If things a broken, I simply delete .emacs.d
and then move the copy back to .emacs.d and I'm back to where I was
before the upgrade. It is somewhat crude, but simple and reliable. In
reality, I've put lots of my configuration files under git, so I can
easily restore a configuration on any system.

With regards to startup time, the key thing is to ensure you don't load
things until they are needed. Emacs has built in support for this with
the 'autoload' facility (get more details from the manual).
Alternatively, you can use something like use-package, which has the
:deferred stanza that will defer loading a package until a specific
command is executed (pretty sure it just uses the autoload facility
under the hood). I load approx 500 additional Emacs packages in my setup
and my load time is only a cople of seconds.

Re: citeproc-org and org-ref 3

[John Kitchin]

nil entries are not that uncommon in bibtex entries that are retrieved
with org-ref, especially for ASAP articles which typically have not been
assigned volumes, pages, etc. I usually put nil in as a placeholder so
that the empty fields don't get deleted when you clean the entry. They
are also easy to find later when updating them after those fields have
real values.

András Simonyi  writes:

> Dear Joseph,
>
> based on the error message there seems to be a problem with the
> 'curley-nil-on-bennet-spinoz' bibliography entry, is it possible that
> it contains a 'year = nil' row? If yes then I don't think that is
> well-formed, at least citeproc-el cannot currently parse it. Anyhow,
> apparently I need to improve/add citeproc-el error messages about
> bib(la)tex parsing, because several parsing problems have surfaced
> lately and the current error messages aren't helpful at all.
>
> best wishes,
> András
>
> On Wed, 1 Dec 2021 at 16:50, Joseph Vidal-Rosset
>  wrote:
>>
>> Dear John,
>>
>> I must say that to export references in html with org-ref 3, I meet a
>> lot of problems (with LaTeX, it's fine).
>>
>> I am using prelude emacs and  GNU Emacs 29.0.50 .
>>
>> Starting emacs --daemon, the code
>>
>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>  (org-open-file  (org-html-export-to-html)))
>>
>> in my setup provokes this unwanting effect:
>>
>> [Prelude] Loading personal configuration files in
>> /home/joseph/.emacs.d/personal/preload...
>> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
>> Output file:
>>
>> and with Enter :
>>
>> [Prelude] Loading personal configuration files in
>> /home/joseph/.emacs.d/personal/preload...
>> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
>> Output file:
>> Warning (initialization): An error occurred while loading
>> ‘/home/joseph/.emacs.d/init.el’:
>>
>> Wrong type argument: stringp, nil
>>
>> To ensure normal operation, you should investigate and remove the
>> cause of the error in your initialization file.  Start Emacs with
>> the ‘--debug-init’ option to view a complete error backtrace. Disable
>> showing Disable logging
>> Starting Emacs daemon.
>>
>> With --debug-init, I get:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>string-to-number(nil)
>>citeproc-bt--to-csl-date("nil" nil)
>>citeproc-blt-entry-to-csl((("Url" .
>> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
>> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
>> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
>> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
>> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
>> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
>> ("=key=" . "curley-nil-on-bennet-spinoz")) nil nil)
>>#f(compiled-function (key entry) #> -0x7fcb46b5c8e80b3>)("curley-nil-on-bennet-spinoz" (("Url" .
>> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
>> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
>> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
>> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
>> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
>> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
>> ("=key=" . "curley-nil-on-bennet-spinoz")))
>>maphash(#f(compiled-function (key entry) #> -0x7fcb46b5c8e80b3>) #)
>>citeproc-hash-itemgetter-from-any(("~/Dropbox/Orgzly/reforg.bib"))
>>org-ref-process-buffer(html)
>>org-ref-csl-preprocess-buffer(html)
>>run-hook-with-args(org-ref-csl-preprocess-buffer html)
>>org-export-as(html nil nil nil (:output-file "~/test.html"))
>>org-export-to-file(html "~/test.html" nil nil nil nil nil)
>>org-html-export-to-html()
>>(org-open-file (org-html-export-to-html))
>>(let ((org-export-before-parsing-hook
>> '(org-ref-csl-preprocess-buffer))) (org-open-file
>> (org-html-export-to-html)))
>>eval-buffer(# nil
>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil t)  ;
>> Reading at buffer position 3196
>>
>> load-with-code-conversion("/home/joseph/.emacs.d/personal/preload/myorgexport..."
>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil nil)
>>load("/home/joseph/.emacs.d/personal/preload/myorgexport...")
>>mapc(load ("/home/joseph/.emacs.d/personal/preload/myorgexport..."))
>>(progn (message "[Prelude] Loading personal configuration files in
>> ..." prelude-personal-preload-dir) (mapc 'load (directory-files
>> prelude-personal-preload-dir 't "^[^#.].*el$")))
>>(if (file-exists-p prelude-personal-preload-dir) (progn (message
>> "[Prelude] Loading personal configuration files in ..."
>> prelude-personal-preload-dir) (mapc 'load (directory-files
>> prelude-personal-preload-dir 't "^[^#.].*el$"
>>eval-buffer(# 

Re: citeproc-org and org-ref 3

[John Kitchin]

Joseph Vidal-Rosset  writes:

> Dear Andras,
>
> You are very probably right. I will have a look on this entry in my
> default bibliography file.
>
> The code
>
> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
> (org-open-file  (org-html-export-to-html)))
>
> put in .emacs.d/personal/preload/myorgexport.el
>
This code should not go in your init file. It is executed each time, and
not what you want. I usually put it a src block at the end in a section
tagged noexport and run it from there.

Alternatively, if this is the only preprocessing you do, I think you can
do C-c C-e rh to export to html (this runs the org-ref html exporter.

Finally, if you really want something in your init file it should be
like this:

(defun my-html ()
  (interactive)
  (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
(org-open-file  (org-html-export-to-html

and then later you run it with M-x my-html


> provokes the request of opening a html file, when emacs --daemon is
> started; therefore I conclude that it should not be used as I did...
>
> Anyway, every  tentative  to export in a bibliography in html fails at
> the moment, even with a new bibliography file...  :(

See of the one at
https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
works. The bib file is in
https://github.com/jkitchin/org-ref/blob/master/org-ref.bib.



>
> Best wishes,
>
> Le 01/12/2021 à 17:33, András Simonyi a écrit :
>> Dear Joseph,
>>
>> based on the error message there seems to be a problem with the
>> 'curley-nil-on-bennet-spinoz' bibliography entry, is it possible that
>> it contains a 'year = nil' row? If yes then I don't think that is
>> well-formed, at least citeproc-el cannot currently parse it. Anyhow,
>> apparently I need to improve/add citeproc-el error messages about
>> bib(la)tex parsing, because several parsing problems have surfaced
>> lately and the current error messages aren't helpful at all.
>>
>> best wishes,
>> András
>>
>> On Wed, 1 Dec 2021 at 16:50, Joseph Vidal-Rosset
>>  wrote:
>>>
>>> Dear John,
>>>
>>> I must say that to export references in html with org-ref 3, I meet a
>>> lot of problems (with LaTeX, it's fine).
>>>
>>> I am using prelude emacs and  GNU Emacs 29.0.50 .
>>>
>>> Starting emacs --daemon, the code
>>>
>>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>>   (org-open-file  (org-html-export-to-html)))
>>>
>>> in my setup provokes this unwanting effect:
>>>
>>> [Prelude] Loading personal configuration files in
>>> /home/joseph/.emacs.d/personal/preload...
>>> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
>>> Output file:
>>>
>>> and with Enter :
>>>
>>> [Prelude] Loading personal configuration files in
>>> /home/joseph/.emacs.d/personal/preload...
>>> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
>>> Output file:
>>> Warning (initialization): An error occurred while loading
>>> ‘/home/joseph/.emacs.d/init.el’:
>>>
>>> Wrong type argument: stringp, nil
>>>
>>> To ensure normal operation, you should investigate and remove the
>>> cause of the error in your initialization file.  Start Emacs with
>>> the ‘--debug-init’ option to view a complete error backtrace. Disable
>>> showing Disable logging
>>> Starting Emacs daemon.
>>>
>>> With --debug-init, I get:
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>> string-to-number(nil)
>>> citeproc-bt--to-csl-date("nil" nil)
>>> citeproc-blt-entry-to-csl((("Url" .
>>> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
>>> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
>>> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
>>> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
>>> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
>>> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
>>> ("=key=" . "curley-nil-on-bennet-spinoz")) nil nil)
>>> #f(compiled-function (key entry) #>> -0x7fcb46b5c8e80b3>)("curley-nil-on-bennet-spinoz" (("Url" .
>>> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
>>> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
>>> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
>>> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
>>> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
>>> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
>>> ("=key=" . "curley-nil-on-bennet-spinoz")))
>>> maphash(#f(compiled-function (key entry) #>> -0x7fcb46b5c8e80b3>) #)
>>> citeproc-hash-itemgetter-from-any(("~/Dropbox/Orgzly/reforg.bib"))
>>> org-ref-process-buffer(html)
>>> org-ref-csl-preprocess-buffer(html)
>>> run-hook-with-args(org-ref-csl-preprocess-buffer html)
>>> org-export-as(html nil nil nil 

Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

[M . ‘quintus’ Gülker]

Am Dienstag, dem 30. November 2021 schrieb Karl Voit:
> One of the next things I do have on my list is to try out crdt as
> I've learned at EmacsConf21 that it is mature enough to be used in
> practice. 
>
> If that holds true, we can start dreaming of having a Etherpad-like
> session from our GNU/Emacs while peers are connected to the same
> session via some web-based tool/service.

I never heard of crdt, but distributed editing sounds useful. There is
Git, of course, but unless you are a programmer, using Git is pretty
much arcane. I was not yet successful to explain Git to MS Word users,
who are actually happy with the change tracking tooling Word has built
in. Though that might be more of a topic for the emacs-humanities
mailing list rather than this list.

> The dominant feedback of
> https://www.reddit.com/r/emacs/comments/r4cq3o/orgdown_the_new_name_for_the_syntax_of_orgmode/
> was negative comments on the name and nothing else. Even here,
> although due to a much more civilized style, the name choice was the
> dominant topic and not the idea. I have to take this as a strong
> signal here and I'm very close in giving up on Orgdown as a project.

The civility of this list is one of the reasons why I like to read it. I
find it incredible how people behave on these so-called social media.
That alone indicates that something is wrong with them.

You should not give up on the project. As I have learned from reading
this thread, there appear to be people who already work on formalising
org’s grammar. You ought to talk to them and see if it is possible to
unite efforts. Tom Gillespie in a message further down this thread has
mentioned that formalising org is a huge effort. I agree with that, but
your novel concept of “compatibility levels” is something I could see as
an intermediate step. It could help to accelerate the formalising
efforts and non-Emacs tools could start targetting them quickly. But I
might be wrong on seeing this as an advantage; I have never written
formal specifications.

It is certainly your success to have generated this discussion thread; I
was not aware of any similar formalisation efforts. I hope that if
nothing else, it contributes to this efforts.

> People do not seem to realize what it took to get there - which is
> partly understandingly because I had to learn by doing what it takes
> to get the idea into a coherent and consistent form.

I do not think anybody wanted to feel you bad. Most are trying to
provide constructive criticism to you in order to improve your
suggestions. There are very few people who are fundamentally opposed to
your effort, because they firmly believe there can be no org outside of
Emacs. My suggestion is to ignore them and continue on your path,
because your idea has no impact on them and they can by definition not
help you to improve it.

Naming is one of the hard things in Computer Science. Just leave the
naming issue aside and work with the people here to formalise the
compatibility levels.

> Bastien told me that he would be interested to see hard numbers on
> my assumption that Org-mode syntax is easier to learn and type in
> comparison to other LWM. And he is right: some research work in
> order to get numbers would be awesome to shed some light on the
> forest of assumptions. Maybe somebody in a position to realize such
> a case study gets motivated now? ;-)

Entirely subjectively, typing:

#+begin_src python
#+end_src

manually without help of the editor feels more difficult than typing:

 python


Any non-Emacs org(down) editor should ensure to ease typing that.

For the purposes of refining your proposal conducting the “case study”
simply by inquiry on this mailing list might suffice. Many people around
here know Markdown and I guess there is no value in applying rigorous
scientific standards here.

> Does "assuming too much on other people's world because on my own
> small world" have a scientific name? I might be in danger of having
> this disease? *g*

I have fallen to this earlier. My computer is full of things to solve
problems many people simply do not even have. I need citation software
that interacts with my Biblatex files, for instance. Since my e.g. my
work collegues do not even use Biblatex, they do not have such a need.
Typing citations out by hand is rather popular in my area; if it is not
done manually, people appear to use Citavi. I certainly know not a
single person in my area who uses Biblatex. Another example is that I
have a rather longish ~/.xinitrc file for automatic starting of several
applications, like the PulseAudio sound server. Somehow, this is a
problem others appearently do not have; it exists because I inflict to
myself the pain of using Linux with i3 and Emacs, which I perceive as
productive rather than painful, not to mention the privacy advantages.
There was a time when I tried to convince people from my setup as
the correct one for everyone, but today I know it is not.

As an aside, 

Re: citeproc-org and org-ref 3

[Joseph Vidal-Rosset]

Dear Andras,

You are very probably right. I will have a look on this entry in my
default bibliography file.

The code

(let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
(org-open-file  (org-html-export-to-html)))

put in .emacs.d/personal/preload/myorgexport.el

provokes the request of opening a html file, when emacs --daemon is
started; therefore I conclude that it should not be used as I did...

Anyway, every  tentative  to export in a bibliography in html fails at
the moment, even with a new bibliography file...  :(

Best wishes,

Le 01/12/2021 à 17:33, András Simonyi a écrit :
> Dear Joseph,
>
> based on the error message there seems to be a problem with the
> 'curley-nil-on-bennet-spinoz' bibliography entry, is it possible that
> it contains a 'year = nil' row? If yes then I don't think that is
> well-formed, at least citeproc-el cannot currently parse it. Anyhow,
> apparently I need to improve/add citeproc-el error messages about
> bib(la)tex parsing, because several parsing problems have surfaced
> lately and the current error messages aren't helpful at all.
>
> best wishes,
> András
>
> On Wed, 1 Dec 2021 at 16:50, Joseph Vidal-Rosset
>  wrote:
>>
>> Dear John,
>>
>> I must say that to export references in html with org-ref 3, I meet a
>> lot of problems (with LaTeX, it's fine).
>>
>> I am using prelude emacs and  GNU Emacs 29.0.50 .
>>
>> Starting emacs --daemon, the code
>>
>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>   (org-open-file  (org-html-export-to-html)))
>>
>> in my setup provokes this unwanting effect:
>>
>> [Prelude] Loading personal configuration files in
>> /home/joseph/.emacs.d/personal/preload...
>> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
>> Output file:
>>
>> and with Enter :
>>
>> [Prelude] Loading personal configuration files in
>> /home/joseph/.emacs.d/personal/preload...
>> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
>> Output file:
>> Warning (initialization): An error occurred while loading
>> ‘/home/joseph/.emacs.d/init.el’:
>>
>> Wrong type argument: stringp, nil
>>
>> To ensure normal operation, you should investigate and remove the
>> cause of the error in your initialization file.  Start Emacs with
>> the ‘--debug-init’ option to view a complete error backtrace. Disable
>> showing Disable logging
>> Starting Emacs daemon.
>>
>> With --debug-init, I get:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>> string-to-number(nil)
>> citeproc-bt--to-csl-date("nil" nil)
>> citeproc-blt-entry-to-csl((("Url" .
>> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
>> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
>> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
>> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
>> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
>> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
>> ("=key=" . "curley-nil-on-bennet-spinoz")) nil nil)
>> #f(compiled-function (key entry) #> -0x7fcb46b5c8e80b3>)("curley-nil-on-bennet-spinoz" (("Url" .
>> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
>> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
>> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
>> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
>> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
>> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
>> ("=key=" . "curley-nil-on-bennet-spinoz")))
>> maphash(#f(compiled-function (key entry) #> -0x7fcb46b5c8e80b3>) #)
>> citeproc-hash-itemgetter-from-any(("~/Dropbox/Orgzly/reforg.bib"))
>> org-ref-process-buffer(html)
>> org-ref-csl-preprocess-buffer(html)
>> run-hook-with-args(org-ref-csl-preprocess-buffer html)
>> org-export-as(html nil nil nil (:output-file "~/test.html"))
>> org-export-to-file(html "~/test.html" nil nil nil nil nil)
>> org-html-export-to-html()
>> (org-open-file (org-html-export-to-html))
>> (let ((org-export-before-parsing-hook
>> '(org-ref-csl-preprocess-buffer))) (org-open-file
>> (org-html-export-to-html)))
>> eval-buffer(# nil
>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil t)  ;
>> Reading at buffer position 3196
>>
>> load-with-code-conversion("/home/joseph/.emacs.d/personal/preload/myorgexport..."
>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil nil)
>> load("/home/joseph/.emacs.d/personal/preload/myorgexport...")
>> mapc(load ("/home/joseph/.emacs.d/personal/preload/myorgexport..."))
>> (progn (message "[Prelude] Loading personal configuration files in
>> ..." prelude-personal-preload-dir) (mapc 'load (directory-files
>> prelude-personal-preload-dir 't "^[^#.].*el$")))
>> (if 

Re: citeproc-org and org-ref 3

[András Simonyi]

Dear Joseph,

based on the error message there seems to be a problem with the
'curley-nil-on-bennet-spinoz' bibliography entry, is it possible that
it contains a 'year = nil' row? If yes then I don't think that is
well-formed, at least citeproc-el cannot currently parse it. Anyhow,
apparently I need to improve/add citeproc-el error messages about
bib(la)tex parsing, because several parsing problems have surfaced
lately and the current error messages aren't helpful at all.

best wishes,
András

On Wed, 1 Dec 2021 at 16:50, Joseph Vidal-Rosset
 wrote:
>
> Dear John,
>
> I must say that to export references in html with org-ref 3, I meet a
> lot of problems (with LaTeX, it's fine).
>
> I am using prelude emacs and  GNU Emacs 29.0.50 .
>
> Starting emacs --daemon, the code
>
> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>  (org-open-file  (org-html-export-to-html)))
>
> in my setup provokes this unwanting effect:
>
> [Prelude] Loading personal configuration files in
> /home/joseph/.emacs.d/personal/preload...
> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
> Output file:
>
> and with Enter :
>
> [Prelude] Loading personal configuration files in
> /home/joseph/.emacs.d/personal/preload...
> Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
> Output file:
> Warning (initialization): An error occurred while loading
> ‘/home/joseph/.emacs.d/init.el’:
>
> Wrong type argument: stringp, nil
>
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file.  Start Emacs with
> the ‘--debug-init’ option to view a complete error backtrace. Disable
> showing Disable logging
> Starting Emacs daemon.
>
> With --debug-init, I get:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>string-to-number(nil)
>citeproc-bt--to-csl-date("nil" nil)
>citeproc-blt-entry-to-csl((("Url" .
> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
> ("=key=" . "curley-nil-on-bennet-spinoz")) nil nil)
>#f(compiled-function (key entry) # -0x7fcb46b5c8e80b3>)("curley-nil-on-bennet-spinoz" (("Url" .
> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
> ("=key=" . "curley-nil-on-bennet-spinoz")))
>maphash(#f(compiled-function (key entry) # -0x7fcb46b5c8e80b3>) #)
>citeproc-hash-itemgetter-from-any(("~/Dropbox/Orgzly/reforg.bib"))
>org-ref-process-buffer(html)
>org-ref-csl-preprocess-buffer(html)
>run-hook-with-args(org-ref-csl-preprocess-buffer html)
>org-export-as(html nil nil nil (:output-file "~/test.html"))
>org-export-to-file(html "~/test.html" nil nil nil nil nil)
>org-html-export-to-html()
>(org-open-file (org-html-export-to-html))
>(let ((org-export-before-parsing-hook
> '(org-ref-csl-preprocess-buffer))) (org-open-file
> (org-html-export-to-html)))
>eval-buffer(# nil
> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil t)  ;
> Reading at buffer position 3196
>
> load-with-code-conversion("/home/joseph/.emacs.d/personal/preload/myorgexport..."
> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil nil)
>load("/home/joseph/.emacs.d/personal/preload/myorgexport...")
>mapc(load ("/home/joseph/.emacs.d/personal/preload/myorgexport..."))
>(progn (message "[Prelude] Loading personal configuration files in
> ..." prelude-personal-preload-dir) (mapc 'load (directory-files
> prelude-personal-preload-dir 't "^[^#.].*el$")))
>(if (file-exists-p prelude-personal-preload-dir) (progn (message
> "[Prelude] Loading personal configuration files in ..."
> prelude-personal-preload-dir) (mapc 'load (directory-files
> prelude-personal-preload-dir 't "^[^#.].*el$"
>eval-buffer(# nil "/home/joseph/.emacs.d/init.el" nil
> t)  ; Reading at buffer position 4489
>load-with-code-conversion("/home/joseph/.emacs.d/init.el"
> "/home/joseph/.emacs.d/init.el" t t)
>load("/home/joseph/.emacs.d/init" noerror nomessage)
>startup--load-user-init-file(#f(compiled-function () # 0xec639179d6199fa>) #f(compiled-function () # -0x1f3c686ddc0dc635>) t)
>command-line()
>normal-top-level()
>
> It's too complicated for me.
> org-ref version 2 with citeproc-org by Andras worked well, 

Re: citeproc-org and org-ref 3

[Joseph Vidal-Rosset]

Dear John,

I must say that to export references in html with org-ref 3, I meet a
lot of problems (with LaTeX, it's fine).

I am using prelude emacs and  GNU Emacs 29.0.50 .

Starting emacs --daemon, the code

(let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
 (org-open-file  (org-html-export-to-html)))

in my setup provokes this unwanting effect:

[Prelude] Loading personal configuration files in
/home/joseph/.emacs.d/personal/preload...
Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
Output file:

and with Enter :

[Prelude] Loading personal configuration files in
/home/joseph/.emacs.d/personal/preload...
Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
Output file:
Warning (initialization): An error occurred while loading
‘/home/joseph/.emacs.d/init.el’:

Wrong type argument: stringp, nil

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace. Disable
showing Disable logging
Starting Emacs daemon.

With --debug-init, I get:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
   string-to-number(nil)
   citeproc-bt--to-csl-date("nil" nil)
   citeproc-blt-entry-to-csl((("Url" .
"http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
"10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
"ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
("=key=" . "curley-nil-on-bennet-spinoz")) nil nil)
   #f(compiled-function (key entry) #)("curley-nil-on-bennet-spinoz" (("Url" .
"http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
"10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
"ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
("=key=" . "curley-nil-on-bennet-spinoz")))
   maphash(#f(compiled-function (key entry) #) #)
   citeproc-hash-itemgetter-from-any(("~/Dropbox/Orgzly/reforg.bib"))
   org-ref-process-buffer(html)
   org-ref-csl-preprocess-buffer(html)
   run-hook-with-args(org-ref-csl-preprocess-buffer html)
   org-export-as(html nil nil nil (:output-file "~/test.html"))
   org-export-to-file(html "~/test.html" nil nil nil nil nil)
   org-html-export-to-html()
   (org-open-file (org-html-export-to-html))
   (let ((org-export-before-parsing-hook
'(org-ref-csl-preprocess-buffer))) (org-open-file
(org-html-export-to-html)))
   eval-buffer(# nil
"/home/joseph/.emacs.d/personal/preload/myorgexport..." nil t)  ;
Reading at buffer position 3196

load-with-code-conversion("/home/joseph/.emacs.d/personal/preload/myorgexport..."
"/home/joseph/.emacs.d/personal/preload/myorgexport..." nil nil)
   load("/home/joseph/.emacs.d/personal/preload/myorgexport...")
   mapc(load ("/home/joseph/.emacs.d/personal/preload/myorgexport..."))
   (progn (message "[Prelude] Loading personal configuration files in
..." prelude-personal-preload-dir) (mapc 'load (directory-files
prelude-personal-preload-dir 't "^[^#.].*el$")))
   (if (file-exists-p prelude-personal-preload-dir) (progn (message
"[Prelude] Loading personal configuration files in ..."
prelude-personal-preload-dir) (mapc 'load (directory-files
prelude-personal-preload-dir 't "^[^#.].*el$"
   eval-buffer(# nil "/home/joseph/.emacs.d/init.el" nil
t)  ; Reading at buffer position 4489
   load-with-code-conversion("/home/joseph/.emacs.d/init.el"
"/home/joseph/.emacs.d/init.el" t t)
   load("/home/joseph/.emacs.d/init" noerror nomessage)
   startup--load-user-init-file(#f(compiled-function () #) #f(compiled-function () #) t)
   command-line()
   normal-top-level()

It's too complicated for me.
org-ref version 2 with citeproc-org by Andras worked well, but now I am
afraid that to downgrade to org-ref 2 is not necessarily the best
solution. I am lost.

Best wishes, and thanks for your help.

Jo.


Le 30/11/2021 à 18:31, John Kitchin a écrit :
> See https://www.youtube.com/watch?v=rRR-5NSpKyE
>  for an overview of what to
> do. basically you need a csl file that provides the style you want, and
> you specify it like this in the org file or in default settings. You may
> also need a locale file if you are not blogging in english.
>
> #+csl-style: apa-5th-edition.csl
>
> #+csl-locale: en-US
>
>
> You can find a basic example org file for html export with CSL at
> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
> 
>
> 

Re: frustrations

[Arthur Miller]

Timothy  writes:

> Hi Jan,
>
> Not that I’m unsympathetic to your issues, however I must say that your email
> seems to have little to do with Org, and this *is* the Org mailing list.
>
> Perhaps you would be better served by something like emacs.stackexchange.com.
>
> Jan Ulrich Hasecke  writes:
>
>> Hi all,
>>
>> after happily using straight for quite a while I am currently frustrated by a
>> couple of problems.
>>
>> In a different thread I asked about exporting citations, which does not
>> work for me at all.
>>
>> Today I discovered that pamparam does not work anymore with an error
>> message mentioned here:
>> 
>>
>> Even to get to this error, as pamparam didn’t start at all, I had to
>> manually fix something in worf.el
>> 
>>
>> If I understand correctly, straight uses the bleeding of packages from
>> github. Maybe this is not what I want. Maybe in the past I just was
>> lucky not to hit a bug or an incompatible change.

I don't think luck is not something you should count on. :)

Don't use straight and bleeding edge repositories with branches and what
not. It's a recipe for spaghetti setup and hard to find bugs.

Built-in package.el + elpa/melpa/nelpa should give you stable setup.

>> There are some more issues. Startup time of my emacs is more than 30
>> seconds even after optimizing something with esup. I have 10.000+ files
>> in my org-roam and fear that I hit some limitation either of org-roam or
>> my hardware.

No idea how you managed to collect 10.000+ notes and what not, but if you are
trying to read them in all at startup, or even index them at startup, it is
going to reflect on the startup time. I don't know what you do, or not, but if
something like that is happening, you should find some solution to the problem,
like index files offline or something else.

30 secs for Emacs startup sounds like a lot even for slowest hardware. My Emacs
on my "fast" gnu/Linux start up in 0.3 seconds, and on very slow old laptop we
have in ~3 seconds, with exact same setup. 

>> How do you configure your emacs using current versions like org 9.5 but
>> at the same time avoiding problems with incompatible packages or newly
>> introduced bugs?
We don't use "bleeding edge" repositories and custom branches.

>> In a few days I’ll get a new computer and I have serious doubt whether
>> to copy my settings.org to the new one, because there are too many
>> problems in the last couple of weeks.
>>
>> Any hints?

For the speed, lazy-evaluate everything at startup; i.e. load things "on
demand", when they are asked for.

'with-eval-after-load' and mode hooks are your friends. There is no need for
neither straight, use-package and/or general.el if you use it too. If you don't
know how to use those properly, so please read about those in the manual that
comes with your Emacs.

Just properly use with-eval-after-load and mode hooks, and you'll be ok.

Also, this question is probably better asked on Reddit, SX, or
help-gnu-em...@gnu.org than in this list.

Re: frustrations

[Tim Visher]

Hi Jan,

On Wed, Dec 1, 2021 at 7:58 AM Eric S Fraga  wrote:

> On Wednesday,  1 Dec 2021 at 13:21, Jan Ulrich Hasecke wrote:
> > How do you configure your emacs using current versions like org 9.5 but
> > at the same time avoiding problems with incompatible packages or newly
> > introduced bugs?
>
> …
>
> Avoiding problems with incompatible packages or new bugs is impossible,
> however.  The solution is to avoid upgrade-itis and only upgrade when
> necessary.  Although I track org from git, I don't update all the time
> and only do so when I know I will have some time to deal with any
> repercussions.  (like today where I upgraded both Emacs and org because
> I know I have no immediate deadlines)
>
> Most other packages, I seldom upgrade if ever.
>

I just wanted to quickly second this. The old saying "If it ain't broke,
don't fix it." is evergreen.

The other thing I'll say though is that so long as you use the `~/.emacs.d`
or `~/.config/emacs` it's very easy to place the entirety of your emacs
config under source control. The key thing to do here is to _check in_ your
package dependencies (`elpa` directory in my case). That way whenever you
upgrade a package it's very easy to revert to a known working state if you
don't have time to work through the incompatibilities.

--

In Christ,

Timmy V.

https://blog.twonegatives.com
http://five.sentenc.es

Re: Bibliographies on export with ox-context and ox-epub

[Nicolas Goaziou]

Hello,

juh  writes:

> thanks a lot.
>
> basic works

Good! We're getting close.

> but with csl I get:
>
> citeproc-style-parse: Opening input file: Datei oder Verzeichnis nicht 
> gefunden, /usr/share/emacs/27.1/etc/org/csl/chicago-author-date.csl
>
> File or directory not found.

That's unexpected. I am curious to know why `org-cite-csl--etc-dir' is
set to "/usr/share/emacs/27.1/etc/org/csl/chicago-author-date.csl".

If you have some time to spare, you could edebug this defconst by using
 on its definition and move with successive . In
particular, (locate-library "oc") should not point to
/usr/share/emacs/27.1/... since it was not available at that time.

> I tried to point 
>
> #+csl_style: ~/Projekte/csl.styles/chicago-author-date.csl
>
> but there is no change in the error message.

Location of the CSL style file should be the second token in the
"cite_export" keyword. So the above should be:

  #+cite_export: csl ~/Projekte/csl.styles/chicago-author-date.csl

You can also shorten this with `org-cite-csl-styles-dir' variable. E.g.,
if _all_ your style files are located in "~/Projekte/csl.styles/", you
could use:

  (setq org-cite-csl-styles-dir "~/Projekte/csl.styles/")

In that case, the second token from "cite_export" keyword would become:

  #+cite_export: csl chicago-author-date.csl

Note there is no "csl_style" keyword in Org Cite. It might be related to
Org Ref, which is a different citation system.

HTH,
-- 
Nicolas Goaziou

Re: how to export red colored TeX to latex

[Eric S Fraga]

On Wednesday,  1 Dec 2021 at 15:00, Juan Manuel Macías wrote:
> Anyway, for format chunks of text in export I think
> org-link-set-parameters is a good alternative to macros.

I also have a few links defined (used to have one for citing but no
longer needed) but macros seem to be my first port-of-call and maybe
shouldn't be!

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: how to export red colored TeX to latex

[Juan Manuel Macías]

Hi Eric,

Eric S Fraga writes:

> Very nice Juan!  I would find this use of links quite useful.

Thank you. Yes, org-link-set-parameters is quite productive, and
addictive in occasions! :-): I also have link types defined for somewhat
extravagant things, such as linking videos and music from the dlna
server of my raspberry...

Anyway, for format chunks of text in export I think
org-link-set-parameters is a good alternative to macros.

Best regards,

Juan Manuel 

Re: Bibliographies on export with ox-context and ox-epub

[Eric S Fraga]

On Wednesday,  1 Dec 2021 at 15:57, juh wrote:
> But then I can't get out, because:
>
> Key ("" to exit) 
>
> What key is this? 

What completion engine are you using?  In selectrum, typing C-j at that
point finishes the completion.  Other engines will differ.  You might
also try up-arrow and RET.

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Bibliographies on export with ox-context and ox-epub

[juh]

Am Wed, Dec 01, 2021 at 03:44:48PM +0100 schrieb juh:
> but with csl I get:
> 
> citeproc-style-parse: Opening input file: Datei oder Verzeichnis nicht 
> gefunden, /usr/share/emacs/27.1/etc/org/csl/chicago-author-date.csl
> 
> File or directory not found.
> 
> I tried to point 
> 
> #+csl_style: ~/Projekte/csl.styles/chicago-author-date.csl
> 
> but there is no change in the error message.

One more thing.

org-cite-insert gives me the list of entries in test.bib as expected.

Pressing ENTER adds "doe"

But then I can't get out, because:

Key ("" to exit) 

What key is this? 

juh

-- 
Autoren-Homepage: . http://literatur.hasecke.com
Satiren & Essays: . http://www.sudelbuch.de
Privater Blog:  http://www.hasecke.eu
Netzliteratur-Projekt:  http://www.generationenprojekt.de




signature.asc
Description: PGP signature

Re: Bibliographies on export with ox-context and ox-epub

[juh]

Hi Nicolas,

thanks a lot.

basic works

Am Wed, Dec 01, 2021 at 02:42:10PM +0100 schrieb Nicolas Goaziou:
> If I change the second line to "#+cite_export: csl" instead, with the
> external Citeproc Emacs library properly loaded, I get:
> 
> (org et al. 2021, 45)
> 
> org et al. (2021, 45)
> 
> 
> org, mode, Citation Syntax, Mailing List, and Time Effort. 2021.
> “Elegant Citations with Org-Mode. J/o”urnal of Plain Text Formats/ 42
> (1).
> --8<---cut here---end--->8---

but with csl I get:

citeproc-style-parse: Opening input file: Datei oder Verzeichnis nicht 
gefunden, /usr/share/emacs/27.1/etc/org/csl/chicago-author-date.csl

File or directory not found.

I tried to point 

#+csl_style: ~/Projekte/csl.styles/chicago-author-date.csl

but there is no change in the error message.

juh

Re: Bibliographies on export with ox-context and ox-epub

[Nicolas Goaziou]

Hello,

juh  writes:

> I fixed this, updated to the newest org but still no rendering in no
> format.
>
> Thanks to all.
>
> I will give up for the moment and maybe come back again later.

For the record, with the following test.bib file:

--8<---cut here---start->8---
@article{doe,
 author={org, mode and Syntax, Citation and List, Mailing and Effort, 
Time},
 journal={Journal of Plain Text Formats},
 title={Elegant Citations with Org-Mode},
 year={2021},
 month={7},
 volume={42},
 number={1}}
--8<---cut here---end--->8---

and the following document:

--8<---cut here---start->8---
#+title: Citation tests
#+cite_export: basic

#+bibliography: test.bib

[cite:@doe 45]

[cite/text:@doe 45]


#+print_bibliography: 
--8<---cut here---end--->8---

I get, when exporting to text ():

--8<---cut here---start->8---

 CITATION TESTS



(org, mode and Syntax, Citation and List, Mailing and Effort, Time, 2021
45)

org, mode and Syntax, Citation and List, Mailing and Effort, Time (2021
45)


org, mode and Syntax, Citation and List, Mailing and Effort, Time
(2021). /Elegant Citations with Org-Mode/, Journal of Plain Text
Formats.
--8<---cut here---end--->8---

If I change the second line to "#+cite_export: csl" instead, with the
external Citeproc Emacs library properly loaded, I get:

--8<---cut here---start->8---

 CITATION TESTS



(org et al. 2021, 45)

org et al. (2021, 45)


org, mode, Citation Syntax, Mailing List, and Time Effort. 2021.
“Elegant Citations with Org-Mode. J/o”urnal of Plain Text Formats/ 42
(1).
--8<---cut here---end--->8---

I tested with development Org, but I don't think it would change using
stable Org. Maybe someone wants to confirm this.

Regards,
-- 
Nicolas Goaziou

examples for org-manual

[General discussions about Org-mode.]

The org-manual could use more practical examples, in my opinion.
How does one submit suggestions/edits?

Re: Formal syntax for org-cite

[Nicolas Goaziou]

Hello,

Timothy  writes:

> Looking at https://orgmode.org/worg/dev/org-syntax.html, there isn't,

Yup, I forgot to update it.

> I have not yet confirmed what =KEYPREFIX= and =KEYSUFFIX= may contain,
> but as a starting point, any of the characters allowed in =KEY= except
> =@= plus whitespace would seem fairly safe. =KEYSUFFIX= must start with
> a whitespace character to be able to be differentiated from =KEY=.

KEYPREFIX may not contain a semicolon nor any combination forming a key
(at-sign followed by a word character or some symbols). Square brackets
are allowed only if they form a symmetric pair. Any other character is
allowed.

KEYSUFFIX has the same restrictions, minus the limitation about the key.

> =CITESTYLE= consists of a main =STYLE= and any number of =VARIANT=​s
> (including zero), prefixed by forwards slashes in the following pattern
>
> #+begin_example
> /STYLE/VARIANT/VARIANT/VARIANT
> #+end_example

Nope. This is only /STYLE/VARIANT, however VARIANT can contain "/" character.

> =STYLE= and =VARIANT= can be made of any alphanumeric character, =_=, or =-=.
>
> =GLOBALPREFIX= and =GLOBALSUFFIX= can contain the same characters as
> =KEYPREFIX= and =KEYSUFFIX=, however =GLOBALPREFIX= must end with a
> semicolon, and =GLOBALSUFFIX= must start with a semicolon.

Note the semicolons do not belong to affixes.

> "cite" and =CITESTYLE=, =KEYCITES= and =GLOBALSUFFIX= are /not/
> separated by whitespace. Neither are =KEYPREFIX=, =@KEY=, or =KEYSUFFIX=
> separated by whitespace.

Addendum: whitespaces are not significant after the leading colon, and
before the closing square bracket. They are significant in any other
case.

HTH,

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Fix org-comment-line-break-function

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> I see that comment-indent-new-line was added to emacs in newcomment.el back
> in 2000. So I don't know why org-comment-line-break-function was added. May
> be Nicolas can comment more on that.

Sorry, I do not remember.

As pointed out in the thread, this function probably wasn't meant to be
public in the first place. Now it is.

> So would this patch work?

Such a patch must be accompanied with tests.

Regards,
-- 
Nicolas Goaziou

Re: frustrations

[Eric S Fraga]

Hello Jan,

I've extracted the org relevant bit from your post.

On Wednesday,  1 Dec 2021 at 13:21, Jan Ulrich Hasecke wrote:
> How do you configure your emacs using current versions like org 9.5 but
> at the same time avoiding problems with incompatible packages or newly
> introduced bugs?

Well, first of all, I ensure that my load path is set before anything
else is done so that anything that might need org will cause org to be
loaded from the right place.  I have this line as the first line in my
.emacs:

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

where I have downloaded the most recent version of org into
~/git/org-mode.

Avoiding problems with incompatible packages or new bugs is impossible,
however.  The solution is to avoid upgrade-itis and only upgrade when
necessary.  Although I track org from git, I don't update all the time
and only do so when I know I will have some time to deal with any
repercussions.  (like today where I upgraded both Emacs and org because
I know I have no immediate deadlines)

Most other packages, I seldom upgrade if ever.

HTH,
eric

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: frustrations

[Timothy]

Hi Jan,

Not that I’m unsympathetic to your issues, however I must say that your email
seems to have little to do with Org, and this *is* the Org mailing list.

Perhaps you would be better served by something like emacs.stackexchange.com.

Jan Ulrich Hasecke  writes:

> Hi all,
>
> after happily using straight for quite a while I am currently frustrated by a
> couple of problems.
>
> In a different thread I asked about exporting citations, which does not
> work for me at all.
>
> Today I discovered that pamparam does not work anymore with an error
> message mentioned here:
> 
>
> Even to get to this error, as pamparam didn’t start at all, I had to
> manually fix something in worf.el
> 
>
> If I understand correctly, straight uses the bleeding of packages from
> github. Maybe this is not what I want. Maybe in the past I just was
> lucky not to hit a bug or an incompatible change.
>
> There are some more issues. Startup time of my emacs is more than 30
> seconds even after optimizing something with esup. I have 10.000+ files
> in my org-roam and fear that I hit some limitation either of org-roam or
> my hardware.
>
> How do you configure your emacs using current versions like org 9.5 but
> at the same time avoiding problems with incompatible packages or newly
> introduced bugs?
>
> In a few days I’ll get a new computer and I have serious doubt whether
> to copy my settings.org to the new one, because there are too many
> problems in the last couple of weeks.
>
> Any hints?
> TIA
> juh

All the best,
Timothy

Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

[Max Nikulin]

On 30/11/2021 19:54, Ihor Radchenko wrote:

Max Nikulin writes:


Ihor, thank you for your work related to such issues. I had a hope to
thank you for the fix, but I faced a warning again in a bit modified
scenario. This time it is soft indent mode.
...
First letter of new heading must be a capital one, though it can be
Latin. Converting top-level "H" heading by C-c C-* does not cause such
warning.


Well... I added yet another exception on main. Note that this special
case is also just in older Emacs versions.


Ihor, have you pushed the change? I still can reproduce the issue with 
Emacs-26.3


Next Ubuntu LTS is expected in April, upgrades will be enabled about 
September. As fallback (for the case of some intrusive changes that 
might be added by Canonical) I consider Debian and it has ~2 years 
release cycle as well.



(and I secretly hope that this kind of
patch will be implemented by someone else as a part of tree-sitter
integration).


A piece of friendly trolling: it would be tree-sitter module for Org syntax.


The most problematic
is the case triggered by self-insert-command, but it will not trigger
cache reset.


I mean namely this case of just typing text somewhere in a large file.

frustrations

[Jan Ulrich Hasecke]

Hi all,

after happily using straight for quite a while I am currently frustrated by a
couple of problems.

In a different thread I asked about exporting citations, which does not
work for me at all.

Today I discovered that pamparam does not work anymore with an error
message mentioned here:
https://github.com/nobiot/org-transclusion/issues/105

Even to get to this error, as pamparam didn't start at all, I had to
manually fix something in worf.el
https://github.com/leotaku/worf/commit/38e901d3888e3a245a5cba14a061bffa1c5fd20b

If I understand correctly, straight uses the bleeding of packages from
github. Maybe this is not what I want. Maybe in the past I just was
lucky not to hit a bug or an incompatible change. 

There are some more issues. Startup time of my emacs is more than 30
seconds even after optimizing something with esup. I have 10.000+ files
in my org-roam and fear that I hit some limitation either of org-roam or
my hardware.

How do you configure your emacs using current versions like org 9.5 but
at the same time avoiding problems with incompatible packages or newly
introduced bugs?

In a few days I'll get a new computer and I have serious doubt whether
to copy my settings.org to the new one, because there are too many
problems in the last couple of weeks.

Any hints?
TIA
juh

-- 
Autoren-Homepage: . http://literatur.hasecke.com
Satiren & Essays: . http://www.sudelbuch.de
Privater Blog:  http://www.hasecke.eu
Netzliteratur-Projekt:  http://www.generationenprojekt.de

Org babel and Guile/Scheme: noise from... Geiser?

[tomas]

Hi,

I'm trying to take some notes and explain things (to myself, to
others). So org babel it is, yay!

This is my first (well, second: `:results value' turned up empty):

  Blah, blah blah...

  #+name: mklst/define
  #+begin_src scheme
(define-syntax mklst
  (lambda (s)
(syntax-case s ()
  ((_ e ...) #'(list e ...)
  #+end_src

  More blah...

  #+name: mklst/test/0
  #+begin_src scheme :noweb yes :results drawer output
<>
(format #t "~S\n" (mklst 'a 22 "foo"))
  #+end_src

But alas, the result has some noise:

  #+RESULTS: mklst/test/0
  :results:
  (a 22 "foo")
  While executing meta-command:
  Wrong type to apply: #t
  scheme@(guile-user)>
  :end:

(the first line is the expected result; the two following ones I don't
know where they come from, and the third is, AFAICS, noises from Geiser
chewing in the background (org babel seems to start a Geiser session).

Is that intended behaviour?

For the moment, I excise all that noise by hand, but this doesn't scale:
the computer is faster at producing noise than me removing it ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [BUG] clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Colin Baxter ]

> Jeff Trull  writes:

> Confirmed, after updating org it now works! Thanks for your help.
> On Tue, Nov 30, 2021 at 1:07 AM Colin Baxter   wrote:

>> Hello Jeff
>> 
>> You clock table works for me, including your missing rate of
>> 150. I attach a screen shot.
>> 
>> By the way, you have a ":inherit-props t" which is not on the
>> #+BEGIN: clocktable line. I assume that has been corrupted in the
>> email formatting.
>> 
>> Best wishes
>> 
>> 

Excellent!

You might be interested in this post in

https://www.adventuresinwhy.com/post/org-mode-timekeeping/

It includes a formula for inserting the total billing amount in the
clock table, calculated from the hourly rate. It works very nicely.

Best wishes,

Re: [PATCH] Fix org-comment-line-break-function

[Marco Wahl]

Tim and all!

>> diff --git a/lisp/org.el b/lisp/org.el
>> index 1a1375461..fdeec0d67 100644
>> --- a/lisp/org.el
>> +++ b/lisp/org.el
>> @@ -19695,7 +19695,8 @@ non-nil."
>>(save-excursion (forward-char -1) (delete-horizontal-space))
>>(delete-horizontal-space)
>>(indent-to-left-margin)
>> -  (insert-before-markers-and-inherit fill-prefix))
>> +  (when fill-prefix
>> +(insert-before-markers-and-inherit fill-prefix)))
>>  
>> I don't have anything better.  I think this is a good patch.  It makes
>> M-j work again.
>>
>> Possible refinements and improvements can follow.
>>
>> +1 for applying of your patch.
>
> I was finally able to reproduce the error. It depends to some degree on
> the text in the buffer and where the cursor is when you hit M-j. Adding
> some additional text and moving the cursor to different locations
> enabled me to reproduce the error and I now agree it is a bug in
> org-comment-line-break-function.
>
> I don't know if your patch is the right fix or not because I don't
> understand what the purpose of insert-before-marks-and-inherit is - in
> fact, the doc string for that function doesn't even state what the @rest
> args argument is for, so I don't understand why it is passing in
> fill-prefix. For example, is it safe to assume
> insert-before-merks-and-inherit does not need to be called if
> fill-prefix is nil? Why is that function even called with the
> fill-prefix as an argument? 

Thanks for staying critical!

I can't answer your questions.  I agree that we should deepen the
understanding.  Your questions are a start.

Pragmatically I still vote for applying the patch immediately since it
is a step in the right direction AFAICS.


Ciao,
-- 
Marco

Re: Re-installing org-mode packages due to annoying message

[Alan E. Davis]

Perhaps I'll try it, just for fun.  I'm pretty happy with my layout and
theme, everything, but maybe I could get some ideas.

Thank you,
Alan

On Mon, Nov 29, 2021 at 7:39 AM Thomas S. Dye  wrote:

> Aloha Alan,
>
> Alan E. Davis  writes:
>
>
> > It is interesting that an old timer like yourself would reach
> > for
> > Spacemacs.  I haven't, mostly because I don't think I need the
> > modal model
> > of Vi.  The keybindings of Emacs or so convenient and
> > intelligent I find
> > them to be enough.  Here's where I might have spent more time in
> > the early
> > days learning the basics better.  One of the things I like about
> > Emacs is
> > that I can dance around a page of text, in a manner that the
> > commercially
> > produced text editors and word processors I know have not dared
> > to
> > implement.  We are locked in to a dumbed down interface in all
> > the software
> > we encounter.  I cannot think of one example just now, but maybe
> > the way
> > one can move back and forth over characters and words.  I never
> > learned Vi,
> > except to be able to edit a simple config file if need be.
> >
> > I know I am over my head, and I have been so for the 30-ish
> > years I have
> > been using Emacs and for the time I have used Org-mode.  It is
> > more than I
> > can do to keep up with the newer complexities that are cropping
> > up.  Yet,
> > just like the plain text files, and the LaTeX source for my one
> > publication, a lexicon of animal names, they live on while
> > documents using
> > the high priced tools are not longer readable or editable.  And
> > through all
> > the changes, my little utilities for editing things that only I
> > could
> > probably care about, and I would not expect anyone to care to
> > learn---they
> > still work today.  I love it!
> >
> FYI, from another old-timer in over his head, Spacemacs has a simple
> option to enable Emacs key bindings.  You don't need to use the modal
> bindings.
>
> hth,
> Tom
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>
>

-- 
  "As we enjoy great advantages from the inventions of others, we *should
be glad of an opportunity to serve others* by any invention of ours, and
this we should do freely and generously."   ---Benjamin Franklin

  "This ignorance about the limits of the earth's ability to absorb
   pollutants should be reason enough for caution in the release
   of polluting substances."
   ---Meadows et al.   1972.  Limits to Growth
.
(p. 81)

Re: [PATCH] Fix org-comment-line-break-function

[Richard Lawrence]

Tim Cross  writes:

> Well, that is the big question - why was
> org-comment-line-break-function added instead of just using the
> default comment-indent-new-line?

Looking back at commit d58d40f0c864ae3a6d7c66df34769619ad2486c1, I see
this comment was added by Nicolas (still in org.el):

;; `org-auto-fill-function' takes care of auto-filling. It calls
;; `do-auto-fill' only on valid areas with `fill-prefix' shadowed with
;; `org-adaptive-fill-function' value. Internally,
;; `org-comment-line-break-function' breaks the line.

which at least suggests ("Internally, ...") that
org-comment-line-break-function was never intended to be called to break
a comment via a user command like M-j, and was only intended to be
called during filling, in a context where fill-prefix would be set correctly.

In that case, the problem might be that org-setup-filling sets
comment-line-break-function to 'org-comment-line-break-function
(overriding the default value of 'comment-indent-new-line) "globally" in
Org buffers, causing it to be called even when fill-prefix is not
set correctly.

The documentation for (the variable) comment-line-break-function is a
bit confusing:

"Mode-specific function that line breaks and continues a comment.
This function is called during auto-filling when a comment syntax
is defined."

which also suggests that this function will only be called during
filling. But that is clearly not true (even if it once was), since
default-indent-new-line calls it directly.

So maybe org-comment-line-break-function was written under assumptions
that no longer hold?

It might also be worth pointing out here that
org-comment-line-break-function is *almost* a line-for-line copy of part of
default-indent-new-line, except the latter is more careful about
checking that fill-prefix is not nil before calling insert-* on it.

> Until this is determined, I think the only 'safe' approach would be to
> just advise those who are impacted by the M-j issue to set
> comment-line-break-function to comment-indent-new-line and then wait
> to see if someone who has more historical context to comment. 

This is a bit trickier than it sounds, because in Org buffers,
org-setup-filling calls

(setq-local comment-line-break-function 'org-comment-line-break-function)

which will override any global value for comment-line-break-function
(e.g. in your init file).  So you'd have to reset it in Org
buffers locally, via a hook that runs after org-setup-filling.

-- 
Best,
Richard

Re: [patch] fix ox-latex async export bug

[Rasmus]

Sébastien Miquel  writes:

> Rasmus Pank Roulund writes:
>>> This is most likely due to native compilation which compiles the
>>> unquoted lambda. Once compiled, it (presumably) fails to be passed to
>>> the external emacs process.
>> Ah, interesting.  Is this a bug or a feature?
>
> I think the bug's with org-mode. As I explain elsewhere in the thread,
> this lambda is to be treated as data, and written to a file to be
> executed by the external emacs instance. It should always have been
> quoted (naming it happens to work also).

Thanks. That makes sense.  I did wonder how those files worked (as the
lambdas are gibberish) when I was debugging the problem.

Rasmus

-- 
Bang bang

Org babel Python and R, table not transformed when :var is called ?

[Sébastien Rey-Coyrehourcq]

Hi there,

Perhaps it's a bug, or something i don't understand, i post on reddit 
(https://www.reddit.com/r/emacs/comments/r5yt4a/r_talking_with_python_using_orgtable_not_work/) 
to see if people on org community know the problem.


I cross post here to see if it's a know bug or somethings ?

There is something i don't understand,
a difference between behavior of org-babel and org-mode when you use org 
table to pass data using or not using :var.


|#+NAME:mypythoncode #+begin_src python :results value raw :output 
:return tabulate(df, headers=df.columns, tablefmt='orgtbl') import numpy 
as np import pandas as pd from tabulate import tabulate df = 
pd.DataFrame(np.random.randint(0,10,size=(10, 4)), columns=list('ABCD')) 
#+end_src #+RESULTS: mypythoncode | | A | B | C | D | 
|---+---+---+---+---| | 0 | 0 | 9 | 6 | 0 | | 1 | 2 | 9 | 0 | 4 | | 2 | 
9 | 6 | 0 | 1 | | 3 | 6 | 1 | 8 | 1 | | 4 | 4 | 2 | 1 | 4 | | 5 | 2 | 1 
| 1 | 1 | | 6 | 4 | 8 | 9 | 0 | | 7 | 1 | 4 | 8 | 7 | | 8 | 9 | 3 | 2 | 
5 | | 9 | 5 | 0 | 7 | 3 | #+NAME:lib-R #+HEADER: :var code=mypythoncode 
#+begin_src R :results output library(ggplot2) library(dplyr) 
library(lubridate) str(code) #+end_src #+RESULTS: lib-R : chr "| | A | B 
| C | D |\n|+-+-+-+-|\n| 0 | 8 | 0 | 5 | 2 |\n| 1 | 
2 | "| __truncated__ |


As you see, the org table is not recognized as a dataframe by R.

If i replace by a basic org table :

|||#+NAME: any_data | | parameter | value | |---+---+---| | 0 
| heats | 30 | | 1 | heats | 30 | #+NAME:lib-R #+HEADER: :var 
code=any_data #+begin_src R :results output library(ggplot2) 
library(dplyr) library(lubridate) str(code) #+end_src #+RESULTS: lib-R : 
'data.frame': 2 obs. of 3 variables: : $ X : int 0 1 : $ parameter: chr 
"heats" "heats" : $ value : int 30 30 |||


That works...

Best regards,

||



OpenPGP_0xD262AFCCE42732D3.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Ada/SPARK support in Babel

[Francesc Rocher]

Hi all,

I've started developing Babel support for Ada and SPARK languages.
I would like to include them in the main org-mode repository, as an
additional ("officially") supported language by org-mode.

Temporary development can be found at
https://github.com/rocher/ob-ada-spark/

For a new language to be included in the main org-mode repository, it
is required that the language:

  1. is supported by Emacs
  2. has a large user-base

IMMO both requirements are satisfied:

  1. ada-mode supports Ada (and, partially, SPARK)
  2. Ada appears in position 32 in the TIOBE rank of programming
 languages popularity (https://www.tiobe.com/tiobe-index/), above
 other languages supported by Babel like Julia, Clojure, Haskell,
 Scheme, awk, Forth, Ocaml or sed. (SPARK appears in the next 100)

Do you think that Ada/SPARK support should be included in the main
org-mode repository? Or in the org-contrib one?

BR,
-- Francesc Rocher