Re: yhetil.org/orgmode now supports searching by Gmane ID

[Eric Abrahamsen]

Kyle Meyer  writes:

> Eric Abrahamsen  writes:
>
>> Kyle Meyer  writes:
>
> [...]
>
>>>   $ w3m -m nntp://news.gmane.io/gmane.emacs.orgmode/112052
>>>
>>> (Offhand I don't know how to do the same in Gnus, despite it being my
>>> primary method for following things over nntp.)
>>
>> I assume you can just use "j" in the summary buffer, and enter the
>> article number. Doing that for message 112052 got me message-id
>> "<87k28w7l6y@gmail.com>", is that correct?
>
> That's the one.  Thanks!
>
> If you happen to know off the top of your head: Is there an easy way for
> me to jump to that article if I'm not subscribed to the
> gmane.emacs.orgmode group but have the nntp:news.gmane.io server set up
> (for other lists)?

Hmm, this isn't something I do very often, but I think if you make an
ephemeral group with either "B" or "G M" (the interfaces are different,
but I believe the result is the same) you can enter the group name,
specify that it should use your nntp:news.gmane.io server, then the
group will open and you can do the "j" trick. The group should disappear
from your Gnus installation when you're done with it. You could also
write your own wrapper around gnus-group-read-ephemeral-group.

It might take some experimentation!

Eric

Re: yhetil.org/orgmode now supports searching by Gmane ID

[Kyle Meyer]

Eric Abrahamsen  writes:

> Kyle Meyer  writes:

[...]

>>   $ w3m -m nntp://news.gmane.io/gmane.emacs.orgmode/112052
>>
>> (Offhand I don't know how to do the same in Gnus, despite it being my
>> primary method for following things over nntp.)
>
> I assume you can just use "j" in the summary buffer, and enter the
> article number. Doing that for message 112052 got me message-id
> "<87k28w7l6y@gmail.com>", is that correct?

That's the one.  Thanks!

If you happen to know off the top of your head: Is there an easy way for
me to jump to that article if I'm not subscribed to the
gmane.emacs.orgmode group but have the nntp:news.gmane.io server set up
(for other lists)?

Re: yhetil.org/orgmode now supports searching by Gmane ID

[Eric Abrahamsen]

Kyle Meyer  writes:

> In the Git and mailing list history, we've got lots of references like
> .  Those Gmane
> http links aren't so useful now, though you can still use that
> information to access the message by doing things such as
>
>   $ w3m -m nntp://news.gmane.io/gmane.emacs.orgmode/112052
>
> (Offhand I don't know how to do the same in Gnus, despite it being my
> primary method for following things over nntp.)

I assume you can just use "j" in the summary buffer, and enter the
article number. Doing that for message 112052 got me message-id
"<87k28w7l6y@gmail.com>", is that correct?

yhetil.org/orgmode now supports searching by Gmane ID

[Kyle Meyer]

In the Git and mailing list history, we've got lots of references like
.  Those Gmane
http links aren't so useful now, though you can still use that
information to access the message by doing things such as

  $ w3m -m nntp://news.gmane.io/gmane.emacs.orgmode/112052

(Offhand I don't know how to do the same in Gnus, despite it being my
primary method for following things over nntp.)

Anyway, for the public-inbox archives at ,
I've recently generated Gmane ID to Message-ID mappings and hooked them
up to public-inbox's altid feature.  The end result is that you can now
use the "gmane:" prefix to search by the Gmane ID:

  https://yhetil.org/orgmode/?q=gmane%3A112052

Re: Policy proposal: Do not move existing functions/macros except in major version increments

[Adam Porter]

Hi Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>
> [...]
>
>> Thankfully, Kyle has proposed a patch to revert that change.  I hope
>> it is merged.
>>
>> If it is not, when a new Org version is released with those changes
>
> What makes you think a new Org would be released in this situation,
> without fixing it first?

I don't know what will happen.  I don't know whether the Org maintainers
would consider the problem serious enough to avert (as you said later,
"it happens").  That's why I pointed out what the consequences would be
if the patch isn't merged, to encourage its merging.

>> I think changes like this should not be made without very careful
>> consideration of the wider implications.  These kinds of changes
>> create a not-insubstantial burden on maintainers of Org-related
>> packages to keep up with churn and maintain compatibility with
>> multiple Org versions (which are used in the wild for years--I know
>> of users still using Org 8, as well as Org 9 versions that are
>> included with older Emacs versions (e.g. Emacs 26.3 is still stuck in
>> Debian unstable, not migrating to testing, stable, or backports)).
>
> [...]
>
>> So, I propose that changes like these should not be made except in
>> major version increments, e.g. this change should have been delayed
>> until the release of Org 10.0.  It would be helpful for users and
>> package authors if they knew that changes like these would not be
>> made until the next major version increment.
>
> FWIW, I think this is too strong a requirement.
>
> This breakage is unfortunate, and I can hear the consequences it has
> on the Org ecosystem, but, hey, it happens. Note that moving part of
> Org elsewhere usually introduces less friction. This is a relatively
> exceptional situation.

