Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Nicolas Goaziou  writes:

> Hello,
>
> Ihor Radchenko  writes:
>
>>> Thanks Ihor, I indeed found related code in Org Mode source. I implemented a
>>> similar functionality in my patch.
>>
>> Oh. I somehow missed your first message...
>>
>> Now, actually adding something to the discussion.
>>
>> FYI, there is org-cycle-include-plain-lists variable. If it is set to
>> 'integrate, plain lists will be included into cycling with point at
>> headline. This is against the logic that org-cycle only needs to be
>> dealing with headlines. So, I don't see your patch breaking the present
>> conventions in org.
>
> Yes, this `integrate' value is not great, IMO. However, plain lists have
> much more in common with headlines than with drawers.
>
> I still think basic cycling should not include drawers whatsoever. This
> is even more true for properties drawers.
>
> Note that you can already display drawers with `org-cycle', using three
> prefix arguments.

I agree. As I described in my given example "org-contacts", which include person
info in properties drawer. That's why I want to expand when I press "Tab" on
expanding headline. If I see a contact's info with "C-u C-u C-u Tab" is not
convenient.

As for this negation, I can accept.

Is it possible to change "org-cycle-hide-drawers" to "org-cycle-toggle-drawers".
Make it more extendable. Because that function only changed one argument of
"org-flag-drawer". If so some user like me will be easy to toggle hide/show
drawers. (Of course, I don't want to add redundant code in my Emacs init.) If
this is fine, I will re-edit my patch. Remove defcustom option, and hook on
cycle. Only keep changes in "org-cycle-hide-drawers".

- -- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6VSEgUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsMFWAgAlhqnLF0PByf0k2Au3v7Ge4kj+BeF
U/S0XL+U3t8sjGSvXpR50AFEH9wPsp2Hr0yguJ2/WJDYDAO8dvzphcMgwP/q5EfZ
25hmKWQOP25rBMiHyXVcws6lVWLcsZ55l9k5ff/3mR2j5qV5dsA37G4gosbfTwMn
a29FXHyLBxMZMZgKGfK3cDY+W7F0tZ+XO4+E6TTZzu6OD8EmUwptbkmBd5XyiomQ
C7R1lBSR2xOYxFgdqy9sEp88lcRufN0tK3dun0hIotfabGq2HVv7lvsfD9DOC+IF
jaJKBzVzIAfvFCJVIUksW+DKvB4CiwL/Wm3NbzRaQmM4XZ66Emn1CaPYjQ==
=xMZt
-END PGP SIGNATURE-

Re: custom props in `org-agenda-get-scheduled`

[Ihor Radchenko]

> The problem is that there doesn't seem to be any hook available for me 
> to add a prop during the agenda creation process. Am I missing 
> something? Or do I just need to modify `org-agenda-get-scheduled` directly?

The closest to what you want is org-agenda-prefix-format, where you can
add user-defined functions to format prefix strings in agenda. The
function will be ran with point at the headline in org file. 

Alternatively, you may add a function cycling over the agenda headlines
to org-agenda-finalize-hook. Then, you can edit the agenda lines as you
wish. Every headline in agenda has 'org-hd-marker text property pointing
to the headline position in the org file.

Hope it helps.

Best,
Ihor


Samuel Maynard  writes:

> Hi all,
>
> First time on the mailing list. Been using org-mode for about half a year.
>
> I'm trying to add a custom display to the agenda view, similar to 
> org-habit. I'm want to pull information from a task's `:LOGBOOK:` drawer 
> and display some stats next to the item in the agenda view.
>
> I've written the code that parses the stats I'm interested in, but I 
> can't seem to figure out how to show them in the agenda. Looking through 
> the org-habit code it seems I need to first use `org-add-props` (or 
> `add-text-properties`) to add a custom `text-property`, which I can then 
> process in an `org-finalize-hook`.
>
> The problem is that there doesn't seem to be any hook available for me 
> to add a prop during the agenda creation process. Am I missing 
> something? Or do I just need to modify `org-agenda-get-scheduled` directly?
>
> Thanks,
> Sam
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

[SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Ihor Radchenko  writes:

>> I try to record into under headline. For example, I use "org-contacts.el" 
>> which
>> record people personalized info. I want to see all properties drawer under a
>> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.
>
> I recall seeing something similar in stackoverflow.
> Here it is:
> https://stackoverflow.com/questions/17478260/completely-hide-the-properties-drawer-in-org-mode
>
> The accepted answer has a hint how to achieve what your want.
>

Thanks Ihor, I indeed found related code in Org Mode source. I implemented a
similar functionality in my patch.

> Best,
> Ihor
>
>
> stardiviner  writes:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>>
>> Nicolas Goaziou  writes:
>>
>>> Hello,
>>>
>>> stardiviner  writes:
>>>
 I think the hidden drawers info is useful for users, this should be
 shown when org-cycle on headlines.
>>>
>>> Doesn't this defeat the whole purpose of drawers? What problem do you
>>> want to solve?
>>
>> Hmm, you're right, my patch seems against the purpose of drawers.
>>
>> I try to record into under headline. For example, I use "org-contacts.el" 
>> which
>> record people personalized info. I want to see all properties drawer under a
>> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.
>>
>> I agree your opinion. I wonder is it possible to define a buffer local 
>> variable
>> so that user can control this behavior. WDYT?
>>
>>>
>>> Regards,
>>
>>
>> - -- 
>> [ stardiviner ]
>>I try to make every word tell the meaning what I want to express.
>>
>>Blog: https://stardiviner.github.io/
>>IRC(freenode): stardiviner, Matrix: stardiviner
>>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>>   
>> -BEGIN PGP SIGNATURE-
>>
>> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6T3JAUHG51bWJjaGls
>> ZEBnbWFpbC5jb20ACgkQG13xyVromsPm0Af+JPZpVaz0GBhs3TS4rbKA58fO5RNS
>> lBbL0oaLpua9sBIh2erwLCnVff6hDcXW9tZp9CCXkFMlvx/kHJ8izGf8Sq59rPsa
>> X7N7szot6W+KJXLEsy+v3VwYcvKX5um8BBh+FrfUguLuCInUy03ZXquiruxHVZun
>> eKc67YBi5KpDJVyhkBD3NGSzuhmP8kiJ2hx05dh9PpLB9+YUeUX+8bb82biEu/O0
>> ynWItysHG7t116+UuSQ0ShHE2yJffZqa0ygKfIukdPw7hLqBKSrudZX0Zp9yyPHh
>> SKh+olNHbOyQCpSZRjrMzhDETBP/g+FjiCMlmO2024F3FOZtyhQF+ALCfw==
>> =0jTv
>> -END PGP SIGNATURE-
>>


- -- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6Uk+MUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsPYmAf/X0l7OXFrPUR86aGuKdppM+uk3/t1
edt3uCt1C2LCUZ2wiiCbCdmXgtTpwQumJjUnUM1WK9viNlMZq5FkmuWSZMwVwhc9
mR7f4QFHGPfjJF02YEWjAOpR27do5N+jZrsH8u2hcSaf9IpdL0bxA/n5nLTXpmpB
+ghOSAT186LqWCCDcxhNFH7vUOKrE2gtrWPo5LeedWiHgfuMJuvhESSbWGfHFHL4
ptxWlrEovDXZKZwsxVxZ578o27p8WgTkoRtfZjv3++lTG0BBg8DuOEfOWuZYDvf2
98OX2JnFoo57rL5KU9JFU8Y170RvRxDQF2ND7tg1e5RQcPoGFEKG+tfMaQ==
=kaPH
-END PGP SIGNATURE-

Re: [PATCH] Show hidden drawers when org-cycle on headlines

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Nicolas Goaziou  writes:

> Hello,
>
> stardiviner  writes:
>
>> I try to record into under headline. For example, I use "org-contacts.el" 
>> which
>> record people personalized info. I want to see all properties drawer under a
>> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.
>>
>> I agree your opinion. I wonder is it possible to define a buffer local 
>> variable
>> so that user can control this behavior. WDYT?
>
> I think that drawers and headlines are unrelated, and `org-cycle' should
> not handle drawers, even through a variable.

I see. I will add a custom hook config in my personal init.

>
> However, using `org-show-all' function, you could write a function that
> expands properties drawers, and add it to `org-cycle-hook'.

Yes, my patch added a similar function like `org-show-all' which I borrowed code
from it to `org-cycle-hook'.

- -- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6UkzkUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsNlUAf9HntaeOxyVKZDEEe19yc9tK60Nn2v
JuzO9mEuFcwwrZQb0hYMADRGcjla5CJ5eQN0HZ9RHlwCQyqLGdqTVa5/Qt+nZvYm
HiP4vefHKAGIUGg+FUJh2Q0rFruRS34S05H/bWzPh4/gtno0KafR0YhqkVLp+Z7U
gPud1yacH6c1ANlMTyBKgVfJND/kntvfXStSNnciNwHX1CgpttrNt7KJC7BJ8poa
HoR6AfPqQK0M1IxUV0rTxpFElVSFYaHq5L+V//9alqRzsqaOLSvcK/HDCRhV8Tak
jl+EuC9HmkDX8PEnPlsp/GjXSZHbuTuYr5tX4A2ncYEN0SvxG7RoqSSTYg==
=L8iO
-END PGP SIGNATURE-

custom props in `org-agenda-get-scheduled`

[Samuel Maynard]

Hi all,

First time on the mailing list. Been using org-mode for about half a year.

I'm trying to add a custom display to the agenda view, similar to 
org-habit. I'm want to pull information from a task's `:LOGBOOK:` drawer 
and display some stats next to the item in the agenda view.


I've written the code that parses the stats I'm interested in, but I 
can't seem to figure out how to show them in the agenda. Looking through 
the org-habit code it seems I need to first use `org-add-props` (or 
`add-text-properties`) to add a custom `text-property`, which I can then 
process in an `org-finalize-hook`.


The problem is that there doesn't seem to be any hook available for me 
to add a prop during the agenda creation process. Am I missing 
something? Or do I just need to modify `org-agenda-get-scheduled` directly?


Thanks,
Sam

Re: wip-cite status question and feedback

[Denis Maier]

> Stefan Nobis  hat am 13. April 2020 10:33 geschrieben:
> 
>  
> Nicolas Goaziou  writes:
> 
> > Alphanumeric suffix provides 62 combinations, which should hopefully
> > be enough for any citation back-end out there (I'm looking at you
> > biblatex). It's not terribly readable, tho, as you point out.
> 
> I second that. Some of the many BibLaTeX commands are due to
> compatibility with other (older) packages and to ease transitions.
> 
> Another aspect: Maybe it would be a good idea to reserve some chars
> (e.g. the numeric ones) for user defined citation commands (a
> minimalistic reserved namespace).

My main concern is not so much the sheer number of available commands. I am 
just not sure if something like [cite6: @doe] will increase readability. (Will 
you remember what that is supposed to mean?) Also: With biblatex you have 
\nocite and \notecite, which one will be [citen: @doe]? I guess here I'd use 
citen for the more common option (nocite), but there still could be the need 
for a notecite version. Perhaps [cite-note: @doe] or [cite/note: @doe]. Again, 
a set of simple commands cite, citet, and perhaps a few others might a good 
starting point, but I am not sure if that is enough in the long run. (I 
currently use mainly CSL so I don't have much need for them myself, but I think 
extensability might become an issue at some point.) Also, some might prefer to 
have more verbose commands.

By the way, I think you should add a nocite version to your proposal. (citen, 
citeno or something similar.)

Concerning the fallback idea (citep being equal to cite if citep is not defined 
by a backend.) That's really good, but perhaps there should be a way to 
customize the fallback rules? Like a certain citex should be treated as cite, 
while citey is equal to citet... 
WDYT?


> [Placing bibliography with "#+bibliography: here"]
> > It is smart, but I'm not sure I like using the same keyword for two
> > different things. OTOH, I don't have a better idea.
> 
> I personally also dislike one keyword for completely different
> purposes. Therefore I suggest to take the idea from BibLaTeX and use a
> keyword like "printbibliography" the mark the place where the
> bibliography should be output.

Ok, fair enough.
So:
#+BIBLIOGRAPHY: file1.bib
#+BIBLIOGRAPHY: file2.bib
[Rest of file]

#+PRINTBIBLIOGRAPHY

Or perhaps:

#+BIBLIOGRAPHYFILE: file1.bib
#+BIBLIOGRAPHYFILE: file2.bib
[Rest of file]

#+BIBLIOGRAPHY

But ultimately, each will be fine. I don't think that matters much...

> This command may also have parameters like filtering options (maybe
> depending on the backend processor; I only know BibLaTeX so I can't
> say if it would be easy to abstract away differences between different
> engines). In the case of BiBLaTeX the printbibliography command
> optionally accepts multiple key-value parameters. Some examples for
> the keys are "heading" for the chapter/section heading, "type" to
> output/print only entries of a certain type (like "book"; or type
> "online" and with the additional key "nottype" separate non-online and
> online sources), "keyword" to filter entries with the associated
> keyword etc.

Yes, biblatex is very powerful here, and much ahead of other solutions. Pandoc 
has some support for multiple bibliographies, but it's nowhere as advanced. So 
offering something here would be great, but the question is how this can be 
done in a output agnostic way.

> [Style selection]
> > I think this part is out of Org's scope. Since values between
> > various citation back-ends are probably not compatible, e.g., some
> > may require a file, others a style name, normalization is not useful
> > here. They can use whatever keyword they fancy.
> 
> Yes, I second that. But it may be worth thinking a second about using
> one Org document to generate output with different backends (e.g. PDF
> via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have
> some way to configure each citation engine form the same document.
> Either use different keywords like "#+CSL_STYLE" and
> "#+BIBLATEX_STYLE" or we use your original suggestion of a ":style"
> parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to
> translate its value individually for each engine - e.g. an alist or
> some function provided by the user. And if no translation is provided,
> just give the value verbatim to the engine, thus if a user only
> targets a single backend, he does not need to provide any
> extra configuration.

These are very good questions. Looking again at pandoc: There you have two 
options:
a) use pandoc-citeproc to produce the citations for each target format
b) use a native bibliographic tool (e.g. biblatex or natbib in latex output).

Option b) is clearly more powerful as you can use 
But option a) can be used if you need the same output in DOCX, HTML and PDF. 
(Say you have an article written for a journal, and the manuscript is uploaded 
to your institution's repository.) That should be possible with Org as well.

Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Ihor Radchenko]

> Yes, this `integrate' value is not great, IMO. However, plain lists have
> much more in common with headlines than with drawers.
>
> I still think basic cycling should not include drawers whatsoever. This
> is even more true for properties drawers.

I tend to agree about the properties drawers. Cannot come up with a
reasonable use-case for such kind of behaviour.
However, I have some use-case for cycling user-defined property drawers.

In some of my entries, I have long tables storing historical data.
These tables tend to be extremely long and I sometimes hide them inside
a drawer. Opening these drawers (or a customised list of drawers) on
 would actually make sense for me. 


Nicolas Goaziou  writes:

> Hello,
>
> Ihor Radchenko  writes:
>
>>> Thanks Ihor, I indeed found related code in Org Mode source. I implemented a
>>> similar functionality in my patch.
>>
>> Oh. I somehow missed your first message...
>>
>> Now, actually adding something to the discussion.
>>
>> FYI, there is org-cycle-include-plain-lists variable. If it is set to
>> 'integrate, plain lists will be included into cycling with point at
>> headline. This is against the logic that org-cycle only needs to be
>> dealing with headlines. So, I don't see your patch breaking the present
>> conventions in org.
>
> Yes, this `integrate' value is not great, IMO. However, plain lists have
> much more in common with headlines than with drawers.
>
> I still think basic cycling should not include drawers whatsoever. This
> is even more true for properties drawers.
>
> Note that you can already display drawers with `org-cycle', using three
> prefix arguments.
>
> Regards,
>
> -- 
> Nicolas Goaziou

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

Re: Assistant to remove unused IDs of org-id

[Ihor Radchenko]

I quickly looked through the code. It seems that you do not consider
attachments, which are normally stored in a folder named after the
entry's ID property. Deleting those ID is terrible idea.

Best,
Ihor


Marc-Oliver Ihm  writes:

> Hi,
>
> as I use the excellent package org-id in a somewhat non-standard way, I tend 
> to produce IDs, that are not referenced from anywhere. Org-id handles this 
> great and does not suffer in performance, but eventually I want to remove 
> those unreferenced IDs.
> Therefore I have written a small interactive assistant:
>
> https://github.com/marcIhm/org-working-set/blob/master/org-id-cleanup.el
>
> to help with removing those IDs.
> The assistant (interactive function: org-id-cleanup) is quite detailed with 
> its instructions and checks, so that the risk of doing harm ist reduced to a 
> minimum, although not to zero (therefore the first step is to ask for a 
> backup).
>
> In any case I wonder, if this functionality (removing unreferenced IDs) could 
> be helpful for anyone else.
>
> So please feel free to have a look.
> Finally I would be grateful for any comment whatsoever 
> (e.g. regarding the name of org-id-cleanup.el).
>
> Best regards
> Marc
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Tim Cross]

Nicolas Goaziou  writes:

> I still think basic cycling should not include drawers whatsoever. This
> is even more true for properties drawers.
>
> Note that you can already display drawers with `org-cycle', using three
> prefix arguments.
>

I agree. I use drawers precisely because they contain information I
don't want to see when cycling. Drawers contain 'meta', which is often
tangential to the main content. 


-- 
Tim Cross

Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Samuel Wales]

i wonder if as a companion to such [perhaps hook-based user]
functionality, org-ellipsis could appear e.g. only if there is text
content.

Re: I'm slowly coming back

[Adam Porter]

Hi Bastien,

I've been keeping an eye out for you!  :)  Glad to hear you're well, and
I'm looking forward to your return.

Adam

Re: Assistant to remove unused IDs of org-id

[Adam Porter]

Marc-Oliver Ihm  writes:

> as I use the excellent package org-id in a somewhat non-standard way,
> I tend to produce IDs, that are not referenced from anywhere. Org-id
> handles this great and does not suffer in performance, but eventually
> I want to remove those unreferenced IDs.  Therefore I have written a
> small interactive assistant:
>
> https://github.com/marcIhm/org-working-set/blob/master/org-id-cleanup.el
>
> to help with removing those IDs.  The assistant (interactive function:
> org-id-cleanup) is quite detailed with its instructions and checks, so
> that the risk of doing harm ist reduced to a minimum, although not to
> zero (therefore the first step is to ask for a backup).
>
> In any case I wonder, if this functionality (removing unreferenced
> IDs) could be helpful for anyone else.
>
> So please feel free to have a look.  Finally I would be grateful for
> any comment whatsoever (e.g. regarding the name of org-id-cleanup.el).

Hi Marc,

Thanks, this looks useful.  I posted some feedback as an issue on the
repository.

Adam

Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

>> Thanks Ihor, I indeed found related code in Org Mode source. I implemented a
>> similar functionality in my patch.
>
> Oh. I somehow missed your first message...
>
> Now, actually adding something to the discussion.
>
> FYI, there is org-cycle-include-plain-lists variable. If it is set to
> 'integrate, plain lists will be included into cycling with point at
> headline. This is against the logic that org-cycle only needs to be
> dealing with headlines. So, I don't see your patch breaking the present
> conventions in org.

Yes, this `integrate' value is not great, IMO. However, plain lists have
much more in common with headlines than with drawers.

I still think basic cycling should not include drawers whatsoever. This
is even more true for properties drawers.

Note that you can already display drawers with `org-cycle', using three
prefix arguments.

Regards,

-- 
Nicolas Goaziou

Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Ihor Radchenko]

> Thanks Ihor, I indeed found related code in Org Mode source. I implemented a
> similar functionality in my patch.

Oh. I somehow missed your first message...

Now, actually adding something to the discussion.

FYI, there is org-cycle-include-plain-lists variable. If it is set to
'integrate, plain lists will be included into cycling with point at
headline. This is against the logic that org-cycle only needs to be
dealing with headlines. So, I don't see your patch breaking the present
conventions in org.


stardiviner  writes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Ihor Radchenko  writes:
>
>>> I try to record into under headline. For example, I use "org-contacts.el" 
>>> which
>>> record people personalized info. I want to see all properties drawer under a
>>> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.
>>
>> I recall seeing something similar in stackoverflow.
>> Here it is:
>> https://stackoverflow.com/questions/17478260/completely-hide-the-properties-drawer-in-org-mode
>>
>> The accepted answer has a hint how to achieve what your want.
>>
>
> Thanks Ihor, I indeed found related code in Org Mode source. I implemented a
> similar functionality in my patch.
>
>> Best,
>> Ihor
>>
>>
>> stardiviner  writes:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>>
>>> Nicolas Goaziou  writes:
>>>
 Hello,

 stardiviner  writes:

> I think the hidden drawers info is useful for users, this should be
> shown when org-cycle on headlines.

 Doesn't this defeat the whole purpose of drawers? What problem do you
 want to solve?
>>>
>>> Hmm, you're right, my patch seems against the purpose of drawers.
>>>
>>> I try to record into under headline. For example, I use "org-contacts.el" 
>>> which
>>> record people personalized info. I want to see all properties drawer under a
>>> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.
>>>
>>> I agree your opinion. I wonder is it possible to define a buffer local 
>>> variable
>>> so that user can control this behavior. WDYT?
>>>

 Regards,
>>>
>>>
>>> - -- 
>>> [ stardiviner ]
>>>I try to make every word tell the meaning what I want to express.
>>>
>>>Blog: https://stardiviner.github.io/
>>>IRC(freenode): stardiviner, Matrix: stardiviner
>>>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>>>   
>>> -BEGIN PGP SIGNATURE-
>>>
>>> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6T3JAUHG51bWJjaGls
>>> ZEBnbWFpbC5jb20ACgkQG13xyVromsPm0Af+JPZpVaz0GBhs3TS4rbKA58fO5RNS
>>> lBbL0oaLpua9sBIh2erwLCnVff6hDcXW9tZp9CCXkFMlvx/kHJ8izGf8Sq59rPsa
>>> X7N7szot6W+KJXLEsy+v3VwYcvKX5um8BBh+FrfUguLuCInUy03ZXquiruxHVZun
>>> eKc67YBi5KpDJVyhkBD3NGSzuhmP8kiJ2hx05dh9PpLB9+YUeUX+8bb82biEu/O0
>>> ynWItysHG7t116+UuSQ0ShHE2yJffZqa0ygKfIukdPw7hLqBKSrudZX0Zp9yyPHh
>>> SKh+olNHbOyQCpSZRjrMzhDETBP/g+FjiCMlmO2024F3FOZtyhQF+ALCfw==
>>> =0jTv
>>> -END PGP SIGNATURE-
>>>
>
>
> - -- 
> [ stardiviner ]
>I try to make every word tell the meaning what I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>   
> -BEGIN PGP SIGNATURE-
>
> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6Uk+MUHG51bWJjaGls
> ZEBnbWFpbC5jb20ACgkQG13xyVromsPYmAf/X0l7OXFrPUR86aGuKdppM+uk3/t1
> edt3uCt1C2LCUZ2wiiCbCdmXgtTpwQumJjUnUM1WK9viNlMZq5FkmuWSZMwVwhc9
> mR7f4QFHGPfjJF02YEWjAOpR27do5N+jZrsH8u2hcSaf9IpdL0bxA/n5nLTXpmpB
> +ghOSAT186LqWCCDcxhNFH7vUOKrE2gtrWPo5LeedWiHgfuMJuvhESSbWGfHFHL4
> ptxWlrEovDXZKZwsxVxZ578o27p8WgTkoRtfZjv3++lTG0BBg8DuOEfOWuZYDvf2
> 98OX2JnFoo57rL5KU9JFU8Y170RvRxDQF2ND7tg1e5RQcPoGFEKG+tfMaQ==
> =kaPH
> -END PGP SIGNATURE-

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

Assistant to remove unused IDs of org-id

[Marc-Oliver Ihm]

Hi,

as I use the excellent package org-id in a somewhat non-standard way, I tend to 
produce IDs, that are not referenced from anywhere. Org-id handles this great 
and does not suffer in performance, but eventually I want to remove those 
unreferenced IDs.
Therefore I have written a small interactive assistant:

https://github.com/marcIhm/org-working-set/blob/master/org-id-cleanup.el

to help with removing those IDs.
The assistant (interactive function: org-id-cleanup) is quite detailed with its 
instructions and checks, so that the risk of doing harm ist reduced to a 
minimum, although not to zero (therefore the first step is to ask for a backup).

In any case I wonder, if this functionality (removing unreferenced IDs) could 
be helpful for anyone else.

So please feel free to have a look.
Finally I would be grateful for any comment whatsoever 
(e.g. regarding the name of org-id-cleanup.el).

Best regards
Marc

Re: org-rss feed title is concatenation of all post titles? (ECM included)

[Nick Dokos]

Stig Brautaset  writes:

> ...
> PS: Can we pretend this whole thread didn't happen? :-)
>

What thread?

-- 
Nick:-)

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: Small documentation errors [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/jorge/.emacs.d/elpa/27.0/develop/org-plus-contrib-20200406/)]

[Kyle Meyer]

Jorge P. de Morais Neto  writes:

> Em [2020-04-12 dom 22:35:09+], Kyle Meyer escreveu:
>
>> Thanks for sending this.  My personal preference would be more focused
>> reports.  (And of course patches would be even better.)
>
> Regarding patches, I feel I am too inexperienced at this moment to
> efficiently write good patches.  It is possible, though, that I am just
> unduly insecure.  Perfectionism and low self esteem combine to generate
> a lot of insecurity.

Well, no pressure to send patches if you're not comfortable doing so.
But sending a patch with an error or that needs work is not an issue.
I'd say the mostly likely outcome is that someone will politely point
that out.

Not so different really than saying something wrong like:

Kyle Meyer  writes:

>> The description of `C-c -' inverts the effect of the prefix argument.
> [...]
> AFAICS that matches the manual's description.

And someone patiently explaining that "as far as Kyle can see"
apparently wasn't very far:

Jorge P. de Morais Neto  writes:

> Yes, this is the behavior I get too.  But see what the manual says:
>
> If there is an active region when calling this, selected text is
> changed into *an item*.
> [ my emphasis ]
>
> It says `C-c -' changes the (potentially multiple) lines into *an item*
> (singular).  With the prefix argument it says:
>
> With a prefix argument, all lines are converted to *list items*.
> [ my emphasis ]
>
> It says `C-c -' changes the (potentially multiple) lines into *list
> items* (plural).

Thanks.  I'll fix that (my) tonight.

Re: links are not parsed in keyword context

[Alan Schmitt]

Hello Nicolas,

On 2020-04-13 11:19, Nicolas Goaziou  writes:

> This is a feature. With a few exception, keyword value is not parsed,
> i.e., Org does not need to understand what happens in there.

Thank you for the explanation.

>> Alternatively, should I suggest org-ref uses an approach similar to
>> the one in ~org-return~?
>
> I think Org Ref can parse the value of the keyword (a string), instead.
> There is, for example, `org-element-parse-secondary-string'.

I mentioned your suggestion in the issue on the org-ref repo
(https://github.com/jkitchin/org-ref/issues/718). Thanks again.

Best,

Alan

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Mon, Apr 13, 2020 at 8:05 AM Gustav Wikström  wrote:

> I'm curious. So take this for what it is; I.e. curiosity. What /exactly/ is 
> meant with a citation here? Is it a new general concept in Org mode, or is it 
> something more narrow, as an extension for some specific third party 
> software? Would I be able to use it without that third party software? What 
> would the content of a citation be? Is it a link to some source plus 
> annotations and formatting? Is it only the link? Is it also the formatting? 
> Is it something else entirely? I'm wondering since Org mode has existing 
> facilities for much of this already. But maybe not packaged together for 
> citations just yet? Is there any purpose of thinking of citations as a 
> wrapper for already existing functionality? Or could the links-syntax be 
> extended with more properties and auxiliary functionality to fulfill the need 
> for citations?

I'm not sure of the value of this sort of question thrown in the
middle of a long-running, many year, conversation. You seem to assume
nobody considered this.

But to answer anyway ...

Citations are references to bibliographic sources.

They are a convention for citing references that developed over
decades, and even centuries, before the internet even existed.

So, they are links of sorts, but lot more.

They're complicated because of the addition of diverse, prescriptive,
and often obscure output formatting requirements, and also because we
have to include additional information beyond just the source.

For example, if I cite some thing, I may need to include page number
references; like (Doe, 2018:18). This says, X info from the Doc, 2018
source, page 18.

So practically, if I submit a manuscript to one journal, it has one
set of formatting requirements; perhaps the above citation style, and
then a separate bibliography style.

If it's rejected and I resubmit it to another journal, it will have a
different set of formatting requirements; perhaps citations look like
this instead (Doe, 2018 p. 18), or are rendered as footnotes.

So we use these systems to decouple authoring from those output requirements.

One can say that academic citation practice is inflexible and archaic,
and one would be right. But it's the world we live in, and very slow
to change. 100 years from now it likely won't look too different!

Effectively, I see this long thread, and similar ones before it, as
how best to reconcile well-known requirements as reflected in existing
systems, but to do so in a way that fits with org.

I think we're close!

HTH.

Bruce

RE: wip-cite status question and feedback

[Gustav Wikström]

Hi,

I'm curious. So take this for what it is; I.e. curiosity. What /exactly/ is 
meant with a citation here? Is it a new general concept in Org mode, or is it 
something more narrow, as an extension for some specific third party software? 
Would I be able to use it without that third party software? What would the 
content of a citation be? Is it a link to some source plus annotations and 
formatting? Is it only the link? Is it also the formatting? Is it something 
else entirely? I'm wondering since Org mode has existing facilities for much of 
this already. But maybe not packaged together for citations just yet? Is there 
any purpose of thinking of citations as a wrapper for already existing 
functionality? Or could the links-syntax be extended with more properties and 
auxiliary functionality to fulfill the need for citations?

Maybe these questions have been discussed already. Sorry in that case, it was a 
long thread and I admit to not having read everything. I'm simply wondering 
since there may be reason for reusing and extending existing functionality 
before creating something new. Hence the question of what exactly a citation 
consists of above. Because Org mode can already provide links to external 
content. And, to me at least, a citation is simply that: a link. A link which 
is the key to the information that is to be marked as the source of the 
citation. Auxiliary functionality on top of that could provide facilities to 
collect all such links into bibliographies based on link-backend and properties 
of that link. Configurations (emacs config or org mode properties, 
[info:org#Property Syntax]) could instruct on formatting.

But as I said in the beginning. Take this as curiosity. And take it as 
questions for someone not very much into the academic world at this time, not 
having to bother with typesetting, formatting and latex related issues.

Kind regards
Gustav

> -Original Message-
> From: Emacs-orgmode  On
> Behalf Of Nicolas Goaziou
> Sent: den 8 april 2020 11:32
> To: Bruce D'Arcus 
> Cc: Joost Kremers ; emacs-orgmode@gnu.org;
> András Simonyi ; John Kitchin
> 
> Subject: Re: wip-cite status question and feedback
> 
> Hello,
> 
> "Bruce D'Arcus"  writes:
> 
> > Note that in CSL processors, the locators are meaningful key-values,
> > basically; not plain text strings.
> 
> OK, but it is enough for Org to feed a CSL processor with, e.g.,
> 
>   key-> "@doe99"
>   prefix -> "see "
>   suffix -> ", pp. 33-35"
> 
> Then CSL processor does its job to extract whatever information it
> needs. Am I right?
> 
> > While I of course can't speak for John, I would hope and expect org
> > ref to support the new syntax.
> >
> > I would hope and expect the same of other packages (like ebib) that
> > use their own custom syntax.
> 
> I hope so, too. But it would help if developers could chime in and tell
> what API Org should provide. This is particularly important since Org
> will only provide the API, without any specialized implementation. More
> on this at the end of the message.
> 
> > 1. just have a super simple citation export formatter, with (per
> >above) room to configure an external one
> 
> Sure. Org should provide default export for citations in LaTeX, ASCII,
> HTML, Texinfo and ODT. Suggestions are more than welcome.
> 
> > 2. while I don't know its status, include citeproc-org in org and
> > emacs
> 
> I think citeproc-el should ship with Emacs, but I cannot speak for
> Emacs; it would be nice to ask Emacs developers about it.
> 
> > I'd say if citeproc-org is far along and free of substantial bugs, 2
> > might make sense. I am, of course, biased, but CSL's been widely
> > deployed in the wild for more than a decade, and there are thousands
> > of available styles.
> >
> > Otherwise, and more likely, 1 would be the best path; users get basic
> > output formatting for citations, but then can plug in more elaborate
> > tools (citeproc-org, citeproc-hs*, etc.) if they need them.
> 
> Option 2 makes a lot of sense if citeproc-el is integrated with Emacs.
> Until them, I agree that option 1 is the way to go at the moment.
> 
> > WDY about that?
> 
> Sounds like a plan. Let me summarize it a bit :
> 
> 1. [ ] Finalize Org citation syntax. It is mostly good, but we need to
>decide about the following points:
> 
>- [ ] Should it include both "(cite):" and "cite:", i.e., does it
>  make sense to provide a (very limited) style specification piece
>  wise?
> 
>- [ ] Should it include /global/ prefix and suffix?
> 
>- [ ] Should we keep the short specification, i.e., "[@key]"?
> 
>- [ ] What kind of markup do we allow in a citation? At the moment
>  the exhaustive list is: bold, code, entity, italic, latex-
> fragment,
>  strike-through, subscript, superscript, underline, verbatim and
>  line breaks.
> 
> 2. [ ] Decide about API Org should provide for it to be useful. Here
> are
>some low hanging fruits:
> 
>- [ ] List all ".bib" files 

Re: Bug: Small documentation errors [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/jorge/.emacs.d/elpa/27.0/develop/org-plus-contrib-20200406/)]

[Jorge P . de Morais Neto]

Em [2020-04-12 dom 22:35:09+], Kyle Meyer escreveu:

> Thanks for sending this.  My personal preference would be more focused
> reports.  (And of course patches would be even better.)

Regarding patches, I feel I am too inexperienced at this moment to
efficiently write good patches.  It is possible, though, that I am just
unduly insecure.  Perfectionism and low self esteem combine to generate
a lot of insecurity.

> "Jorge P. de Morais Neto"  writes:
>> ** [[info:org#Plain Lists]]
>>
>> The description of `C-c -' inverts the effect of the prefix argument.
>
> I'm not seeing that behavior on my end.  With
>
>   a
>   b
>
> and a region spanning before "a" and after "b", hitting 'C-c -' gives me
>
>   - a
>   - b
>
> Hitting 'C-u C-c -' instead I get
>
>   - a
> b

Yes, this is the behavior I get too.  But see what the manual says:

If there is an active region when calling this, selected text is
changed into *an item*.
[ my emphasis ]

It says `C-c -' changes the (potentially multiple) lines into *an item*
(singular).  With the prefix argument it says:

With a prefix argument, all lines are converted to *list items*.
[ my emphasis ]

It says `C-c -' changes the (potentially multiple) lines into *list
items* (plural).

Regards
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- 
- 

Re: wip-cite status question and feedback

[Stefan Nobis]

Joost Kremers  writes:

> I don't think it's necessary to use a dash (or any other character)
> in longer cite commands, though. =citeintext= isn't that much more
> difficult to read than =cite-intext=. (Biblatex does just fine
> without dashes, and there's always camelCase if you're so inclined.)

It is not necessary, but it may be an opportunity to introduce
namespaces. For example cite and citeX (with a single letter) is
strictly reserved for Org core. Package may introduce new commands
like "cite-subcommand" with a single dash and something like
"cite--subcommand" or "cite/subcommand" is reserved for local use by
users and should not be used by packages.

I think citation needs are quite manifold and thus there might be many
upcoming packages each supporting some special needs. Therefore it
would be nice to a some simple kind of namespaces for commands to
avoid name clashes when using multiple specialised support packages at
the same time.

-- 
Until the next mail...,
Stefan.

Re: I'm slowly coming back

[Christian Moe]

Important work! Stay safe.

Christian

Bastien writes:

> Dear all,
>
> my day job is to work for the open data public agency in France.
>
> I have been drown under a massive workload in the last four weeks,
> due to the COVID-19 crisis.
>
> I am slowly freeing more time and I'll be back at reading the list
> on a regular basis at the end of week 16.
>
> Thanks,

Re: wip-cite status question and feedback

[denis . maier . lists]

Sorry, my last message was unreadable. (and possibly sent twice, once from a 
wrong account... don't know if this will come through)
 
> Stefan Nobis  hat am 13. April 2020 10:33 geschrieben:
> 
>  
> Nicolas Goaziou  writes:
> 
> > Alphanumeric suffix provides 62 combinations, which should hopefully
> > be enough for any citation back-end out there (I'm looking at you
> > biblatex). It's not terribly readable, tho, as you point out.
> 
> I second that. Some of the many BibLaTeX commands are due to
> compatibility with other (older) packages and to ease transitions.
> 
> Another aspect: Maybe it would be a good idea to reserve some chars
> (e.g. the numeric ones) for user defined citation commands (a
> minimalistic reserved namespace).

My main concern is not so much the sheer number of available commands. I am 
just not sure if something like [cite6: @doe] will increase readability. (Will 
you remember what that is supposed to mean?) Also: With biblatex you have 
\nocite and \notecite, which one will be [citen: @doe]? I guess here I'd use 
citen for the more common option (nocite), but there still could be the need 
for a notecite version. Perhaps [cite-note: @doe] or [cite/note: @doe]. Again, 
a set of simple commands cite, citet, and perhaps a few others might a good 
starting point, but I am not sure if that is enough in the long run. (I 
currently use mainly CSL so I don't have much need for them myself, but I think 
extensability might become an issue at some point.) Also, some might prefer to 
have more verbose commands.

By the way, I think you should add a nocite version to your proposal. (citen, 
citeno or something similar.)

Concerning the fallback idea (citep being equal to cite if citep is not defined 
by a backend.) That's really good, but perhaps there should be a way to 
customize the fallback rules? Like a certain citex should be treated as cite, 
while citey is equal to citet... 
WDYT?


> [Placing bibliography with "#+bibliography: here"]
> > It is smart, but I'm not sure I like using the same keyword for two
> > different things. OTOH, I don't have a better idea.
> 
> I personally also dislike one keyword for completely different
> purposes. Therefore I suggest to take the idea from BibLaTeX and use a
> keyword like "printbibliography" the mark the place where the
> bibliography should be output.

Ok, fair enough.
So:
#+BIBLIOGRAPHY: file1.bib
#+BIBLIOGRAPHY: file2.bib
[Rest of file]

#+PRINTBIBLIOGRAPHY

Or perhaps:

#+BIBLIOGRAPHYFILE: file1.bib
#+BIBLIOGRAPHYFILE: file2.bib
[Rest of file]

#+BIBLIOGRAPHY

But ultimately, each will be fine. I don't think that matters much...

> This command may also have parameters like filtering options (maybe
> depending on the backend processor; I only know BibLaTeX so I can't
> say if it would be easy to abstract away differences between different
> engines). In the case of BiBLaTeX the printbibliography command
> optionally accepts multiple key-value parameters. Some examples for
> the keys are "heading" for the chapter/section heading, "type" to
> output/print only entries of a certain type (like "book"; or type
> "online" and with the additional key "nottype" separate non-online and
> online sources), "keyword" to filter entries with the associated
> keyword etc.

Yes, biblatex is very powerful here, and much ahead of other solutions. Pandoc 
has some support for multiple bibliographies, but it's nowhere as advanced. So 
offering something here would be great, but the question is how this can be 
done in a output agnostic way.

> [Style selection]
> > I think this part is out of Org's scope. Since values between
> > various citation back-ends are probably not compatible, e.g., some
> > may require a file, others a style name, normalization is not useful
> > here. They can use whatever keyword they fancy.
> 
> Yes, I second that. But it may be worth thinking a second about using
> one Org document to generate output with different backends (e.g. PDF
> via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have
> some way to configure each citation engine form the same document.
> Either use different keywords like "#+CSL_STYLE" and
> "#+BIBLATEX_STYLE" or we use your original suggestion of a ":style"
> parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to
> translate its value individually for each engine - e.g. an alist or
> some function provided by the user. And if no translation is provided,
> just give the value verbatim to the engine, thus if a user only
> targets a single backend, he does not need to provide any
> extra configuration.

These are very good questions. Looking again at pandoc: There you have two 
options:
a) use pandoc-citeproc to produce the citations for each target format
b) use a native bibliographic tool (e.g. biblatex or natbib in latex output).

Option b) is clearly more powerful as you can use 
But option a) can be used if you need the same output in DOCX, HTML and PDF. 
(Say you have an 

Re: wip-cite status question and feedback

[denis . maier . lists]

> > Stefan Nobis  hat am 13. April 2020 10:33 geschrieben:
> > 
> >  
> > Nicolas Goaziou  writes:
> > 
> > > Alphanumeric suffix provides 62 combinations, which should hopefully
> > > be enough for any citation back-end out there (I'm looking at you
> > > biblatex). It's not terribly readable, tho, as you point out.
> > 
> > I second that. Some of the many BibLaTeX commands are due to
> > compatibility with other (older) packages and to ease transitions.
> > 
> > Another aspect: Maybe it would be a good idea to reserve some chars
> > (e.g. the numeric ones) for user defined citation commands (a
> > minimalistic reserved namespace).
> 
> My main concern is not so much the sheer number of available commands. I am 
> just not sure if something like [cite6: @doe] will increase readability. 
> (Will you remember what that is supposed to mean?) Also: With biblatex you 
> have \nocite and \notecite, which one will be [citen: @doe]? I guess here I'd 
> use citen for the more common option (nocite), but there still could be the 
> need for a notecite version. Perhaps [cite-note: @doe] or [cite/note: @doe]. 
> Again, a set of simple commands cite, citet, and perhaps a few others might a 
> good starting point, but I am not sure if that is enough in the long run. (I 
> currently use mainly CSL so I don't have much need for them myself, but I 
> think extensability might become an issue at some point.) Also, some might 
> prefer to have more verbose commands.
> 
> By the way, I think you should add a nocite version to your proposal. (citen, 
> citeno or something similar.)
> 
> Concerning the fallback idea (citep being equal to cite if citep is not 
> defined by a backend.) That's really good, but perhaps there should be a way 
> to customize the fallback rules? Like a certain citex should be treated as 
> cite, while citey is equal to citet... 
> WDYT?
> 
> 
> > [Placing bibliography with "#+bibliography: here"]
> > > It is smart, but I'm not sure I like using the same keyword for two
> > > different things. OTOH, I don't have a better idea.
> > 
> > I personally also dislike one keyword for completely different
> > purposes. Therefore I suggest to take the idea from BibLaTeX and use a
> > keyword like "printbibliography" the mark the place where the
> > bibliography should be output.
> 
> Ok, fair enough.
> So:
> #+BIBLIOGRAPHY: file1.bib
> #+BIBLIOGRAPHY: file2.bib
> [Rest of file]
> 
> #+PRINTBIBLIOGRAPHY
> 
> Or perhaps:
> 
> #+BIBLIOGRAPHYFILE: file1.bib
> #+BIBLIOGRAPHYFILE: file2.bib
> [Rest of file]
> 
> #+BIBLIOGRAPHY
> 
> But ultimately, each will be fine. I don't think that matters much...
> 
> > This command may also have parameters like filtering options (maybe
> > depending on the backend processor; I only know BibLaTeX so I can't
> > say if it would be easy to abstract away differences between different
> > engines). In the case of BiBLaTeX the printbibliography command
> > optionally accepts multiple key-value parameters. Some examples for
> > the keys are "heading" for the chapter/section heading, "type" to
> > output/print only entries of a certain type (like "book"; or type
> > "online" and with the additional key "nottype" separate non-online and
> > online sources), "keyword" to filter entries with the associated
> > keyword etc.
> 
> Yes, biblatex is very powerful here, and much ahead of other solutions. 
> Pandoc has some support for multiple bibliographies, but it's nowhere as 
> advanced. So offering something here would be great, but the question is how 
> this can be done in a output agnostic way.
> 
> > [Style selection]
> > > I think this part is out of Org's scope. Since values between
> > > various citation back-ends are probably not compatible, e.g., some
> > > may require a file, others a style name, normalization is not useful
> > > here. They can use whatever keyword they fancy.
> > 
> > Yes, I second that. But it may be worth thinking a second about using
> > one Org document to generate output with different backends (e.g. PDF
> > via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have
> > some way to configure each citation engine form the same document.
> > Either use different keywords like "#+CSL_STYLE" and
> > "#+BIBLATEX_STYLE" or we use your original suggestion of a ":style"
> > parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to
> > translate its value individually for each engine - e.g. an alist or
> > some function provided by the user. And if no translation is provided,
> > just give the value verbatim to the engine, thus if a user only
> > targets a single backend, he does not need to provide any
> > extra configuration.
> 
> These are very good questions. Looking again at pandoc: There you have two 
> options:
> a) use pandoc-citeproc to produce the citations for each target format
> b) use a native bibliographic tool (e.g. biblatex or natbib in latex output).
> 
> Option b) is clearly more powerful as you can use 
> But option a) can be 

