Re: [WDYT, mini] key h in agenda for quick help

[Bastien]

Timothy  writes:

> Great to hear! I think this would probably be developed as a branch like
> wip-cite-new

Yes.

> , and it would need transient to be installed (via ELPA?) on
> Emacs <28, but I think it has the potential to both:
>  - Improve the user experience, and
>  - Remove Org's own home-cooked transient-ish interfaces,
>so leave us with less code to watch over

Yes, exactly.  Also there is plan to include Transient in Emacs core,
so this makes this move even more appealing:

https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00944.html

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

[Bastien]

Hi Juan,

Juan Manuel Macías  writes:

> Done! I've attached the corrected patch. Sorry for the flaws in me
> previous patch: I'm a bit of a novice at submitting patches...

applied in the maint branch as commit 5be650714.

The patch was missing a proper changelog entry: please see
https://orgmode.org/worg/org-contribute.html#commit-messages
for future patches.

Thanks!

Re: [PATCH] org-protocol: Fix missing '+' in js snippet

[Bastien]

Hi Maxim,

Maxim Nikulin  writes:

> On 19/04/2021 17:53, David Asabina wrote:
>>   javascript:location.href =
>> \\='org-protocol://capture?url=\\='+ \\
>> -encodeURIComponent(location.href) + \\='=\\=' \\
>> +encodeURIComponent(location.href) + \\='=\\=' + \\
>>   encodeURIComponent(document.title) + \\='=\\=' + \\
>>   encodeURIComponent(window.getSelection())
>
> I am not a maintainer, so I can not merge the patch. I hope, finally
> it will happen, maybe some months later.

Would you like to volunteer as the maintainer for org-protocol.el?

For now org-protocol.el indicates that Sebastian Rose, the original
author, is the maintainer, but I don't think he would mind handing it
to someone else.

Re: [PATCH] org-protocol: Fix missing '+' in js snippet

[Bastien]

Applied, thanks a lot.

David Asabina  writes:

> * org-protocol (org-protocol-capture): Add missing plus-sign to
> javascript snippet to allow readers of the doc string to use example
> snippet with minimal edits.

Re: [WDYT, mini] key h in agenda for quick help

[Timothy]

Bastien  writes:

> I would welcome patches for moving Org to using transient.
>
> Since this is a big effort, big then we will probably move to
> supporting Emacs >= 25.1.

Great to hear! I think this would probably be developed as a branch like
wip-cite-new, and it would need transient to be installed (via ELPA?) on
Emacs <28, but I think it has the potential to both:
 - Improve the user experience, and
 - Remove Org's own home-cooked transient-ish interfaces,
   so leave us with less code to watch over

--
Timothy

Re: Manual on web site is not the latest version

[Bastien]

Do you still see differences between the doc/org-manual.org and the
one published on https://orgmode.org/manual/ ? 

If so, please point at one or two differences.  Thanks!

Re: Include org-pretty-table by Matus Goljer (Fuco1) in org-mode

[Bastien]

Hi Arthur,

Arthur Miller  writes:

> Can we get org-pretty-table into org-mode?
>
> https://github.com/Fuco1/org-pretty-table

It is a matter of personal visual preferences, so it is good that it
exists as a separate package.  If you think people should know more
about it, please contribute to Worg by advertizing it there.

See https://orgmode.org/worg/worg-about.html

Thanks

Re: [WDYT, mini] key h in agenda for quick help

[Bastien]

Timothy  writes:

> I actually think Org would benefit from using transient (which has
> recently been merged into Emacs), and it could reduce the maintenance
> burden, but I suppose that's not possible with our minimum version at
> Emacs 24...

I would welcome patches for moving Org to using transient.

Since this is a big effort, big then we will probably move to
supporting Emacs >= 25.1.

Re: [WDYT, mini] key h in agenda for quick help

[Timothy]

Bastien  writes:

> thanks for the proposal.  I'm not convinved that users who don't know
> about `C-h m' will think of hitting `h' or another key.  I might be
> wrong, so if beginners suggest they expect such a key and were amazed
> at how useful C-h m was for them when reading this thread, I might
> change my mind.

I can distinctly recall hitting "?" in Org agenda when I was getting
started, after getting used to Magit.

I actually think Org would benefit from using transient (which has
recently been merged into Emacs), and it could reduce the maintenance
burden, but I suppose that's not possible with our minimum version at
Emacs 24...

--
Timothy

Re: [WDYT, mini] key h in agenda for quick help

[Bastien]

Hi Marco,

Marco Wahl  writes:

> What do you think about binding key h to function describe-mode in Org
> agenda?  Basically pressing key h would open a window showing the key
> bindings in the agenda.  There would also be additional information.
>
> The implementation could be just the line
>
> (org-defkey org-agenda-mode-map (kbd "h") #'describe-mode)

thanks for the proposal.  I'm not convinved that users who don't know
about `C-h m' will think of hitting `h' or another key.  I might be
wrong, so if beginners suggest they expect such a key and were amazed
at how useful C-h m was for them when reading this thread, I might
change my mind.

Re: Turning off all indentation in 9.4.4

[Bastien]

TRS-80  writes:

> So, my reading of this new(?) headline-data setting, was that it seemed
> to be exactly what I had been looking for!  But perhaps I misunderstood?

So core idea behind (setq org-adapt-indentation 'headline-data) is to
let people end up with:

* TODO item
  :PROPERTIES:
  :CUSTOM_ID: item
  :END:
  :LOGBOOK:
  ...
  :END:

A paragraph here.

Let me know if if does not what you want, including what you expect
from hitting RET after the headline, with the various combinations of
org-adapt-indentation and electric-indent-mode.

Re: Turning off all indentation in 9.4.4

[Bastien]

Hi TRS-80,

TRS-80  writes:

> In the same timeframe, I have also noticed my Logbook entries not being
> indented (when changing TODO states) which I think was also brought
> about by this change (or rather, my changes to org-adapt-indentation).
> I am not sure if I should make a separate thread about that, or not?

this particular issue has been fixed yesterday in master, if you want
to give it a try.

Thanks!

Re: [patch] to allow org-attach-git to handle individual repositories

[Bastien]

Hi Juan,

Juan Manuel Macías  writes:

> I would like to propose and discuss this patch for org-attach-git,
> following a series of comments and suggestions from Ihor Radchenko in
> this thread:
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00483.html

thanks for the patch and sorry for the slow reply.

It looks good but it is significative enough to require you to sign
the FSF copyright assignment.  If you're willing to go through this
(which will secure future contributions too), please see:

https://orgmode.org/request-assign-future.txt

Thanks!

Re: [PATCH]

[Timothy]

Bastien  writes:

> Feel free to install changes when they have reached consensus, 
> or to ask for decisions when not.

Thanks for the reply Bastien, would you mind elaborating on this a bit
more? I'm comfortable with the idea of what I can do with org-plot.el as
the maintainer (directly push, but field patches to the ML for
non-trivial changes), but as a non-core-contributor I didn't think I
could push my own patches for other things.

Also, with the batch of patches I sent a plea about recently, how would
you recommend I proceed with that? There doesn't seem to be any
consensus or decision despite prompting.

Thanks,

Timothy

Re: org-goto and org-store-link/org-id-get-create

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> A fix to this particular issue could be using org-no-read-only in
> org-entry-put. Though more functions may suffer from similar issues in
> read-only org buffers.

Can you provide a patch for this?

Re: Free up C-c SPC/org-table-blank-field?

[Bastien]

Eric Abrahamsen  writes:

> That took a while, for such a simple patch! Hope this is acceptable.

... and it took a while to install it, but finally done with commit
7a1c8cadf. 

Thanks!

Re: org-fontify-done-headline t by default?

[Bastien]

Hi,

Kévin Le Gouguec  writes:

> I don't have a strong opinion about org-fontify-done-headline being t by
> default (though I disable it), but I agree that the current definition
> of org-headline-done is jarring with most of the themes out there.

Agreed too.

> Maybe it would make sense to make it inherit from one of Emacs's core
> faces (e.g. shadow): that would pretty much guarantee that themes would
> cover it, so it would stand out less.

Agreed here again, I would welcome a patch to enhance this.

Anyone?

Re: [PATCH]

[Bastien]

Hi Timothy,

TEC  writes:

> This is just some tweaks to the styling in ox-html that I think may
> appeal (and prevent ridiculously long lines on non-small displays, which
> are an issue for legibility).

thanks for the patches and sorry for the slow reply.

Feel free to install changes when they have reached consensus, 
or to ask for decisions when not.

Thanks!

Re: Bug: org-babel only tangles first noweb reference on a line [9.4 (9.4-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Bastien]

Hi Kyle,

Kyle Meyer  writes:

> A patch upthread ()
> was applied in 469ee6340 (ob-core: Fix handling of multiple noweb refs
> in same line, 2020-09-15).

I missed this one, thanks for letting me know and sorry for the noise.

Re: More use of lexical-binding in ox.el

[Stefan Monnier]

> It looks great but it introduces a test failure, however.
>
> `org-export-expand-include-keyword' is called from within
> `org-export-with-buffer-copy'.
>
> At the very beginning of `org-export-expand-include-keyword', there is
>
>   (buffer-file-name (buffer-base-buffer))
>
> Before the patch, it returned the source file name. After the patch it
> returns nil.
>
> Actually I'm a bit surprised it used to work, since we're evaluating
> this from a new buffer, not an existing one. But hey, it worked!

That's because the "buffer copy" also copies the local vars, and indeed
that's where I made a typo.

> Do you know what could cause this?

Yes:

(push (cons var val) varvals
   varvals)))

should be

(push (cons var val) varvals)
 varvals))

so that the final `varvals` is outside the `dolist` (it's the thing we
want to return to store it in the outer `varvals` variable).

Sorry 'bout that,


Stefan

Re: org-info-store-link uses :desc instead of :description

[Nicolas Goaziou]

Hello,

Alex  writes:

> In the definition of |org-info-store-link|, when calling
> |org-link-store-props|, the |:desc| key is given whereas I think 
> |:description| was intended.

You're right. This should now be fixed. Thank you.

Regards,
-- 
Nicolas Goaziou

Re: How to reinject custom function into derived backend which doesn't implement it, ex : footnote in ox-slimhtml backend.

[Nicolas Goaziou]

Hello,

rey-coyrehourcq  writes:

> Actually footnotes are not defined in ox-slimhtml, so as i read in the org 
> documentation [1] ), 
> i try to add this capacity by simply calling vanilla ox-html function 
> org-html-footnote-reference into translate-alist :
>
> (org-export-define-derived-backend 'ox-slimhtml-publish-to-html 'slimhtml


The first argument of `org-export-define-derived-backend' should be the
name of the new back-end, as a symbol, not the function used to publish.
E.g,

  (org-export-define-derived-backend 'slimhtml-improved 'slimhtml
   )

>   :translate-alist '((bold . ox-slimhtml-bold)
>  
> (footnote-reference . org-html-footnote-reference)
>  (verse-block . org-html-
> verse-block)
>  (special-block . org-html-special-block)))
>
> Using the vanilla ox-html export function, everything is awesome and footnote 
> appear in my html, normal.
>  
> :publishing-function org-blog-publish-to-html 
>
> But if i switch to ":publishing-function ox-slimhtml-publish-to-html"
> the function 

You need to define your own publishing function with the help of
`org-publish-org-to' and make it use `slimhtml-improved. Here you're
re-using plain slimhtml, without your additions. E.g.,

  (defun ox-slimhtml-improved-publish-to-html (plist filename pub-dir)
"Publish an org file to html.
  PLIST is the property list for the given project.  FILENAME
  is the filename of the Org file to be published.  PUB-DIR is
  the publishing directory.
  Return output file name."
(let ((html-extension (or (plist-get plist :html-extension) 
org-html-extension)))
  (org-publish-org-to 'slimhtml-improved
  filename
  (if (and html-extension (not (string= "" 
html-extension)))
  (concat "." html-extension) "")
  plist
  pub-dir)))

Then you can set :publishing-function to `org-slimhtml-publish-to-html'.

> There is something i don't understand in the processing of "translate-alist", 
> so perhaps if the derived backend doesn't
> implement a footnote-reference function, i cannot extend it ?

You should be able to extend it.

Regards,
-- 
Nicolas Goaziou

Re: The Website Revamp: The final stretch

[Bastien]

Timothy  writes:

> Bastien  writes:
>
>> I suggest having a new https://orgmode.org/manuals.html page
>> Timothy, WDYT?
>
> I've seen a few manual-related requests like this but held off from
> doing anything from a concern about clutter. Now that you mention it, I
> think a dedicated page would make a lot of sense .
>
> I could have a go at this during the weekend.

Thanks in advance!

Re: Bug: org-babel only tangles first noweb reference on a line [9.4 (9.4-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Kyle Meyer]

Bastien writes:

> Hi Tom,
>
> Tom Gillespie  writes:
>
>>The 9.4 release has a bug where it will only tangle the first noweb
>> reference on a line.
>> This is also present at 9c31cba002a1ba93053aebea1f778be87f61ba06. It happens 
>> in
>> emacs-27 and emacs-28. The reproduction is below. Best!
>> Tom
>>
>> The expected content of oops-3.el should be 1 2 1, but is instead 1
>> <> <>.
>> C-c C-v C-t or C-c C-v C-v will show the issue.
>
> Do you still have this issue?  I cannot reproduce it here.

A patch upthread ()
was applied in 469ee6340 (ob-core: Fix handling of multiple noweb refs
in same line, 2020-09-15).

Re: More use of lexical-binding in ox.el

[Nicolas Goaziou]

Hello,

Stefan Monnier  writes:

> Here's another patch to remove some more use of the old dynamically
> scoped dialect of ELisp.
>
> Stefan
>
>
> * lisp/ox.el: Fix various uses of the non-lexical-binding ELisp dialect.
> (org-export--get-global-options, org-export-insert-default-template):
> Use lexical-binding.
> (org-export--generate-copy-script): Return a closure rather than
> list starting with `lambda`.
> (org-export-async-start): Turn it into a function (there seems to be
> no reason this was a macro).  Use `write-region` rather than
> `with-temp-file`.  Always use `utf-8-emacs-unix` coding system since
> it's more efficient and is guaranteed to handle all chars.
> Use lexical-binding in the temp file as well.
> Actually set `debug-on-error` if `org-export-async-debug` says so.
> (org-export-to-buffer, org-export-to-file): Pass a closure rather than
> list starting with `lambda` to `org-export-async-start`.

Thank you!

It looks great but it introduces a test failure, however.

`org-export-expand-include-keyword' is called from within
`org-export-with-buffer-copy'.

At the very beginning of `org-export-expand-include-keyword', there is

  (buffer-file-name (buffer-base-buffer))

Before the patch, it returned the source file name. After the patch it
returns nil.

Actually I'm a bit surprised it used to work, since we're evaluating
this from a new buffer, not an existing one. But hey, it worked!

Do you know what could cause this?

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] org-refile.el: Add org-refile-reverse which toggles org-reverse-note-order

