I'm slowly coming back

[Bastien]

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,

-- 
 Bastien

Re: patch for org-confluence.el to add menu entry

[Nicolas Goaziou]

Hello,

Richard Kim  writes:

> Add key binding for converting org mode to Confluence wiki, i.e.,
> 'C-x C-e f f' converts current org buffer to a temporary buffer
> holding Confluence wiki markup.
>
> This key binding takes effect only when org-confluence.el file
> in contrib directory is loaded first.

Thank you. 

However, I meant a commit message using "git format-patch", for proper
attribution.

Regards,

-- 
Nicolas Goaziou

Re: wip-cite status question and feedback

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> I'm not 100% sure, but I think citet meets that goal also, so Denis'
> suggestion might work.

I hadn't realised that AuthorInText was a Citeproc(-hs) interpretation
of CSL.

Anyway, Org cite syntax should:
- fully support CSL,
- allow changing globally style of cites,
- be extensible enough to support « advanced » citation markup (NatBib,
  Biblatex…),
- degrade gracefully when using less advanced markup,
- be short enough

Here's a proposal for a definitive citation syntax.

This syntax implements one default cite command, and specialized (or
typed) ones.

The default citation command is, as usual:

  [cite: ... @key1...]

with allowed global pre/post strings, and a minus marker to specify
SuppressAuthor per cite. 

I assume that [cite:@key] is common enough, so bare @key is a shorthand
for it. Likewise, -@key is a shorthand for [cite:-@key].

Default citations uses the default citation style, which could be
defined globally (by a defcustom), locally (keyword, or property), or
per ".bib" file.

The syntax also provides typed citations:

  [citeX: ... @key1...]

where X stands for any alphanumeric character.

A typed citation is meant to locally override default style. Each
citation back-ends may interpret "X" type, but if they don't, "citeX"
should be treated as "cite".

For example, assuming Citeproc treats

  [cite:@doe]

as (Doe, 2020), then

  [citet:@doe]

could be interpreted as AuthorInText by Citeproc, i.e.,

  Doe (2020)

but

  [citep:@doe]

could be ignored, and therefore become

  (Doe, 2020)

Of course Biblatex may interpret it differently.

Note that the following proposal drops support for [@key1], which
I found awkward anyway.


WDYT?

-- 
Nicolas Goaziou

Re: wip-cite status question and feedback

[Bruce D'Arcus]

Hi,

On Sun, Apr 12, 2020 at 6:38 AM Nicolas Goaziou  wrote:

> Anyway, Org cite syntax should:
> - fully support CSL,
> - allow changing globally style of cites,
> - be extensible enough to support « advanced » citation markup (NatBib,
>   Biblatex…),
> - degrade gracefully when using less advanced markup,
> - be short enough

Perfect.

> Here's a proposal for a definitive citation syntax.
>
> This syntax implements one default cite command, and specialized (or
> typed) ones.
>
> The default citation command is, as usual:
>
>   [cite: ... @key1...]
>
> with allowed global pre/post strings, and a minus marker to specify
> SuppressAuthor per cite.
>
> I assume that [cite:@key] is common enough, so bare @key is a shorthand
> for it. Likewise, -@key is a shorthand for [cite:-@key].

All good.

> Default citations uses the default citation style, which could be
> defined globally (by a defcustom), locally (keyword, or property), or
> per ".bib" file.

I'm just a little confused here, particularly on the last item. Why
would one set a style per bib file?

> The syntax also provides typed citations:
>
>   [citeX: ... @key1...]
>
> where X stands for any alphanumeric character.
>
> A typed citation is meant to locally override default style. Each
> citation back-ends may interpret "X" type, but if they don't, "citeX"
> should be treated as "cite".
>
> For example, assuming Citeproc treats
>
>   [cite:@doe]
>
> as (Doe, 2020), then
>
>   [citet:@doe]
>
> could be interpreted as AuthorInText by Citeproc, i.e.,
>
>   Doe (2020)
>
> but
>
>   [citep:@doe]
>
> could be ignored, and therefore become
>
>   (Doe, 2020)
>
> Of course Biblatex may interpret it differently.

This looks to be an elegant solution to the goals you articulated at the top.

On the "could be ignored" part, you are referring to the optional type
character, so that citey: becomes cite:; correct?

Finally, what does the above example look like when, say, there are
two cites (say @doe2020 and @doe2019), and a global prefix?

Is it this?

[cite:see ;@doe2020;@doe2019]

And a SuppressAuthor variant would be this?

[cite:see ;-@doe2020;-@doe2019]

Bruce

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

[Stig Brautaset]

Hi,

I'm using org-rss.el to generate an RSS feed for my blog. I use a
separate file, ~feed.org~, which uses ~#+include:~ to source entries.
This works well for each item in the feed, but not for the main feed
title and feed image title, which appears to be a concatenation of the
feed and all the titles in all the items.

If I export RSS for the below ~feed.org~, the RSS title becomes:

: The Feed Title Title of first post Title of second post

However I *expect* it to be just:

: The Feed Title

The feed image title also is similarly affected:

#+begin_src xml
  
https://orgmode.org/img/org-mode-unicorn-logo.png
The Feed Title Title of first post Title of second post

  
#+end_src



Below is the Org files used in this example.

feed.org:

#+begin_src org
,#+title: The Feed Title
,* First Post
:PROPERTIES:
:RSS_PERMALINK: first-post.html
:END:
,#+include: first-post.org
,* Second Post
:PROPERTIES:
:RSS_PERMALINK: second-post.html
:END:
,#+include: second-post.org
#+end_src

first-post.org:

#+begin_src org
,#+title: Title of first post
First post content.
#+end_src

second-post:

#+begin_src org
,#+title: Title of second post
Second post content.
#+end_src


Software Versions:

- macOS 10.15.3
- Org mode version 9.3.2 (9.3.2-24-g5c72d6-elpaplus @ 
/Users/stig/.emacs.d/elpa/org-plus-contrib-20200203/)
- GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.20 Version 
10.14.3 (Build 18D109)) of 2019-09-02