Re: wip-cite status question and feedback

[Joost Kremers]

On Mon, Apr 13 2020, Nicolas Goaziou wrote:

denis.maier.li...@mailbox.org writes:

What about allowing something more verbose? Perhaps
"cite-intext:" or "cite:intext:"?

[...]
The simple syntax is great for most cases, but if you want to 
support
some of those not so common biblatex commands, this might be 
better.


Alphanumeric suffix provides 62 combinations, which should 
hopefully be

enough for any citation back-end out there (I'm looking at you
biblatex). It's not terribly readable, tho, as you point out.


62 combinations might sound like a lot, but if you want your cite 
commands to be mnemonic, you'll run out of options much more 
quickly.


This is a conciseness versus readability problem, not a 
technical one,
as long as we do not allow too much, from a parser point of 
view.


I have no strong opinion on the topic. It would be more valuable 
to hear

from actual citations users. What would they prefer?


Not sure if my opinion counts, given that I mainly use LaTeX + 
biblatex to write my texts, but I would definitely allow more than 
one character. The more common commands (=citep=, =citet=) can 
still use a single character (and thus remain concise), but for 
less common commands, the ability to have more descriptive names 
is to be preferred. Imagine looking at a document you wrote a few 
years back and having to figure out what =citeQ= or =cite7= was 
meant for again, or finding that =citeF= was changed from 
=\fullcite= to =\footfullcite= because at some point the 
developers figured the latter would be used more often.


