Re: org-table-blank-field key binding removal

[Michael Brand]

Hi all

Then Version 9.6 (or forget) seems right to me.

Michael

Re: How to keep getting org updates

[Greg Minshall]

hi, Tim,

> I think it is always a mistake to google for answers without first
> checking what Emacs has in the built-in documentation and manual. What
> is in the Emacs manual or docstrings for variables and functions is
> guaranteed to be accurate for the version of Emacs your running. What
> you find googling and serching reddit, stack overflow, etc is more often
> than not outdated and from what I've seen, often incorrect. A little
> time getting to learn the help commands bound to C-h will save you much
> time in the long run.  

this is undoubtedly true, though i certainly find myself googling a fair
amount, comparing answers to see if there is consensus.  and, then,
often, using those results to dive into the manual (or the mailing list
archives) to see if i can find "official" guidance.

> Running C-h d v package-pinned-packages shows the following, which
> explains how to set the variable for pinning packages.

for example, i might google, and find that `package-pinned-packages` was
a variable of interest.

i strongly agree that staying an "out-of-the-box" user, setting options
with Emacs' customization interface (and, i guess, using ELPA), is the
way to go if you want to be spared of many details (which can be
daunting, and are approximately infinite :).

but, all that said, didn't some of us on the list (even, iiuc, "out of
the box" users) have problems upgrading from previous ELPA'ish versions
of org-mode to the 9.5 version, because of the confusion of ELPA (?)
non-semantic version numbers appearing to be greater than "9.5"?  that
was really what i was considering, and wondering how to document that
issue in the info pages, so the official documentation will, in fact,
help people upgrade.  (though maybe the answer here is, "stay with the
non-gnu ELPA [or base Emacs] version of org-mode you are currently using
until you upgrade to Emacs 28, at which point you will automatically
follow the box to org-mode 9.5"?)

cheers, Greg

Re: org-table-blank-field key binding removal

[Tim Cross]

Eric Abrahamsen  writes:

> Kyle Meyer  writes:
>
>> Michael Brand writes:
>>
>>> The change is not announced in ORG-NEWS. I think it should be in Version 
>>> 9.4.
>>
>> Right, I agree this change should have come with a NEWS entry, though
>> 0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
>> is from the 9.5 release not 9.4.
>>
>> However, 9.5 is out, and my understanding is that released NEWS sections
>> should not be substantially modified in most cases
>> ().  I'll leave it to
>> the author of the original change and Bastien to decide if they want to
>> make an exception in this case.
>
> I also agree it should have had a NEWS entry (something I never
> remember), but don't have much of an opinion on whether that entry gets
> added after the fact or not!

I agree an entry should have been added in the 9.5 news file. However,
I'm not sure it is a good idea to add one now given that 9.5 has been
released.

The problem with adding one now is that it means 9.5 will have 2
different news files. This could cause confusion as some people will
have a news file which includes the details and some will not. If people
are willing to accept that possible bit of confusion, I would add the
entry, otherwise, leave it and add it to the 9.6 news file (so that at
least the change was documented/tracked, albeit after the fact.

Re: org-table-blank-field key binding removal

[Eric Abrahamsen]

Kyle Meyer  writes:

> Michael Brand writes:
>
>> The change is not announced in ORG-NEWS. I think it should be in Version 9.4.
>
> Right, I agree this change should have come with a NEWS entry, though
> 0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
> is from the 9.5 release not 9.4.
>
> However, 9.5 is out, and my understanding is that released NEWS sections
> should not be substantially modified in most cases
> ().  I'll leave it to
> the author of the original change and Bastien to decide if they want to
> make an exception in this case.

I also agree it should have had a NEWS entry (something I never
remember), but don't have much of an opinion on whether that entry gets
added after the fact or not!

Re: org-table-blank-field key binding removal

[Kyle Meyer]

Michael Brand writes:

> The change is not announced in ORG-NEWS. I think it should be in Version 9.4.

Right, I agree this change should have come with a NEWS entry, though
0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
is from the 9.5 release not 9.4.

However, 9.5 is out, and my understanding is that released NEWS sections
should not be substantially modified in most cases
().  I'll leave it to
the author of the original change and Bastien to decide if they want to
make an exception in this case.

[OT] Ebib file field [was: New user experience ct'd: exporting citations into LaTeX (9.5)]

[Joost Kremers]

On Wed, Oct 13 2021, Leszek Wroński wrote:
> thank you very much for your responses to my previous query. (I will
> study the ebib package more closely; as of now it does not seem to
> work with the file fields in my Mendeley-created .bib file.

This can probably be remedied with a little Elisp. There's a user option
`ebib-file-name-mod-function`, which is called to convert the contents of the
`file` field into a file name that can be passed to a pdf viewer (and vice
versa).

An example is in this Github issue:

https://github.com/joostkremers/ebib/issues/126

If your Elisp fu isn't too strong, I should be able to help.


-- 
Joost Kremers
Life has its moments

[PATCH] org-manual.org: org-cite additions

[Bruce D'Arcus]

This is a minor patch to address the most obvious missing pieces that
have confused people.

Please feel free to modify; I don't really have any experience with
this, and don't have a lot of time.

For example, I'm not clear on conventions for instructing people
whether and how to load a package.

Bruce
From bdd33dd4efc1cd237dd90dc1a5c5741604cfd807 Mon Sep 17 00:00:00 2001
From: Bruce D'Arcus 
Date: Wed, 13 Oct 2021 18:04:20 -0400
Subject: [PATCH] org-manual: minor org-cite additions

* doc/org-manual.org (Handling citations): Add note and example to load
a processor package, and on the PRINT_BIBLIOGRAPHY keyword.
---
 doc/org-manual.org | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 2cb538975..7415d9ece 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -16532,7 +16532,11 @@ capabilities:
 - insert :: Add and edit citations via ~org-cite-insert~.
 - export :: Via different libraries for different target formats.
 
-The user can configure these with ~org-cite-activate-processor~,
+To use a "citation processor", the user must load them; for example;
+
+: (require 'oc-bibtex)
+
+They can then configure them with ~org-cite-activate-processor~,
 ~org-cite-follow-processor~, ~org-cite-insert-processor~, and
 ~org-cite-export-processors~ respectively.
 
@@ -16597,15 +16601,18 @@ Org currently includes the following export processors:
   - csl :: this export processor uses format files written in [[https://en.wikipedia.org/wiki/Citation_Style_Language][Citation
 Style Language]] via [[https://github.com/andras-simonyi/citeproc-el][citeproc-el]];
 
-- In contrast, two other processors target LaTeX and LaTeX-derived
+- In contrast, three other processors target LaTeX and LaTeX-derived
   formats exclusively:
 
-  - natbib :: this export processor uses BibTeX, the historical
+  - bibtex :: this export processor uses BibTeX, the historical
 bibliographic processor used with LaTeX, thus allowing the use of
-data and style files compatible with this processor (including
-a large number of publishers' styles).  It uses citation commands
-implemented in the LaTeX package =natbib=, allowing more stylistic
-variants that LaTeX's =\cite= command.
+data and style files compatible with this processor (including a
+large number of publishers' styles). It only supports LaTeX's
+=\cite= and =\nocite= commands.
+
+  - natbib :: as with the bibtex processor, but using the LaTeX
+package =natbib=, allowing more stylistic variants that LaTeX's
+=\cite= command.
 
   - biblatex :: this backend allows the use of data and formats
 prepared for BibLaTeX, an alternate bibliographic processor used
@@ -16638,6 +16645,11 @@ conformant to the Harvard style and the specification of the
 Wolkers-Kluwer publisher; since it relies on the ~bibtex~ processor of
 your LaTeX installation, it won't export to anything but PDF.
 
+The =PRINT_BIBLIOGRAPHY= keyword specifies where the bibliography
+should print.
+
+: #+print_bibliography:
+
 * Working with Source Code
 :PROPERTIES:
 :DESCRIPTION: Export, evaluate, and tangle code blocks.
-- 
2.33.0

Re:Re: New user experience ct'd: exporting citations into LaTeX (9.5)

[tumashu]

#+print_bibliography seem to not document in info.
(require 'oc-csl) is not too.







--
发自我的网易邮箱手机智能版



- Original Message -
From: "Bruce D'Arcus" 
To: "Leszek Wroński" 
Cc: org-mode-email 
Sent: Wed, 13 Oct 2021 17:34:50 -0400
Subject: Re: New user experience ct'd: exporting citations into LaTeX (9.5)

Try adding this where you want the bibliography.


#+print_bibliography:






On Wed, Oct 13, 2021 at 5:27 PM Leszek Wroński  wrote:
>
> Guys,
>
> thank you very much for your responses to my previous query. (I will
> study the ebib package more closely; as of now it does not seem to
> work with the file fields in my Mendeley-created .bib file. (Yes, I
> promise will stop using Mendeley.))
>
> I wanted to try the two LaTeX export processors mentioned in the 15.2
> section of the manual: natbib and biblatex. My .org file has a
> #+bibliography line specifying my .bib (which is correct, since
> inserting citations is now working). I put both (use-package
> oc-natbib) and (use-package oc-biblatex) in my .emacs . (I've used
> natbib for years when writing .tex documents; I don't know biblatex.)
>
> The situation is as follows:
> -- if I put #+cite_export: natbib at the beginning of my .org file,
> then C-c C-e l L gives me a LaTeX file which does *not* specify the
> .bib file; it has \citep{} commands where they should be, but of
> course bibtex doesn't know what to do with them;
> -- if I use #+cite_export: biblatex instead, then the resulting .tex
> file does contain the \addbibresource{} line pointing to my .bib , and
> \autocite{} commands where citations should be; however, I simply
> cannot get this to work: Biber works alright, but eventually pdflatex
> gives me the following error:
>
> --
> ERROR: LaTeX3 Error: Mismatched LaTeX support files detected.
>
> --- TeX said ---
> (LaTeX3)Loading 'l3backend-pdftex.def' aborted!
> (LaTeX3)
> (LaTeX3)The L3 programming layer in the LaTeX format
> (LaTeX3)is dated 2021-01-09, but in your TeX tree the files require
> (LaTeX3)at least 2021-02-18.
> ---
>
> which I'm unable to get rid of. (This is of course not a question for
> this group but if anyone had similar problems I'd be grateful for
> pointers ;-);  fmtutil-sys --all and fmtutil-user --all did nothing to
> alleviate this)
>
> So: I'd really like to keep using natbib and make it somehow insert
> the information about the .bib file into the .tex when exporting. How
> do I do that?
>
> Thank you again for your help!
>
> Best regards,
>
> Leszek.
>

Re: New user experience ct'd: exporting citations into LaTeX (9.5)

[Bruce D'Arcus]

Try adding this where you want the bibliography.

#+print_bibliography:

On Wed, Oct 13, 2021 at 5:27 PM Leszek Wroński  wrote:
>
> Guys,
>
> thank you very much for your responses to my previous query. (I will
> study the ebib package more closely; as of now it does not seem to
> work with the file fields in my Mendeley-created .bib file. (Yes, I
> promise will stop using Mendeley.))
>
> I wanted to try the two LaTeX export processors mentioned in the 15.2
> section of the manual: natbib and biblatex. My .org file has a
> #+bibliography line specifying my .bib (which is correct, since
> inserting citations is now working). I put both (use-package
> oc-natbib) and (use-package oc-biblatex) in my .emacs . (I've used
> natbib for years when writing .tex documents; I don't know biblatex.)
>
> The situation is as follows:
> -- if I put #+cite_export: natbib at the beginning of my .org file,
> then C-c C-e l L gives me a LaTeX file which does *not* specify the
> .bib file; it has \citep{} commands where they should be, but of
> course bibtex doesn't know what to do with them;
> -- if I use #+cite_export: biblatex instead, then the resulting .tex
> file does contain the \addbibresource{} line pointing to my .bib , and
> \autocite{} commands where citations should be; however, I simply
> cannot get this to work: Biber works alright, but eventually pdflatex
> gives me the following error:
>
> --
> ERROR: LaTeX3 Error: Mismatched LaTeX support files detected.
>
> --- TeX said ---
> (LaTeX3)Loading 'l3backend-pdftex.def' aborted!
> (LaTeX3)
> (LaTeX3)The L3 programming layer in the LaTeX format
> (LaTeX3)is dated 2021-01-09, but in your TeX tree the files require
> (LaTeX3)at least 2021-02-18.
> ---
>
> which I'm unable to get rid of. (This is of course not a question for
> this group but if anyone had similar problems I'd be grateful for
> pointers ;-);  fmtutil-sys --all and fmtutil-user --all did nothing to
> alleviate this)
>
> So: I'd really like to keep using natbib and make it somehow insert
> the information about the .bib file into the .tex when exporting. How
> do I do that?
>
> Thank you again for your help!
>
> Best regards,
>
> Leszek.
>

New user experience ct'd: exporting citations into LaTeX (9.5)

[Leszek Wroński]

Guys,

thank you very much for your responses to my previous query. (I will
study the ebib package more closely; as of now it does not seem to
work with the file fields in my Mendeley-created .bib file. (Yes, I
promise will stop using Mendeley.))

I wanted to try the two LaTeX export processors mentioned in the 15.2
section of the manual: natbib and biblatex. My .org file has a
#+bibliography line specifying my .bib (which is correct, since
inserting citations is now working). I put both (use-package
oc-natbib) and (use-package oc-biblatex) in my .emacs . (I've used
natbib for years when writing .tex documents; I don't know biblatex.)

The situation is as follows:
-- if I put #+cite_export: natbib at the beginning of my .org file,
then C-c C-e l L gives me a LaTeX file which does *not* specify the
.bib file; it has \citep{} commands where they should be, but of
course bibtex doesn't know what to do with them;
-- if I use #+cite_export: biblatex instead, then the resulting .tex
file does contain the \addbibresource{} line pointing to my .bib , and
\autocite{} commands where citations should be; however, I simply
cannot get this to work: Biber works alright, but eventually pdflatex
gives me the following error:

--
ERROR: LaTeX3 Error: Mismatched LaTeX support files detected.

--- TeX said ---
(LaTeX3)Loading 'l3backend-pdftex.def' aborted!
(LaTeX3)
(LaTeX3)The L3 programming layer in the LaTeX format
(LaTeX3)is dated 2021-01-09, but in your TeX tree the files require
(LaTeX3)at least 2021-02-18.
---

which I'm unable to get rid of. (This is of course not a question for
this group but if anyone had similar problems I'd be grateful for
pointers ;-);  fmtutil-sys --all and fmtutil-user --all did nothing to
alleviate this)

So: I'd really like to keep using natbib and make it somehow insert
the information about the .bib file into the .tex when exporting. How
do I do that?

Thank you again for your help!

Best regards,

Leszek.

Re: How to keep getting org updates

[Tim Cross]

Galaxy Being  writes:

> Appreciate the help and encouragement. This pinning business ... seems like 
> musical chairs with different suggestions here and
> there. Should I use this suggestion, or maybe this one, or...? And where is 
> the maintained list of packages? I see
> .../elpa/archives/ but don't see anything else. Sorry to be a help vampire, 
> but I've never gotten past "casual Emacs user" status
> and don't think I ever will with my hectic schedule.
>

I think it is always a mistake to google for answers without first
checking what Emacs has in the built-in documentation and manual. What
is in the Emacs manual or docstrings for variables and functions is
guaranteed to be accurate for the version of Emacs your running. What
you find googling and serching reddit, stack overflow, etc is more often
than not outdated and from what I've seen, often incorrect. A little
time getting to learn the help commands bound to C-h will save you much
time in the long run.  

Running C-h d v package-pinned-packages shows the following, which
explains how to set the variable for pinning packages. 

package-pinned-packages is a variable defined in ‘package.el’.

Its value is nil

An alist of packages that are pinned to specific archives.
This can be useful if you have multiple package archives enabled,
and want to control which archive a given package gets installed from.

Each element of the alist has the form (PACKAGE . ARCHIVE), where:
 PACKAGE is a symbol representing a package
 ARCHIVE is a string representing an archive (it should be the car of
an element in ‘package-archives’, e.g. "gnu").

Adding an entry to this variable means that only ARCHIVE will be
considered as a source for PACKAGE.  If other archives provide PACKAGE,
they are ignored (for this package).  If ARCHIVE does not contain PACKAGE,
the package will be unavailable.

  This variable may be risky if used as a file-local variable.
  This variable was introduced, or its default value was changed, in
  version 24.4 of Emacs.
  You can customize this variable.

So you would probably want something like

(setq package-pinned-packages '(('org . "gnu")))

assuming "gnu" is the name associated with the elpa.gnu.org archive.

There is also a good overview of the package management system in the
Emacs manual. Reading this will provide all the details you need and
often provide more than one possible solution. For example, you can also
set the priority of different archives so that packages from one archive
will have a higher priority than the same package from another archive.

The list of installed packages I was referring to is in the 'custom'
section of your init file and is called package-selected-packages. The
C-h d v for this variable is


Store here packages installed explicitly by user.
This variable is fed automatically by Emacs when installing a new package.
This variable is used by ‘package-autoremove’ to decide
which packages are no longer needed.
You can use it to (re)install packages on other machines
by running ‘package-install-selected-packages’.

To check if a package is contained in this list here, use
‘package--user-selected-p’, as it may populate the variable with
a sane initial value.

  This variable was introduced, or its default value was changed, in
  version 25.1 of Emacs.
  You can customize this variable.

If your short on time and don't feel you can spend time to get into the
guts of Emacs, then I would also recommend reading the manual section on
customization and use the built-in Emacs customize interface to
configure your system rather than a hand crafted init.el file. 

I think you have two choices when it comes to Emacs. Either you stick
with what comes 'out of the box', which includes adding additional
packages from the standard ELPA and non-gnu ELPA repositories and use
the built in custom system to configure emacs, which has
the advantage of requiring minimal knowledge/understanding of the Emacs
ecosystem or you decide to be more advanced and update to latest
versions of some/all of the things you use, which requires more effort
and time spent to learn more of the intricacies of the ecosystem.

The worst approach is to crate an emacs init.el file filled with little
bits of elisp gathered from various forums which you don't really
understand. While this might make it appear to work OK, it leaves you
high and dry when something stops working and you cannot fix it.

> On Wed, Oct 13, 2021 at 4:55 AM Greg Minshall  wrote:
>
>  > The install instructions on the main org page were not very clear, to
>  > say the least.
>
>  yes, that does sound messy.  sorry your experience was so unfortunate.
>
>  i guess one question for the list: is there a general solution to the
>  "20200912" > "9.5" issue?  or, "now" that we are only distributing via
>  [git repository and] gnu elpa, will that issue disappear?  does this
>  new-fangled concept of "semantic versioning" come into play here?
>
>  possibly in the info pages we could 

Re: org-table-blank-field key binding removal

[Michael Brand]

Hi all

The change is not announced in ORG-NEWS. I think it should be in Version 9.4.

Michael

Re: Manual suggestion and experience report from a new user (citation processors, 9.5)

[Peter Neilson]

On Wed, 13 Oct 2021 11:33:16 -0400, Leszek Wroński   
wrote:



Guys,

I've been using Emacs for about 20 years, but I'm only now starting to
seriously explore the Org-mode, since I read about the new citation
options. I'd like to report my initial experience since maybe this
could lead to some amendments to the manual?


%snip%

Thank you for reporting. The "new user" experience can only be captured  
once, and it is all too common for the experienced user to omit "obvious"  
material from documentation. Some day I might go through all the org docs  
wearing my "new user" hat. I'm not a real new user (emacs since about  
1976, TECO before that) but my old-age forgetfulness might help.

Re: Manual suggestion and experience report from a new user (citation processors, 9.5)

[Bruce D'Arcus]

On Wed, Oct 13, 2021, 1:41 PM Leszek Wroński  wrote:

> Thank you very much! I will explore more. The keys are correct. On
> reopening the .org file, the behavior is now consistent: clicking on
> any citation does nothing :-)


Try org-open-at-point. That at least should work.

Bruce

Re: Manual suggestion and experience report from a new user (citation processors, 9.5)

[Leszek Wroński]

Thank you very much! I will explore more. The keys are correct. On
reopening the .org file, the behavior is now consistent: clicking on
any citation does nothing :-) I will try to experiment with your
processor. I did manage to configure org-ref-cite to open PDFs a few
months ago, but when trying to combine it with org-roam and helm I
managed to screw up my configuration and so I'm now starting from
scratch more carefully.

Best regards,

Leszek.

On Wed, 13 Oct 2021 at 19:00, Bruce D'Arcus  wrote:
>
> Forgot to reply-all ...
>
> On Wed, Oct 13, 2021 at 11:36 AM Leszek Wroński  wrote:
>
> > I've been using Emacs for about 20 years, but I'm only now starting to
> > seriously explore the Org-mode, since I read about the new citation
> > options. I'd like to report my initial experience since maybe this
> > could lead to some amendments to the manual?
>
> Your suggestions make a lot of sense.
>
> > Another thing: the way the citations work is inconsistent for me at
> > this point. In some cases, a click on a citation opens my library.bib
> > at the relevant entry. In other cases, nothing happens (i.e. nothing
> > that I can see.) On what could this depend?
>
> I don't know. Is the key by chance wrong?
>
> > Ideally I'd like a click on a citation to open the PDF whose location
> > is stored in the 'file' field of the .bib entry: is there an easy way
> > to achieve this? [I've tried various ways of doing this in the last
> > 10+ years, including org-ref, RefTex etc., but am I correct in
> > assuming that currently the idea is that one should only use the
> > Org-mode for such things?]
>
> As for the "follow" functionality you're asking about, this is mostly
> what third party processors are for; "oc-basic" is intentionally
> "basic".
>
> This landscape is still new, but my oc-bibtex-actions one allows you,
> for example, to use embark to run different actions from an org-cite
> citation. By default it will open associated documents or links.
>
> https://github.com/bdarcus/bibtex-actions
>
> John Kitchin's org-ref-cite does similar with a hydra menu, though I'm
> unsure of his plans for the package.
>
> https://github.com/jkitchin/org-ref-cite
>
> Bruce

Re: Manual suggestion and experience report from a new user (citation processors, 9.5)

[M . ‘quintus’ Gülker]

Am Mittwoch, dem 13. Oktober 2021 schrieb Leszek Wroński:
> Ideally I'd like a click on a citation to open the PDF whose location
> is stored in the 'file' field of the .bib entry: is there an easy way
> to achieve this? [I've tried various ways of doing this in the last
> 10+ years, including org-ref, RefTex etc., but am I correct in
> assuming that currently the idea is that one should only use the
> Org-mode for such things?]

Maybe it helps you: I use ebib for managing my .bib files. While I have
not yet tried directly to jump from a citation key in an .org file to
the corresponding ebib entry, I suppose there is a way. In ebib then it
is as easy as pressing “f” to open the PDF referenced in the “file”
field.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Manual suggestion and experience report from a new user (citation processors, 9.5)

[Bruce D'Arcus]

Forgot to reply-all ...

On Wed, Oct 13, 2021 at 11:36 AM Leszek Wroński  wrote:

> I've been using Emacs for about 20 years, but I'm only now starting to
> seriously explore the Org-mode, since I read about the new citation
> options. I'd like to report my initial experience since maybe this
> could lead to some amendments to the manual?

Your suggestions make a lot of sense.

> Another thing: the way the citations work is inconsistent for me at
> this point. In some cases, a click on a citation opens my library.bib
> at the relevant entry. In other cases, nothing happens (i.e. nothing
> that I can see.) On what could this depend?

I don't know. Is the key by chance wrong?

> Ideally I'd like a click on a citation to open the PDF whose location
> is stored in the 'file' field of the .bib entry: is there an easy way
> to achieve this? [I've tried various ways of doing this in the last
> 10+ years, including org-ref, RefTex etc., but am I correct in
> assuming that currently the idea is that one should only use the
> Org-mode for such things?]

As for the "follow" functionality you're asking about, this is mostly
what third party processors are for; "oc-basic" is intentionally
"basic".

This landscape is still new, but my oc-bibtex-actions one allows you,
for example, to use embark to run different actions from an org-cite
citation. By default it will open associated documents or links.

https://github.com/bdarcus/bibtex-actions

John Kitchin's org-ref-cite does similar with a hydra menu, though I'm
unsure of his plans for the package.

https://github.com/jkitchin/org-ref-cite

Bruce

Manual suggestion and experience report from a new user (citation processors, 9.5)

[Leszek Wroński]

Guys,

I've been using Emacs for about 20 years, but I'm only now starting to
seriously explore the Org-mode, since I read about the new citation
options. I'd like to report my initial experience since maybe this
could lead to some amendments to the manual?

Anyway: I installed Org 9.5 from Melpa in Emacs 27.1. I proceeded
through the 'Installation' part in the online manual, so the only
things I put into .emacs were the rudimentary keybindings. I then
switched to the 15.1 Citations chapter and created a file the first
line of which pointed to my library.bib. The introduction to chapter
15 says 'The included “basic” processor provides all four
capabilities.' (w.r.t. 'activate', 'follow', 'insert', 'export'). I
thus assumed that the basic processor was included. However,
org-cite-insert ended with 'Unknown processor basic'.

After reading the list I put "(use-package oc-basic)" in my .emacs.
Since then I can get the citations to appear in my org file. So that's
one thing that could be helpful to new users: even though the citation
processors are included, you have to manually enable them in the
.emacs, e.g. using use-package. [If I'm wrong, please correct me, I'm
new to this and I'm trying to help.]

Another thing: the way the citations work is inconsistent for me at
this point. In some cases, a click on a citation opens my library.bib
at the relevant entry. In other cases, nothing happens (i.e. nothing
that I can see.) On what could this depend?

Ideally I'd like a click on a citation to open the PDF whose location
is stored in the 'file' field of the .bib entry: is there an easy way
to achieve this? [I've tried various ways of doing this in the last
10+ years, including org-ref, RefTex etc., but am I correct in
assuming that currently the idea is that one should only use the
Org-mode for such things?]

Thanks to everyone involved for their hard work!

Best regards,

Leszek Wronski

Re: How to keep getting org updates

[Galaxy Being]

Appreciate the help and encouragement. This pinning business ... seems like
musical chairs with different suggestions here and there. Should I use this

suggestion,
or maybe this

one, or...? And where is the maintained list of packages? I see
.../elpa/archives/ but don't see anything else. Sorry to be a help vampire,
but I've never gotten past "casual Emacs user" status and don't think I
ever will with my hectic schedule.

On Wed, Oct 13, 2021 at 4:55 AM Greg Minshall  wrote:

> > The install instructions on the main org page were not very clear, to
> > say the least.
>
> yes, that does sound messy.  sorry your experience was so unfortunate.
>
> i guess one question for the list: is there a general solution to the
> "20200912" > "9.5" issue?  or, "now" that we are only distributing via
> [git repository and] gnu elpa, will that issue disappear?  does this
> new-fangled concept of "semantic versioning" come into play here?
>
> possibly in the info pages we could have a section on
> "re-installing/upgrading", to help people navigate this process.  (once
> we, ourselves, have a map.)
>
> cheers, Greg
>


-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com

Re: Customization of IDs generation method

[Ihor Radchenko]

Ypo  writes:

> How would the "New option org-id-ts-format" work?
>
> I added to my init.el these lines with no result (sorry if I am 
> commiting heresy):
>
> (defcustom org-id-ts-format "%Y-%m-%d-T%H-%M-%S.%6N"
>    "Timestamp format for IDs generated using `ts' `org-id-method'.
> The format should be suitable to pass as an argument to 
> `format-time-string'.
> Defaults to ISO8601 timestamps without separators and without
> timezone, local time and precision down to 1e-6 seconds."
>    :type 'string
>    :package-version '(Org . "9.5"))

Hmm. Did you literally add this "defcustom" code?
You should either use Emacs customize interface
(see 49.1 Easy Customization Interface section of Emacs manual)
or use setq (see 49.4.2 Init File Examples) like the following:

(setq org-id-method 'ts)
(setq org-id-ts-format "%Y-%m-%d-T%H-%M-%S.%6N")

Hope it helps.

Best,
Ihor

bug#51167: 29.0.50; org-indent-line broken

[Max Nikulin]

On 13/10/2021 01:35, Kévin Le Gouguec wrote:

Andreas Röhler writes:


With following stuff in org-mode buffer:

* bla
asd

M-x org-indent-line RET on second line has no effect.


Andreas, do the following settings make behavior consistent with you 
expectations?


(add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
(setq org-adapt-indentation t)

Have in mind that TAB is a rather busy key in Org. Besides indentation 
it is used for fold-reveal cycle for headings, list items, drawers, 
source code blocks and examples.


On 13/10/2021 14:34, Kévin Le Gouguec wrote:

Or are you saying you would like org-indent-line to also indent "* bla",
because « a command called "indent-line definitely should indent »?


* Is a heading

  * List item.
Another line of list item
*
#^---

TAB indents here. However there is no zero indent in the cycle and it 
might be considered as a bug.


On 13/10/2021 13:47, Andreas Röhler wrote:

Maybe make RET RET again?


Now I am confused if TAB or RET makes you unhappy. `org-indent-line' has 
closer relations with TAB than with RET.

Re: A minor suggestion about formatting citations

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> On Mon, Oct 11, 2021 at 11:54 AM Nicolas Goaziou  
> wrote:

>> I don't think that's totally true. The additional space makes sense
>> typographically, in particular when some suffix is associated to the
>> key.
>
> Can you give an example of what you mean here? I can't think of one
> off the top-of-my-head.

I mean that it seems natural to write, e.g.,

 [cite:@doe21 p. 1; @doe99]

instead of 

  [cite:@doe21 p. 1;@doe99]

>> Org Cite is unrelated to this. One could as well have inserted spaces
>> manually, i.e., without calling `org-cite-insert' at all.
>
> I know; but you changed the default behavior of 
> org-cite-make-insert-processor.
>
> The OP asked if there were any implications for this generally, and
> I'm just saying "yes, there is."

OK. Then, we are in a violent agreement. :)

> You do have to trim the whitespace on either side of the key, since
> the space is the delimiter. I guess it's not possible for the citation
> parser to ignore the other whitespace?

I'm not sure to understand your question. The space is not the
delimiter; the semicolon is.

For now, the whitespaces are significant for the parser, barring the
leading and trailing ones. It seemed useful for export back-end and
citation processor combinations unable to handle punctuation
automatically (e.g., HTML + oc-basic). I can't tell if they should be
ignored instead.

>> The functions responsible for swapping citations ought to cope with this 
>> situation
>> too.
>
> So check if the content of an affix, for example, is " " (rather than
> whether there's an affix), and adjust accordingly?

I don't think you need to check affixes when cycling citation
references. You could split at ";", trim, re-order, and re-build the
contents inserting "; " between each reference.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Eric S Fraga]

On Wednesday, 13 Oct 2021 at 19:23, Max Nikulin wrote:
> Does someone have settings that pins help buffer to particular
> window/frame of location in a frame (e.g. bottom of "sidebar")?

This is what I use, which is slightly more complex because I have a wide
landscape monitor and a tall portrait one and want different behaviour
in each:

#+begin_src emacs-lisp
  (defun esf/display-buffer-in-side-window (buffer alist)
(let ((fw (/ 80.0 (frame-width
  (display-buffer-in-side-window buffer
 (if (> (frame-width) 120)
 (list (cons 'window-width fw)
   '(side . left)
   '(slot . 0)) 
   '((window-height . 0.25)
 (side . bottom)
 (slot . 0)) 
  (setq display-buffer-alist
'(("^\\*Async Shell Command*" . (display-buffer-no-window))
  ("^magit-[a-z]+: " . (esf/display-buffer-in-side-window))
  ("\\*\\(Backtrace\\|Compile-Log\\|DICT 
.*\\|grep\\|[Hh]elp.*\\|Messages\\|Occur\\|tex-shell\\|vc-\\(diff\\|change-log\\)\\|Warnings\\|WoMan
 .*\\)\\*"
   (esf/display-buffer-in-side-window
#+end_src 

This doesn't pin to a specific frame but does make the pop-ups appear in
the same place always in each respectively frame.  By the way, I use
exwm so I have one frame per monitor, full screen, generally.

HTH,
eric

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Max Nikulin]

On 13/10/2021 16:44, Marco Wahl wrote:


Clearly I'm for kicking out org-no-popups completely.  Many details have
been mentioned already.  The big argument for that change for me is that
the code gets simpler.


I have no strong opinion. Second patch locally restoring 
`pop-up-windows' is more suitable for the bugfix branch since it is 
closer to older behavior. Dropping the macro completely may be a step to 
future, so first version of patch is more suitable for main (do not 
forget to drop other variant during merge however).


I am not confident with complicated `display-buffer' machinery. It has 
action argument that looks promising to specify local hint to override 
default actions but to let users customize `display-buffer-alist'. I 
have no idea of particular hint for `org-goto' though. Unfortunately 
`with-output-to-temp-buffer' used there does not allow to specify action 
argument for `display-buffer'. Unsure if `temp-buffer-setup-hook' can be 
used to prepare a window for `display-buffer'.


Does someone have settings that pins help buffer to particular 
window/frame of location in a frame (e.g. bottom of "sidebar")?

Re: How to keep getting org updates

[Greg Minshall]

> The install instructions on the main org page were not very clear, to
> say the least.

yes, that does sound messy.  sorry your experience was so unfortunate.

i guess one question for the list: is there a general solution to the
"20200912" > "9.5" issue?  or, "now" that we are only distributing via
[git repository and] gnu elpa, will that issue disappear?  does this
new-fangled concept of "semantic versioning" come into play here?

possibly in the info pages we could have a section on
"re-installing/upgrading", to help people navigate this process.  (once
we, ourselves, have a map.)

cheers, Greg

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Marco Wahl]

Thanks Ihor!

> Marco Wahl  writes:
>
>> My feeling is that the "protection" is good intention but brings more
>> harm than good.  I think it's not a good idea to enforce a certain
>> window setting.  I guess the knowing user has an easier path to fine
>> tune the org-goto user interface when there is less "protection".
>
> I fully agree. That was the motivation behind removing
> dislpay-buffer-alist in 399481bad1. It is indeed not a good idea to
> overwrite user customisations. They can be deliberate. For example, see
> https://orgmode.org/list/87h7ij12t8.fsf@localhost
>
> Max Nikulin  writes:
>> However current version of macro does not protect against
>> 
>>(setq display-buffer-base-action
>>   '((display-buffer-reuse-window display-buffer-pop-up-frame)
>> (reusable-frames . 0)))
>> 
>> The example is taken from (info "(elisp) Choosing Window Options"). I 
>> have no idea if such customization can be considered as shooting a foot.
>
> display-buffer-base-action, if customised by user, can later be
> fine-tuned using display-buffer-alist. If necessary, the user can easily
> add org-goto popup as an exception. At least, it is my understanding
> from reading docs.
>
> However, pop-up-frames and pop-up-windows are different beasts. They
> cannot be fine-tuned by the user to not affect org-goto.  AFAIK, the
> only way for the user to overcome the problem would be advicing
> org-goto.
>
>> Summary: The org-goto interface today is somewhat broken.  I vote for
>> taking the occasion and kicking out the macro org-no-popups entirely.
>> This way the org-goto interface is functional AFAICS.  If problems occur
>> on that path we'll take care and action.
>>
>> Do you agree?
>
> My second version of the patch also fixes org-goto interface :)

Indeed, thanks.

> On the other hand, kicking org-no-popups macro completely may be an
> option. pop-up-windows and pop-up-frames are obsolete and should not be
> used anymore.
>
> Also, a compromise could be changing org-no-popups to just
> (let (pop-up-frames) ...)
>
> WDYT?

Clearly I'm for kicking out org-no-popups completely.  Many details have
been mentioned already.  The big argument for that change for me is that
the code gets simpler.

But that's just me.  All the other fixes may have advantages too.  In
the first place I want back a usable org-goto interface.

I'd like to leave it to you to commit a fix.


Best regards,
-- 
Marco

bug#51167: 29.0.50; org-indent-line broken

[Kévin Le Gouguec]

Andreas Röhler  writes:

> On 13.10.21 09:34, Kévin Le Gouguec wrote:
>>
>> "Modern" did not factor in; the goal was to have RET and C-j behave
>> consistently in all major modes.
>
> That does not deliver an argument to change the meaning of RET.

If there is a compelling argument that justifies RET and C-j behaving
differently in Org wrt other major modes, I haven't heard it yet.

> BTW the costs of such changes are terribly underestimated in Emacs.

AFAICT, the costs of user-facing changes are regularly discussed on the
Emacs development lists, and different developers have different
opinions on how underestimated they are.

In the specific case of RET and C-j, I'd argue (and Org maintainers seem
to have agreed) that the long-term benefits of Org falling in line with
other modes outweigh the short-term costs of annoying long-time users,
especially since they are offered ways to bring back the previous
behaviour (outlined in ORG-NEWS).

And in the specific case of org-adapt-indentation, again, changing the
default to nil was the result of extensive discussion on emacs-orgmode,
where several users explicitly stated that they did not want text to be
indented (neither with RET, C-j, TAB, nor org-indent-line) and never
realized that org-adapt-indentation was t because Org ignored
electric-indent-mode before 9.4.

>> Since electric-indent-mode is enabled globally in Emacs,
>
> Which IMO was another mistake.
>
> Preferring a clean editor, which does fancy things only if enabled.

There are plenty of things Emacs does by default that I personally find
unhelpful; fortunately I can just disable them.  And as long as release
notes point out changes in default behaviour (and how to revert them),
I'm happy with new releases enabling new features.

YMMV 路

Re: org-beamer empty titles

[Joseph Vidal-Rosset]

To Eric and to Ihor, many thanks. My problem was already solved by Eric
with the LateX magic trick, so, I consider now that the problem is solved.

Best wishes,

Jo.

Le 13/10/2021 à 09:50, Ihor Radchenko a écrit :
> Joseph Vidal-Rosset  writes:
>
>> Maybe. I'm using presently Prelude Emacs and in elpa I have org-20210920/
>>
>> What can I do?
>
> I guess https://prelude.emacsredux.com/en/latest/support/
> ELPA does have the right Org mode version:
> http://elpa.gnu.org/packages/org.html
>

bug#51167: 29.0.50; org-indent-line broken

[Andreas Röhler]

On 13.10.21 09:34, Kévin Le Gouguec wrote:

Andreas Röhler  writes:


Sounds like a chain of confusion.

A command called "indent-line" definitely should indent.

org-indent-line indents just like every indentation function in every
other major mode: if the syntactic convention calls for it, it indents
or de-indents the current line; otherwise it leaves the line untouched.

Or are you saying you would like org-indent-line to also indent "* bla",
because « a command called "indent-line definitely should indent »?


Seems the original coulprit is that unhappy switch of RET and C-j, in
order to make Emacs "modern".

"Modern" did not factor in; the goal was to have RET and C-j behave
consistently in all major modes.


That does not deliver an argument to change the meaning of RET.

BTW the costs of such changes are terribly underestimated in Emacs.


Maybe make RET RET again?

After much discussion on emacs-orgmode, it has been found that a lot of
users expect neither (1) their prose to be indented, nor (2) RET to
indent.

Since electric-indent-mode is enabled globally in Emacs,


Which IMO was another mistake.

Preferring a clean editor, which does fancy things only if enabled.


RET indents
according to the major mode's indentation rules.  Thus it was decided to
change the default value of org-adapt-indentation, to reflect the
expectations of the Org users who took the time to chime in on the
mailing list to describe their workflow and expectations.

If you think the default value should be reverted back to t, I suggest
you make your case on emacs-orgmode.

Re: org-beamer empty titles

[Ihor Radchenko]

Joseph Vidal-Rosset  writes:

> Maybe. I'm using presently Prelude Emacs and in elpa I have org-20210920/
>
> What can I do?

I guess https://prelude.emacsredux.com/en/latest/support/
ELPA does have the right Org mode version:
http://elpa.gnu.org/packages/org.html

bug#51167: 29.0.50; org-indent-line broken

[Kévin Le Gouguec]

Andreas Röhler  writes:

> Sounds like a chain of confusion.
>
> A command called "indent-line" definitely should indent.

org-indent-line indents just like every indentation function in every
other major mode: if the syntactic convention calls for it, it indents
or de-indents the current line; otherwise it leaves the line untouched.

Or are you saying you would like org-indent-line to also indent "* bla",
because « a command called "indent-line definitely should indent »?

> Seems the original coulprit is that unhappy switch of RET and C-j, in
> order to make Emacs "modern".

"Modern" did not factor in; the goal was to have RET and C-j behave
consistently in all major modes.

> Maybe make RET RET again?

After much discussion on emacs-orgmode, it has been found that a lot of
users expect neither (1) their prose to be indented, nor (2) RET to
indent.

Since electric-indent-mode is enabled globally in Emacs, RET indents
according to the major mode's indentation rules.  Thus it was decided to
change the default value of org-adapt-indentation, to reflect the
expectations of the Org users who took the time to chime in on the
mailing list to describe their workflow and expectations.

If you think the default value should be reverted back to t, I suggest
you make your case on emacs-orgmode.

Re: org-beamer empty titles

[Eric S Fraga]

On Tuesday, 12 Oct 2021 at 17:35, Joseph Vidal-Rosset wrote:
> Maybe. I'm using presently Prelude Emacs and in elpa I have org-20210920/

I don't know.  Sorry.

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Best way to include METAPOST in ConTeXt exporter

[Ihor Radchenko]

Jason Ross  writes:

>> Or you can use "raw" results by default and format everything as you
>> wish in your Org Babel module programatically.
>
> I'm not sure I understand this yet. Would this emit METAPOST code to the
> Org buffer? Ideally, I'd like to emit METAPOST code if the backend is
> `context`, otherwise, emit a file.

A hackish way would be detecting if you are executing code during export
and emitting different results (say, you may look at
org-export-current-backend).  However, it will do nothing when user
specifies :results file

Best,
Ihor

Re: Best way to include METAPOST in ConTeXt exporter

[Ihor Radchenko]

Jason Ross  writes:

> Here's a hook that modifies the source blocks to wrap their
> output in #+BEGIN/END_METAPOST tags if the ConTeXt backend is used,
> before Org Babel gets to them, but otherwise leaves them alone.
>
> I wonder if anyone has any better ideas of how to do this. I'm
> modifying the Org source with the hook before the document gets parsed
> so that it can be more backend-agnostic but it seems like it would
> be better if there was a way to modify the document parse tree
> directly instead. I don't like that I'm effectively parsing and
> rebuilding (hopefully) the same string in order to change the :result
> type.

I am not sure if there is an easy way. ob-exp gets run before backend
filters and you do not yet have access to the document parse tree.

You may consider a patch for ob-exp to get better control over code
execution during export.

Best,
Ihor

bug#51167: 29.0.50; org-indent-line broken

[Andreas Röhler]

On 12.10.21 20:35, Kévin Le Gouguec wrote:

Andreas Röhler  writes:


With following stuff in org-mode buffer:

* bla
asd

M-x org-indent-line RET on second line has no effect.

Org 9.5 changed the default value of org-adapt-indentation from t to
nil, as that seemed to be what a lot of users expect[1], so
org-indent-line should not indent the second line in Emacs 28 onward
unless configured otherwise:

- setting org-adapt-indentation back to t will make Org indent by
   inserting whitespace;

- alternatively, enabling org-indent-mode will make Org "soft-indent"
   with text properties.


[1] Org 9.4 made RET and C-j obey electric-indent-mode like they do in
 most other major modes.  Since org-adapt-indentation was t by
 default, this led to many dismayed reports on emacs-orgmode that
 "RET now messes up indentation", indicating that these users did not
 expect their prose to be indented.



Sounds like a chain of confusion.

A command called "indent-line" definitely should indent.

Seems the original coulprit is that unhappy switch of RET and C-j, in 
order to make Emacs "modern".


Maybe make RET RET again?