Re: BUG?: Are TAGs case sensitive? ('org-agenda-show-tags')

[Ihor Radchenko]

> Is it a bug that 'org-agenda-show-tags' does this?

It is a bug. Agenda is downcasing all the tags. Also, see
https://orgmode.org/list/87k0rftf8t.fsf@localhost/

Someone needs to study the agenda code to understand the need of
downcasing and how to remove it safely. Patches are welcome.

Best,
Ihor

David Masterson  writes:

> David Masterson  writes:
>
>> I have been using upper-case TAGs and just noticed that
>> 'org-agenda-show-tags' is reporting them in lower-case which is not
>> right since I have another TAG that is the lower-case version of the
>> upper-case TAG (sort of a visual importance indicator).
>
> In case my wording wasn't good, I meant:
>
> 1. I have upper case tags attached to several task headers,
> 2. 'org-agenda-show-tags' reports them as lower case tags.
> 3. I have unused tags in 'org-tag-alist' that are the lower case forms
> of the upper case tags (as well as the upper case ones)
>
> Is it a bug that 'org-agenda-show-tags' does this?
>
> -- 
> David Masterson

Re: When auto-fill breaks a link into multiple lines, the link is no longer displayed as a link

[Yukio Siraichi]

Hi Bastien.

I'm also having the same issue here.

Emacs: GNU Emacs 27.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.5) of 2021-04-16
Package: Org mode version 9.4.4 (release_9.4.4 @ 
/home/user/.local/share/emacs/27.2.50/lisp/org/)


I've been able to reproduce with 'emacs -Q' (file is attached).
Apparently, whether emacs can display the link correctly or not depends 
on the number of characters before breaking the link with a newline.
If you remove one character before the newline, it works as expected. If 
you 'C-c C-l' in the link, it also works as expected until you close the 
file and open again, which goes back to not working.


Am I missing anything?

--

Yukio

.Arbitrary 497 characters before the newline in the middle of the 
link...
[[h][The link
here]]

[PATCH] org-table-import: Give option to import interactively even if filename doesn't match

[Utkarsh Singh]

Hi,

Can we give small flexibility in choosing the filename interactively for
`org-table-import'?  Currently org-table-import will just throw an error
when file name doesn't have .txt, .csv or .tsv as extension.

This patch tries to add a simple yes-and-no to let user choose if they
want to continue importing or not.

diff --git a/lisp/org/org-table.el b/lisp/org/org-table.el
index 0e93fb271f..ab66859d6a 100644
--- a/lisp/org/org-table.el
+++ b/lisp/org/org-table.el
@@ -938,7 +938,8 @@ org-table-import
 - regexp  When a regular expression, use it to match the separator."
   (interactive "f\nP")
   (when (and (called-interactively-p 'any)
-(not (string-match-p (rx "." (or "txt" "tsv" "csv") eos) file)))
+(not (string-match-p (rx "." (or "txt" "tsv" "csv") eos) file))
+ (not (yes-or-no-p "File doesn't have .txt, .tsv or .csv as 
extension.  Do you still want to continue? ")))
 (user-error "Cannot import such file"))
   (unless (bolp) (insert "\n"))
   (let ((beg (point))

-- 
Utkarsh Singh
http://utkarshsingh.xyz

[PATCH] org.el (org-show-context-detail): add option 'ancestors-with-entry

[Cheong Yiu Fung]

Hi, I'm proposing a new option in `org-show-context-detail', which shows
current headline, its ancestors, *and the entry itself*. This is useful
when export matched subtrees and their contents quickly with least
manual intervention.

Consider when working on different aspects of a project and taking notes
as we go:

* Project
A project tree
** Task1
** Task2
*** ASK Something to align
Something for discussion
** Task3
** Task4
*** ASK Something else to align
Something else.

At some point, we may wish to export only certain contents. For example,
to export headings with TODO keyword of "ASK", along with the task
context (ancestors TASK heading name), and their own content for
discussion with colleagues. Ideally, this can be done by
org-sparse-tree, followed by org-export with visible-only + subtree-only
option.