I don't think it's necessary to use a dash (or any other 
character) in longer cite commands, though. =citeintext= isn't 
that much more difficult to read than =cite-intext=. (Biblatex 
does just fine without dashes, and there's always camelCase if 
you're so inclined.)



1. For the bibliography:

#+bibliography: something.bib
(Could this be a list containing multiple files?)


Multiple keywords may be more appropriate, particularly if you 
need to

spell out absolute file names.

Org can provide a function listing all of them anyway.


Yes, and please make it a public (one-dash) function. :-)


2. Placing the bibliography with:

#+bibliography: here
(Ideally, it would be possible to have this multiple times, 
perhaps
with some filters, like printing only the works of a certain 
author,
or with certain keywords, or so. But that's, of course 
something for

later...)


It is smart, but I'm not sure I like using the same keyword for 
two

different things. OTOH, I don't have a better idea.


As someone already suggested, using something like 
=#+printbibliography:= would work. And if that is too 
biblatex-like, you could instead opt for e.g. 
=#+list-of-references:=. (Output formats such as HTML or epub 
don't involve any printing anyway, so... ;-)



--
Joost Kremers
Life has its moments

Re: wip-cite status question and feedback

[denis . maier . lists]

> Nicolas Goaziou  hat am 13. April 2020 00:19 
> geschrieben:
> 
>  
> Hello,
> 
> denis.maier.li...@mailbox.org writes:
> 
> > Just one question concerning typed citations. citeX is good and
> > concise, but why limit this to only one character?
> 
> Because… it is good and concise? ;)
> 
> > What about allowing something more verbose? Perhaps
> > "cite-intext:" or "cite:intext:"?
> 
> Note the latter introduces an ambiguity: [cite:see: @doe was right!].
> Fixing it requires two colons in default cite prefix: [cite::@doe].
> I don't think we want this.
> 
> The former doesn't have this bias.