Of course, I am biased here, but I feel like it's not quite as
exceptional as it ought to be.  The more Org-related packages I make and
maintain, the more version-specific workarounds I have to add due to
changed function names, signatures, etc.  These are sometimes necessary,
of course, but I think they should be made more carefully and
deliberately.

Of course, Org doesn't make any promises to third-party packages.  But
that is the issue, isn't it?  I'm saying that I think it should start
taking this issue a little more seriously.  :)

> Master is an unstable branch, relatively open to experimentation.
> Moreover, that experimentation happens before deciding if the next
> release should be 10.0 or 9.4, so it wouldn't help users or package
> authors.

That is a matter of policy, which is what I'm proposing.  When such a
change is desired (symbol name, function signature, etc), it should be
targeted at the next major version increment.  If the project as a whole
is not ready to make that increment, that change should be delayed until
then--it can be developed in a branch and merged when preparing the
major release.  These kinds of changes could even be documented in
advance, e.g. in a ROADMAP or PLANS file, or whatever you want to call
it, which would be more explicit and referenceable than merely a mailing
list post.

> It doesn't mean we cannot do better here. For example, I think we
> could improve the way Org loads its libraries. Ideally, external
> libraries should only (require 'org), and optionally, (require 'ox-*)
> or (require 'ol-*). Thus, changes like the one discussed here would be
> implementation details. For example, "ox-hugo.el" requires directly
> "ob-core.el", and now "org-refile.el", which is, IMO, a path to
> troubles. It should only require "org.el".
>
> The current situation is tricky though: "org.el" requires some
> libraries (e.g., "org-key.el", "org-table.el", ...), and some
> libraries require "org.el" (e.g., "org-capture.el", "org-element.el",
> ...). I expect "org.el" to be the entry point for the Org package, so
> loading should happen in one-way only.
>
> This would not solve everything, but it would certainly make things
> smoother for external libraries.
>
> WDYT?

That is a good idea, and one that needs addressing.  I'd be glad to give
some feedback on it, but in a separate thread, please, because it seems
like a different matter from the issue I'm raising and the proposal I'm
making.

Thanks,
Adam

Re: [ANN] org-ql 0.4 released

[Adam Porter]

David R  writes:

> On Saturday, January 25, 2020, Adam Porter  wrote:
>
>> I care about stability, not MELPA Stable.  It's your choice to use MELPA
>> Stable, and you're free to upgrade or downgrade individual packages to
>> work around such occasional, temporary breakage caused by it--the pieces
>> are yours to keep.  I'm sorry for any inconvenience, but your config is
>> up to you.
>
> It seems to me that this last statement ("Your config is up to you"),
> or perhaps the point of view that produces it, is not self-evident
> when applied to package versions. I think that in some way it's near
> the heart of the controversy.
>
> Maybe for me personally, my config being up to me (regarding package
> versions) is a disadvantage. I gratefully make use of a number of
> packages that I don't fully understand, and if I was required to study
> all of them until I was confident that I *did* fully understand them
> before installing, I'd just give up using Emacs at all.

That is not what I am suggesting.

I suggest that you:

1.  Keep your Emacs config backed up, preferably with version control,
including all installed packges.

2.  Upgrade packages deliberately, not "upgrade all upgradable
packages."

3.  When you discover a problem caused by an upgrade, roll-back to a
known-good configuration until you have time to debug the problem.

This is what I recommend to all Emacs users.  It does not require
understanding any packages' source code.

Elisp has no inter-package API.  It's just a Lisp machine.  Elisp
packages are just symbols that you load into your image.  There is no
actual separation between packages' symbols.  There are no versioned
APIs, no synchronized transitions.

Each user's configuation, image, set of installed packages, etc. is that
user's responsibility.  In that sense, it's no different from a computer
system as a whole: you choose what software to install on it.  If you
like or need a certain version of certain software, it's up to you to
ensure that you have a copy of it available.  If you upgrade some
software and it doesn't work anymore with some other software version,
it's up to you to deal with it.

One of Emacs's chief strengths is user empowerment.  That doesn't mean
that users need to know how everything works--not even the core Emacs
developers do.  It means that you should know enough to maintain the
operability of the system, like you generally do for the rest of your
computer system.

The Emacs package "ecosystem" is not a "vendored" system.  It's not like
Debian, with thousands of relatively curated packages maintained as a
middleman, expected to work together in a stable release.  In Emacsland,
Each package (outside of Emacs and ELPA, and somewhat within ELPA as
well) is developed independently.

Nor should Emacs be treated like other software systems that are
live-updated whenever the developers hit the "push" button, with users
expecting the latest everything to work together all the time because
one party (ostensibly) takes responsibility for ensuring that.

Emacs gives the user the power.  And with great power...well, you know.

Having said all that, the problems with MELPA Stable are, in a sense,
artificial, and they're orthogonal to these general issues.  I can only
recommend, again, to not use it.  If you're lucky, it will work fine.
When it doesn't, the solution will involve not using it.  So you might
as well just skip it.  If you want less-frequent package upgrades, just
don't upgrade your packages so frequently.  Or use something like Quelpa
or Straight or Borg, where you can easily install the package versions
you want.

Re: babel/noweb concatenation of equally-named code blocks fails?

[Greg Minshall]

Nicolas,

below is a format-patch.  i signed FSF papers for emacs a number of
years ago (and for gawk more recently).

cheers, Greg

From e2d440186ccf62216406abb440455edbac72ba79 Mon Sep 17 00:00:00 2001
From: Greg Minshall 
Date: Wed, 22 Apr 2020 14:45:52 -0700
Subject: [PATCH] some clarification on <>, #+name:, :noweb-ref

---
 doc/org-manual.org | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 2a2700739..1c4a1f954 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17988,12 +17988,13 @@ using a noweb[fn:145] style syntax:
 : <>
 
 #+texinfo: @noindent
-where {{{var(CODE-BLOCK-ID)}}} refers to either the =NAME= of
-a specific source code block, or a collection of source code blocks
+where {{{var(CODE-BLOCK-ID)}}} refers to either the =NAME= of 
+a single source code block, or a collection of one or more source code blocks
 sharing the same =noweb-ref= header argument (see [[*Using Header
-Arguments]]).  Org can replace such references with the source code---or
-concatenation thereof--- being referenced, or with the results of an
-evaluation.
+Arguments]]).  Org can replace such references with the source code of
+the block or blocks being referenced, or, in the case of a single
+source code block named with =NAME=, with the results of an
+evaluation of that block.
 
 #+cindex: @samp{noweb}, header argument
 The =noweb= header argument controls expansion of noweb syntax