Expected output:
* Project
** Task2
*** ASK Something to align
Something for discussion
** Task4
*** ASK Something else to align
Something else.

Current options, though, either require manual expansion to show both
ancestors AND entry, which becomes tedious soon;

* Project
** Task2
*** ASK Something to align
** Task4
*** ASK Something else to align

or it shows extra contents (`local' will include the *next* heading, in
this example, the non-related Task3)

* Project
*** ASK Something to align
Something for discussion
** Task3
*** ASK Something else to align
Something else.

`ancestor-with-entries' is a long name that pose some difficulties to
updating documentations, so I wish to have some feedbacks before moving
on. Is there better way to achieve this effect? Am I overlooking
something?

Yiufung

>From 38703eace6062ec4e4ccdf1912a641b266efbf61 Mon Sep 17 00:00:00 2001
From: Cheong Yiu Fung 
Date: Fri, 16 Apr 2021 18:35:17 +0800
Subject: [PATCH] org.el (org-show-context-detail): add option
 'ancestors-with-entry

* lisp/org.el: Add option 'ancestors-with-entry to
`org-show-context-detail', which shows current headline, entry, and
its direct ancestors.
---
 lisp/org.el | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 675a614e2..0e625d9ed 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1240,6 +1240,7 @@ more context."
 			   (const minimal)
 			   (const local)
 			   (const ancestors)
+   (const ancestors-with-entry)
 			   (const lineage)
 			   (const tree)
 			   (const canonical))
@@ -6763,7 +6764,7 @@ DETAIL is either nil, `minimal', `local', `ancestors', `lineage',
 information."
   ;; Show current heading and possibly its entry, following headline
   ;; or all children.
-  (if (and (org-at-heading-p) (not (eq detail 'local)))
+  (if (and (org-at-heading-p) (not (memq detail '(local ancestors-with-entry
   (org-flag-heading nil)
 (org-show-entry)
 ;; If point is hidden within a drawer or a block, make sure to
@@ -6775,14 +6776,14 @@ information."
   (org-with-limited-levels
(cl-case detail
 	 ((tree canonical t) (org-show-children))
-	 ((nil minimal ancestors))
+	 ((nil minimal ancestors ancestors-with-entry))
 	 (t (save-excursion
 	  (outline-next-heading)
 	  (org-flag-heading nil)))
   ;; Show all siblings.
   (when (eq detail 'lineage) (org-show-siblings))
   ;; Show ancestors, possibly with their children.
-  (when (memq detail '(ancestors lineage tree canonical t))
+  (when (memq detail '(ancestors ancestors-with-entry lineage tree canonical t))
 (save-excursion
   (while (org-up-heading-safe)
 	(org-flag-heading nil)
-- 
2.31.0

Re: Improving org-macro.el

[Nicolas Goaziou]

Hello,

Stefan Monnier  writes:

> In any case, the code struck me as quite inefficient since it
> reparses the macro definition every time the macro is called.

Indeed.

> I came up with the tentative patch below.

Thank you.

> It seems to work on Org's own manual, but other than that I haven't gone
> out of my way to test it.

There were a few problems reported by the test suite that I tried to
address. I also updated `org-lint', which didn't handle macro
definitions as functions.

> - It also changes the behavior when $N appears elsewhere than an
>   "expression context".  E.g.:
>
>   #+macro:  (eval (let (($1 foo)) (bar)))

This is not a valid macro definition anyway since placeholders are
strings.

>   #+macro:  (eval (fun-with "code $1"))

I don't think this was valid previously either, for the same reason.

> I don't think it requires changes to the manual because the semantics
> described in the manual is sufficiently incomplete that both the old and
> the new semantics satisfy it.

One noticeable effect is that empty or missing placeholders in macro
call are now nil, instead of the empty string. This broke our internal
macros (e.g., {{{n}}} and {{{property}}}) so I updated them.

I mentioned it in the ORG-NEWS file, and applied your changes. We'll see
how it goes.

Regards,
-- 
Nicolas Goaziou

Re: [Patch] to correctly sort the items with emphasis marks in a list

[Maxim Nikulin]

Hi Juan,

On 16/04/2021 01:21, you wrote:

#+begin_src emacs-lisp :tangle list-var.el
   (message "%S" (sort '("-\s\sv" "-\sv" "-\sa" "-\s\sa")
#'string-collate-lessp))
#+end_src

#+begin_src sh
exec 2>&1
LC_ALL=en_US.UTF-8 emacs --batch -Q -l list-var.el
#+end_src

#+RESULTS:
: -  a" "- a" "-  v" "- v

#+begin_src sh
exec 2>&1
LC_ALL=es_ES.UTF-8 emacs --batch -Q -l list-var.el
#+end_src

#+RESULTS:
: -  a" "-  v" "- a" "- v


You have managed to convince me that despite my first suspects the 
locale on your computer is correct. It is unexpectedly correct and it is 
more correct that most of locales in libc.


However I do not have opinion concerning you patch yet. I have not 
realized what is the proper way to sort list.


Space is significant. At least it may be. Only a few languages have got 
such fix, Spanish is among them 
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hp=d17612f6726d0c098ac981e06f3702106540bb23;hb=159738548130d5ac4fe6178977e940ed5f8cfdc4;hpb=ce6636b06b67d6bb9b3d6927bf2a926b9b7478f5


Notice "collating-symbol "

I have found example of sorting names in a language where woman surname 
usually have additional "a" in comparison to man surname.


printf "Ivanova Alla\nIvanov Adam\nIvanova Svetlana\n" \
  | LANG=pl_PL.UTF-8 sort
Ivanov Adam
Ivanova Alla
Ivanova Svetlana

es_ES behavior is just as the above example.

printf "Ivanova Alla\nIvanov Adam\nIvanova Svetlana\n" \
  | LANG=en_US.UTF-8 sort
Ivanova Alla
Ivanov Adam
Ivanova Svetlana

Ukrainian sort works better than Russian one with such example:

printf "Иванова Алла\nИванов Адам\nИванова Светлана\n" \
  | LANG=uk_UA.UTF-8 sort
Иванов Адам
Иванова Алла
Иванова Светлана

printf "Иванова Алла\nИванов Адам\nИванова Светлана\n" \
  | LANG=ru_RU.UTF-8 sort
Иванова Алла
Иванов Адам
Иванова Светлана

Man names are sorted first in such lists. Other cases might exist when 
significant space is undesired.


So sorting is tricky than I expected.

Re: Is it possible to #+include: src blocks and tangle them too?

[Greg Minshall]

Rama,

one other comment/suggestion.

> I haven’t been able to fully work with Donald Knuth’s suggestion of
> writing a Literate Program directly in a tool like orgmode/noweb since
> it is a nuisance to keep having to type C-c ' to go into the editing
> mode of the language concerned.

while i have not much experience with it, you might look at the emacs
packages polymode, poly-org, and poly-whatever-other-languages-you-use.
it seems as if they might give you [C-c ']-like behavior when editing
source blocks in line in an org mode buffer.

(others who use polymode: does this make sense?)

cheers, Greg

Re: [Patch] to correctly sort the items with emphasis marks in a list

[Maxim Nikulin]

On 16/04/2021 21:59, Maxim Nikulin wrote:

Ukrainian sort works better than Russian one with such example:

printf "Иванова Алла\nИванов Адам\nИванова Светлана\n" \
   | LANG=uk_UA.UTF-8 sort
Иванов Адам
Иванова Алла
Иванова Светлана

printf "Иванова Алла\nИванов Адам\nИванова Светлана\n" \
   | LANG=ru_RU.UTF-8 sort
Иванова Алла
Иванов Адам
Иванова Светлана


Sorry, I forgot to generate uk_UA locale so simple ordering were applied 
without ignoring of spaces in the shared part of locale definitions.


printf "Иванова Алла\nИванов Адам\nИванова Светлана\n" \
  | LANG=uk_UA.UTF-8 sort
Иванова Алла
Иванов Адам
Иванова Светлана

So only pl_PL and es_ES have significant spaces

 ;IGNORE;IGNORE;

vs.

 IGNORE;IGNORE;IGNORE; % SPACE

in iso14651_t1_common

Re: Repository of Org files with important dates?

[Eric S Fraga]

If you want solar based information (equinox, solstice, etc.), which is
not quite what you mentioned, I used this script to generate org file
headings:

#+begin_src shell :results output raw
  tmpfile=$(mktemp /tmp/date.XX)
  for year in $(seq 2018 2068)
  do
  links http://aa.usno.navy.mil/seasons?year=${year} -dump | \
  grep -E 'helion|quinox|olstice' > ${tmpfile}
  while read -r line
  do
  item=$(echo $line | awk '{print $1}')
  date="$(echo $line | awk '{print $5 " " $4 " " $3}') ${year}"
  isodate=$(date --date="${date}" +"%Y-%m-%d %H:%M")
  echo "** <${isodate}> $item"
  done < ${tmpfile}
  done
  rm ${tmpfile}
#+end_src

This script assumes "links" is available but is otherwise sort of
portable for any bash like shell.

But I haven't used it since 2018 when I generated the data for the next
50 years so cannot guarantee the website is still there! :-)

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: Improving org-macro.el

[Stefan Monnier]

>> It seems to work on Org's own manual, but other than that I haven't gone
>> out of my way to test it.
> There were a few problems reported by the test suite that I tried to
> address. I also updated `org-lint', which didn't handle macro
> definitions as functions.

Thanks.

>> - It also changes the behavior when $N appears elsewhere than an
>>   "expression context".  E.g.:
>>   #+macro:  (eval (let (($1 foo)) (bar)))
> This is not a valid macro definition anyway since placeholders are
> strings.

Indeed for this specific example it was invalid anyway, but I can
imagine some variations on the theme where it still lead to valid code.

>>   #+macro:  (eval (fun-with "code $1"))
> I don't think this was valid previously either, for the same reason.

I'm pretty sure this could be made to do interesting things, tho it does
feel a bit like "exploiting a security hole" ;-)

>> I don't think it requires changes to the manual because the semantics
>> described in the manual is sufficiently incomplete that both the old and
>> the new semantics satisfy it.
>
> One noticeable effect is that empty or missing placeholders in macro
> call are now nil, instead of the empty string. This broke our internal
> macros (e.g., {{{n}}} and {{{property}}}) so I updated them.

Ah, indeed, that was indeed a more serious difference which I had missed
(I see in one of my tests failed to catch it just because `concat`
treats nil and "" in the same way).

> I mentioned it in the ORG-NEWS file, and applied your changes. We'll see
> how it goes.

Great, thanks.

BTW, macros of the form

#+macro FOO (lambda ...)

would lead to much simpler code on `org-macro.el` ;-)


Stefan

Re: wip-cite status question and feedback

[András Simonyi]

Dear All,

apologies for being this late with my reaction --  here  are some
comments/questions on Nicolas's summary:

On Mon, 12 Apr 2021 at 15:19, Nicolas Goaziou  wrote:

> suffix" are all optional. So, in its minimal form, it can be as simple
> as:
>
>   [cite:@Doe:1995a]

are short-form citations like @doe2018 or  [@doe2018] also supported?

> Now about the API, which is partly implemented on a local branch.

>   - "opening" action is straightforward. All is needed for the processor
> is to provide a function accepting two arguments: the citation key,
> as a string, and possibly a universal argument, which it may ignore,
> or not.
>
> All this is already implemented locally.

I can imagine situations in which the location (e.g. page range) of
the citation is also important, e.g., when the
processor opens the cited document, so it'd be nice to pass this
information (when available) as well.

> First, export happens as pre-process, before export back-ends are
> introduced. IOW, export back-ends are never going to see a citation
> object, which means no support whatsoever is needed on their end.

This is pretty close to how citeproc-org operates right now.

> Support export requires two functions. The first function is
> responsible for rendering a bibliography. Its arguments are the list
> of citations in the document, the list of bibliography files, the
> style, if any, and the export back-end. It should return a string.

Am I correct in assuming that the returned bibliography should be
rendered as a legitimate Org fragment regardless of the back-end?

> The second mandatory function is obviously responsible for rendering
> citations. It is called with a citation object, the desired style,
> if any, and the export back-end, the full list of citations objets
> in the document, and the list of bibliography files. It should also
> return a string. Org provides a helper function to determine the
> footnote containing a citation (and its label, or number) from
> a citation object.

This might not be an important point, but citeproc-el is rather
citation list oriented in the sense that it processes the list of all
citations and returns a list of their formatted counterparts, so it
might be useful to provide this "bulk" API as well, at least as an
optional addition.

What is very important and was rather tricky to implement as I recall
is that the list of citations should be in the order they actually
appear in the exported document even for citations in footnotes,
because certain styles format citations differently if another
reference to the same work occurred in a nearby, earlier note. In
addition to the precise order of the citations and whether they are in
a footnote or not, the concrete identity  of the notes is also
important, because formatting can differ depending on whether two
citations are in the same note or in different ones.

>   - "fontification" is meant to give full access to face selection, what
> is really displayed, additional keymaps, all using a single
> function.

> At the moment, I have no idea about what arguments would be useful.
> I think John Kitchin gave ideas about this already on this ML.
> I have to re-read his posts on the subject. In any case, feedback
> welcome.

I'm thinking about implementing a "fontification" solution which would
use citeproc-el with a standard style to produce nice preview-like
representations of the citations in the buffer. This would require
basically the same pieces of information as citation export I think,
although it might be made strictly  local, working only with the
single citation object plus the bibliography information. Providing
really precise previews is probably out of scope here,because some
details depend on global information about other citations which can
frequently change and would be difficult to keep up-to-date.

> A citation processor does not need to provide integration in all these
> areas. Users may be able to mix and match processors. This is another
> (minor) point which is yet to be designed. How is a user supposed to
> select a processor for each integration area? It could be done through
> three variables, e.g.,
>
>   (setq org-cite-display-processor 'org-ref)
>   (setq org-cite-export-processor 'citeproc)
>   (setq org-cite-follow-processor 'default)
>
> I think it is unlikely for a user to locally select "display" and
> "follow" processors. However, we need a way to use a local export
> processor for a given document. I may need to introduce
> a #+citation_processor keyword during export. Any other idea?

All of these solutions seem to be good starting points.  As for
setting the "display" and "follow" processors locally, this leads to a
question which probably has to be addressed at a certain point: that
of bibliography formats. The Emacs world is currently rather BibTeX
centered, but biblatex is an important (and rather dif

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Fri, Apr 16, 2021 at 1:06 PM András Simonyi  wrote:

> The Emacs world is currently rather BibTeX
> centered, but biblatex is an important (and rather different)
> alternative, and there is CSL as well which I expect to become more
> and more relevant (it's citeproc-el's native format). Moreover, these
> formats have some variants, e.g., for BibTeX there is also org-bibtex,
> for CSL there is CSL-JSON and a CSL-YAML etc.

I might just jump in here and mention two recent, more general, CSL
processor projects, both designed with similar goals of being usable
as libraries, and so in theory should be able to hook up to this
system at some point with some elisp glue.

1. the haskell based https://github.com/jgm/citeproc, now used in pandoc
2. the rust based https://github.com/zotero/citeproc-rs (I expect this
to be incorporated into Zotero in the future)

Here's the most clear natural language description of the API in the
first, which should be similar in the second.

https://github.com/jgm/citeproc#how-to-use-it

Bruce

Concerns about community contributor support

[Timothy]

Dear all,

Over the last few months I have felt an increasing level of concern over
the lack of response to patches. This email is rather long, but please,
bear with me. The goal is to start a discussion on the problems this
creates, and consider short and long-term solutions.

When both community and maintainer response to new patches is lacking,
many first-time contributors are actively dissuaded from contributing
again. Furthermore, each patch represents a considerable time investment
--- particularly if it's from an individual who is new to the mailing
list / patch workflow. Org-mode is not "done" and still requires the
support of long-term contributors to keep improving, anything that
discourages them from contributing back to the community needs to be
carefully understood and resolved if we want to continue harmoniously.

Take for example Jay Bosamiya's patch from September last year [1]. It
appears to be his first submission to this mailing list, and yet there
has been absolutely no response to it. There are currently 24 other
patches listed on the updates.orgmode.org which have seen no response
from this community, some of which are from first-time contributors.
There are 36 other patches with at least two replies, but yet to be
resolved. Bastien's updates.orgmode.org is fantastic in helping prevent
contributions slip through the cracks, but it is also highlighting the
lack of community response to a significant number of patches.

This mailing list was my first experience with an email+patch based
contribution workflow. Thankfully, I received prompt and friendly
feedback and was guided through the adjustments needed so it could be
merged in a timely manner. Should my patch have been similarly ignored,
I would have been quite disheartened; it is not an overstatement to say
I would likely have written off this mailing list and not tried again.

Simply put, this is not good enough. This does a disservice to those
that have dedicated time and effort to try and better this project only
to be ignored. Not rejected, not even acknowledged, nothing.

It is imperative that this community improves our response to
contributions for the long-term health of this project. Do not take me
to be a doomsayer; I have faith that Org is going to keep on improving
regardless. However, failing to welcome and encourage contributors has a
deleterious effect on the health of the project.

I do not blame the maintainers in the slightest. As Bastien brought up
in a recent worg discussion, as time goes on we find ourselves taking on
more and more life responsibilities. Therefore it's in our best interest
to delegate some of the maintainer responsibilities to consistently
active, and supportive community members to "pass down the torch" so the
community and platform can continue to expand with grace and care.

What can the community do?

I don't know of any silver bullet, but I believe there are some steps
which could help, namely:
+ The development and publication of "reasonable expectations" which
  contributors should have when submitting a patch, and that the
  maintainers should strive to uphold (e.g. "expect a response within
  ").
+ A community effort/sprint to respond to those patches that have been
  seemingly abandoned
+ Onboarding of new maintainers, when reasonable and suitable candidates
  exist (I'd very willingly throw my hat in the ring for consideration).
  If it's too much work, spread it out as much as possible.

If any other ideas come to mind, please share them so we can discuss
them further.

Finally, it's not all bad.

While this discussion has called for some criticism, I don't want to
give the false impression that I think nothing is working and nobody is
supporting contributors. This is not the case at all, there are some
standout individuals one the mailing list who have been fantastic. Kudos
to you all.

My best to everyone,

Timothy

[1] 
https://orgmode.org/list/caoywxzg1cbl07thlzxhbbczm6te2vmtqnmm0w63331gybrj...@mail.gmail.com/
[2] https://orgmode.org/list/87h7qi2l2m@gmail.com/

Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

[Jorge P. de Morais Neto]

Hi.  The HTML export has JavaScript that LibreJS does not recognize as
free.

My first attempt at an workaround (inspired by the Org Mode mailing
list) was merely encoding the ampersand in the magnet link, but that
*did not make LibreJS happy*.  Then I checked LibreJS manual and saw
this excerpt:

https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1

Public domain is not a license (see
https://www.gnu.org/licenses/license-list.html#PublicDomain).  If
you want to release your work to the public domain, the FSF
recommends using CC0.

Then I came up with a successful workaround.  I included the following
code in my Org Mode customization file:

;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS
(with-eval-after-load 'ox-html
  (setq org-html-scripts
(string-replace "\
// @license 
magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt
 Public Domain"
"\
// @license 
magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08&dn=cc0.txt 
CC0-1.0"
org-html-scripts)))

This works; it makes LibreJS happy.

Thank you for your work in Org Mode!

Regards

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
cairo version 1.16.0)
Package: Org mode version 9.4.5 (9.4.5-16-g94be20-elpaplus @ 
/home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)
-- 
-  "In Support of Richard Stallman"
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

Re: Repository of Org files with important dates?

[Marcin Borkowski]

On 2021-04-16, at 17:55, Eric S Fraga  wrote:

> If you want solar based information (equinox, solstice, etc.), which is
> not quite what you mentioned, I used this script to generate org file
> headings:

Can't Emacs itself generate those data?

-- 
Marcin Borkowski
http://mbork.pl

Re: Is it possible to #+include: src blocks and tangle them too?

[Berry, Charles]

Hi Greg,

> On Apr 16, 2021, at 8:27 AM, Greg Minshall  wrote:
> 
> Rama,
> 
> one other comment/suggestion.
> 
>> I haven’t been able to fully work with Donald Knuth’s suggestion of
>> writing a Literate Program directly in a tool like orgmode/noweb since
>> it is a nuisance to keep having to type C-c ' to go into the editing
>> mode of the language concerned.
> 
> while i have not much experience with it, you might look at the emacs
> packages polymode, poly-org, and poly-whatever-other-languages-you-use.
> it seems as if they might give you [C-c ']-like behavior when editing
> source blocks in line in an org mode buffer.
> 
> (others who use polymode: does this make sense?)


I have tried it a few times, but not had satisfactory results. 

I use mostly R src blocks, so I want to have ESS like functionality. And I 
really like to be able to execute src blocks with 
`org-babel-execute-src-block'. 

Unfortunately, it seems like polymode gets into conflicts with org mode from 
time to time. My memory is a bit dim on exactly the issues, but I think there 
were freezes. Maybe turning off all the stops and whistles in org mode (like 
fontification) would solve this, but I never gave it a go. 

Having said that, I will say it is easy enough to install and try out. And 
perhaps your mileage will vary.

Best,
Chuck

Re: Improving org-macro.el

[Stefan Monnier]

> I mentioned it in the ORG-NEWS file, and applied your changes. We'll see
> how it goes.

I just saw that it burps in Emacs-26 because of a bug when functions are
declared with 0 optional arguments like (&optional &rest x).

So I suggest the patch below,


Stefan


diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 0f1dfa2e48..ea4d12133b 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -91,10 +91,11 @@ directly, use instead:
   (setq i (match-end 0))
   (setq max (max max (string-to-number (match-string 1 template)
 (let ((args '(&rest _)))
-  (while (> max 0)
-(push (intern (format "$%d" max)) args)
-(setq max (1- max)))
-  (cons '&optional args
+  (if (< max 1) args ;Avoid `&optional &rest', refused by Emacs-26!
+(while (> max 0)
+  (push (intern (format "$%d" max)) args)
+  (setq max (1- max)))
+(cons '&optional args)
 
 (defun org-macro--set-templates (templates)
   "Set template for the macro NAME.

[PATCH] Remove diary-list-entries Emacs 21 compat code

[Stefan Kangas]

Please find attached a small cleanup patch to org-agenda.el.
From 16224c9730fe2403d280fc3390ed700ce39c00ae Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sat, 17 Apr 2021 01:45:31 +0200
Subject: [PATCH] Remove diary-list-entries Emacs 21 compat code

* lisp/org-agenda.el (org-get-entries-from-diary): Remove some
Emacs 21 compat code; 'list-diary-entries' was made obsolete in
favour of 'diary-list-entries' in 22.1 and removed in 24.1.
---
 lisp/org-agenda.el | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index f22e6fa65..5368f5839 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -5255,9 +5255,7 @@ of what a project is and how to check if it stuck, customize the variable
 	 (org-disable-agenda-to-diary t))
 (save-excursion
   (save-window-excursion
-	(funcall (if (fboundp 'diary-list-entries)
-		 'diary-list-entries 'list-diary-entries)
-		 date 1)))
+(diary-list-entries date 1)))
 (if (not (get-buffer diary-fancy-buffer))
 	(setq entries nil)
   (with-current-buffer diary-fancy-buffer
-- 
2.30.2

non-brittle granular includes

[Samuel Wales]

can body text or paragraphs be included upon export?

i have a file like this:

* top
** a
b [these are paragraphs]

c [another paragraph]

d [another paragraph]
** e
# i'd like to include b and c here redundantly
# because i want to export e separately

f [paragraph]
** g

i'd like to use #+NAME or <> or org-id to specify the thing to
include, and to reference it.

however, the #+include syntax doesn't quite allow less-brittle references.

is there anything that can do this?  it isn't a huge issue, but i have
run across it a few times over many years.