Ok, ambiguity is not good. So we need something else. (As in the other message: 
cite/note or cite-intext?)

> 
> > The simple syntax is great for most cases, but if you want to support
> > some of those not so common biblatex commands, this might be better.
> 
> Alphanumeric suffix provides 62 combinations, which should hopefully be
> enough for any citation back-end out there (I'm looking at you
> biblatex). It's not terribly readable, tho, as you point out.
> 
> > What do you think?
> 
> This is a conciseness versus readability problem, not a technical one,
> as long as we do not allow too much, from a parser point of view.
> 
> I have no strong opinion on the topic. It would be more valuable to hear
> from actual citations users. What would they prefer?

What about allowing both, just like most command line tools have short and long 
options (e.g., -o and --open)?

Best,
Denis

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Mon, Apr 13, 2020 at 4:34 AM Stefan Nobis  wrote:

> [Placing bibliography with "#+bibliography: here"]
> > It is smart, but I'm not sure I like using the same keyword for two
> > different things. OTOH, I don't have a better idea.
>
> I personally also dislike one keyword for completely different
> purposes. Therefore I suggest to take the idea from BibLaTeX and use a
> keyword like "printbibliography" the mark the place where the
> bibliography should be output.

So we need one keyword to designate the bibliographic data file, and
another where to place the formatted output.