@@ -18056,9 +18057,9 @@ the second code block is expanded as
 ,#+END_SRC
 #+end_example
 
-You may also concatenate the contents of multiple blocks sharing
-a common =noweb-ref= header argument.  For simple concatenation, set
-its value at the sub-tree or file level.  In the example Org file
+You may also include the contents of multiple blocks sharing
+a common =noweb-ref= header argument, which can be set at the file,
+sub-tree, or code-block level.  In the example Org file
 shown next, the body of the source code in each block is extracted for
 concatenation to a pure code file when tangled.
 
@@ -18091,19 +18092,19 @@ concatenation to a pure code file when tangled.
 By default a newline separates each noweb reference concatenation.  To
 use a different separator, edit the =noweb-sep= header argument.
 
-Eventually, Org can include the results of evaluation of a single code
-block rather than its body.  To that effect, append parentheses,
-possibly including arguments, to the code block name, as shown below.
+Alternatively, Org can include the results of evaluation of a single code
+block rather than its body.  Evaluation occurs when parentheses,
+possibly including arguments, are appended to the code block name, as shown 
below.
 
 : <>
 
-Note that when using the above approach to a code block's results, the
+Note that in this case, a
 code block name set by =NAME= keyword is required; the reference set
-by =noweb-ref= is not effective in that case.
+by =noweb-ref= will not work when evaluation is desired.
 
 Here is an example that demonstrates how the exported content changes
 when noweb style references are used with parentheses versus without.
-With:
+Given:
 
 #+begin_example
 ,#+NAME: some-code
-- 
2.26.0

Re: [ANN] org-ql 0.4 released

[David R]

On Saturday, January 25, 2020, Adam Porter  wrote:

> I care about stability, not MELPA Stable.  It's your choice to use MELPA
> Stable, and you're free to upgrade or downgrade individual packages to
> work around such occasional, temporary breakage caused by it--the pieces
> are yours to keep.  I'm sorry for any inconvenience, but your config is
> up to you.


I'm making an extremely late reply, sorry.

It seems to me that this last statement ("Your config is up to you"), or
perhaps the point of view that produces it, is not self-evident when
applied to package versions. I think that in some way it's near the heart
of the controversy.

Maybe for me personally, my config being up to me (regarding package
versions) is a disadvantage. I gratefully make use of a number of packages
that I don't fully understand, and if I was required to study all of them
until I was confident that I *did* fully understand them before installing,
I'd just give up using Emacs at all.