Regards,
Stig

Re: wip-cite status question and feedback

[Nicolas Goaziou]

> I'm just a little confused here, particularly on the last item. Why
> would one set a style per bib file?

No idea. The need exists though:


This is a natural following step. Does Org need to standardize styles?
Or is it up to each citation back-end to handle this? 

My naive thinking was to allow something like:

   #+bibliography: "something.bib" :style author-year

but maybe the "style" part is too citation back-end dependant, and
should not be standardized.

I would be nice, however, to standardize two keywords: one to define
a bibliography, and another one to insert it in a document, upon export.

Suggestions welcome!

> On the "could be ignored" part, you are referring to the optional type
> character, so that citey: becomes cite:; correct?

Yes, basically, the parser returns, e.g., '(:style "y"). It is up to the
citation back-end to interpret, or not, that :style attribute. If it
ignores it, the citation effectively becomes equivalent to '(:style
nil), i.e., "cite:". Is that clearer?

> Finally, what does the above example look like when, say, there are
> two cites (say @doe2020 and @doe2019), and a global prefix?
>
> Is it this?
>
> [cite:see ;@doe2020;@doe2019]

Yes, and a "t-styled" citation would be:

  [citet:see;@doe2020;@doe2019]

Barring the prefix, the syntax of the citation does not change wrt to
"wip-cite" branch. However, this is enough to be slightly incompatible,
hence the "wip".

> And a SuppressAuthor variant would be this?
>
> [cite:see ;-@doe2020;-@doe2019]

Indeed.

How does that sound?

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]

* Small documentation errors

Hi.  Below I report a series of small documentation errors.  Please tell
me whether it was helpful to coalesce these several errors into one bug
report or I should have filed several reports.