> This command may also have parameters like filtering options (maybe
> depending on the backend processor; I only know BibLaTeX so I can't
> say if it would be easy to abstract away differences between different
> engines). In the case of BiBLaTeX the printbibliography command
> optionally accepts multiple key-value parameters. Some examples for
> the keys are "heading" for the chapter/section heading, "type" to
> output/print only entries of a certain type (like "book"; or type
> "online" and with the additional key "nottype" separate non-online and
> online sources), "keyword" to filter entries with the associated
> keyword etc.
>
> Another nice feature of BibLaTeX is the possibility to generate
> bibliography per chapter/section (e.g. setting conference
> proceedings). In the simplest case each chapter/section is marked, in
> the case of LaTeX/BibLaTeX it is wrapped with "\begin{refsection}" and
> "\end{refsection}" and the printbibliography command occurs inside
> this refsection block. In this case BibLaTeX defaults to output only
> references used inside the marked block.

Indeed, this is a good summary, and also a feature often requested on
the Zotero forums.

I think the way biblatex handles this is general, based on reading the
docs, is good.

It'd be nice to have, but maybe not essential for a first step?

Bruce

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Sun, Apr 12, 2020 at 6:19 PM Nicolas Goaziou  wrote:

> denis.maier.li...@mailbox.org writes:
>
> > Just one question concerning typed citations. citeX is good and
> > concise, but why limit this to only one character?
>
> Because… it is good and concise? ;)
>
> > What about allowing something more verbose? Perhaps
> > "cite-intext:" or "cite:intext:"?
>
> Note the latter introduces an ambiguity: [cite:see: @doe was right!].
> Fixing it requires two colons in default cite prefix: [cite::@doe].
> I don't think we want this.
>
> The former doesn't have this bias.