I don't think there's likely to be any person who uses all of the packages
offered in the list. It appears to me that there are sort of "interest
groups" of Emacs users, where members of each group tend to all install,
use, and collectively debug a similar subset of what's available. I've
discovered that if I install the packages that are most popular among the
org-mode group, Emacs does what I want and everything seems to work. A sort
of de facto "group curation system", that has created a sort of unofficial
ad-hoc "org-mode group consensus distro of Emacs".

-- 
David

-- 
David Rogers

Re: babel/noweb concatenation of equally-named code blocks fails?

[Nicolas Goaziou]

Greg Minshall  writes:

> two minor edits i might make to the first paragraph, 1) to make clear
> that #+name: names only one block, and 2) to (maybe?) simplify the
> latter part of the same paragraph, while, at the same time, trying to
> keep a strong mention of the distinction between =NAME= and
> =noweb-ref= at the top of the article.

Your proposal is an improvement, indeed. Thank you.

> additionally, i did some wordsmithing.  i've appended a diff, hopefully
> in a useful format (C-x C-v =); i'm not a git, git patch, expert.

Could you use "git format-patch" and use a proper commit message? You
may need to add TINYCHANGE at its end, if you haven't signed FSF papers
yet.

> i wonder if there might a place in this article to mention
> org-babel-expand-src-block (C-c C-v v)?  it is mentioned, tangentially,
> later in the manual (but i only came across it recently).

You are right, this is a serious omission in this part of the manual.
Would you want to document it?

Re: babel/noweb concatenation of equally-named code blocks fails?

[Greg Minshall]

hi, Nicolas,

thanks, and sorry, i should have git-pull'd.  the new version seems very
nice to me.  two minor edits i might make to the first paragraph, 1) to
make clear that #+name: names only one block, and 2) to (maybe?)
simplify the latter part of the same paragraph, while, at the same time,
trying to keep a strong mention of the distinction between =NAME= and
=noweb-ref= at the top of the article.

additionally, i did some wordsmithing.  i've appended a diff, hopefully
in a useful format (C-x C-v =); i'm not a git, git patch, expert.

i wonder if there might a place in this article to mention
org-babel-expand-src-block (C-c C-v v)?  it is mentioned, tangentially,
later in the manual (but i only came across it recently).

cheers, Greg

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 2a2700739..1c4a1f954 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17988,12 +17988,13 @@ using a noweb[fn:145] style syntax:
 : <>
 
 #+texinfo: @noindent
-where {{{var(CODE-BLOCK-ID)}}} refers to either the =NAME= of
-a specific source code block, or a collection of source code blocks
+where {{{var(CODE-BLOCK-ID)}}} refers to either the =NAME= of 
+a single source code block, or a collection of one or more source code blocks
 sharing the same =noweb-ref= header argument (see [[*Using Header
-Arguments]]).  Org can replace such references with the source code---or
-concatenation thereof--- being referenced, or with the results of an
-evaluation.
+Arguments]]).  Org can replace such references with the source code of
+the block or blocks being referenced, or, in the case of a single
+source code block named with =NAME=, with the results of an
+evaluation of that block.
 
 #+cindex: @samp{noweb}, header argument
 The =noweb= header argument controls expansion of noweb syntax
@@ -18056,9 +18057,9 @@ the second code block is expanded as
 ,#+END_SRC
 #+end_example
 
-You may also concatenate the contents of multiple blocks sharing
-a common =noweb-ref= header argument.  For simple concatenation, set
-its value at the sub-tree or file level.  In the example Org file
+You may also include the contents of multiple blocks sharing
+a common =noweb-ref= header argument, which can be set at the file,
+sub-tree, or code-block level.  In the example Org file
 shown next, the body of the source code in each block is extracted for
 concatenation to a pure code file when tangled.
 
@@ -18091,19 +18092,19 @@ concatenation to a pure code file when tangled.
 By default a newline separates each noweb reference concatenation.  To
 use a different separator, edit the =noweb-sep= header argument.
 
-Eventually, Org can include the results of evaluation of a single code
-block rather than its body.  To that effect, append parentheses,
-possibly including arguments, to the code block name, as shown below.
+Alternatively, Org can include the results of evaluation of a single code
+block rather than its body.  Evaluation occurs when parentheses,
+possibly including arguments, are appended to the code block name, as shown 
below.
 
 : <>
 
-Note that when using the above approach to a code block's results, the
+Note that in this case, a
 code block name set by =NAME= keyword is required; the reference set
-by =noweb-ref= is not effective in that case.
+by =noweb-ref= will not work when evaluation is desired.
 
 Here is an example that demonstrates how the exported content changes
 when noweb style references are used with parentheses versus without.