** [[info:org#Sparse Trees]]

 The final paragraph recommends the command ‘C-c C-e v’ to export only
the visible part of the document.  The correct keybinding, however, is
‘C-c C-e C-v’.

** [[info:org#Plain Lists]]

The description of `C-c -' inverts the effect of the prefix argument.

** [[info:org#Drawers]]

I don't understand the sentence

   Completion over drawer keywords is also possible using ‘M-’

Could give me a simple example of drawer keyword completion?

** [[info:org#TODO Basics]]

This section omits `C-S-'.  Is that intentional?

** [info:org#Tracking TODO state changes]

The following sentence is misplaced, interrupting the previous train of
thought:

To record a timestamp without a note for TODO keywords configured
with `@', just type `C-c C-c' to enter a blank note when prompted.

** Docstring of `org-time-stamp-inactive'

It has less information than the docstring of `org-time-stamp'.  If that
is intentional, then I suggest at least referring to the docstring of
`org-time-stamp' for more information.

Also, it says that inactive timestamp do not link to the calendar and
cannot be changed with the S-cursor keys; the actual behavior -- which I
tested both in an updated Spacemacs (develop branch) and in `emacs -q`
-- contradicts both assertions.

Finally, the last paragraph says:

When called with two universal prefix arguments, insert an active
time stamp with the current time without prompting the user.

Clearly it should say /inactive/ instead of /active/.

* Feedback

I am obsessed with detail and I welcome feedback about that.  Please
tell me whether I am nitpicking.

Regards

Emacs  : GNU Emacs 27.0.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
 of 2020-04-11
Package: Org mode version 9.3.6 (9.3.6-29-g6a3dff-elpaplus @ 
/home/jorge/.emacs.d/elpa/27.0/develop/org-plus-contrib-20200406/)
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

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

[Nicolas Goaziou]

Hello,

Stig Brautaset  writes:

> I'm using org-rss.el to generate an RSS feed for my blog. I use a
> separate file, ~feed.org~, which uses ~#+include:~ to source entries.
> This works well for each item in the feed, but not for the main feed
> title and feed image title, which appears to be a concatenation of the
> feed and all the titles in all the items.

Indeed. According to the manual, in (info "(org)Export settings")

  ‘TITLE’
   Org displays this title.  For long titles, use multiple ‘#+TITLE’
   lines.

Multiple TITLE keywords are concatenated to create a document title.


Regards,

-- 
Nicolas Goaziou

Re: wip-cite status question and feedback

[Bruce D'Arcus]

I'm going to split off the syntax part of your email, Nicholas, for
quick comment.

I need to think more about the other questions.

On Sun, Apr 12, 2020 at 10:02 AM Nicolas Goaziou  wrote:

> > Finally, what does the above example look like when, say, there are
> > two cites (say @doe2020 and @doe2019), and a global prefix?
> >
> > Is it this?
> >
> > [cite:see ;@doe2020;@doe2019]
>
> Yes, and a "t-styled" citation would be:
>
>   [citet:see;@doe2020;@doe2019]
>
> Barring the prefix, the syntax of the citation does not change wrt to
> "wip-cite" branch. However, this is enough to be slightly incompatible,
> hence the "wip".
>
> > And a SuppressAuthor variant would be this?
> >
> > [cite:see ;-@doe2020;-@doe2019]
>
> Indeed.
>
> How does that sound?

Good; no issues that I see with this at all.

Only question is I see you removed whitespace after the prefix on your
citet: example.

Is the expectation (which is reasonable; am just asking) that prefixes
would add the whitespace after it on output, so users don't have worry
about this?

So in other words, the value of an affix would be a trimmed string?

Bruce

Re: wip-cite status question and feedback

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> On Sun, Apr 12, 2020 at 10:02 AM Nicolas Goaziou  
> wrote:

>> Yes, and a "t-styled" citation would be:
>>
>>   [citet:see;@doe2020;@doe2019]
>>
>> Barring the prefix, the syntax of the citation does not change wrt to
>> "wip-cite" branch. However, this is enough to be slightly incompatible,
>> hence the "wip".
>
> Good; no issues that I see with this at all.

Great!

I'll wait a bit for others to comment. If there is no objection, I'll
implement this in "wip-cite" and rebase that branch on top of "master"
for easier testing and feedback.

> Only question is I see you removed whitespace after the prefix on your
> citet: example.
>
> Is the expectation (which is reasonable; am just asking) that prefixes
> would add the whitespace after it on output, so users don't have worry
> about this?
>
> So in other words, the value of an affix would be a trimmed string?

That was a typo. But that's a good question anyway.

Generally speaking, I'd rather avoid any magic, so the parser should not
add any space whatsoever. However, should it remove some?

AFAICT, Biblatex would probably ignore spacing since it provides its own
mechanism to separate multiple cites. I don't know about Citeproc. Maybe
trimming prefixes and postfixes is the way to go. What would you suggest
here?

In any case, consecutive spaces ought to be packed into a single one.
This allows auto-filling a paragraph at a citation, e.g.,

  Some very long explanation [cite:see @doe2020 
  pp. 12-15].

is equivalent to

  Some very long explanation [cite:see @doe2020 pp. 12-15]

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Sun, Apr 12, 2020 at 11:32 AM Nicolas Goaziou  wrote:
>
> "Bruce D'Arcus"  writes:

...

> > So in other words, the value of an affix would be a trimmed string?
>
> That was a typo. But that's a good question anyway.
>
> Generally speaking, I'd rather avoid any magic, so the parser should not
> add any space whatsoever. However, should it remove some?
>
> AFAICT, Biblatex would probably ignore spacing since it provides its own
> mechanism to separate multiple cites. I don't know about Citeproc. Maybe
> trimming prefixes and postfixes is the way to go. What would you suggest
> here?

In that case, since it was a typo, I would do as pandoc does: treat it
as a string.

The below syntax examples are more clear.

> In any case, consecutive spaces ought to be packed into a single one.
> This allows auto-filling a paragraph at a citation, e.g.,
>
>   Some very long explanation [cite:see @doe2020
>   pp. 12-15].
>
> is equivalent to
>
>   Some very long explanation [cite:see @doe2020 pp. 12-15]

That makes sense.

Bruce

Re: wip-cite status question and feedback

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> In that case, since it was a typo, I would do as pandoc does: treat it
> as a string.

Do you mean: keep all spaces wherever they may be?

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Sun, Apr 12, 2020 at 11:58 AM Nicolas Goaziou 
wrote:
>
> "Bruce D'Arcus"  writes:
>
> > In that case, since it was a typo, I would do as pandoc does: treat it
> > as a string.
>
> Do you mean: keep all spaces wherever they may be?

No, I thought your point about auto-filling was a good one.

Re: wip-cite status question and feedback

[denis . maier . lists]

Nicolas Goaziou  hat am 12. April 2020 17:32 
geschrieben:
> 
>  
> "Bruce D'Arcus"  writes:
> 
> > On Sun, Apr 12, 2020 at 10:02 AM Nicolas Goaziou  
> > wrote:
> 
> >> Yes, and a "t-styled" citation would be:
> >>
> >>   [citet:see;@doe2020;@doe2019]
> >>
> >> Barring the prefix, the syntax of the citation does not change wrt to
> >> "wip-cite" branch. However, this is enough to be slightly incompatible,
> >> hence the "wip".
> >
> > Good; no issues that I see with this at all.
> 
> Great!
> 
> I'll wait a bit for others to comment. If there is no objection, I'll
> implement this in "wip-cite" and rebase that branch on top of "master"
> for easier testing and feedback.

Your proposal looks good to me. Just one question concerning typed citations. 
citeX is good and concise, but why limit this to only one character? 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.
What do you think? (I think there's been a discussion about that, but I don't 
remember the exact details.) Anyway, I think your proposal is a good start, and 
it can be extended afterwards.

Concerning some other open questions, I suggest sticking to what citeproc-org 
uses:

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

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...)

3. Setting the style:
#+CSL_STYLE: "some-style.csl"

Of course, if you're using biblatex or natbib you'll need another option for 
that.

Best,
Denis

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

[Stig Brautaset]

Nicolas Goaziou  writes:
> Indeed. According to the manual, in (info "(org)Export settings")
>
>   ‘TITLE’
>Org displays this title.  For long titles, use multiple ‘#+TITLE’
>lines.
>
> Multiple TITLE keywords are concatenated to create a document title.

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

Regards,
Stig

Bug: Org with auto-fill does not insert linebreaks properly [9.3 (release_9.3 @ /snap/emacs/current/usr/share/emacs/27.0.90/lisp/org/)]

[Leo Alekseyev]

Consider the following text:
begin example
---
---
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
---
---
end example-

With auto-fill mode on, continuing to type on the "Lorem ipsum"
line results in the following:
begin example
---
---
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
---eiusmod asdf
---
end example-

Notice how "eiusmod" does not start on a new line, as would be expected.
Here is a GIF of this behavior in action:
https://www.dropbox.com/s/w9a803t0qotqe6j/org_autofill_bug.gif?dl=0

Tested with emacs -Q, org 9.3 (lisp that ships with emacs 27)

Re: wip-cite status question and feedback

[Nicolas Goaziou]

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.

> 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?

> Concerning some other open questions, I suggest sticking to what
> citeproc-org uses:
>
> 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.

> 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.

> 3. Setting the style:
> #+CSL_STYLE: "some-style.csl"
>
> Of course, if you're using biblatex or natbib you'll need another
> option for that.

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.

Regards,

-- 
Nicolas Goaziou

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

[Nicolas Goaziou]

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?

Re: Bug: Org with auto-fill does not insert linebreaks properly [9.3 (release_9.3 @ /snap/emacs/current/usr/share/emacs/27.0.90/lisp/org/)]

[Nicolas Goaziou]

Hello,

Leo Alekseyev  writes:

> Consider the following text:
> begin example
> ---
> ---
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
> ---
> ---
> end example-
>
> With auto-fill mode on, continuing to type on the "Lorem ipsum"
> line results in the following:
> begin example
> ---
> ---
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
> ---eiusmod asdf
> ---
> end example-
>
> Notice how "eiusmod" does not start on a new line, as would be
> expected.

I don't think this is specific to Org mode. Text mode behaves the same.
The prefix for the current paragraph is "---".

Regards,

-- 
Nicolas Goaziou

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:

> * Small documentation errors
>
> Hi.  Below I report a series of small documentation errors.  Please tell
> me whether it was helpful to coalesce these several errors into one bug
> report or I should have filed several reports.

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

I'm responding to some of the points below, focusing on what I viewed as
the more clear-cut errors.

> ** [[info:org#Sparse Trees]]
>
>  The final paragraph recommends the command ‘C-c C-e v’ to export only
> the visible part of the document.  The correct keybinding, however, is
> ‘C-c C-e C-v’.

Corrected.

> ** [[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

AFAICS that matches the manual's description.

> ** Docstring of `org-time-stamp-inactive'
[...]
> Also, it says that inactive timestamp do not link to the calendar and
> cannot be changed with the S-cursor keys; the actual behavior -- which I
> tested both in an updated Spacemacs (develop branch) and in `emacs -q`
> -- contradicts both assertions.

That statement has been around a while.  Perhaps that used to be a case,
but, testing a few recent versions, it certainly doesn't seem true now.
I've removed that part.

> Finally, the last paragraph says:
>
> When called with two universal prefix arguments, insert an active
> time stamp with the current time without prompting the user.
>
> Clearly it should say /inactive/ instead of /active/.

This was recently fixed by Leo Vivier in acd163596 (2020-04-08).

Re: Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]

[Gustavo Barros]

Hi Kyle,

On Sun, Apr 12 2020, Kyle Meyer wrote:


I'll plan to revert the commit tomorrow.  Please chime in if you
disagree with me doing so.


Reverted in 1de7eabf2.


Thank you very much for this. I've already received the weekly build, 
and it looks good again.
Hopefully a solution for the one-time delay issue which does not trigger 
this new problem can be found.  But I concur (if I may) it was a wise 
decision to revert the commit in the meantime.


Best,
Gustavo.

Re: I'm slowly coming back

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


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,

I'm happy to hear your coming back news. Glad to see you active on ML.

- -- 
[ 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-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6T28kUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsM/dwf/ZhuSQdfkhIMnfIMdsgy4dYfpvSUo
sCHU4/onncddi1rxBAczBpD7Ryet7C+rXVdJrnvKI254lM8B1j+9JJLpl+A6q6w5
JxiPVAsRRy42xujLM1X/8cPfti0fCdTFxuA5E0UD2KAF565WfxwTpkC2TmQmCS6W
VmuMabdO5/n7nN+I3wW3WyGfhK7cu0uu/E/fnMGNxH83ItqjSbGZY1Isqu4s0IwL
H0m05PGLvjoTy9SVrIvobr8twIK+w0ya68mbr0w0y512CsUjuEA7SEjENCkm8MBo
CjapuofUcjaou8MELytT1svyrLkmsBaw2FN6POXS2GtrgYgIg6B2dh404g==
=hyin
-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 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-