So cite-intext vs citet?

> > The simple syntax is great for most cases, but if you want to support
> > some of those not so common biblatex commands, this might be better.
>
> Alphanumeric suffix provides 62 combinations, which should hopefully be
> enough for any citation back-end out there (I'm looking at you
> biblatex). It's not terribly readable, tho, as you point out.
>
> > What do you think?
>
> This is a conciseness versus readability problem, not a technical one,
> as long as we do not allow too much, from a parser point of view.
>
> I have no strong opinion on the topic. It would be more valuable to hear
> from actual citations users. What would they prefer?

For me, I'm less concerned with the syntax question than I am with the
flexibility and clarity of knowing how to get the output I want.

If I have to look at some table of commands, or pause to remember
which command I need, that's providing friction to my work.

I will add that the biggest request of Zotero's citation support
(which only has the two forms: parenthetical and suppress author) is
textual citations, like natbib's citet.

Perhaps it would make sense to reserve that style in org?


Bruce

Re: org-rss feed title is concatenation of all post titles? (ECM included)

[Stig Brautaset]

Nicolas Goaziou  writes:

> Stig Brautaset  writes:
>
>> Doh! Thanks for that. I tried working around this behaviour ~:lines
>> "1-"~, to skip the included file's #+title line, but that didn't seem to
>> work either. E.g. like this:
>>
>> : #+include: first-post.org :lines "1-"
>
> Doesn't "1-" mean the whole document?