-With:
+Given:
 
 #+begin_example
 ,#+NAME: some-code

Re: bug? org-lint issues warning when ; PROPERTIES: drawer before first headline

[Nicolas Goaziou]

Hello,

Charles Millar  writes:

> Org mode version 9.3.6 (release_9.3.6-528-gf874b6 @
> /usr/local/share/org-mode/lisp/)
> GNU Emacs 28.0.50 (build 102, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.18, cairo version 1.16.0) of 2020-04-21
>
> AFAIU this is now allowed. Should org-lint be modified?

True. Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Feature request: Footnotes immediately following the paragraph when exported ($)

[D. C. Toedt]

For an ongoing pro bono project, it would be nice if there were an
in-buffer #+OPTION: configuration for footnotes, when exporting to HTML (or
DOCX or PDF), to have the footnote text in small print just below the
paragraph in which the footnote reference occurs.

I'd be willing to pay something to have this done and contributed to the
standard installation.

Here's an example of the desired "look"; it's copied and pasted from a court
opinion ,
with the footnote numbers bolded:



[T]he CSA allowed Pruitt to not only access CIP, but also to "build
Customer Use Cases*[4]*
 and
configure Data Feeds*[5]* for those" cases. *[remainder of paragraph
omitted]*


*[4]* The CSA defines "Use Case" as a "Cloud Services configuration that
incorporates Data Feeds with designated views to address specific issues
within [Pruitt] or [Pruitt's] Facilities." Doc. 1–1 at 7. "Customer Use
Cases," in turn, "means any Use Case developed by or for [Pruitt] or
customized for [Pruitt]." *Id.*

*[5]* "Data Feeds" are "inbound electronic data messages from [Pruitt]
information systems to the Cloud Services." Doc. 1–1 at 7. Essentially, a
data feed is the delivery of information from a Pruitt electronic medical
records software system to CIP, which Caradigm hosts on its own computers,
and which Pruitt accesses via the "cloud." *See* doc. 73 at 6 ("data feeds
are the electronic data messages from PruittHealth systems to [CIP].")
(quotes omitted).

The Order—"made as of June 25th, 2013 ("Order Effective Date ") pursuant to
the [CSA]"—meanwhile, reveals that Pruitt, in addition to the $20,000/month
CIP development license, purchased two other "Cloud Services:" *[remainder
of text omitted]*



I've just (re)checked the manual
 but didn't see this
feature.

A Google search yielded a 2014 Stack Overflow question

along
the same lines.

D. C. Toedt III   Attorney & neutral arbitrator — tech contracts & IP
*(My last name is pronounced "Tate")  * +1 (713) 364-6545
d...@toedt.com@dctoedt 
Skype: dctoedt

www.OnContracts.com/About 
Unless expressly stated otherwise, this message is not intended to serve
as assent to an agreement or other document, even if attached to this
message.

#+BEGIN_SRC sh C-c C-c in Windows

[Neil Cherry]

I've searched for a resolution for this but haven't found one. I want to be able
to call a different command shell in Windows. What I keep seeing is that it 
can't
find /bin/sh

#+BEGIN_SRC sh :results output
set
#+END_SRC

I would prefer that I can change it to the bash shell in PortableGit.
Also I have no ability to add packages to the machine (other than emacs).
I don't have admin on this machine.

Thanks
-- 
Linux Home Automation Neil Cherry   nche...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/My HA Blog
Author of:  Linux Smart Homes For Dummies

Re: babel/noweb concatenation of equally-named code blocks fails?

[Nicolas Goaziou]

Hello,

Greg Minshall  writes:

> Nicolas,
>
> thank you.  wordsmithing opens up endless possibilities, so i don't know
> that the following is at all an improvement on your suggestion.  but, it
> occurs to me to get the importance of =noweb-ref=, and its role in
> concatenation, brought out early on the "page".

Thank you. I certainly appreciate some help on documentation writing.

The wording evolved a bit since you checked it. Just to be sure, you
suggest to replace (I'm adding context here)

Source code blocks can include references to other source code blocks,
using a noweb[fn:145] style syntax:

: <>

where CODE-BLOCK-ID refers to either the NAME of a specific source
code block, or a collection of source code blocks sharing the same
noweb-ref header argument (see Using Header Arguments). Org can
replace such references with the source code---or concatenation
thereof--- being referenced, or with the results of an evaluation.

The noweb header argument controls expansion of noweb syntax
references. Expansions occur when source code blocks are evaluated,
tangled, or exported.

with

Source code blocks can include references to other source code
blocks, using a noweb style syntax:

: <>

where CODE-BLOCK-ID refers to either the NAME of a specific source
code block, or a collection of source code blocks sharing the same
noweb-ref header argument (see Using Header Arguments). Depending on
the setting of the noweb header argument, Org will either ignore
a noweb style reference, or will attempt to replace it. In the
latter case, the replacement text will be either the source code
from exactly *one* named source code block (using either a NAME
keyword line, or a noweb-ref header argument), or a concatenation of
one or more source code blocks, each with an identically named
noweb-ref header argument. Expansions can only occur when source
code blocks are evaluated, tangled, or exported. For more details,
see below.

The noweb header argument controls expansion of noweb syntax
references. Expansions occur when source code blocks are evaluated,
tangled, or exported.


Note there's some duplication with the last paragraph. Can we avoid it?

Also, I'm not sure we should insist on the fact that you can use
a unique noweb-ref header argument as a code block ID: it is the slow
path without any advantage over NAME keyword.

I also suggest to replace

Depending on the setting of the noweb header argument, Org will
either ignore a noweb style reference, or will attempt to replace
it. In the latter case, the replacement text will be either ...

with

Depending on the setting of the noweb header argument, Org either
ignores the reference, or replaces it. In the latter case, the
replacement text is ...

I.e., I'm not a big fan of future tense in documentation, unless there's
some grammar rule involved.

But then, the following part:

the source code from exactly *one* named source code block (using
either a NAME keyword line, or a noweb-ref header argument), or
a concatenation of one or more source code blocks, each with an
identically named noweb-ref header argument.

is redundant with the earlier

CODE-BLOCK-ID refers to either the NAME of a specific source code
block, or a collection of source code blocks sharing the same
noweb-ref header argument

This already explains that there are two ways for referencing code, as
a single code block or as a collection of such blocks, and how to
reference them. Can we re-use this to explain that replacement text is
the consequence of that choice, instead of repeating ourselves?

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: Trivial fix for (void-function org-get-outline-path) in org-eldoc.

[Jacob MacDonald]

However, looking at the list I see the existing discussion and that
there's already another patch floating. Forgive me, and I'll wait for
that one.

bug#38855: bug#38856: Odp: 26.3; org-clock-display displays 0 total time when the date is in 2020

[Roberto Alejandro Rodriguez]

oh thanks for the tip

On 19/4/20 10:50, Nicolas Goaziou wrote:

Hello,

robertorodrig...@wp.pl  writes:


By the way, the dates in the file have to be in 2019 for the bug to
happen. If the dates are all in 2020, everything will be fine. Dnia
1 stycznia 2020 17:42 robertorodrig...@wp.pl
robertorodrig...@wp.pl napisał(a): visit an org file with time
records, press C-c C-x C-d.  Total time displayed in the minibuffer
will be 0 minutes.  Happens in GNU/Linux and Windows 7 when the date
is in 2020.  If you set the date to 2019, the correct amount will be
displayed.

Default value for `org-clock-display-default-range' is `thisyear'. By
default, only the clocks in the current year count.

Regards,

Trivial fix for (void-function org-get-outline-path) in org-eldoc.

[Jacob MacDonald]

I noticed that after updating my Org I was getting errors instead of
eldoc locations in my .org buffers. Thankfully the fix was a simple
oneliner. Patch attached.

Cheers,

Jacob.
From 84881cf925df74765eceefa208bf35615e28aa32 Mon Sep 17 00:00:00 2001
From: Jacob MacDonald 
Date: Tue, 21 Apr 2020 13:03:05 -0500
Subject: [PATCH] org-eldoc: Fix void-function error for org-get-outline-path

contrib/lis/org-eldoc.el: require org-refile for org-get-outline-path
---
 contrib/lisp/org-eldoc.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/lisp/org-eldoc.el b/contrib/lisp/org-eldoc.el
index 72b10a1fb..0da4c1c75 100644
--- a/contrib/lisp/org-eldoc.el
+++ b/contrib/lisp/org-eldoc.el
@@ -35,6 +35,7 @@
 ;;; Code:
 
 (require 'org)
+(require 'org-refile)
 (require 'ob-core)
 (require 'eldoc)
 
-- 
2.26.0

Adding RO translation for ox.el

[Claudiu Tănăselia]

Hello,

I hope I'm doing this right, since it's my first time trying something like 
this, but I've added a Romanian translation for ox.el that I would like to 
share with you, hoping that it will make it into the main branch. Since I'm 
using a website generated from ox-hugo, this is useful for me and I hope others 
can find it helpful in the future.

I've pasted my patch below, let me know it there's anything else I have to do.

Best regards,
Claudiu.

 lisp/ox.el | 21 +
 1 file changed, 21 insertions(+)

diff --git a/lisp/ox.el b/lisp/ox.el
index 6f5e81af2..d5d0c9b41 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5817,6 +5817,7 @@ them."
  ("nn" :default "Forfattar")
  ("pl" :default "Autor")
  ("pt_BR" :default "Autor")
+ ("ro" :default "Autor")
  ("ru" :html "" :utf-8 "Автор")
  ("sl" :default "Avtor")
  ("sv" :html "Frfattare")
@@ -5834,6 +5835,7 @@ them."
  ("nl" :default "Vervolg van vorige pagina")
  ("pt" :default "Continuação da página anterior")
  ("pt_BR" :html "Continuao da pgina anterior" 
:ascii "Continuacao da pagina anterior" :default "Continuação da página 
anterior")
+ ("ro" :default "Continuare de pe pagina precedentă")
  ("ru" :html 
"()"
   :utf-8 "(Продолжение)")
  ("sl" :default "Nadaljevanje s prejšnje strani"))
@@ -5848,12 +5850,14 @@ them."
  ("nl" :default "Vervolg op volgende pagina")
  ("pt" :default "Continua na página seguinte")
  ("pt_BR" :html "Continua na prxima pgina" :ascii 
"Continua na proxima pagina" :default "Continua na próxima página")
+ ("ro" :default "Continuare pe pagina următoare")
  ("ru" :html 
"( 
)"
   :utf-8 "(Продолжение следует)")
  ("sl" :default "Nadaljevanje na naslednji strani"))
 ("Created"
  ("cs" :default "Vytvořeno")
  ("pt_BR" :default "Criado em")
+ ("ro" :default "Creat")
  ("sl" :default "Ustvarjeno"))
 ("Date"
  ("ar" :default "بتاريخ")
@@ -5874,6 +5878,7 @@ them."
  ("nb" :default "Dato")
  ("nn" :default "Dato")
  ("pl" :default "Data")
+ ("ro" :default "Data")
  ("pt_BR" :default "Data")
  ("ru" :html "" :utf-8 "Дата")
  ("sl" :default "Datum")
@@ -5895,6 +5900,7 @@ them."
  ("nb" :default "Ligning")
  ("nn" :default "Likning")
  ("pt_BR" :html "Equao" :default "Equação" :ascii 
"Equacao")
+ ("ro" :default "Ecuația")
  ("ru" :html 
""
   :utf-8 "Уравнение")
  ("sl" :default "Enačba")
@@ -5914,6 +5920,7 @@ them."
  ("nb" :default "Illustrasjon")
  ("nn" :default "Illustrasjon")
  ("pt_BR" :default "Figura")
+ ("ro" :default "Imaginea")
  ("ru" :html "" :utf-8 
"Рисунок")
  ("sv" :default "Illustration")
  ("zh-CN" :html "" :utf-8 "图"))
@@ -5932,6 +5939,7 @@ them."
  ("nb" :default "Illustrasjon %d")
  ("nn" :default "Illustrasjon %d")
  ("pt_BR" :default "Figura %d:")
+ ("ro" :default "Imaginea %d:")
  ("ru" :html ". %d.:" :utf-8 "Рис. %d.:")
  ("sl" :default "Slika %d")
  ("sv" :default "Illustration %d")
@@ -5957,6 +5965,7 @@ them."
  ("nn" :default "Fotnotar")
  ("pl" :default "Przypis")
  ("pt_BR" :html "Notas de Rodap" :default "Notas de Rodapé" :ascii 
"Notas de Rodape")
+ ("ro" :default "Note de subsol")
  ("ru" :html "" :utf-8 "Сноски")
  ("sl" :default "Opombe")
  ("sv" :default "Fotnoter")
@@ -5995,6 +6004,7 @@ them."
  ("nb" :default "Tabeller")
  ("nn" :default "Tabeller")
  ("pt_BR" :html "ndice de Tabelas" :default "Índice de Tabelas" 
:ascii "Indice de Tabelas")
+ ("ro" :default "Tabele")
  ("ru" :html " 
"
   :utf-8 "Список таблиц")
  ("sl" :default "Seznam tabel")
@@ -6013,6 +6023,7 @@ them."
  ("no" :default "Dataprogram")
  ("nb" :default "Dataprogram")
  ("pt_BR" :default "Listagem")
+ ("ro" :default "Lista")
  ("ru" :html 
""
   :utf-8 "Распечатка")
  ("sl" :default "Izpis programa")
@@ -6029,6 +6040,7 @@ them."
  ("ja" :default "ソースコード%d:")
  ("no" :default "Dataprogram %d")
  ("nb" :default "Dataprogram %d")
+ ("ro" :default "Lista %d")
  ("pt_BR" :default "Listagem %d:")
  ("ru" :html 
" %d.:"
   :utf-8 "Распечатка %d.:")
@@ -6042,6 +6054,7 @@ them."
  ("fr" :ascii "References" :default "Références")
  ("it" :default "Riferimenti")
  ("pt_BR" :html "Referncias" :default "Referências" :ascii 
"Referencias")
+ ("ro" :default "Bibliografie")
  ("sl" :default "Reference"))
 ("See figure %s"
  ("cs" :default "Viz obrázek %s")
@@ -6049,12 +6062,14 @@ them."
   :html "cf.figure%s" :latex "cf.~figure~%s")
  ("it" :default "Vedi figura %s")
  ("pt_BR" :default "Veja a figura %s")
+ ("ro" :default "Vezi figura %s")
  ("sl" :default "Glej sliko %s"))
 ("See listing %s"
  ("cs" :default "Viz program %s")
  ("fr" :default "cf. programme %s"
   :html "cf.programme%s" :latex "cf.~programme~%s")
  ("pt_BR" :default 

Re: Faces and spaces

[Norman Tovey-Walsh]

> I pushed a fix on master for that. Please give it a try if you can.

Works perfectly, thank you!

Be seeing you,
  norm

--
Norman Tovey-Walsh 
https://nwalsh.com/

> Time is that quality of nature which keeps events from happening all at
> once. Lately it doesn't seem to be working.


signature.asc
Description: PGP signature

Re: Conditionally loading ob-sh or ob-shell

[Loris Bennett]

Hi Steve,

Thanks for that - much more compact.  I didn't know about the
`,-construction.

Cheers,

Loris

Steve Downey  writes:

> My workaround for dealing with different org versions on different machines:
>
>   (org-babel-do-load-languages
>'org-babel-load-languages
>`((perl   . t)
>  (ruby   . t)
>  ,(if (version< org-version "9.0")
>   '(sh . t)
> '(shell  . t))
>  (python . t)
>  (emacs-lisp . t)
>  (C  . t)
>  (dot. t)
>
> On Tue, Apr 21, 2020 at 9:59 AM Loris Bennett  
> wrote:
>
>  Loris Bennett  writes:
>
>  > Hi,
>  >
>  > I want to use one init.el across multiple machines with different
>  > versions of Emacs and Org.  Since 'ob-sh.el' changed to 'ob-shell', I
>  > need to do either
>  >
>  >   (org-babel-do-load-languages
>  >'org-babel-load-languages
>  >'((org . t)
>  >  (emacs-lisp . t)
>  >  (shell . t)
>  >  (perl . t)
>  >  (R . t)
>  >  (matlab . t)
>  >  (gnuplot . t)
>  >  (dot . t)
>  >  (ditaa . t)
>  >  (plantuml . t)
>  >  (sqlite . t)
>  >  (python . t)
>  >  (latex . t)))
>  > or 
>  >
>  >   (org-babel-do-load-languages
>  >'org-babel-load-languages
>  >'((org . t)
>  >  (emacs-lisp . t)
>  >  (sh . t)
>  >  (perl . t)
>  >  (R . t)
>  >  (matlab . t)
>  >  (gnuplot . t)
>  >  (dot . t)
>  >  (ditaa . t)
>  >  (plantuml . t)
>  >  (sqlite . t)
>  >  (python . t)
>  >  (latex . t)))
>  >  
>  > I can obviously use a conditional to test the Emacs or Org version and
>  > execute one block or the other.  However, since the list of languages is
>  > quite long, I would like to avoid repeating it.
>  >
>  > I create init.el from an init.org, so I am open to tangling solutions too.
>  >
>  > Cheers,
>  >
>  > Loris
>
>  I discovered
>
>append org-babel-load-languages 
>
>  and solved the problem like this:
>
>(org-babel-do-load-languages   
>
> 'org-babel-load-languages 
>
> '(
>
>   (org . t)   
>
>   (emacs-lisp . t)
>
>   (perl . t)  
>
>   (R . t) 
>
>   (matlab . t)
>
>   (gnuplot . t)   
>
>   (dot . t)   
>
>   (ditaa . t) 
>
>   (plantuml . t)  
>
>   (sqlite . t)
>
>   (python . t)
>
>   (latex . t)))
>
>(if (string= org-version "8.2.10") 
>
>(org-babel-do-load-languages   
>
> 'org-babel-load-languages 
>
> (append org-babel-load-languages  
>
> '((sh . t 
>
>  (org-babel-do-load-languages 
>
>   'org-babel-load-languages   
>
>   (append org-babel-load-languages
>
>   '((shell . t)   
>
>  The version test is a bit rigid, but
>
>org-version-check
>
>  is deprecated in my newer, primary version of Org and I couldn't work
>  out how to use it anyway 
>
>  Cheers,
>
>  Loris
>
>  -- 
>  This signature is currently under construction.
>
-- 
This signature is currently under construction.