Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Dr. Arne Babenhauserheide

Juan Manuel Macías  writes:

> Joost Kremers writes:
>
>> Why not just use the term "Org markup"?  It's descriptive and should be
>> understandable to people familiar with the concept of markup languages.
>
> This. 'Org markup language' and 'Org Syntax' are obvious and natural
> terms that can easily be inferred from the Org manual. Honestly I don't
> see much point in coming up with new names for a concept which is
> already transparent and self-explanatory. It is something I find
> unnecessary and baroque.

Org markup and Org syntax sound good, I think. I’m unsure which is
better to convey that this includes features — that org-mode is much
more than just a way to encode some information, but a way to interact
with documents and an implementation of the syntax should keep that in
mind.

One thing that is important to keep: Org Syntax or Org Markup is
implementation-defined. You cannot claim *full compatibility*, if you
are not fully compatible with org-mode. This includes a lot of Emacs
features, like linking to arbitrary files/buffers/things, extending
links, and so on.

The minimal syntax (missing a lot of features) would be outline markup
or outline syntax (from outline-mode, the ancestor of org-mode).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature


Unwanted italics formatting between two URLs

2021-11-28 Thread Rafael Laboissière

Hello,

In an org-mode buffer, I have the following:

   [[https://first/-/url/][pre]] text [[https://second-url/?][post]]

The “pre” and “text” words appear (wrongly) in italics, as you can see in 
the attached screenshot. This misbehavior is certainly related to the 
presence of the characters “-” and “?” in the URLs.


I am using Org mode version 9.5.1 (release_9.5.1-11-g96d91b)

Best,

Rafael Laboissière


Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Marcin Borkowski


On 2021-11-28, at 23:25, Juan Manuel Macías  wrote:

> Hi,
>
> [...] For example: there is TeX (the typographic engine) and TeX
> (the programming language for that engine). And there has never been any
> conflict.

Quite the contrary.  The amount of confusion between TeX (engine)/TeX
(language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
novice/casual users has always been terrible.

Just my 2 cents,

-- 
Marcin Borkowski
http://mbork.pl



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

2021-11-28 Thread Timothy
Hi Tim,

> I’m wondering if this could be a problem when exporting to latex if the
>underlying latex process encounters errors and is waiting for user input before
>it can continue (which happens if there are problems in the tex source latex is
>trying to process)?
>
> It might be worth checking next time you encounter an error if you can
> run latex on the generated *.tex file and see if it waits for user
> input?

If you look at the default value of `org-latex-pdf-process', it has the flag
`-interaction=nonstopmode' which should mean the process never pauses and waits
for user input.

All the best,
Timothy


Re: [PATCH] Fix regex for determining image width from attribute

2021-11-28 Thread Timothy
Hi Matt,

> I also still don’t really like the behavior
> here. I don’t think it makes sense to interpret a width as 120% if we
> have something like
>
> #+attr_latex: :width 1.2

What would be a more sensible interpretation in your mind? The “true” value
depends on the number of columns, and fetching that information seems a bit
unreasonable. Since this isn’t just used if nothing else if given, I see a 120%
interpretation as fairly reasonable.

All the best,
Timothy


Re: org-tag-persistent-alist AND per-file dynamic tags

2021-11-28 Thread chris
On Saturday, 6 November 2021 10:10:55 CET Victor A. Stoichita wrote:
> Greetings to all,
> 
> Reading the manual about setting glopal/per-file tags [1], I wonder if
> it is possible to use org-tag-persistent-alist AND per-file
> dynamic tags.

I use footnote 53 from https://orgmode.org/manual/Setting-Tags.html[1].
I put my tags in `tags-file.org`, using `#+TAGS:`.
I've put the next two lines in `init.el`.

(setq org-agenda-files (list "~/path-to/tags-file.org")
 org-complete-tags-always-offer-all-agenda-tags t)

And I have completion on both the tags in `tags-file.org` and tags in the 
current buffer.
I don't use `org-tag-alist`, so the comments made in 
https://emacs.stackexchange.com/q/
69369#comment111307_69369[2], would not apply.

I use a script to collect the tags, based on Kitchin's 
https://stackoverflow.com/a/
27527252[3], and help from `#emacs`.
I use `with-temp-buffer` because otherwise all the files accessed by 
`org-map-entries` are 
showing when I do `C-x C-b` and I find it cumbersome.
The tags are sorted by frequency, which is not necessary here, but it's really 
nice.
I suppose you could put a `defun nice-function-name` on top of it, but so far, 
it's only a 
hack.
`~/path-to-directory` and `tags-file.org` should be tweaked to your needs. 
`default-
directory` can be used for the former, too.
(caveat: the script makes use of `-flatten`, `-map` and `-uniq, from `dash.el`. 
It also 
makes use of `mapcar` where `-map` would do, `seq-sort` where `-sort` would do, 
`seq-
reduce` where `-reduce` would do. Standard elisp has `flatten-tree`, for 
`-flatten`, 
`mapcar` for `-map`, `delete-dups` for `-uniq`. https://github.com/Droogans/
unmaintainable-code[4])

(let* ((dir "~/path-to-directory")
   (all-tags
(-flatten
 (-map
  (lambda (fpath)
(with-temp-buffer
  (insert-file-contents fpath)
  (org-mode)
  (org-map-entries
   (lambda ()
 (let ((tag-string (car (last (org-heading-components)
   (when tag-string
 (split-string tag-string ":" t nil nil)))
  (directory-files-recursively dir "^[^#].*org$")
  (let ((tags-count
 (cl-loop for tag in (-uniq all-tags)
  collect (cons tag (cl-count tag all-tags :test 'string=)
(let ((tags-list
   (mapcar 'car (seq-sort (lambda (a b) (< (cdr b) (cdr a))) 
tags-count
  (let ((tags-string
 (cl-reduce (lambda (a b) (concat a " " b)) tags-list)))
(let ((filled-tags-string
   (with-temp-buffer
 (setq fill-column 70
   fill-prefix "#+TAGS: ")
 (insert (concat "#+TAGS: " tags-string)) (fill-paragraph) 
(buffer-string
  (with-temp-file "tags-file.org" (insert filled-tags-string)))


> 
> When using org-set-tags-command, I’d like to select from a list
> comprising both:
> 1. the list of predefined tags in org-tag-persistent-alist
> 2. the list of all the tags that are already in use in the current
>buffer (some of which might not be in the persistent alist). I don’t
>want to use the #+TAGS keyword at file-level, just the list of tags
>already attached to some headline in the buffer.
> 
> The manual says:
> > If you have globally defined your preferred set of tags using the
> > variable org-tag-alist, but would like to use a dynamic tag list in
> > a specific file, add an empty ‘TAGS’ keyword to that file
> 
> And then it says:
> > If you have a preferred set of tags that you would like to use in every
> > file, in addition to those defined on a per-file basis by ‘TAGS’
> > keyword, then you may specify a list of tags with the variable
> > org-tag-persistent-alist.
> 
> I tried to combine both behaviors by putting an empty ’TAGS’ keyword at
> the top of my file. But this still only gives me the tags in
> org-tag-persistent-alist. What would be the best way to add to it for
> completion the tags already used in the buffer?
> 
> Regards,

Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Devin Prater
Or OrgMark. Simple, please no levels to show the amount of adherence to the
spec. OrgMark would symbolize the "markings" or syntax of Org-mode, and not
be close enough to Mark(down) to where people would think, like I did, that
this was Org-mode power given to a subset of Markdown to help, say,
Obsidian users come to Org-mode. No, I don't think we need that either.

Otherwise, I'm perfectly find with calling it Org. Just like Python, HTML,
all that. We don't say, in relaxed speech where the speaker assumes prior
known knowledge, or knowledge that can be easily filled in, "I'm writing a
book in Markdown markup language." We just say "I'm writing a book in
Markdown." And if the listener doesn't know what we mean, we can explain.
Devin Prater
r.d.t.pra...@gmail.com




On Sun, Nov 28, 2021 at 5:24 PM Jean-Christophe Helary <
li...@traduction-libre.org> wrote:

>
>
> > On Nov 29, 2021, at 7:57, Tom Gillespie  wrote:
> >
> > PS Another brainstormed name: Orgsyn?
>
> Org Agnostic Syntax Modules → OrgASM
>
> --
> Jean-Christophe Helary @brandelune
> https://mac4translators.blogspot.com
> https://sr.ht/~brandelune/omegat-as-a-book/
>
>
>


Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Juan Manuel Macías
Joost Kremers writes:

> Why not just use the term "Org markup"?  It's descriptive and should be
> understandable to people familiar with the concept of markup languages.

This. 'Org markup language' and 'Org Syntax' are obvious and natural
terms that can easily be inferred from the Org manual. Honestly I don't
see much point in coming up with new names for a concept which is
already transparent and self-explanatory. It is something I find
unnecessary and baroque.

Best regards,

Juan Manuel



Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Michael Ashton


> On Nov 28, 2021, at 6:22 PM, Jim Porter  wrote:
> 
> On 11/28/2021 11:46 AM, Karl Voit wrote:
>> At this year's EmascsConf, I had a 12 minute video where I explain why
>> we do need a different name for the syntax of Org-mode in contrast to
>> the Elisp implementation of GNU/Emacs Org-mode.
>> I would like you to read my rationale and motivate you to use the term
>> "Orgdown" for the syntax and "Orgdown1" for the first (very basic)
>> level of Orgdown syntax elements.
> 
> I agree that it's useful to distinguish the files/syntax from the *mode*, 
> which contains many functions for doing things with those files.
> 
> For what it's worth (perhaps not much), I've always referred to the 
> syntax/file format as simply "Org"; for example, "I put my notes into an Org 
> file." This is by analogy with most of the other Emacs major modes for 
> editing files. I write Python in `python-mode', I write C++ in `c++-mode', I 
> write text files in `text-mode', and so on.
> 
> Maybe "Org" isn't distinct enough though. People unfamiliar with Org-Mode 
> might confuse "Org" with "org charts" or some other use of the word. Still, 
> if we look to other tools that can read the same files as Org-Mode, they tend 
> to be called things like "Organice", not "Orgmodeanice". :)

Perhaps orgtext or org-text?




Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Jim Porter

On 11/28/2021 11:46 AM, Karl Voit wrote:

At this year's EmascsConf, I had a 12 minute video where I explain why
we do need a different name for the syntax of Org-mode in contrast to
the Elisp implementation of GNU/Emacs Org-mode.

I would like you to read my rationale and motivate you to use the term
"Orgdown" for the syntax and "Orgdown1" for the first (very basic)
level of Orgdown syntax elements.


I agree that it's useful to distinguish the files/syntax from the 
*mode*, which contains many functions for doing things with those files.


For what it's worth (perhaps not much), I've always referred to the 
syntax/file format as simply "Org"; for example, "I put my notes into an 
Org file." This is by analogy with most of the other Emacs major modes 
for editing files. I write Python in `python-mode', I write C++ in 
`c++-mode', I write text files in `text-mode', and so on.


Maybe "Org" isn't distinct enough though. People unfamiliar with 
Org-Mode might confuse "Org" with "org charts" or some other use of the 
word. Still, if we look to other tools that can read the same files as 
Org-Mode, they tend to be called things like "Organice", not 
"Orgmodeanice". :)


- Jim



Re: Is M-j broken for you in Org on Emacs 27 and 28?

2021-11-28 Thread Tim Cross


Richard Lawrence  writes:

> Colin Baxter   writes:
>
>> I confirm that it also appears broken to me in emacs-27.2, with the same
>> error as you found. I have never noticed it before, possibly because I
>> use C-j rather than M-j.
>
> Thanks for confirming. Do you know what the difference between C-j and
> M-j is "supposed" to be? They both do very mode-dependent things. I
> guess M-j is more explicitly aimed at continuing comments (which is
> probably why I started using it), but it has always worked great for me
> as a newline-and-indent-like-I-want command outside of comments too.

I'm running Emacs 28 and cannot reproduce the issue you observe. Running
emacs -Q I find M-j is bound to

M-j runs the command default-indent-new-line (found in global-map),
which is an interactive compiled Lisp function in ‘simple.el’.

It is bound to C-M-j, M-j.

(default-indent-new-line  SOFT FORCE)

Break line at point and indent.
If a comment syntax is defined, call ‘comment-line-break-function’.

The inserted newline is marked hard if variable ‘use-hard-newlines’ is true,
unless optional argument SOFT is non-nil.

This binding is the same inside and outside of org mode. This is with
org version

Org mode version 9.5 (release_9.5-72-gc5d6656 @ 
/usr/local/share/emacs/28.0.60/lisp/org/)

and Emacs version

GNU Emacs 28.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.16.0) of 2021-11-26

Note that C-j in org mode is different from 'normal' C-j in that it is
bound to org-return-and-maybe-indent. If you want M-j to act like C-j in
org mode, you would need to rebind M-j to org-return-and-maybe-indent in
an appropriate org mode startup hook. 



Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread George Mauer
Agree with Joost. If I remember correctly, the "down" part of markdown was
meant as a play on words to indicate that, unlike a proper markup language,
markdown has a direction and a value system but no defined standard. Since
org is definitely not that why must the waters? Just go for clarity.

On Sun, Nov 28, 2021, 17:30 Joost Kremers  wrote:

>
> On Sun, Nov 28 2021, Tom Gillespie wrote:
> > PS Another brainstormed name: Orgsyn?
>
> Why not just use the term "Org markup"?  It's descriptive and should be
> understandable to people familiar with the concept of markup languages.
>
> --
> Joost Kremers
> Life has its moments
>
>


Re: [PATCH] Fix regex for determining image width from attribute

2021-11-28 Thread Matt Huszagh
Max Nikulin  writes:

> I am confused. I can not figure out how to create the following as HTML 
> export result:
>
> 
>
> Attempt to add quotes leads to  and does not prevent ":width" to 
> become another attribute.
>
>#+attr_html: :alt An image without :width 600 attribute
>[[file:img.png]]
>
>
> 
>
> My current variant:
>
> ":\\(?:[^\n]*?[[:blank:]]\\)?:width[[:blank:]]+\\(\\S-+\\)"
>
> The regexp should not match e.g.
>
> #+attr_html: :alt something
> :width 600
>
> P.S. I would prefer to use the same parser as ox does.

(cadr par) contains all the attr_ keywords with their values. I think it
would be better to use this instead of doing a regex search, which I
expect would be slower and more prone to errors. If we want to be strict
(and probably more correct), we could use
org-export-registered-backends. Otherwise, we could look for any key
that starts with attr_.

I can probably implement this if people want. But, let me know if I
should indeed use org-export-registered-backends. However, I'm starting
to feel like this should be separate patch (the goal for mine was just
to prioritize attr_org). I also still don't really like the behavior
here. I don't think it makes sense to interpret a width as 120% if we
have something like

#+attr_latex: :width 1.2\columnwidth

Matt



Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Joost Kremers


On Sun, Nov 28 2021, Tom Gillespie wrote:
> PS Another brainstormed name: Orgsyn?

Why not just use the term "Org markup"?  It's descriptive and should be
understandable to people familiar with the concept of markup languages.

-- 
Joost Kremers
Life has its moments



Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Jean-Christophe Helary



> On Nov 29, 2021, at 7:57, Tom Gillespie  wrote:
> 
> PS Another brainstormed name: Orgsyn?

Org Agnostic Syntax Modules → OrgASM

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/




Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Tom Gillespie
> I believe (IMHO) that it does not make much sense to separately name the
> Org Mode syntax (as a markup language). That would only generate
> confusion among users.

This is unfortunately not the case. Conflating Org mode which is an Emacs
major mode with Org syntax is a major communication barrier that leads to
confusion for anyone trying to implement a tool based on Org syntax. For
example I couldn't just call my implementation of an org-mode-like package
for Racket "Org mode" because it is not an Emacs major mode. The absence
of a name for Org syntax hampers search and discovery. I'm happy to keep
using the multi-word term Org syntax, but I have found a practical need to
distinguish the surface syntax from the Emacs major mode to reduce
confusing for technical users. Best,
Tom

PS Another brainstormed name: Orgsyn?



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

2021-11-28 Thread Tim Cross


Nicolas Goaziou  writes:

> Hello,
>
> Rasmus  writes:
>
>> When I try to export documents asynchronously with ox-latex, I always get
>> a bug in the “org-export-processFOO” files. The last sexp is always 
>> something like this: 
>>
>> (funcall '# 
>> "test.tex")
>>
>> where the “#” and “’” are mixed around. This happens even with a very
>> simple ‘org-export-async-init-file’ just loading ELPA Org.
>>
>> This was previously reported here:
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00422.html
>>
>> Nicolas’ fix (replicated in this patch) seems to fix it.
>
> Applied. Thank you.
>
>> I don’t really understand why this bug happens to be honest.
>
> The patch is already an improvement, but the beast is still lurking,
> indeed.
>

Just a shot in the dark which might be completely misleading, but ...

I noticed a thread recently on emacs-devel which talked about one of the
problems with async calls in Emacs is that they cannot handle user input
correctly. All seems to work fine provided the async process being
generated doesn't try to wait for user input at some point. I'm
wondering if this could be a problem when exporting to latex if the
underlying latex process encounters errors and is waiting for user input
before it can continue (which happens if there are problems in the tex
source latex is trying to process)?

It might be worth checking next time you encounter an error if you can
run latex on the generated *.tex file and see if it waits for user
input?



Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Tim Cross


Karl Voit  writes:

> Hi Org-mode community,
>
> At this year's EmascsConf, I had a 12 minute video where I explain why
> we do need a different name for the syntax of Org-mode in contrast to
> the Elisp implementation of GNU/Emacs Org-mode.
>
> I would like you to read my rationale and motivate you to use the term
> "Orgdown" for the syntax and "Orgdown1" for the first (very basic)
> level of Orgdown syntax elements.
>
> - The EmacsConf21 talk: https://emacsconf.org/2021/talks/org-outside
> - Orgdown site: https://gitlab.com/publicvoit/orgdown (please contribute!)
> - My motivation article: https://karl-voit.at/2021/11/27/orgdown/
>   - This is the longer version of my 12 minute EmacsConf21 video.
> - My personal copy of the video: 
> https://tube.graz.social/w/bgJVfjPLQAoJwLJQZoo3Hu
>
>
> Just as a sneak preview (not as a replacement for my motivation article):
>
> Orgdown is and will be defined in a set of levels, starting with very
> basic Orgdown1 (or OD1 or O↓1 or ⧬1 - depending on your coolness
> factor of choice :-) )
>
> - OD1 → 
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org
> - OD2 → will be defined in future
> - OD3 → will be defined in future
> - ...
> - OD∞ = Org-mode (by definition)
>
> Any OD-level needs to be compatible with Org-mode as implemented in
> Elisp for GNU/Emacs Org-mode according to https://orgmode.org. Any ODx
> is a sub-set of the syntax elements of ODy (with y>x).
>
> With introducing a new term specific for the syntax, we do get the
> benefit of getting a better way to handle Org-mode support in
> 3rd-party tools such as listed on
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org
> (please extend!).
>
> Having a well-defined sub-set of Org-mode, I also do think that formal
> definitions of the Org-mode syntax will be easier to develop, starting
> with the very simple OD1 level.
>
> It would be awesome if we start referring to syntax support in
> 3rd-party tools with the corresponding OD levels.
>
> I want to emphasize that the goal of Orgdown is NOT and will never be
> something that is an alternative to our golden standard Org-mode. We
> will try hard not to get into the Markdown situation where you need to
> know the exact flavor of the markup in order to produce text.
>
> So far, the response was great at the conference and I do hope that
> this idea will get a life of its own, developing the standard further,
> bringing this magnificent lightweight markup to the digital world.
> This also eases some pain for users of GNU/Emacs when it comes to
> exchanging text-based data.
>

Hi Karl,

while I can appreciate the point you are making, I'm doubtful your
suggestion will gain the traction necessary to work. To me, it feels a
little like the frequent posts from RMS in the emacs-devel list where he
gets upset when people refer to Linux instead of GNU Linux. To some
extent, the distinction will be too subtle for many and often, it isn't
clear whether an issue is a syntax definition (orgdown) or an
implementation bug or just simply user misunderstanding.

Perhaps we just need a name for the markup syntax which doesn't actually
reference 'org' at all - it simply is the markup syntax which org
happens to use. A completely separate name might avoid confusion and
would make it very clear that the markup syntax is not org mode. Problem
is, naming is terribly difficult and I have no suggestions on what would
be a good name.

I have not yet viewed your video, but will certainly be doing so. Again,
agree with the sentiment of what your trying to do, just not convinced
it is compatible with basic human nature. 



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

2021-11-28 Thread Tim Cross


"Alan E. Davis"  writes:

> I have just spent an hour trying to figure out what's going on with ELPA, GNU 
> ELPA, NONGNU ELPA packages.  I am lost.
>
> A plethora of methods exist for installing org-mode and other packages; it is 
> unnecessary to list them, even if I could.
>
> I've been using Emacs and Org-mode for many years.  I am not interested in 
> spending an hour of my time to learn a new way to install
> something that has been working well for me.  I may not use org-mode with the 
> facility of a programmer who can whip off a quick utility
> in emacs lisp, but I have come to depend on the basic tools as a core of my 
> work flow.
>
> I have tried "use package",  but I would prefer something straightforward, 
> like just list-packages then install.  I don't understand how to
> set up my init file (dot emacs) for various package repos.  It was working, 
> that's all I needed.  Now I get a 5 second delay each time I use
> org-mode.  I cannot seem to find the information I need to fix this.  On 
> reddit, on emacs wiki, on this list, I cannot find the magic search
> term.  I see advice like "the maintainer has written a very clear explanation 
> of the issue" but,this very clear explanation does not help
> me understand what I need to do.
>
> I guess I need a formula, but I have cut and pasted two or three different 
> things into the top of my .init file.  Perhaps I need to start
> again, but my .init file has been taking root for nearly 30 years; it's 
> burned into my muscle memory.
>
> I hope I will never have to write another email like this to get help for 
> something that should be simple.  Maybe I will now have to install
> from git.  I think I am already too far out at sea to abandon the packages 
> approach.  I guess it serves me right for stepping off the
> beach.
>

Hi Alan,

sorry your feeling so frustrated. Unfortunately, in order to be able to
maintain org mode with the limited resources available, it has been
necessary to make some changes and as with most transitions, there can
be some rough bits to get through initially. In the long term, things
should actually be simpler with respect to org mode as there will be
no need to add any repositories to use org mode or the org contgrib
packages as they will be available in the default package.el
configuration (Emacs 28 has both GNU ELPA and the new NONGNU
repositories defined by default). 

It is difficult to provide you with any concrete help as you did not
include some important information in your message. Things which would
help include

- What Emacs version are you using? Emacs comes with org built-in, so if
  your running a reasonably recent version of Emacs, perhaps you don't
  actually need to install org at all?

- Do you use any org mode extensions or add on packages (those which are
  not part of org mode or the org mode contrib packages)?

- Is there a reason you need the latest version of org mode rather than
  just using the version which comes bundled in Emacs? Many people just
  stick with the version which is bundled with Emacs as it is stable and
  requires no additional installation steps.

- What is the annoying message you reference in the subject but failed
  to include in the body of your message? 

The good news is that while there are many different ways of installing
packages, you really don't need any of them except those that come with
Emacs. I don't use straight, eget, or any of the many other package
management solutions for Emacs. I use just package.el and use-package,
which works on top of package.el (it can use straight and other package
managers, but your not required to). This gives you exactly what you
want - M-x list-packages, from where you can just select the packages
you want to install and install them.

I would not advise installing from git. This will likely just make
things even more complicated as then you also need to make sure your
building from the right branch/tag - you don't want to run org from the
head of the main branch as this is the development branch, which is
likely not as stable as you want. 

Assuming you are running the current Emacs stable release (Emacs 27.2),
the only repository you have to add in your init file is the new nongnu
repository. You no longer require the orgmode.org/elpa repository. As
the GNU ELPA repository has been standard in Emacs for the last few
releases, you don't need to add anything in order to get the current org
mode. If you use some of the contrib packages, then you now need to
install the nongnu repository. This repository will be configured by
default for the next Emacs release (Emacs 28), but for versions prior to
that, you need to add https://elpa.nongnu.org/nongnu/ to the package
archives list. I have the following in my init.el file

(require 'package)

(setq package-archives '(("nongnu" . "https://elpa.nongnu.org/nongnu/;)
 ("elpa" . "https://elpa.gnu.org/packages/;)
 

Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Juan Manuel Macías
Hi,

I believe (IMHO) that it does not make much sense to separately name the
Org Mode syntax (as a markup language). That would only generate
confusion among users. Furthermore, 'Org Mode', as a whole, is already a
sufficiently recognized and popular name, even outside the GNU Emacs
community. A single name is best remembered. More than one name means
atomization. For example: there is TeX (the typographic engine) and TeX
(the programming language for that engine). And there has never been any
conflict.

On the other hand, drawing a dividing line between Org (a lightweight
markup language) and Org (a GNU Emacs major mode) as if both things
could exist separately is an illusory exercise. I mean, that the
Org's global experience is the fusion of both things. 

I migrated from Markdown to Org Mode a long time ago not because I was
looking for a new and best lightweight markup language but because Org
provides me with a complete and quite sophisticated and productive work
environment. An environment that includes, yes, its own syntax, but all
within Emacs, which is where makes sense. I do not know if it is an
emergent quality, but I see Org, in many ways (and with all its
synapses) as an interface for Emacs.

Best regards,

Juan Manuel 




Re: [org-cite] autoload oc processors?

2021-11-28 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> Is there any reason not to autoload the processors?

I am not sure about what you mean. Could you elaborate?

Regards,
-- 
Nicolas Goaziou



[org-cite] autoload oc processors?

2021-11-28 Thread Bruce D'Arcus
Is there any reason not to autoload the processors?

Bruce


Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Tom Gillespie
I had jokingly suggested "orgup" to have a more positive feeling (up
instead of down) than markdown. I'm not sure orgdown will be any more
confusing than some other name. It could imply a version of the org
syntax that uses markdown surface syntax, but it seems that that would
probably be called org flavored markdown by the existing conventions
in the markdown community. Best,
Tom



Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Bruce D'Arcus
On Sun, Nov 28, 2021 at 4:34 PM Jean-Christophe Helary
 wrote:
>
> Considering the total incompatibility between markdown and org-mode it does 
> not seem to me that ’orgdown’ is a useful name. It will only confuse people 
> and generate useless comments and counter-comments wherever org-mode syntax 
> is mentioned.

That was my thought as well.

Also, for symmetry, perhaps the name should include a hyphen; like "org-bar".

Bruce



Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Jean-Christophe Helary
Considering the total incompatibility between markdown and org-mode it does not 
seem to me that ’orgdown’ is a useful name. It will only confuse people and 
generate useless comments and counter-comments wherever org-mode syntax is 
mentioned.

Org-mode and its syntax bring users functions that are vastly superior to 
whatever markdown does, and we should not forget that markdown’s originator (at 
least the one who is still alive today) pretty much systematically despises 
free software and the free software movement on his blog…

Jean-Christophe Helary

> On Nov 29, 2021, at 4:46, Karl Voit  wrote:
> 
> Hi Org-mode community,
> 
> At this year's EmascsConf, I had a 12 minute video where I explain why
> we do need a different name for the syntax of Org-mode in contrast to
> the Elisp implementation of GNU/Emacs Org-mode.
> 
> I would like you to read my rationale and motivate you to use the term
> "Orgdown" for the syntax and "Orgdown1" for the first (very basic)
> level of Orgdown syntax elements.
> 
> - The EmacsConf21 talk: https://emacsconf.org/2021/talks/org-outside
> - Orgdown site: https://gitlab.com/publicvoit/orgdown (please contribute!)
> - My motivation article: https://karl-voit.at/2021/11/27/orgdown/
>  - This is the longer version of my 12 minute EmacsConf21 video.
> - My personal copy of the video: 
> https://tube.graz.social/w/bgJVfjPLQAoJwLJQZoo3Hu
> 
> 
> Just as a sneak preview (not as a replacement for my motivation article):
> 
> Orgdown is and will be defined in a set of levels, starting with very
> basic Orgdown1 (or OD1 or O↓1 or ⧬1 - depending on your coolness
> factor of choice :-) )
> 
> - OD1 → 
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org
> - OD2 → will be defined in future
> - OD3 → will be defined in future
> - ...
> - OD∞ = Org-mode (by definition)
> 
> Any OD-level needs to be compatible with Org-mode as implemented in
> Elisp for GNU/Emacs Org-mode according to https://orgmode.org. Any ODx
> is a sub-set of the syntax elements of ODy (with y>x).
> 
> With introducing a new term specific for the syntax, we do get the
> benefit of getting a better way to handle Org-mode support in
> 3rd-party tools such as listed on
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org
> (please extend!).
> 
> Having a well-defined sub-set of Org-mode, I also do think that formal
> definitions of the Org-mode syntax will be easier to develop, starting
> with the very simple OD1 level.
> 
> It would be awesome if we start referring to syntax support in
> 3rd-party tools with the corresponding OD levels.
> 
> I want to emphasize that the goal of Orgdown is NOT and will never be
> something that is an alternative to our golden standard Org-mode. We
> will try hard not to get into the Markdown situation where you need to
> know the exact flavor of the markup in order to produce text.
> 
> So far, the response was great at the conference and I do hope that
> this idea will get a life of its own, developing the standard further,
> bringing this magnificent lightweight markup to the digital world.
> This also eases some pain for users of GNU/Emacs when it comes to
> exchanging text-based data.
> 
> Thanks for your support here!
> 
> 
> -- 
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/




Re: Is M-j broken for you in Org on Emacs 27 and 28?

2021-11-28 Thread Richard Lawrence
Colin Baxter   writes:

> I confirm that it also appears broken to me in emacs-27.2, with the same
> error as you found. I have never noticed it before, possibly because I
> use C-j rather than M-j.

Thanks for confirming. Do you know what the difference between C-j and
M-j is "supposed" to be? They both do very mode-dependent things. I
guess M-j is more explicitly aimed at continuing comments (which is
probably why I started using it), but it has always worked great for me
as a newline-and-indent-like-I-want command outside of comments too.

-- 
Best,
Richard



Re-installing org-mode packages due to annoying message

2021-11-28 Thread Alan E. Davis
I have just spent an hour trying to figure out what's going on with ELPA,
GNU ELPA, NONGNU ELPA packages.  I am lost.

A plethora of methods exist for installing org-mode and other packages; it
is unnecessary to list them, even if I could.

I've been using Emacs and Org-mode for many years.  I am not interested in
spending an hour of my time to learn a new way to install something that
has been working well for me.  I may not use org-mode with the facility of
a programmer who can whip off a quick utility in emacs lisp, but I have
come to depend on the basic tools as a core of my work flow.

I have tried "use package",  but I would prefer something straightforward,
like just list-packages then install.  I don't understand how to set up my
init file (dot emacs) for various package repos.  It was working, that's
all I needed.  Now I get a 5 second delay each time I use org-mode.  I
cannot seem to find the information I need to fix this.  On reddit, on
emacs wiki, on this list, I cannot find the magic search term.  I see
advice like "the maintainer has written a very clear explanation of the
issue" but,this very clear explanation does not help me understand what I
need to do.

I guess I need a formula, but I have cut and pasted two or three different
things into the top of my .init file.  Perhaps I need to start again, but
my .init file has been taking root for nearly 30 years; it's burned into my
muscle memory.

I hope I will never have to write another email like this to get help for
something that should be simple.  Maybe I will now have to install from
git.  I think I am already too far out at sea to abandon the packages
approach.  I guess it serves me right for stepping off the beach.


Alan Davis

-- 
  "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: Timestamps

2021-11-28 Thread Nicolas Goaziou
Hello,

David Masterson  writes:

> Has the format for timestamps covering (say) a few hours changed?  The
> following is still possible with "C-c .", but (I think) it is not
> documented in the Org-Mode manual:
>
>   <2021-11-27 Sat 10:30-12:30>
>
> This seems to be the new standard:
>   <2021-11-27 Sat 10:30>--<2021-11-27 Sat 12:30>

Both are valid. Maybe the manual needs some clarification. Would you
want to tackle it?

Regards,
-- 
Nicolas Goaziou



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

2021-11-28 Thread Nicolas Goaziou
Hello,

Rasmus  writes:

> When I try to export documents asynchronously with ox-latex, I always get
> a bug in the “org-export-processFOO” files. The last sexp is always something 
> like this: 
>
> (funcall '# 
> "test.tex")
>
> where the “#” and “’” are mixed around. This happens even with a very
> simple ‘org-export-async-init-file’ just loading ELPA Org.
>
> This was previously reported here:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00422.html
>
> Nicolas’ fix (replicated in this patch) seems to fix it.

Applied. Thank you.

> I don’t really understand why this bug happens to be honest.

The patch is already an improvement, but the beast is still lurking,
indeed.

Regards,
-- 
Nicolas Goaziou



"Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Karl Voit
Hi Org-mode community,

At this year's EmascsConf, I had a 12 minute video where I explain why
we do need a different name for the syntax of Org-mode in contrast to
the Elisp implementation of GNU/Emacs Org-mode.

I would like you to read my rationale and motivate you to use the term
"Orgdown" for the syntax and "Orgdown1" for the first (very basic)
level of Orgdown syntax elements.

- The EmacsConf21 talk: https://emacsconf.org/2021/talks/org-outside
- Orgdown site: https://gitlab.com/publicvoit/orgdown (please contribute!)
- My motivation article: https://karl-voit.at/2021/11/27/orgdown/
  - This is the longer version of my 12 minute EmacsConf21 video.
- My personal copy of the video: 
https://tube.graz.social/w/bgJVfjPLQAoJwLJQZoo3Hu


Just as a sneak preview (not as a replacement for my motivation article):

Orgdown is and will be defined in a set of levels, starting with very
basic Orgdown1 (or OD1 or O↓1 or ⧬1 - depending on your coolness
factor of choice :-) )

- OD1 → 
https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org
- OD2 → will be defined in future
- OD3 → will be defined in future
- ...
- OD∞ = Org-mode (by definition)

Any OD-level needs to be compatible with Org-mode as implemented in
Elisp for GNU/Emacs Org-mode according to https://orgmode.org. Any ODx
is a sub-set of the syntax elements of ODy (with y>x).

With introducing a new term specific for the syntax, we do get the
benefit of getting a better way to handle Org-mode support in
3rd-party tools such as listed on
https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org
(please extend!).

Having a well-defined sub-set of Org-mode, I also do think that formal
definitions of the Org-mode syntax will be easier to develop, starting
with the very simple OD1 level.

It would be awesome if we start referring to syntax support in
3rd-party tools with the corresponding OD levels.

I want to emphasize that the goal of Orgdown is NOT and will never be
something that is an alternative to our golden standard Org-mode. We
will try hard not to get into the Markdown situation where you need to
know the exact flavor of the markup in order to produce text.

So far, the response was great at the conference and I do hope that
this idea will get a life of its own, developing the standard further,
bringing this magnificent lightweight markup to the digital world.
This also eases some pain for users of GNU/Emacs when it comes to
exchanging text-based data.

Thanks for your support here!


-- 
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/




Re: smart quotes and languages like en-gb

2021-11-28 Thread Nicolas Goaziou
Hello,

Rasmus  writes:

> I have noticed that smart quotes are not picked up for “long” languages,
> like “en-gb”, since smart quotes are defined for “short” languages, like
> “en”, in org-export-smart-quotes-alist.
>
> The attached patch is an attempt at remedying this.  Not sure if it is the
> best fix, though...

IMO, this is a bit of a kludge. 

"oc.el" parses language-region tags already, although it has not been
factored out as an independent function yet. See
`org-cite--get-note-rule'. Maybe moving this part to "org-macs.el" would
be a better solution.

WDYT?

Regards,
-- 
Nicolas Goaziou



Re: oc-biblatex too aggressive in replacing styles

2021-11-28 Thread Nicolas Goaziou
Hello,

Rasmus  writes:

> However, I think it is currently too aggressive in overwriting styles.

Ah?

> Could it perhaps accept any style that is given in
> ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only
> overwrite it if another style is explicitly specified in the file to be
> exported?

Isn't it the case already?

> Currently, the only way I have found that I can specify that I want to use
> biblatex-chicago is by issuing
>
> #+cite_export: biblatex chicago-authordate

If you need chicago-authordate style globally, you can set
`org-cite-export-processors' instead, e.g., to

  ((t biblatex "chicago-authordate"))

You are responsible, however, for requiring appropriate packages in the
document header (with `org-latex-packages-alist', for example).

Regards,
-- 
Nicolas Goaziou



Re: oc-biblatex too aggressive in replacing styles

2021-11-28 Thread Rasmus
"Bruce D'Arcus"  writes:

> On Sun, Nov 28, 2021 at 12:19 PM Bruce D'Arcus  wrote:
>>
>> On Sun, Nov 28, 2021, 12:04 PM Rasmus  wrote:
>>
>
>>> However, I think it is currently too aggressive in overwriting styles.
>>>
>>> Could it perhaps accept any style that is given in
>>> ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only
>>> overwrite it if another style is explicitly specified in the file to be
>>> exported?
>>
>> I raised a similar question awhile back, and am not sure the best approach.
>
> Here's Nicolas' response to my query, which I agree with, and which is
> consistent I think with what you are suggesting.
>
> https://lists.gnu.org/archive/html//emacs-orgmode/2021-10/msg00449.html
>
> Bruce

Thanks a lot for pointing me to that thread! 

Rasmus




smart quotes and languages like en-gb

2021-11-28 Thread Rasmus
Hi,

I have noticed that smart quotes are not picked up for “long” languages,
like “en-gb”, since smart quotes are defined for “short” languages, like
“en”, in org-export-smart-quotes-alist.

The attached patch is an attempt at remedying this.  Not sure if it is the
best fix, though...

Test file:

#+language: en-gb
"Foo"

Thanks,
Rasmus

-- 
Dung makes an excellent fertilizer
>From 44df143a60e035816bcf5a241631e48b9b0a487a Mon Sep 17 00:00:00 2001
From: Rasmus Pank Roulund 
Date: Sun, 28 Nov 2021 18:41:34 +0100
Subject: [PATCH] org-export-activate-smart-quotes: Support languages with
 hyphens.

Get smart-quotes from "en" for "#+language: en-gb".
---
 lisp/ox.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 98c9c1119..6f10112bb 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5688,8 +5688,9 @@ Return the new string."
  (lambda (match)
(or (plist-get
 	(cdr (assq (pop quote-status)
-		   (cdr (assoc (plist-get info :language)
-   org-export-smart-quotes-alist
+		   (cdr (cl-assoc (plist-get info :language)
+  org-export-smart-quotes-alist
+  :test (lambda (lang k) (string-match-p k lang))
 	encoding)
 	   match))
  s nil t)))
-- 
2.34.1



Re: oc-biblatex too aggressive in replacing styles

2021-11-28 Thread Bruce D'Arcus
On Sun, Nov 28, 2021 at 12:19 PM Bruce D'Arcus  wrote:
>
> On Sun, Nov 28, 2021, 12:04 PM Rasmus  wrote:
>
>> However, I think it is currently too aggressive in overwriting styles.
>>
>> Could it perhaps accept any style that is given in
>> ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only
>> overwrite it if another style is explicitly specified in the file to be
>> exported?
>
> I raised a similar question awhile back, and am not sure the best approach.

Here's Nicolas' response to my query, which I agree with, and which is
consistent I think with what you are suggesting.

https://lists.gnu.org/archive/html//emacs-orgmode/2021-10/msg00449.html

Bruce



Re: [oc-csl] org-cite-csl-styles-dir and default-directory

2021-11-28 Thread Bruce D'Arcus
On Sun, Nov 28, 2021, 11:25 AM Rasmus  wrote:

> One frustration with oc-csl.el is that is does not like relative dirs,
> which I guess is fine overall as one would probably store styles
> centrally, somewhere, similarly to LaTeX.
>
> However, one niece that would seem useful is to simply dump something
> relative to the org file (useful for e.g. a doc stored in git and compiled
> via docker).
>
> So it might be nice if oc-csl would look for style files in
> default-directory / command-line-default-directory?
>
> I haven’t been following the discussions closely so my apology if there’s
> a reason for not doing this.

Here's a recent thread; seems like they settled on a plan, but just
hasn't been implemented yet.

https://lists.gnu.org/archive/html/emacs-orgmode/2021-11/msg00066.html

Bruce



Re: oc-biblatex too aggressive in replacing styles

2021-11-28 Thread Bruce D'Arcus
On Sun, Nov 28, 2021, 12:04 PM Rasmus  wrote:

However, I think it is currently too aggressive in overwriting styles.
>
> Could it perhaps accept any style that is given in
> ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only
> overwrite it if another style is explicitly specified in the file to be
> exported?


I raised a similar question awhile back, and am not sure the best approach.

But to give some context:

The current styles in the core processors are designed for portability;
they are not natbib or biblatex or CSL styles, but org styles that can be
mapped to those targets in more-or-less consistent ways.

This is tricky to do, in part because of inconsistencies; in particular
between natbib and biblatex.

Which is to say, in some cases the style mappings might be enhanced or
modified.

But I agree there should be some kind to fallback, in particular for
biblatex, which has an insane amount of commands.

Bruce


oc-biblatex and biblatex substyles

2021-11-28 Thread Rasmus
Hi,

I wonder if oc-biblatex should support loading biblatex-derived libraries,
e.g. biblatex-chicago?

There’s a quite a few of these libraries:

   $ tlmgr search --global "biblatex-" | wc -l
 66

(This is somewhat overestimating the true number of “biblatex-*”
packages).

These libraries are typically nie because they are (i) easier to configure
than biblatex for a specific style and (ii) actually support some
\usepackage keywords that can’t be used by biblatex (e.g. ibidtracker for
biblatex-chicago).

Thus, it might be able to at least support

#+cite_export: biblatex-$SUBSTYLE

E.g. #+cite_export: biblatex-chicago.  But oc-biblatex would likely also
have to be able to pickup biblatex-* packages in
org-latex-(default-)packages-alist...

So maybe it’s a can of worms?

Rasmus

-- 
Enough with the blah blah!




oc-biblatex too aggressive in replacing styles

2021-11-28 Thread Rasmus
Hi,

Thanks for providing ox-biblatex.

It works very well and has replaced my local hacks for LaTeX
bibliographies.

However, I think it is currently too aggressive in overwriting styles.

Could it perhaps accept any style that is given in
‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only
overwrite it if another style is explicitly specified in the file to be
exported?

A bit like how ox-koma-letter looks for in-buffer changed values.

Currently, the only way I have found that I can specify that I want to use
biblatex-chicago is by issuing

#+cite_export: biblatex chicago-authordate

But this is a bit blunt as it overrules ‘org-cite-export-processors’ and
thus biblatex is used for e.g. text export (of course I can replicate
org-cite-export-processors with a macro that looks at the current export
backend).

(If you want I am happy to try to work on this)

Thanks,
Rasmus

Example:

See [cite/t:@OrgCitations]

#+bibliography: lit.bib

# only way to "actuallyhicago:
#+cite_export: biblatex chicago-authordate
* settings :noexport:
#+begin_src emacs-lisp
  (require 'oc-biblatex)
  ;; test 1:  style is gobbled 
  ;; (setq org-cite-biblatex-options "style=chicago-authordate, 
maxcitenames=2")
  ;; test 2:  style is gobbled
  ;; (setq org-latex-packages-alist '(("style=chicago-authordate, 
maxcitenames=2" "biblatex")))
  ;; test 3: biblatex and biblatex-chicago are both loaded
  ;; (setq org-latex-packages-alist '(("authordate" "biblatex-chicago")))
#+end_src


-- 
9000!




[oc-csl] org-cite-csl-styles-dir and default-directory

2021-11-28 Thread Rasmus
Hi there,

Congrats on oc.el!

I have had a chance to try it a bit and it is really nice to work with!

One frustration with oc-csl.el is that is does not like relative dirs,
which I guess is fine overall as one would probably store styles
centrally, somewhere, similarly to LaTeX.

However, one niece that would seem useful is to simply dump something
relative to the org file (useful for e.g. a doc stored in git and compiled
via docker).

So it might be nice if oc-csl would look for style files in
default-directory / command-line-default-directory?

I haven’t been following the discussions closely so my apology if there’s
a reason for not doing this.

Thanks,
Rasmus

Example file

See [cite/t:@OrgCitations]
#+bibliography: lit.bib
#+cite_export: csl chicago-author-date.csl

* setup :noexport:
#+name: setup env
#+begin_src sh
  wget 
https://raw.githubusercontent.com/citation-style-language/styles/master/chicago-author-date.csl
  cat >> lit.bib << EOF
  @article{OrgCitations,
   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},
   pages={2-3}}
  EOF
#+end_src

#+begin_src emacs-lisp
  (require 'oc-csl)
#+end_src

Make ~oc-csl~ use current folder.
It would be nice not to have to specify this. 
#+begin_src emacs-lisp
  (setq org-cite-csl-styles-dir default-directory)
#+end_src


-- 
What will be next?




[patch] fix ox-latex async export bug

2021-11-28 Thread Rasmus
Hi there,

When I try to export documents asynchronously with ox-latex, I always get
a bug in the “org-export-processFOO” files. The last sexp is always something 
like this: 

(funcall '# 
"test.tex")

where the “#” and “’” are mixed around. This happens even with a very
simple ‘org-export-async-init-file’ just loading ELPA Org.

This was previously reported here:

https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00422.html

Nicolas’ fix (replicated in this patch) seems to fix it.
I don’t really understand why this bug happens to be honest.

This happens both on my GNU/Linux system (Emacs v29) and my work Windows
PC (Emacs v28 or v29) [all pre-releases, obviously].

Thanks,
Rasmus

-- 
If you can mix business and politics wonderful things can happen!
>From be15ab50ef4cefc579f87766b21eaed7514379d1 Mon Sep 17 00:00:00 2001
From: Rasmus Pank Roulund 
Date: Sun, 28 Nov 2021 16:34:37 +0100
Subject: [PATCH] org-latex-export-to-pdf: Avoid using lambda function.

Fix "invalid-read-syntax '#'" when exporting asynchronously with
ox-latex.

See also previous bug report: https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00422.html
---
 lisp/ox-latex.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 409d92164..8187119ec 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3708,7 +3708,7 @@ Return PDF file's name."
   (let ((outfile (org-export-output-file-name ".tex" subtreep)))
 (org-export-to-file 'latex outfile
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  #'org-latex-compile)))
 
 (defun org-latex-compile (texfile  snippet)
   "Compile a TeX file.
-- 
2.34.1



Re: Is M-j broken for you in Org on Emacs 27 and 28?

2021-11-28 Thread Colin Baxter 
> Richard Lawrence  writes:

> Hi Org community, Some questions for those of you on Emacs 27 and
> 28:

> Does M-j in an org-mode buffer do what you expect?  Does it throw
> an error?  What function is M-j bound to in Org?

> Backstory:

> I have long been on Emacs 26.3 (in Debian stable) but recently
> decided to try a newer Emacs from GNU Guix. I immediately ran into
> an issue, and now I'm trying to figure out if it's a bug, and if
> so where to file it: in both Emacs 27.2 and 28.0.50, typing M-j in
> an Org buffer throws (wrong-type-argument char-or-string-p nil)

> The source of this problem appears to be that the keybinding for
> M-j changed between Emacs 26 and 27. In Emacs 26 it calls
> indent-new-comment-line. In Emacs 27 and 28 it calls
> default-indent-new-line, and the call stack look like:

>   insert-before-markers-and-inherit(nil)
> org-comment-line-break-function(nil) default-indent-new-line()
> funcall-interactively(default-indent-new-line)
> call-interactively(default-indent-new-line nil nil)
> command-execute(default-indent-new-line)

> The error arises because insert-before-markers-and-inherit cannot
> accept nil (the value of fill-prefix in this context).

> I see this error in emacs -q with both Emacs 27 and 28 from Guix.

> After some investigation, the functions involved here don't appear
> to have changed at all recently (though see [1]); just the
> binding. This leads me to ask: why hasn't this been discovered
> already? Which leads me to wonder if I am using M-j in some
> non-standard way.

> Some time in the distant past, I internalized the idea that M-j is
> a better way to type a newline because (a) it doesn't involve a
> pinky reach and (b) in most contexts in Emacs, it is more likely
> to "do what I mean" than RET is. In particular, it continues
> comments and indents properly. (I am also an evil-mode user and
> there is probably some part of my brain that thinks "M-j is like j
> for insert mode".) But maybe that was always wrong, and the
> recently changed binding is just an indication that I was not
> using M-j as intended.

> So which is it? Is this a bug in Emacs, in Org, or in my ingrained
> typing habits? Many thanks for your advice.

> -- Best, Richard

> [1] There is a commit which changed default-indent-new-line in
> August of this year, but the changes don't seem relevant to the
> error I'm seeing, since I also see it in Emacs 27.2:

> 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b41f31d2b60269bd0e7addd1081f3738f91e76bc

I confirm that it also appears broken to me in emacs-27.2, with the same
error as you found. I have never noticed it before, possibly because I
use C-j rather than M-j.

Best wishes,



Re: Is M-j broken for you in Org on Emacs 27 and 28?

2021-11-28 Thread Greg Minshall
Richard,

i also see an error message when entering M-j running:
: emacs -Q foo.org

cheers, Greg


Org mode version 9.5 (9.5-gced2b3 @ /home/minshall/.emacs.d/straight/build/org/)

GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27,
cairo version 1.17.4) of 2021-03-26



Re: Unintended consequences of removing org-speed-commands-user

2021-11-28 Thread dal-blazej


Hi,

If you want to insert a new element in the list after a particular
element, you could do :

#+begin_src emacs-lisp 
(let ((bk (cdr (member '("Agenda Views etc") org-speed-commands
  (setf (cdr (member '("Agenda Views etc") org-speed-commands))
(cons '("@" . my-foobarized-speed-command) bk)))
#+end_src

Use append to insert a list of new elements instead of one.

Also simply add a new list at the end, use append :

#+begin_src emacs-lisp :results code
(setq org-speed-commands 
  (append org-speed-commands '(("my foo commands!")
   ("@" . my-foobarized-speed-command)
   ("&" . my-barfooized-speed-command
#+end_src

However if you define many new commands, simply redefining the whole
list is simpler ;)



org-agenda-filter-by-tag doco

2021-11-28 Thread Phil Hudson
I'd like to expand the docstring of command `org-agenda-filter-by-tag`
to document the Elisp equivalent of interactive prefix arguments. By
trial and error and guesswork I determined that I could emulate `C-u
C-u` by passing `'(16)` as the second argument
(`strip-or-accumulate`). I'd like to add text explaining this,
generalized to all prefix combinations.

I just thought I'd mention it on the list first, to get any thoughts
and advice that might be useful. For instance, currently there is a
paragraph for each prefix combination (`C-u`, `C-u C-u` and `C-u C-u
C-u`). Should I add Elisp calling doco to each, or should I expand the
subsequent paragraph that deals specifically with Elisp calling? I
tend to favor the latter as least confusing, but that might be a
matter of convention or opinion that others are better qualified to
comment on.

A further point: I already knew from prolonged usage that `C-u`
combinations evaluate numerically as powers of 4, but a newbie might
not. Should we explain this? I don't think it would be appropriate,
but again I'm open to advice. If not, should we at least link to the
explanation in the Elisp manual? I know we don't usually bother, but
since outcomes differ substantively in this case, maybe we should
here.



Is M-j broken for you in Org on Emacs 27 and 28?

2021-11-28 Thread Richard Lawrence
Hi Org community,

Some questions for those of you on Emacs 27 and 28:

Does M-j in an org-mode buffer do what you expect?
Does it throw an error?
What function is M-j bound to in Org?

Backstory:

I have long been on Emacs 26.3 (in Debian stable) but recently decided
to try a newer Emacs from GNU Guix. I immediately ran into an issue,
and now I'm trying to figure out if it's a bug, and if so where to file
it: in both Emacs 27.2 and 28.0.50, typing M-j in an Org buffer throws
(wrong-type-argument char-or-string-p nil)

The source of this problem appears to be that the keybinding for M-j
changed between Emacs 26 and 27. In Emacs 26 it calls
indent-new-comment-line. In Emacs 27 and 28 it calls
default-indent-new-line, and the call stack look like:

  insert-before-markers-and-inherit(nil)
  org-comment-line-break-function(nil)
  default-indent-new-line()
  funcall-interactively(default-indent-new-line)
  call-interactively(default-indent-new-line nil nil)
  command-execute(default-indent-new-line)

The error arises because insert-before-markers-and-inherit cannot accept
nil (the value of fill-prefix in this context).

I see this error in emacs -q with both Emacs 27 and 28 from Guix.

After some investigation, the functions involved here don't appear to
have changed at all recently (though see [1]); just the binding. This
leads me to ask: why hasn't this been discovered already? Which leads
me to wonder if I am using M-j in some non-standard way.

Some time in the distant past, I internalized the idea that M-j is a
better way to type a newline because (a) it doesn't involve a pinky
reach and (b) in most contexts in Emacs, it is more likely to "do what I
mean" than RET is. In particular, it continues comments and indents
properly. (I am also an evil-mode user and there is probably some part
of my brain that thinks "M-j is like j for insert mode".) But maybe that
was always wrong, and the recently changed binding is just an indication
that I was not using M-j as intended.

So which is it? Is this a bug in Emacs, in Org, or in my ingrained
typing habits? Many thanks for your advice.

-- 
Best,
Richard

[1] There is a commit which changed default-indent-new-line in August of
this year, but the changes don't seem relevant to the error I'm seeing,
since I also see it in Emacs 27.2:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b41f31d2b60269bd0e7addd1081f3738f91e76bc



Re: [BUG] org-element--cache: unregistered buffer modifications warning when using org-toggle-heading and org-toggle-item on lines beginning with capital letters [9.6 (9.6-??-d4e1925 @ /home/pete/.ema

2021-11-28 Thread Ihor Radchenko
Peter Williams  writes:

> This is my first time sending mail to the list so let me know if I
> breach any convention.
> ...
> # Cause the Warning
> S R Ξ A S2 X こ T 漢字 Д Ԋ ಱ Ѷ
> # No Problems (= R= is single use)
> 힡 ℤ / s S R nA 漢字 2S _W /W s こ 2 @ _

Welcome and thank you very much for the detailed report. It's really
thorough :)

> I seem to be one of many people who have been having issues with
> org-element--cache recently. I have been getting the messages quite
> regularly in many different cases, but I finally pinpointed one of the
> apparent causes: running org-toggle-heading, org-toggle-item, and
> probably other org functions that modify the structure of the org document
> on a line beginning with a capital letter from a language (not special
> font/mathematical characters, but not limited to the Latin alphabet).

This has been fixed in faf8ce7de. Can you update to latest main and let
us know if you are still seeing the problem?

Best,
Ihor



[BUG] org-element--cache: unregistered buffer modifications warning when using org-toggle-heading and org-toggle-item on lines beginning with capital letters [9.6 (9.6-??-d4e1925 @ /home/pete/.emacs.d

2021-11-28 Thread Peter Williams
This is my first time sending mail to the list so let me know if I
breach any convention.

I seem to be one of many people who have been having issues with
org-element--cache recently. I have been getting the messages quite
regularly in many different cases, but I finally pinpointed one of the
apparent causes: running org-toggle-heading, org-toggle-item, and
probably other org functions that modify the structure of the org document
on a line beginning with a capital letter from a language (not special
font/mathematical characters, but not limited to the Latin alphabet).

I expected to run org-toggle-heading, the line to be converted into a
heading, and no error messages to be thrown.

While the line was properly toggled into a heading, there was a cache
warning that said the following:

Warning (emacs): org-element--cache: Unregistered buffer modifications
detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing
list (M-x org-submit-bug-report).
The buffer is: cachebug.org
 Current command: nil
 Backtrace:
"  backtrace-to-string(nil)
  org-element--cache-sync(#)
  apply(org-element--cache-sync #)
  timer-event-handler([t 0 0 59 nil org-element--cache-sync (#) idle 99])
"
Here are the contents of the buffer showing the things I tested.


# Cause the Warning
S
R
Ξ
A
S2
X こ
T 漢字
Д
Ԋ
ಱ
Ѷ
# No Problems (= R= is single use)
힡
ℤ
/
s S
 R
nA
漢字
2S
_W
/W
s
こ
2
@
_





Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
 of 2020-09-19
Package: Org mode version 9.6 (9.6-??-d4e1925 @
/home/pete/.emacs.d/.local/straight/build-27.1/org/)

current state:
I deleted all settings with no mention of 'cache' because my email client
seemed to be having issues with the length of my message.
==
(setq
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 )