...

Yeees, it does. And using 2- makes it work as I expect. 


PS: Can we pretend this whole thread didn't happen? :-)

Regards,
Stig

Re: links are not parsed in keyword context

[Nicolas Goaziou]

Hello,

Alan Schmitt  writes:

> If you consider the following line in an org file
>
> #+begin_src org
> #+FOO: http://alan.petitepomme.net/
> #+end_src
>
>
> then calling ~org-element-context~ returns
>
> #+begin_src emacs-lisp
> (keyword
>  (:key "FOO"
>   :value "http://alan.petitepomme.net/;
>   :begin 1
>   :end 38
>   :post-blank 1
>   :post-affiliated 1
>   :parent nil))
> #+end_src

This is a feature. With a few exception, keyword value is not parsed,
i.e., Org does not need to understand what happens in there.

> Could is be possible to parse a link in keyword context?

That wouldn't make sense in most contexts.

> Alternatively, should I suggest org-ref uses an approach similar to
> the one in ~org-return~?

I think Org Ref can parse the value of the keyword (a string), instead.
There is, for example, `org-element-parse-secondary-string'.

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Ihor Radchenko]

> I try to record into under headline. For example, I use "org-contacts.el" 
> which
> record people personalized info. I want to see all properties drawer under a
> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.

I recall seeing something similar in stackoverflow.
Here it is:
https://stackoverflow.com/questions/17478260/completely-hide-the-properties-drawer-in-org-mode

The accepted answer has a hint how to achieve what your want.

Best,
Ihor


stardiviner  writes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> stardiviner  writes:
>>
>>> I think the hidden drawers info is useful for users, this should be
>>> shown when org-cycle on headlines.
>>
>> Doesn't this defeat the whole purpose of drawers? What problem do you
>> want to solve?
>
> Hmm, you're right, my patch seems against the purpose of drawers.
>
> I try to record into under headline. For example, I use "org-contacts.el" 
> which
> record people personalized info. I want to see all properties drawer under a
> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.
>
> I agree your opinion. I wonder is it possible to define a buffer local 
> variable
> so that user can control this behavior. WDYT?
>
>>
>> Regards,
>
>
> - -- 
> [ stardiviner ]
>I try to make every word tell the meaning what I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>   
> -BEGIN PGP SIGNATURE-
>
> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6T3JAUHG51bWJjaGls
> ZEBnbWFpbC5jb20ACgkQG13xyVromsPm0Af+JPZpVaz0GBhs3TS4rbKA58fO5RNS
> lBbL0oaLpua9sBIh2erwLCnVff6hDcXW9tZp9CCXkFMlvx/kHJ8izGf8Sq59rPsa
> X7N7szot6W+KJXLEsy+v3VwYcvKX5um8BBh+FrfUguLuCInUy03ZXquiruxHVZun
> eKc67YBi5KpDJVyhkBD3NGSzuhmP8kiJ2hx05dh9PpLB9+YUeUX+8bb82biEu/O0
> ynWItysHG7t116+UuSQ0ShHE2yJffZqa0ygKfIukdPw7hLqBKSrudZX0Zp9yyPHh
> SKh+olNHbOyQCpSZRjrMzhDETBP/g+FjiCMlmO2024F3FOZtyhQF+ALCfw==
> =0jTv
> -END PGP SIGNATURE-
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

Re: wip-cite status question and feedback

[Stefan Nobis]

Nicolas Goaziou  writes:

> Alphanumeric suffix provides 62 combinations, which should hopefully
> be enough for any citation back-end out there (I'm looking at you
> biblatex). It's not terribly readable, tho, as you point out.

I second that. Some of the many BibLaTeX commands are due to
compatibility with other (older) packages and to ease transitions.

Another aspect: Maybe it would be a good idea to reserve some chars
(e.g. the numeric ones) for user defined citation commands (a
minimalistic reserved namespace).


[Placing bibliography with "#+bibliography: here"]
> It is smart, but I'm not sure I like using the same keyword for two
> different things. OTOH, I don't have a better idea.

I personally also dislike one keyword for completely different
purposes. Therefore I suggest to take the idea from BibLaTeX and use a
keyword like "printbibliography" the mark the place where the
bibliography should be output.

This command may also have parameters like filtering options (maybe
depending on the backend processor; I only know BibLaTeX so I can't
say if it would be easy to abstract away differences between different
engines). In the case of BiBLaTeX the printbibliography command
optionally accepts multiple key-value parameters. Some examples for
the keys are "heading" for the chapter/section heading, "type" to
output/print only entries of a certain type (like "book"; or type
"online" and with the additional key "nottype" separate non-online and
online sources), "keyword" to filter entries with the associated
keyword etc.

Another nice feature of BibLaTeX is the possibility to generate
bibliography per chapter/section (e.g. setting conference
proceedings). In the simplest case each chapter/section is marked, in
the case of LaTeX/BibLaTeX it is wrapped with "\begin{refsection}" and
"\end{refsection}" and the printbibliography command occurs inside
this refsection block. In this case BibLaTeX defaults to output only
references used inside the marked block.

[Style selection]
> I think this part is out of Org's scope. Since values between
> various citation back-ends are probably not compatible, e.g., some
> may require a file, others a style name, normalization is not useful
> here. They can use whatever keyword they fancy.

Yes, I second that. But it may be worth thinking a second about using
one Org document to generate output with different backends (e.g. PDF
via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have
some way to configure each citation engine form the same document.
Either use different keywords like "#+CSL_STYLE" and
"#+BIBLATEX_STYLE" or we use your original suggestion of a ":style"
parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to
translate its value individually for each engine - e.g. an alist or
some function provided by the user. And if no translation is provided,
just give the value verbatim to the engine, thus if a user only
targets a single backend, he does not need to provide any
extra configuration.

Just my 2¢.

-- 
Until the next mail...,
Stefan.

links are not parsed in keyword context

[Alan Schmitt]

Hello,

If you consider the following line in an org file

#+begin_src org
#+FOO: http://alan.petitepomme.net/
#+end_src

then calling ~org-element-context~ returns

#+begin_src emacs-lisp
(keyword
 (:key "FOO"
  :value "http://alan.petitepomme.net/;
  :begin 1
  :end 38
  :post-blank 1
  :post-affiliated 1
  :parent nil))
#+end_src

If the same link is in the body of the org file, one gets

#+begin_src emacs-lisp
(link
 (:type "http"
  :path "//alan.petitepomme.net/"
  :format plain
  :raw-link "http://alan.petitepomme.net/;
  :application nil
  :search-option nil
  :begin 38
  :end 66
  :contents-begin nil
  :contents-end nil
  :post-blank 0
  :parent (paragraph
   (:begin 38
:end 68
:contents-begin 38
:contents-end 67
:post-blank 1
:post-affiliated 38
:parent nil
#+end_src

The link can still be opened in both cases using ~org-open-at-point~,
but it is a problem for org-ref that relies on the second format to
extract the link information (see
https://github.com/jkitchin/org-ref/blob/master/org-ref-core.el#L2045,
where the link is set to ~nil~ because there is no ~:path~ property).

I see that orgmode uses a workaround in ~org-return~ when
~org-return-follows-link~ is set to true, to detect if there is a link
using a regexp
(https://code.orgmode.org/bzg/org-mode/src/maint/lisp/org.el#L18106):
#+begin_src emacs-link
((and org-return-follows-link
  (or (org-in-regexp org-ts-regexp-both nil t)
  (org-in-regexp org-tsr-regexp-both nil  t)
  (org-in-regexp org-any-link-re nil t)))
(call-interactively #'org-open-at-point))
#+end_src

Could is be possible to parse a link in keyword context? Alternatively,
should I suggest org-ref uses an approach similar to the one in ~org-return~?

Thanks,

Alan

Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Nicolas Goaziou]

Hello,

stardiviner  writes:

> I try to record into under headline. For example, I use "org-contacts.el" 
> which
> record people personalized info. I want to see all properties drawer under a
> headline when I press [Tab] (org-cycle) to expand it. It's more intuitive.
>
> I agree your opinion. I wonder is it possible to define a buffer local 
> variable
> so that user can control this behavior. WDYT?

I think that drawers and headlines are unrelated, and `org-cycle' should
not handle drawers, even through a variable.

However, using `org-show-all' function, you could write a function that
expands properties drawers, and add it to `org-cycle-hook'.

Regards,

-- 
Nicolas Goaziou