[Bastien]

Hi Adam,

Kyle Meyer  writes:

> Thanks for the patch.
>
> Adam Spiers writes:
>
>> This is useful for prepending to the start of the target headline
>> instead of appending to the end, or vice-versa depending on
>> org-reverse-note-order.
>
> It sounds like Bastien and Amin would also find this useful.  I would
> have liked to see a few more people chime in because I'm lukewarm on it
> myself, as I tend to think things like this are better suited for
> personal customization.
>
> In any case, I think we should go forward with it.  Could you add a
> changelog entry to the commit message?

Sorry if I miss latest Adam's patch, with a changelog entry and a
commit message -- Adam, would you mind resending it?

Thanks

Re: prettify-symbols-mode in org agenda?

[Bastien]

Hi William,

William Xu  writes:

> Thanks for the info. I'll be happy to prepare the patch. However, I
> would like to hear what is the opinion of org maintainter(s) on this
> topic.

Thanks for bringing this idea up.

If allowing prettify-symbols-mode in Org agenda mode does not slow
down the agenda display and does not create spacing problems, then
yes, why not.

Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient

[Bastien]

Hi Adam,

Adam Spiers  writes:

> [This is only lightly tested and therefore probably not quite ready
> for merging yet; however I'm submitting now to get feedback.]

Did you make any progress on stabilizing this patch?

Thanks

Re: org-cycle-internal-local unfold a plain list in parent

[Bastien]

Hi Yasushi,

sorry for the slow reply.

Yasushi SHOJI  writes:

> I see a plain list unfolded when I cycle a sub headline.

I have no time fixing this right now, but I confirm the bug,
thanks for reporting this.

Re: How to reinject custom function into derived backend which doesn't implement it, ex : footnote in ox-slimhtml backend.

[Bastien]

Hi,

rey-coyrehourcq  writes:

> I'm trying to develop my own `publish.el` for some research project
> linked to reproductibility.

You didn't receive much feedback - sorry for that.

Did you make progress about your project?

Re: [PATCH] Persistently save downloaded inline remote images

[Bastien]

Hi Jack,

Jack Kamm  writes:

> If we do proceed in this direction, I'd suggest replacing the current
> cache mechanism entirely -- I don't see a good reason to maintain 2
> solutions to the same problem. Also, we could combine the "download" and
> "cache" options into a single implementation, making them synonyms for
> backwards compatibility.

I just added a call for help about this.  Thanks!

Re: [PATCH] Persistently save downloaded inline remote images

[Bastien]

Hi,

Jack Kamm  writes:

> So, I suggest Ferdinand confirm he's tested the existing "cache" option,
> and articulate why he found it unsuitable, before merging this.

As no feedback was received, I'm discarding this patch.

Re: [PATCH] Add org-meta*-final-hook

[Bastien]

Hi Jay,

Jay Bosamiya  writes:

> Similar to org-shiftup-final-hook, org-shiftdown-final-hook, etc, I
> have added org-metaup-final-hook, org-metadown-final-hook, etc.
> Please see attached patch.

Can you give a concrete example of a hook here?

And thanks for the patch.

As Timothy suggested, you may need to sign the FSF paper before we can
accept it (although in this case, "original" lines are probably below
the limit of 15 lines).

Would you agree to sign https://orgmode.org/request-assign-future.txt?

This would secure future contributions too.

Re: The Website Revamp: The final stretch

[Timothy]

Bastien  writes:

> I suggest having a new https://orgmode.org/manuals.html page
> Timothy, WDYT?

I've seen a few manual-related requests like this but held off from
doing anything from a concern about clutter. Now that you mention it, I
think a dedicated page would make a lot of sense .

I could have a go at this during the weekend.

--
Timothy

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

[Nicolas Goaziou]

Hello,

"Cheong Yiu Fung"  writes:
> Subject: [PATCH] org-manual.org: add hints for visible-only export

I tweaked your commit messages and applied your patches.

Thank you.

Regards,
-- 
Nicolas Goaziou

Re: The Website Revamp: The final stretch

[Bastien]

David Arroyo Menendez  writes:

> Another important thing, I will happy if we can add some link to the
> spanish version of org guide. You can find the sources in
> https://savannah.nongnu.org/git/?group=orgguide-es

I suggest having a new https://orgmode.org/manuals.html page for
listing the various ressources:

- The HTML single-page manual
- The PDF manual
- The HTML multiple-pages manual
- The Org guide (HTML and PDF)
- The Worg documentation

And translations:

- The spanish translation mentioned by David
- The french translation of the Org Guide :
  https://code.orgmode.org/bzg/orgguide_fr/

Timothy, WDYT?

bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use

[Nicolas Goaziou]

Hello,

Utkarsh Singh  writes:

> I am attaching my patch which also include my previous suggestion of
> including yes-or-no prompt to org-table-import to allow file which don't
> have csv, tsv or txt as extension.  

I suggest to make several patches. Do not try to stuff as many changes
as possible in a single one, please.

> + When using org-table-import interactively if we failed to guess
> separator then we will be left with a user-error message and an
> 'unconverted table'.  We can make use of 'temp-buffer' to import our
> file after successfully conversion.

I'm not sure to understand what you mean.

> + Conversion part of org-table-convert-region make a distinction between
> '(4) (comma separator) and rest of the separator we should either string
> version of comma as AND condition or rewrite to simplify it.

Ditto. But it can be the object of another patch. Let's concentrate on
`org-table-guess-separator' first.

> I am willing to do these possible changes but currently waiting for your
> review for org-table-guess-separator as there can be more serious bugs
> lurking around on my code which I am considering base for these
> changes.

You should definitely write tests for this function. Here's a start:

(ert-deftest test-org-table/guess-separator ()
  "Test `test-org-table/guess-separator'."
  ;; Test space separator.
  (should
   (equal " "
  (org-test-with-temp-text "a b\nc d"
(org-table-guess-separator (point-min) (point-max)
  (should
   (equal " "
  (org-test-with-temp-text "a b\nc d"
(org-table-guess-separator (point-min) (point-max)
  ;; Test "inverted" region.
  (should
   (equal " "
  (org-test-with-temp-text "a b\nc d"
(org-table-guess-separator (point-max) (point-min)
  ;; Do not error on empty region.
  (should-not
   (org-test-with-temp-text ""
 (org-table-guess-separator (point-max) (point-min
  (should-not
   (org-test-with-temp-text "   \n"
 (org-table-guess-separator (point-max) (point-min)

> +  (end (save-excursion
> +(goto-char (max beg end0))

This should be beg0 instead of beg above.

> + (sep-regexp '((","  (rx bol (1+ (not (or ?\n ?,))) eol))
> +("\t" (rx bol (1+ (not (or ?\n ?\t))) eol))
> +(";"  (rx bol (1+ (not (or ?\n ?\;))) eol))
> +(":"  (rx bol (1+ (not (or ?\n ?:))) eol))
> +(" "  (rx bol (1+ (not (or ?' ?\" ))
> + (not (or ?\s ?\;))
> + (not (or ?' ?\"))) eol

Use
 (sep-regexp
  (list (list ","  (rx bol (1+ (not (or ?\n ?,))) eol))
(list "\t" (rx bol (1+ (not (or ?\n ?\t))) eol))
(list ";"  (rx bol (1+ (not (or ?\n ?\;))) eol))
(list ":"  (rx bol (1+ (not (or ?\n ?:))) eol))
(list " "  (rx bol (1+ (not (or ?' ?\" ))
   (not (or ?\s ?\;))
   (not (or ?' ?\")))
   eol

so you don't need eval below, and rx forms become constants when
compiled.

> + sep)

This `sep' binding can be removed.

> +(unless (= beg end)
> +  (save-excursion
> +(goto-char beg)
> +(catch :found
> +  (pcase-dolist (`(,sep ,regexp) sep-regexp)
> +(save-excursion
> +  (unless (re-search-forward (eval regexp) end t)

You can drop the `eval'.

>(when (and (called-interactively-p 'any)
> -  (not (string-match-p (rx "." (or "txt" "tsv" "csv") eos) file)))
> +  (not (string-match-p (rx "." (or "txt" "tsv" "csv") eos) file))
> + (not (yes-or-no-p "File does not havs .txt .txt .csv as 
> extension.  Do you still want to continue? ")))

"does not have" and ".txt" -> ".tsv" I guess.

Also please provide a patch with a commit message, possibly using `git
format-patch'.

Thanks!

Regards,
-- 
Nicolas Goaziou

Re: [tip] search this mailing list with helm-surfraw

[Juan Manuel Macías]

Hi Bastien,

Bastien writes:

> Neat!  
>
> You might want to write another one for the public-inbox archive:
>
> E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas

I was unaware that searches in the public-box archive are faster...
Thank you very much for the advice :-)

Best regards,

Juan Manuel 

org-info-store-link uses :desc instead of :description

[Alex]

In the definition of |org-info-store-link|, when calling 
|org-link-store-props|, the |:desc| key is given whereas I think 
|:description| was intended.

Re: org-store-link and help for a key

[Nicolas Goaziou]

Maxim Nikulin  writes:

> On 27/04/2021 22:52, Nicolas Goaziou wrote:
>> Maxim Nikulin  writes:
>>> My expectation is to get
>>> link to org-beginning-of-line if help is invoked from an org buffer
>>> and link to beginning-of-line if I came to the help page from some
>>> other file.
>> I did this on master. I only tested it lightly.
>
> Thank you for the fix. Function name is stored for keys as I expected.
>
> Behavior is changed however. Inserting link to a function help page
> previously caused a prompt for description, new version inserts
>
> [[help:org-refile][help:org-refile]]
>
> without additional query.

This is now fixed. Thanks.

Regards,

Re: variable-pitch-mode misaligns org-mode heading tags

[Bastien]

I would welcome a clean solution for tags alignment.

Ideally, one could switch from the current (manual) alignment, which
tries to align to a fixed column, while allowing to switch to a more
visually consistent alignement in variable-pitch-mode.

But this need to be done *without* slowing done big Org files, which
is probably a challenge.

Re: tags-todo agenda shoud not ignore DONE items

[Bastien]

Kyle Meyer  writes:

>> As mentioned in the thread, might potentially cause issues by changing
>> how it matches -- should there be an option? Or is the idea just that
>> if you really do want to exclude done tags, you'd query like "/!DONE"?
>
> Yep, that's the idea, I think.

Closing this issue right now -- feel free to report again if if still
needs to be resolved.

Re: Bug: org-babel only tangles first noweb reference on a line [9.4 (9.4-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Bastien]

Hi Tom,

Tom Gillespie  writes:

>The 9.4 release has a bug where it will only tangle the first noweb
> reference on a line.
> This is also present at 9c31cba002a1ba93053aebea1f778be87f61ba06. It happens 
> in
> emacs-27 and emacs-28. The reproduction is below. Best!
> Tom
>
> The expected content of oops-3.el should be 1 2 1, but is instead 1
> <> <>.
> C-c C-v C-t or C-c C-v C-v will show the issue.

Do you still have this issue?  I cannot reproduce it here.

Thanks

Re: [PATCH] Fixed-pitch tables and code blocks that do not break variable-pitch-mode

[Bastien]

Hi Protesilaos,

> Please see the attached diff.  An explanation is offered below.  I have
> already assigned copyright to the FSF.

Sorry it took so long to commit this, it is done in commit 667cb6f1a
in master, adding fixed-pitch for org-hide, org-verbatim and org-code
too.

Thanks!

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

[Jorge P . de Morais Neto]

Hi Bastien

Em [2021-04-26 seg 18:57:19+0200], Bastien escreveu:

> I hope both you and Anthony agree with this, or at least recognize
> that the current solution is acceptable.

Yes, I find acceptable to license Anthony’s code under the GPLv3+, if
that is what you meant.  If you want to keep Carsten’s original code,
that is acceptable too.  And unfortunately I lack sufficient JavaScript
knowledge to opine on which code is better---I studied Electronic
Engineering, which didn’t include web development.

Regards

-- 
-  "In Support of Richard Stallman"
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

Re: org-store-link and help for a key

[Maxim Nikulin]

On 27/04/2021 22:52, Nicolas Goaziou wrote:

Maxim Nikulin  writes:

My expectation is to get
link to org-beginning-of-line if help is invoked from an org buffer
and link to beginning-of-line if I came to the help page from some
other file.


I did this on master. I only tested it lightly.


Thank you for the fix. Function name is stored for keys as I expected.

Behavior is changed however. Inserting link to a function help page 
previously caused a prompt for description, new version inserts


[[help:org-refile][help:org-refile]]

without additional query.

Re: org-store-link and help for a key

[Nicolas Goaziou]

Hello,

Maxim Nikulin  writes:

> On 27/04/2021 21:25, Bastien wrote:
>> Even though storing links to help buffers describing key bindings is
>> tempting, there is no way to recreate such buffers only based on the
>> key string, because keys are contextual.
>> In org-mode, C-h k C-a will describe org-beginning-of-line while in
>> other modes it will probably describe beginning-of-line.
>> So we cannot really write a proper handler for these links and the
>> user error is correct here.
>> I'm closing this bug report now.
>
> I have looked into the code storing and handling links yet, so I am
> unaware what is possible and what is not. My expectation is to get
> link to org-beginning-of-line if help is invoked from an org buffer
> and link to beginning-of-line if I came to the help page from some
> other file. I do not know whether associated function may be obtained
> for a help buffer opened for keystroke.

I did this on master. I only tested it lightly.

Regards,
-- 
Nicolas Goaziou

Re: wip-cite status question and feedback

[Denis Maier]

Am 27.04.2021 um 16:07 schrieb Bruce D'Arcus:

On Tue, Apr 27, 2021 at 9:58 AM Denis Maier  wrote:


Your example fails on 1 because it suggests the citation attaches to
(starts) the following sentence.

Only if you mentally parse it as a parenthetical author-date citation.

I don't think so. A period is a way we delimit sentences; is it not?


Sure, but what about this:
This is a sentence with a footnote attached to it.[fn:: This footnote 
belongs to the preceding sentence, doesn't it?]




...


I'm after all not totally sure we need a one-size-fits-all solution.

This particular sub-thread started when Andras noted he needed a way
to handle this case, and Nicolas coded up an initial example.

So I think we just need to establish what a reasonable default is.


Absolutely, I'm just asking what can be changed afterwards, maybe by 
providing an extended inline quotes syntax or so.


Denis

Re: org-store-link and help for a key

[Maxim Nikulin]

On 27/04/2021 21:25, Bastien wrote:


Even though storing links to help buffers describing key bindings is
tempting, there is no way to recreate such buffers only based on the
key string, because keys are contextual.

In org-mode, C-h k C-a will describe org-beginning-of-line while in
other modes it will probably describe beginning-of-line.

So we cannot really write a proper handler for these links and the
user error is correct here.

I'm closing this bug report now.


I have looked into the code storing and handling links yet, so I am 
unaware what is possible and what is not. My expectation is to get link 
to org-beginning-of-line if help is invoked from an org buffer and link 
to beginning-of-line if I came to the help page from some other file. I 
do not know whether associated function may be obtained for a help 
buffer opened for keystroke.


Maybe I will look at this issue later, so I do not mind that the bug is 
closed.

Re: org-store-link and help for a key

[Bastien]

Hi Maxim and Ihor,

Ihor Radchenko  writes:

>> Such behavior exists for ages, at least since 8.2.10 till current master.
>
> I can reproduce this.
>
> The reason of error is simple: help buffers for key combinations where
> not considered when writing help: link type.
> Current code does not even store the link to such help buffers correctly
> - when the key sequence has more than a single key only the first key
> will be stored (tested in  k  k help buffer).
> The code to open help: link type also does not know that help: link can
> point to anything other than function or variable.
>
> I can see two solutions:
>
> 1. Avoid storing links to help buffers describing key sequences. Show
>error when trying to store such link instead

Even though storing links to help buffers describing key bindings is
tempting, there is no way to recreate such buffers only based on the
key string, because keys are contextual.

In org-mode, C-h k C-a will describe org-beginning-of-line while in
other modes it will probably describe beginning-of-line.

So we cannot really write a proper handler for these links and the
user error is correct here.

I'm closing this bug report now.

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Tue, Apr 27, 2021 at 9:58 AM Denis Maier  wrote:

> > Your example fails on 1 because it suggests the citation attaches to
> > (starts) the following sentence.
>
> Only if you mentally parse it as a parenthetical author-date citation.

I don't think so. A period is a way we delimit sentences; is it not?

...

> I'm after all not totally sure we need a one-size-fits-all solution.

This particular sub-thread started when Andras noted he needed a way
to handle this case, and Nicolas coded up an initial example.

So I think we just need to establish what a reasonable default is.

Bruce

Re: wip-cite status question and feedback

[Denis Maier]

Am 27.04.2021 um 14:32 schrieb Bruce D'Arcus:

On Tue, Apr 27, 2021 at 7:44 AM Denis Maier  wrote:


Regarding simpler ways, why not just:

"A simple quote." [cite: @doe p. 45]


No, that's worse ;-)

Let's review basic requirements:

1. a plain text document really should be readable and its semantics clear
2. a user should be able to write their documents, and use different
output styles, without modifying that source document

Your example fails on 1 because it suggests the citation attaches to
(starts) the following sentence.
Only if you mentally parse it as a parenthetical author-date citation. 
If you read it as note citation then your conclusion doesn't follow 
naturally.




2 is hard given the details we've laid out, but if whatever solution
works for the majority of cases, and at worst requires the user either
a) to be aware of how the processing works and adjust accordingly+,
and/or b) to edit the final document a bit, that seems a reasonable
balance.

Bruce

+ a lot of the corner cases in citations come from a mismatch between
the need for a certain regularity and rigor required for
machine--processing, and users' desire for complete flexibility


Yes, that's indeed the question.

I'm after all not totally sure we need a one-size-fits-all solution. By 
way of analogy, biblatex has an \autocite command that scans ahead for 
following punctuation and moves that around.


Bla bla \autocite{doe20}.
can be
Bla bla (Doe 2020).
Or
Bla bla.\footnote{Doe 2020.)

"Bla bla" \autocite{doe20}.
can be
"Bla bla" (Doe 2020).
Or
"Bla bla".\footnote{Doe 2020.)

Then, for more complex cases you'll need special markup provided by the 
csquotes package. Maybe such a modular solution could be useful?


Denis

Re: On using to-do lists efficiently

[Eric S Fraga]

On Monday, 26 Apr 2021 at 16:18, Bastien wrote:
> Slightly offtopic but I sat down this week-end trying to grasp with
> very few words what I learned on how to use to-do lists efficiently
> over the years, and here it is:
>
> https://bzg.fr/en/on-using-to-do-lists-efficiently/

Thank you for this.  I pretty much follow what you advise.  I also
recommend watching a video by Marcin Swickzkowski from EmacsConf2019:

 https://media.emacsconf.org/2019/09.html 

And I combine all of this with a Zero Inbox approach, not ever using my
inbox as a todo list!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-337-g29d4cc.dirty

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Tue, Apr 27, 2021 at 7:44 AM Denis Maier  wrote:

> Regarding simpler ways, why not just:
>
> "A simple quote." [cite: @doe p. 45]

No, that's worse ;-)

Let's review basic requirements:

1. a plain text document really should be readable and its semantics clear
2. a user should be able to write their documents, and use different
output styles, without modifying that source document

Your example fails on 1 because it suggests the citation attaches to
(starts) the following sentence.

2 is hard given the details we've laid out, but if whatever solution
works for the majority of cases, and at worst requires the user either
a) to be aware of how the processing works and adjust accordingly+,
and/or b) to edit the final document a bit, that seems a reasonable
balance.

Bruce

+ a lot of the corner cases in citations come from a mismatch between
the need for a certain regularity and rigor required for
machine--processing, and users' desire for complete flexibility.

Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

[No Wayman]

Kyle Meyer  writes:


Bastien writes:


Hi,

thanks for the patch, we do indeed need to move forward for 
this.


Could you propose the patch against the master branch (not the 
maint
branch, since this is not a bugfix) and perhaps fix *all* 
warnings?


Thanks, but these were already taken care of by 8c29cbdef 
(Backport
commit c45bfd3c4 from Emacs, 2021-04-18), which was merged into 
master

with 664b65344.


Apologies for the noise!

Re: (Not so) Short note about citations in Org

[Bruce D'Arcus]

On Mon, Apr 26, 2021 at 4:02 PM Nicolas Goaziou  wrote:

> "Bruce D'Arcus"  writes:

> > Nicolas: I get that you need more code to do this, but are there other
> > practical consequences of allowing more than plain-text?
>
> The code I need to write does not count, really. It is 10 locs at most,
> without the tests.
>
> My concern is the additional burden for processor developers. They will
> need to shift from one representation to the other, this is not
> convenient. Also some tasks then become an order of magnitude harder.

I see.

So, for example, András currently has the function
'citeproc-org--parse-locator-affix', which takes as input a suffix
string.

That would need to be adapted to allow this, and it could be a hassle.

I agree with Denis that some users will want this, but I am unsure how
common the request might be.

Here's a thought:

How about having suffix plain text, since this is where locators are
parsed, and they are particularly important, but allow more on
prefixes?

Bruce

Re: wip-cite status question and feedback

[Denis Maier]

Am 27.04.2021 um 12:12 schrieb Bruce D'Arcus:

On Mon, Apr 26, 2021 at 4:35 PM Denis Maier  wrote:


Regarding the proposal: I think that could go in the right direction,
but in the current form it has the downside that you can't use the
prefix anymore, right?


Not sure why you would need a prefix for this case, but org-cite has
two levels of affixes. So maybe:

[cite/quote:Prefix ;quote @doe19]


What about keeping this separate, like so:

[quote: A simple quote.][cite: @doe p. 45]

But maybe even that is not necessary, and there might be simpler ways.


Hmm .. org doesn't have an inline quote, I guess?


Don't know. That was just a suggestion.

Regarding simpler ways, why not just:

"A simple quote." [cite: @doe p. 45]

That way no information is lost, and you could just move around 
punctuation as appropriate. A distinct syntax might be more powerful, 
but also less readable.


Denis

Re: [PATCH] ox-md.el export code blocks using grave accents.

[Nicolas Goaziou]

Hello,

Timothy  writes:

> Even just commonmark has multiple ways you can do things (backticks and
> spaces for code), and I'd think supporting a set like: Gruber's
> original, commonmark, and GFM would make sense.
>
> Alternatively, we can leave that to other backends like ox-gfm.

That is the idea. "ox-md" is here to do the boring tasks, while being as
neutral as possible. There no need to handle specific syntax since you
can easily create a derived back-end.

> Basically: markdown is a mess and I'm not sure what would be a good
> course of action.

Regards,
-- 
Nicolas Goaziou

Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Gustavo Barros]

On Tue, 27 Apr 2021 at 04:29, Bastien  wrote:


Ihor Radchenko  writes:


Maybe you can use

(eq (org-element-type (car (org-element-lineage element))) 'drawer)


Indeed, thanks for the tip!  Committed as 26d1d29cf.


Bastien and Ihor, thank you!

Gustavo.

Re: On using to-do lists efficiently

[tbanelwebmin]

 Todo lists...

 Of course it resonates. You describe the errors I do.
 I keep moving from to-do-list, to agenda, to notes, and back again.
 
 You say it is not about a tool or a process,
 but rather about discipline.
 Right!
 
 Discipline may be connected to habits.
 From 8:00 to 8:30 I (should) review my to-do-list
 Unfortunately, our lives are full of perturbations
 which invalidate our habits.
 
 Even though it is not about tools,
 I spent years looking for the right tool:
 - pen & paper
 - postit
 - electronic postit
 - note-pads, paper or electronic
 - countless PC & phone applications
 
 Eventually I settled on Emacs Org Mode.
 It was a refreshment when I discovered it.
 
 Thanks for sharing your thoughts.
 
 Note to my future self: enhance my to-do-list


Le 26/04/2021 à 18:18, Bastien a écrit :
> Slightly offtopic but I sat down this week-end trying to grasp with
> very few words what I learned on how to use to-do lists efficiently
> over the years, and here it is:
>
> https://bzg.fr/en/on-using-to-do-lists-efficiently/
>
> Posted it on HN: https://news.ycombinator.com/item?id=26944239
>
> I'm curious if this resonates with your experience.
>
> It took me quite long to appease this love-hate relationship I have
> with my to-do lists.
>
> As usual: enjoy!
>
>
>

Re: wip-cite status question and feedback

[Timothy]

Bruce D'Arcus  writes:

> Hmm .. org doesn't have an inline quote, I guess?

I don't think so, unless @@quote:@@ is recognised.

--
Timothy

Re: [PATCH] ox-md.el export code blocks using grave accents.

[Timothy]

Bruce D'Arcus  writes:

> On Sat, Jan 30, 2021, 6:29 PM Tim Cross  wrote:
>
>> There are no precise standards for markdown, but org states in the
>> manual that the version of markdown it supports is that defined at
>> http://daringfireball.net/projects/markdown
>
> Perhaps at some point it would make sense to change to this, which is
> much more precisely specified:
>
> https://commonmark.org/

The only change I'd think would be worthwhile, is to complicate ox-md by
introducing the concept of styles/presets.

Even just commonmark has multiple ways you can do things (backticks and
spaces for code), and I'd think supporting a set like: Gruber's
original, commonmark, and GFM would make sense.

Alternatively, we can leave that to other backends like ox-gfm.

Basically: markdown is a mess and I'm not sure what would be a good
course of action.

--
Timothy

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Mon, Apr 26, 2021 at 4:35 PM Denis Maier  wrote:

> Regarding the proposal: I think that could go in the right direction,
> but in the current form it has the downside that you can't use the
> prefix anymore, right?

Not sure why you would need a prefix for this case, but org-cite has
two levels of affixes. So maybe:

[cite/quote:Prefix ;quote @doe19]

> What about keeping this separate, like so:
>
> [quote: A simple quote.][cite: @doe p. 45]
>
> But maybe even that is not necessary, and there might be simpler ways.

Hmm .. org doesn't have an inline quote, I guess?

Bruce

Re: org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

On Tue, Apr 27, 2021 at 3:52 AM Denis Maier
 wrote:

> I think Bruce's point was that author suppresion list items other than
> the first lies in the jurisdiction of the citeproc, and has to be
> handled depending on citation style. (I.e., user input does /not/ matter
> here.)

Yes, thank you; that's much better put.

Bruce

Re: [PATCH] ox-md.el export code blocks using grave accents.

[Bruce D'Arcus]

On Sat, Jan 30, 2021, 6:29 PM Tim Cross  wrote:

> There are no precise standards for markdown, but org states in the
> manual that the version of markdown it supports is that defined at
> http://daringfireball.net/projects/markdown

Perhaps at some point it would make sense to change to this, which is
much more precisely specified:

https://commonmark.org/

Bruce

Re: [PATCH] ox-md.el export code blocks using grave accents.

[Bastien]

Tim Cross  writes:

> I don't think this patch is correct.

I'm marking it as "canceled" right now, thanks.

Re: [PATCH] ox-html.el: Add HTML_CONTENT_CLASS to support css classes in content tag

[Bastien]

Bastien  writes:

> I added "TINYCHANGE" at the bottom of your commit message to signal
> this is small change done by someone who has not (yet) assigned his
> copyright to the FSF.

Er, sorry Sameer, my mistake, you are actually listed on
https://orgmode.org/worg/org-contribute.html as a copyright
contributor.

Re: org-cite: make 'suppress-author' a citation 'style'

[Richard Lawrence]

Denis Maier  writes:

> I think Bruce's point was that author suppresion list items other than 
> the first lies in the jurisdiction of the citeproc, and has to be 
> handled depending on citation style. (I.e., user input does /not/ matter 
> here.)

Ahhh OK, that makes it clearer. Thanks! Sorry for the noise -- I haven't
been able to follow this thread all that closely due to other work,
though I remain interested and willing to help.

-- 
Best,
Richard

Re: Bug: org-html-export-to-html doesn't handle .gpg files properly [9.3.6 (9.3.6-17-g389288-elpa @ /home/adalricus/.emacs.d/elpa/org-20200224/)]

[Bastien]

Fixed with commit b1ff9afc in maint, thanks.

Bastien  writes:

> Adalricus Ovicula  writes:
>
>> - create a file called "test.org.gpg"
>> - run org-html-export-to-html
>>
>> File gets exported as test.org.html, shouldn't it be test.html?
>
> Yes it should -- I will have a look at this, and if the fix does not
> feel to hackish I will commit it.

Re: org-cite: make 'suppress-author' a citation 'style'

[Denis Maier]

Am 27.04.2021 um 09:36 schrieb Richard Lawrence:

"Bruce D'Arcus"  writes:


e.g. you can write

Smith claims foo [(cite): -@Smith2019; -@Smith2020; see also @Jones2018].

to render

Smith claims foo (2019; 2020; see also Jones 2018).



You identified the same case Andras and I discussed just above.

I think the solution is simple; with the updated syntax:

[cite/-:@Smith2019;@Smith2020; see also @Jones2018].

So the rule is (and this is for the processor to worry about, of
course, not org), when a suppress-author style is specified, the
suppression only applies to the author of the first citation
item/reference. That would generate the output you noted.


I think I see what you mean after parsing this a few times, but I would
rephrase the rule, since the way you phrased it initially seemed to
contradict the example. The point of my example was that author
suppression should also apply to the author of the *second* reference in
the list, though that happens to be the same author as the author of the
first item. So maybe the rule is more like: "when a suppress-author
style is specified, the suppression only applies to the initial segment
of citation items/references that have the same author as the first
reference"?


I think Bruce's point was that author suppresion list items other than 
the first lies in the jurisdiction of the citeproc, and has to be 
handled depending on citation style. (I.e., user input does /not/ matter 
here.)


[cite/-:@Smith2019;@Smith2020; see also @Jones2018].

=> Suppress author in the first item, Smith 2019.
=> whether the author's name in the second list item (Smith 2020) is 
shown depends on the citation style. Some styles repeat the author's 
name, others won't.


For comparison:

[cite:@Smith2019;@Smith2020; see also @Jones2018]

=> Don't suppress author in the first item, Smith 2019.
=> whether the author's name in the second list item (Smith 2020) is 
shown depends on the citation style. Some styles repeat the author's 
name, others won't.


Denis

Re: [Patch] Update previews correctly with color changes

[Bastien]

Applied as commit 8bdcf51ac, thanks a lot.

Yuri Lensky  writes:

> The hash computed for LaTeX previews did not actually take into
> account the true foreground/background text color, so org would not
> refresh previews when themes change.

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

[Bastien]

Hi David,

David Masterson  writes:

> I have been using upper-case TAGs and just noticed that
> 'org-agenda-show-tags' is reporting them in lower-case which is not
> right since I have another TAG that is the lower-case version of the
> upper-case TAG (sort of a visual importance indicator).

Thanks for reporting this bug.  I've pushed a fix to the maint branch
with commit 13a1a4fb9.

Re: org-cite: make 'suppress-author' a citation 'style'

[Richard Lawrence]

"Bruce D'Arcus"  writes:

>> e.g. you can write
>>
>> Smith claims foo [(cite): -@Smith2019; -@Smith2020; see also @Jones2018].
>>
>> to render
>>
>> Smith claims foo (2019; 2020; see also Jones 2018).

> You identified the same case Andras and I discussed just above.
>
> I think the solution is simple; with the updated syntax:
>
> [cite/-:@Smith2019;@Smith2020; see also @Jones2018].
>
> So the rule is (and this is for the processor to worry about, of
> course, not org), when a suppress-author style is specified, the
> suppression only applies to the author of the first citation
> item/reference. That would generate the output you noted.

I think I see what you mean after parsing this a few times, but I would
rephrase the rule, since the way you phrased it initially seemed to
contradict the example. The point of my example was that author
suppression should also apply to the author of the *second* reference in
the list, though that happens to be the same author as the author of the
first item. So maybe the rule is more like: "when a suppress-author
style is specified, the suppression only applies to the initial segment
of citation items/references that have the same author as the first
reference"?

-- 
Best,
Richard

Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Bastien]

Ihor Radchenko  writes:

> Maybe you can use
>
> (eq (org-element-type (car (org-element-lineage element))) 'drawer)

Indeed, thanks for the tip!  Committed as 26d1d29cf.

Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Ihor Radchenko]

Bastien  writes:

> This should be fixed with commit 730a05f78.

> ;; FIXME: when storing a note in a LOGBOOK drawer,
> ;; `org-store-log-note' needs to insert a new line before
> ;; the newly inserted note, thus the `type' at point will
> ;; return `paragraph' instead of the expected `drawer', so
> ;; we need to manually detect the drawer.

Maybe you can use

(eq (org-element-type (car (org-element-lineage element))) 'drawer)

A quick test showed that org-element-lineage can detect drawer even when
element is a note inside LOGBOOK drawer.

Best,
Ihor

Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Bastien]

Hi Gustavo,

sorry it took so long to get back to this.

Bastien  writes:

> Gustavo Barros  writes:
>
>> the new release brought the interesting value `headline-data' to the 
>> option `org-adapt-indentation'.  However it introduces some issues 
>> regarding the indentation of log entries in the `LOGBOOK' drawer, which 
>> I describe below.
>
> I can reproduce this bug, I will try to fix it.  Thanks.

This should be fixed with commit 730a05f78.

Thanks!

Re: Help with reproducing bugs reported on this list

[Bastien]

Bastien  writes:

> we are looking for someone to take charge of a very important task:
> reproducing bugs reported on this list.

I'm happy to close this call for help, as John (cc'ed) kindly
volunteered to help with this task.

Thanks John!

Of course, everyone is still welcome to try reproducing bugs,
as this is a critical tasks for maintainance.