Re: [PATCH] Omit file description when :file-desc has nil value

[Kyle Meyer]

Matt Huszagh writes:

>> Kyle Meyer  writes:
>>
>>> I also don't find the current behavior particularly intuitive.  (I'm
>>> also not really a babel user, so my opinion probably shouldn't count for
>>> much.)  If we were adding it today, I think what you describe would be
>>> better, but, as you mention, breakage also now also weighs against
>>> making a change here.
>>>
>>> In any case, I'd suggest raising the discussion on the list after the
>>> 9.4 release.
>
> Hello, just following up on this since 9.4 has been released. Thoughts?

No babel users have chimed in.

My current opinion is that I'd prefer not to break the use case
mentioned earlier in this discussion [1].  It may not be intuitive, but
it's longstanding and I don't have a sense for how much it's relied on.

  [1] https://orgmode.org/list/87tuwef76g@kyleam.com/
  https://orgmode.org/list/87limm4eo2@med.uni-goettingen.de/T/#u

Quoting what you said earlier:

> For one, I think that the current implementation is a bit
> confusing. More importantly though, it makes it impossible to both
> provide a default value for :file-desc and omit it in some cases. The
> benefit (as mentioned in that thread) is that in those select cases,
> the same argument would not need to be provided twice. I think the
> cost of the current functionality outweighs the benefit.

But it's not a direct comparison against that use case and the use case
you want to support.  The potential breakage of existing documents is a
big factor to go against.

> I guess there are other solutions we could explore, such as an empty
> string (is an empty file descriptor ever a valid use case?) taking the
> place of the current functionality, or fully eliminating the file
> descriptor. However, this is starting to feel like a lot of hacks and
> would be very confusing to new users.

Unfortunately, such a kludge is how I'd suggest to move forward.
Perhaps an empty string, or perhaps any value (e.g., ":file-desc []")
that org-babel-read won't treat as a string or nil (the two cases that
mean something right now).  The rough patch below is an example of the
latter.

> Moreover, it really just pushes the problem down the road rather than
> fixing it outright.

I'm not sure I get this.  What's next down the road in this scenario?
With something like the above kludge, haven't we exhausted the cases for
:file-desc?


diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 7300f239e..4483585a1 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -646,6 +646,13 @@ (defun org-babel--expand-body (info)
   (replace-regexp-in-string
(org-src-coderef-regexp coderef) "" expand nil nil 1
 
+(defun org-babel--file-desc (params result)
+  (pcase (assq :file-desc params)
+(`nil nil)
+(`(:file-desc) result)
+(`(:file-desc . ,(and (pred stringp) val)) val)
+(_ nil)))
+
 ;;;###autoload
 (defun org-babel-execute-src-block ( arg info params)
   "Execute the current source code block.
@@ -749,8 +756,7 @@ (defun org-babel-execute-src-block ( arg info 
params)
(let ((*this* (if (not file) result
(org-babel-result-to-file
 file
-(let ((desc (assq :file-desc params)))
-  (and desc (or (cdr desc) result)))
+(org-babel--file-desc params result)
  (setq result (org-babel-ref-resolve post))
  (when file
(setq result-params (remove "file" result-params))
@@ -2257,9 +2263,8 @@ (defun org-babel-insert-result (result  
result-params info hash lang)
 (setq result (org-no-properties result))
 (when (member "file" result-params)
   (setq result (org-babel-result-to-file
-result (when (assq :file-desc (nth 2 info))
- (or (cdr (assq :file-desc (nth 2 info)))
- result))
+result
+(org-babel--file-desc (nth 2 info) result)
((listp result))
(t (setq result (format "%S" result
   (if (and result-params (member "silent" result-params))
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 648e9c115..e7a292de3 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -1084,7 +1084,16 @@ (ert-deftest test-ob/file-desc-header-argument ()
 (org-babel-execute-src-block)
 (goto-char (point-min))
 (should (search-forward "[[file:foo][bar]]" nil t))
-(should (search-forward "[[file:foo][foo]]" nil t
+(should (search-forward "[[file:foo][foo]]" nil t)))
+  (should (string-match-p
+  (regexp-quote "[[file:foo]]")
+  (org-test-with-temp-text "
+#+begin_src emacs-lisp :results file :file-desc []
+  \"foo\"
+#+end_src"
+(org-babel-next-src-block)
+

Re: ORG update made Dired the only way to open folders

[Kyle Meyer]

Ypo writes:

> Then could it be a bug? Before the update file: links to a folder
> opened it out of emacs. Now it doesn't, even using "attach"'s option
> which offers to open links out of emacs.

Which attach option is that?

Did you follow Ihor's suggestion of removing (directory . emacs) from
org-file-apps?  That entry was added to org-file-apps in v9.4 and should
explain the change in behavior you're seeing.  If that's the case,
removing it should restore the old behavior.  If that doesn't work, you
can try adding (directory . system) to org-file-apps.

Re: Cycling through TODO workflow joins the next line onto the current one

[Samuel Wales]

i can confirm visual [not physical] joining of entries [plausibly
doneified tasks] frequently since at least the previous maint, in
vanilla emacs 24 and 25.


On 9/23/20, Ihor Radchenko  wrote:
>> On my emacs 27, following demonstrates the problem.
>
> The patch is attached. It should fix the problem.
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Bug: Infinite loop caused by org-agenda-property-list [9.4 (9.4-elpa @ /home/dsmasterson/.emacs.d/elpa/org-9.4/)]

[Nick Dokos]

>From what I can gather, this does not have much to do with Org mode
proper, which has no org-agenda-property-list at all. I presume that
you have

https://github.com/Malabarba/org-agenda-property/blob/master/org-agenda-property.el

installed, which does provide such a variable, but all that one can
say atm is that that library has a bug *or* is incompatible with
(current?) Org mode.  In either case, I think you should report it as
an issue to the above site.  Once they have figured out what is wrong,
then maybe an RFE against Org mode *might* be indicated.

-- 
Nick

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

Re: Getting Org-Crypt to work (doc bug?)

[David Masterson]

Bastien  writes:

> Hi David,
>
> Applied as e2bb60581:
> https://code.orgmode.org/bzg/org-mode/commit/e2bb60581
>
> I'm attaching the patch so that you can see how to format the
> ChangeLog for future contributions.
>
> Best,

Thanks

-- 
David Masterson

Re: newline or no newline at end of capture: expected behavior

[Samuel Wales]

i have the same question for headline-only capture
buffers.  i.e. what is the expected result with and without trailing
newline.

Re: newline or no newline at end of capture: expected behavior

[Samuel Wales]

i have been trying various hooks so this might not be the worst case,
but i know that finalizing a completely empty buffer will insert a
newline after the target.  that can't be worked around with hooks.


On 9/23/20, Bastien  wrote:
> Hi Samuel,
>
> Samuel Wales  writes:
>
>> basically i am getting unwanted newlines all over the place when i
>> capture.  but i want to confirm expected behavior for all 4 questions.
>
> Let's take this one by one.
>
> Can you provide the *worst* use case of Org going completely insane
> regarding empty lines after captured notes?
>
> --
>  Bastien
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Texinfo in Org-Mode but with texinfo syntax highlighting

[David Masterson]

Bastien  writes:

> Christopher Dimech  writes:

>> I am writing a document in texinfo, but I also have some commands in
>> Org-Mode so that if I change my Emacs Major Mode to Org-Mode
>> I get an easy way to traverse my texinfo code. However I would like
>> to keep the syntax highlighting as the use set for texinfo, rather than
>> that of org-mode. I share a way to do that?

> There is some code out there to let you run multiple major modes in
> Emacs, I would look into that:

> See https://www.emacswiki.org/emacs/MultipleModes and perhaps check
> for https://github.com/purcell/mmm-mode

> 2 cents,

Further 2 cents (now we're up to 4 cents ;-) ):

There is a folding minor mode on MELPA that seems to be what you want
instead of org-mode.  You just embed fold markers in a comment (what's a
comment for texinfo?) and fold away.

However, why not consider writing your document with Org and then export
to Texinfo?
-- 
David Masterson

Re: org-tables with monetary amounts

[Nick Dokos]

For fixed precision, you can either use an explicit format as Russell Adams 
points out,
or you can modify (globally or per file) the variable org-calc-default-modes. 
That's a
complicated variable and you only need to change one part of it for this:

(plist-put org-calc-default-modes 'calc-float-format '(fix 2))

See e.g. https://emacs.stackexchange.com/a/59181/14825 for some discussion.
-- 
Nick

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

Re: Org-Crypt and HTML export

[David Masterson]

Bastien  writes:

> Hi David,
>
> David Masterson  writes:
>
>> I take it that, when you do an HTML export on an Org file, it is assumed
>> that all items that have been encrypted with org-crypt will have been
>> decrypted, correct?
>
> Is it what you get?

I get you -- my mistake for not trying it more.  I'm still figuring
org-crypt out.

>> Is there a way to create an HTML file with Org that includes some
>> encrypted data to be decrypted by whoever views the file (with
>> appropriate password)?
>
> Nope, unless someone coded this in some corner of the web.

Rats.  Thanks.

-- 
David Masterson

Re: official orgmode parser

[rey-coyrehourcq]

Hi Przemysław,

Some partial org Parsers (AST or regex...) i found on the web for a recent 
state of the art : 

* org-js
https://github.com/mooz/org-js

* orgajs
Orga is a flexible org-mode syntax parser. It parses org content into AST 
(Abstract Syntax Tree)
https://github.com/orgapp/orgajs
* orgparse
* org-mode-parser
https://github.com/daitangio/org-mode-parser
* org-rs
https://github.com/org-rs/org-rs
* org-ruby
https://github.com/wallyqs/org-ruby
* org-swift
https://github.com/orgapp/swift-org
* organice
https://github.com/200ok-ch/organice
* organum
https://github.com/seylerius/organum
* clj org
https://github.com/eigenhombre/clj-org
* orgmode-parse
https://github.com/ixmatus/orgmode-parse
* org-mode
https://www.fosskers.ca/
https://hackage.haskell.org/package/org-mode
* orgize
https://github.com/PoiScript/orgize
https://www.worthe-it.co.za/blog.html

Best regards,

Le mercredi 23 septembre 2020 à 19:46 +0200, Przemysław Kamiński a écrit :
> On 9/23/20 10:09 AM, Bastien wrote:
> > Hi Przemysław,
> > 
> > Przemysław Kamiński  writes:
> > 
> > > I oftentimes find myself needing to parse org files with some external
> > > tools (to generate reports for customers or sum up clock times for
> > > given month, etc). Looking through the list
> > > 
> > > https://orgmode.org/worg/org-tools/
> > 
> > Can you help on making the above page more useful to anyone?
> > 
> > Perhaps we can have a separate worg page just for parsers, reporting
> > the ones that seem to fully work.
> > 
> > I disagree that a parser is too difficult to maintain because Org is
> > a moving target.  Org core syntax is not moving anymore, a parser can
> > reasonably target it.  That's what is done with the Ruby parser, in
> > use in this small project called github.com :)
> > 
> > So I'd say:
> > 
> > - let's enhance Worg's documentation
> > - yes, please go for enhancing parsing tools
> > 
> > I don't think we need official tools.  The official Org parser exists,
> > it is Org itself.
> > 
> > Thanks,
> > 
> 
> Hello Bastien,
> 
> Thank you for your remarks.
> 
> I updated the README, hopefully it's more usable now.
> 
> Przemek
> 
-- 


Sébastien Rey-Coyrehourcq
Research Engineer UMR IDEES
02.35.14.69.30

{Stronger security for your email, follow EFF tutorial : https://ssd.eff.org/}

Re: official orgmode parser

[Przemysław Kamiński]

On 9/23/20 10:09 AM, Bastien wrote:

Hi Przemysław,

Przemysław Kamiński  writes:


I oftentimes find myself needing to parse org files with some external
tools (to generate reports for customers or sum up clock times for
given month, etc). Looking through the list

https://orgmode.org/worg/org-tools/


Can you help on making the above page more useful to anyone?

Perhaps we can have a separate worg page just for parsers, reporting
the ones that seem to fully work.

I disagree that a parser is too difficult to maintain because Org is
a moving target.  Org core syntax is not moving anymore, a parser can
reasonably target it.  That's what is done with the Ruby parser, in
use in this small project called github.com :)

So I'd say:

- let's enhance Worg's documentation
- yes, please go for enhancing parsing tools

I don't think we need official tools.  The official Org parser exists,
it is Org itself.

Thanks,



Hello Bastien,

Thank you for your remarks.

I updated the README, hopefully it's more usable now.

Przemek

Re: Slow to open certain file

[Peter Bienstman]

Ok, it turned out the url http functions also showed up when I was
trying to update packages. It seems I'm suffering from this bug:
https://emacs.stackexchange.com/questions/60560/error-retrieving-https-elpa-gnu-org-packages-archive-contents-error-http-400
and perhaps for some reason when opening the file through ivy, emacs
tried to update a package?

Anyway, I updated to emacs 27.1 to fix that particular bug, but the
file still loads very slowly. I'll report this to the ivy developers.

On Wed, Sep 23, 2020 at 9:21 AM Peter Bienstman
 wrote:
>
> Attached the profile when i open with 'find-file'. It still seems to
> call ivy-read, but the interesting thing is that now a lot of time is
> apparently spent in 'url-http' functions. The file contains lots of
> web links, so it seems emacs is trying to do something with them when
> it really shouldn't...
>
> Cheers,
>
> Peter
>
> PS: this is not a permanent paper archive, but rather an ephemeral
> collection of journal rss feeds
>
> On Wed, Sep 23, 2020 at 3:48 AM Ihor Radchenko  wrote:
> >
> > I have no issue opening your file (under 1 second).
> >
> > > I also attach the profile.
> >
> > Looking at the profile, the problem seems to be with ivy. Can you try
> > opening the file without ivy. Something like
> >
> > M-: (find-file "~/Org/notes.org") 
> >
> > P.S. You can also add notes to papers from org-ref. That is a great help
> >  when your paper database grow bigger.
> >
> > Best,
> > Ihor
> >
> > Peter Bienstman  writes:
> >
> > > Opening this file takes more than 10 seconds:
> > >
> > > https://www.dropbox.com/s/tg7pr6tetlh7jwb/toc%2020200922%2007.00.01.org?dl=0
> > >
> > > I also attach the profile.
> > >
> > > I have org files which are much bigger, and they open almost instantly.
> > >
> > > This is on Windows 10, emacs 26.3, all packages updated to the latest 
> > > version.
> > >
> > > Is there anything I can do to speed this up?
> > >
> > > Thanks!

Re: org-tables with monetary amounts

[Eric S Fraga]

Not answering your question directly but, depending on why and how you
are using org tables for monetary calculations, you may wish to look at
ledger [1].  There is support in org for ledger via babel (ob-ledger.el,
distributed with org).

HTH,
eric

Footnotes:
[1]  https://www.ledger-cli.org/

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-18-gaea110

Re: Bug: DOI links are broken in HTML exports

[General discussions about Org-mode.]

Thanks Bastien.


> Do you use a link abbreviation for doi: links ?
>
>> When I export this document to HTML the DOI link gets converted into a
>> broken hyperlink. It should be converted into
>> https://doi.org/10.1186/s12864-016-2377-z as explained
>> in https://www.doi.org/. 
>>
>
> If you use a link abbreviation.
>
>> Following the link from the org file with C-c C-o works fine, though.
>>
>> It'd be great if this could get fixed, as DOI links are incredibly
>> helpful when dealing with bibliographic items.
>>
>
> What version of Emacs and Org are you using?
>

I'm not using a link abbreviation for doi: links.

I can reproduce this bug running a stock Emacs (27.1) and stock Org (9.4-elpa) 
i.e., no init file.

I encountered this bug for the first time a few months ago, when I first used 
doi: links.

I hope this helps.

Re: Slow to open certain file

[Eric S Fraga]

Opens almost immediately for me.  Linux, recent emacs and org from git.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-18-gaea110

Re: The Website Revamp: The final stretch

[Timothy E Chapman]

Hi Bastien,

Just remembered I haven't addressed everything you mentioned here.

Bastien  wrote:

> Also, let's remove the mini-unicorn in the top bar, it is redundant
> and reminds me of the opening of IT Crowd.

Ah yes, I see the resemblance :P I'm not sure this is a good idea though, as
while this can be seen as redundant on the homepage, the navbar is used on
every page. Considering that this is a site to help people learn about Org,
I think that the visual consistency of having it on every page, and
how that helps reinforce the association between Org and that logo is worth it.
Having it regularly appear should help it stick.

> - I believe there are too many pages: I'd love the website to be just
>   one HTML page.  Rich contents should go to Worg and yes, we need to
>   upgrade Worg's design too. Let's try moving such contents to Worg as
>   soon as we can -- but this is not a blocker for the switch.

I think a single page might be a bit further than ideal, as I see it a
'core' of static pages
for orgmode.org would be
 - index/homepage
 - features
 - quickstart
 - install

How does that sound to you? Of course, all of this migration to Worg
can happen after an iniIal switch.

> - For the manual, I'd prefer to use the same design that the one used
>   on the gnu.org website:

This is quite easy (and not actually part of this branch), I think we
just need to pass
--css-ref "https://www.gnu.org/software/emacs/manual.css;
to the makeinfo/texi2any/texi2html command in
https://code.orgmode.org/bzg/org-mode/src/master/doc/Makefile

All the best,

Timothy.

Re: Bug: Occasional error with recurring tasks in agenda [9.4 (release_9.4-3-ge6021b @ /home/james/.config/emacs/straight/build/org-plus-contrib/)]

[James N . V . Cash]

Ihor Radchenko  writes:

>> It seems to always work properly from the org buffer itself, so I assume
>> it's something happening in the agenda, but I'm not sure where to look.
>> I've tried debugging `org-agenda-todo`, but I can't see anything in
>> askance there. Any advice as to what I should be looking for?
>
> I had similar issue. As I recall, the problem was with some custom
> function in org-trigger-hook that threw an error because it did not
> expect to be ran with point in agenda buffer. Do you have any
> customisation related to todo triggers?

Hm, it looks like org-trigger-hook and the various other
org-trigger-*-hook variables are nil in org-agenda buffers, but that
seems like a good place to look. I'll try to see if I have any other org
hooks that might be interferring with this.

Re: Bug: org-cycle stops working on Org files with empty lines at end of buffer [9.4 (9.4-elpaplus @ /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Ihor Radchenko]

> I did a git bisect test, found the bad commit.
> "ee3c3b554 | * bad org.el: Allow empty subtrees to be folded back"

Additional observation:
The unfolding does not happen because org-cycle-show-empty-lines
_always_ reveals trailing empty lines at the end of buffer. It breaks
the assumption in org-cycle-internal-local that end of folded subtree
must always be the same as the end of the folded region.

Before ee3c3b554, that situation was handled by additional check, but it
is not the case anymore.

Best,
Ihor


stardiviner  writes:

> Bastien  writes:
>
>> Hi,
>>
>> stardiviner  writes:
>>
>>> I also did a bisect debug. Found the function ~org-cycle-show-empty-lines~ 
>>> in hook
>>> ~org-cycle-hook~ caused this problem.
>>
>> Did you find the commit that introduces this bug?
>
> I did a git bisect test, found the bad commit.
>
> "ee3c3b554 | * bad org.el: Allow empty subtrees to be folded back"
>
>>
>> Also, if you can provide a patch, please go ahead.
>>
>
> Can't help on this. Don't know much on regexp matching and position boundries 
> etc.
>
> Will keep improving skill.
>
> -- 
> [ stardiviner ]
>I try to make every word tell the meaning that I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Gustavo Barros]

Hi stardiviner,

On Wed, 23 Sep 2020 at 11:17, stardiviner  wrote:

I have same issue when using Ivy. But can't reproduce this by disabled 
ivy-mode.
And only happened when I refiled once, then the target will has two 
slash like this:


#+begin_example
Tasks/kk//   (file.org)
Tasks/hello/ (file.org)
#+end_example



Thank you for checking this and for confirming you also observe this 
behavior with Ivy.


Regarding when ivy-mode is off, as I argued in the original report, the 
problem is indeed *not visible* when using `completing-read-default', 
the double trailing slash is nevertheless there if you inspect the value 
being passed as default value to the completing-read-function.  The 
tests included with ivy-mode turned off were meant to emphasize things 
are expected to work with the suggested fix also in this case, in other 
words, that this is not "just a fix for ivy-mode", which is not the 
problem here.


Best,
Gustavo.

Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[Dr. Arne Babenhauserheide]

Bastien  writes:

>> Rather than a huge refactoring or pushing code back into other Emacs
>> modes, my thought was that Org should be trimmed into the "core" of
>> Org functions and that other things should be implemented as modules
>> available in MELPA outside of the official Org core. That way the
>> limited maintainer time can be focused on the core of Org and
>> maintaining strong interfaces for components made and maintained by
>> others.

> I agree with this goal, as long as Org modules are maintained too.
>
> Picking up the example I gave above in this thread of modularizing
> org-table.el, it will be a good think iff it gets as much attention
> than Org's core itself.

Keep in mind that this will make it much harder to change org-api.

I have some experience with Mecurial extensions, as a maintainer of
those, and basically every extension which is not shipped with Mercurial
(those live in the same source tree) is broken from time to time.

I had to give up one extension and two are currently broken (but not yet
really given up), because I could not keep up with the changes in
Mercurial, simply due to reduced free time.

So while I think that having a stronger separation, I only see a good
case for moving parts out of the org-mode source tree when there is
considerably more activity in those parts than in the core. That can
allow faster release-cycles than org itself, since fewer parts have to
be tested.

Stuff that’s moved out while it does not have its own community is in
danger of becoming dead code that must not be broken, but is much less
convenient to test (and the tests harder to automate) when stuff in org
core changes.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Support for simultaneous running clocks?

[stardiviner]

Michael Welle  writes:

> Hello,
>
> Samuel Wales  writes:
>
>> more than one clock can be useful, but maybe need not be org-related,
>> even if that would be nice?  for example, your laundry is due in 45m,
>> tea will be steeped in 8m, etc.
> for that exactly that use case ;) I have a small shell script that
> creates at jobs and pops up a msg box when laundry is due. With an elisp
> wrapper it's easy to M-x it from Emacs. Nothing fancy or elaborated, but
> it works for me.

Like this, you're just using system. Not Org Mode. Clock need to clock specific
headline tasks or something else. Well, sure, if user in similar case, of course
can use shell script, that will be more convenient.

Anyone would also like to add this feature?

# ==

I've looked command ~org-clock-in~ source code around, I summarized some parts
might related or be affected:

- clock under different headlines for multiple clocking.
- clock in org-agenda buffer should similar as above.
- clock in/out hooks should still working as before.
- the mode-line lighter of displaying clock need to be changed (my idea is use
  mouse hover to display all running clocks in Emacs tooltip).

# ==

Here is some thought about how to implement it, just some thought, not code 
prototype.
(Copied text from my previous message, and added something.)

- Most clock commands I uses is clocking from headline on in org-agenda, or even
  from org-capture. Then clock out. If support multiple simultaneous clocks.
  Then might need to use some extra arguments like headline location. About
  this, I think should not be much complexity.
- Need to use different variable to maintain all running clocks.
- If there are some case have not considered, can also be supported for new 
feature.
- maybe the mode-line clocking might need to adjusted. Anyone have good idea?
  + If only one clock, then display clocking task tile.
  + If have more than one clocks, then display clock numbers?
  + Use mouse-hover tooltip to display currently all running clocks.
- But this new feature will bring more usage benefits. Like time tracking on
  different tasks; project top-level headline and sub-task simultaneous clocking
  for projects; and more accurate time statistics output on time-block etc. Also
  user can start new clock without interrupt old clock, for example, user
  defined an org-capture template will auto start a clock, but don't want to
  interrupt current clock.

# ==

After this think over, I might want to take a try.

I will dig deeper in source code. Come back later.

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

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

Re: The Website Revamp: The final stretch

[Takaaki Ishikawa]

Dear Timothy,

I can provide Japanese translated webpages.
Currently, I have a permission to push translated pages in Japanese to
orgmode.org but I don't understand where you are working on for the
new website.
Could you provide me further information to help you? Email to me is welcome :)

Best regards,
Takaaki


Takaaki ISHIKAWA 

2020年9月23日(水) 0:01 TEC :
>
> Hello everyone,
>
> I'm pleased to announce that after chatting with Bastien, my
> little
> revamp project seems to be nearing the point where it may replace
> the
> current site.
>
> Two things that would be good to get sorted:
>  1. Translation of the index page to French/Japanese ::
> I'm english only, and Bastien is busy, so volunteers would be
> much appreciated!
>  2. Picking the best 'Hero banner' on the home page ::
> Concerns were raised over the lack of contrast between the
> logo and
> the current banner background. I've chatted to someone else
> with
> some ideas and we've produced a few concepts which we'd like
> to get
> your feedback on.
> See the file attached, and if you could give say your top
> three
> picks (ordered), and any relevant
> reasoning/considerations/comments
> that would be great!
>
> All the best,
>
> Timothy.
>
> p.s. I haven't had much luck with attachments in the past, if this
> fails
> I'll reply with the attachment.
>

Re: Cycling through TODO workflow joins the next line onto the current one

[Ihor Radchenko]

> On my emacs 27, following demonstrates the problem.

The patch is attached. It should fix the problem.

>From 8e99e5dea780041d314f666f506a120224f064eb Mon Sep 17 00:00:00 2001
From: Ihor Radchenko 
Date: Wed, 23 Sep 2020 21:54:47 +0800
Subject: [PATCH] Do not remove trailing newline when deleting planning info
 line.

* lisp/org.el (org-add-planning-info): Remove front newline instead of
trailing newline when deleting planning info is completetly removed
from a heading.  Fixes "Cycling through TODO workflow joins the next
line onto the current one".

The old behaviour affected folded headlines containing only planning
info in the body:

Before deletion:
* DONE Headline
  CLOSED: [2020-09-23 Wed 21:39]
* test

After deletion:
* DONE Headline
* test

The newline after the first headline is hidden making both the
headlines appear at the same visual line.

New behaviour:
After deletion:
* DONE Headline
* test

All the folded text is completely removed.
---
 lisp/org.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index a9fdc7b77..845920a71 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10684,8 +10684,8 @@ WHAT entry will also be removed."
 	 ;; If there is nothing more to add and no more keyword is
 	 ;; left, remove the line completely.
 	 (if (and (looking-at-p "[ \t]*$") (not what))
-	 (delete-region (line-beginning-position)
-			(line-beginning-position 2))
+	 (delete-region (line-end-position 0)
+			(line-end-position))
 	   ;; If we removed last keyword, do not leave trailing white
 	   ;; space at the end of line.
 	   (let ((p (point)))
-- 
2.26.2



Richard Kim  writes:

> Richard Kim  writes:
>
>> Bastien  writes:
>>
>>> Hi Krishan,
>>>
>>> Krishan Kharagjitsing  writes:
>>>
 Hello, I found the following weird behaviour. 
>>>
>>> What is M-x org-version RET ?
>>
>> Because of (setq org-log-done 'time) according to
>> https://github.com/syl20bnr/spacemacs/issues/13901#issuecomment-697323151
>>
 When I set some tasks to DONE and fold the headings with TAB, then
 when I cycle back from DONE to TODO it joins the next line with the
 current one.

 org_mode_bug

 Reproduction guide

 Make two TODO headings in org mode
 Cycle both TODO items to DONE
 Fold the headings (so the dots appear, because the timestamp gets
 folded with the heading)
 Cycle the first DONE heading
>>>
>>> Why are there timestamps?  Can you provide a test .org file where we
>>> can reproduce the problem?
>>>
>>> Thanks,
>>
>> The original report at the top of
>> https://github.com/syl20bnr/spacemacs/issues/13901
>> has gif animation on how this problem can be seen.
>
> On my emacs 27, following demonstrates the problem.
>
> (let ()
>   (switch-to-buffer (generate-new-buffer "*demo line joining bug*"))
>   (erase-buffer)
>   (org-mode)
>   (setq org-log-done 'time)
>   (insert "* one\n")
>   (insert "* two\n")
>   (goto-line 1)
>   (org-todo)
>   (org-todo)
>   (org-todo)
>   (org-cycle)
>   (org-todo)
>   (org-todo)
>   )

Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[stardiviner]

I have same issue when using Ivy. But can't reproduce this by disabled ivy-mode.
And only happened when I refiled once, then the target will has two slash like 
this:

#+begin_example
Tasks/kk//   (file.org)
Tasks/hello/ (file.org)
#+end_example

Gustavo Barros  writes:

> Hi All,
>
> some time ago, I've reported an issue regarding duplicity of the default 
> candidate in `org-refile' 
> (https://orgmode.org/list/87lftw1k2n@gmail.com/).  The problem was 
> that, when using `org-refile-use-outline-path' an "extra" slash was 
> appended at the end of every path, but candidates were stored in 
> `org-refile-history' without that extra slash.  Bastien took care of 
> that and indeed changed things so as to pass the elements to 
> `org-refile-history' with the trailing slash as appropriate.
>
> At the time, I reported a difference of behavior between 
> `completing-read-default' and `ivy-completing-read' after the mentioned 
> commit by Bastien.  But the issue did not appear for Bastien, which does 
> not use Ivy, and I also was not able to diagnose the problem properly. 
> I felt I didn't have enough to offer as to insist, so I resorted to an 
> old hack of mine.  But the new release this week (thank you very much!, 
> btw) has bitten me again on this, so I went back to some digging, and 
> hopefully I can do a better job this time in diagnosing the problem and 
> suggesting a fix.
>
>
> An ECM to reproduce the issue as it currently stands is:
>
> - Start 'emacs -Q'
>
> - Do an initial setup:
>   #+begin_src emacs-lisp
>   (add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
>   (add-to-list 'load-path "~/.emacs.d/elpa/ivy-20200826.955")
>   ;; Those are the latest Org weekly build (Org 9.4) and the current up 
>   to date
>   ;; Ivy at Melpa
>   (setq org-refile-targets '(("~/org/test.org" :maxlevel . 2)))
>   (setq org-refile-use-outline-path 'file)
>   (setq org-outline-path-complete-in-steps nil)
>   (require 'ivy)
>   (ivy-mode)
>   ;; Bear with me, the problem is not with Ivy, I'll demonstrate that.
>   #+end_src
>
> - Open file "~/org/test.org", with contents:
>   #+begin_src org
>   ,* Top heading 1
>   ,* Top heading 2
>   ,** Entry 1
>   ,** Entry 2
>   #+end_src
>
> - Go to heading "Entry 1", refile it to "Top heading 1"
>
> - Go to heading "Entry 2", and call `org-refile'
>
> - Observe the available candidates, and notice "test.org/Top heading 1/" 
>   is there twice, once as the default candidate, with a *double* 
>   trailing slash, and also on the paths list, with a single trailing 
>   slash.
>
>
> I've tried to pin down what is going on here and my understanding is 
> that Bastien's fix on that previous thread did indeed correct the 
> problem of the missing trailing slash in `org-refile-history' and this 
> indeed corresponds correctly to the state of the completion "collection" 
> (the let bound `tbl' variable in `org-refile-get-location'), as it 
> should.  But there remained a couple of instances in 
> `org-refile-get-location' which added the trailing slash considering 
> `org-refile-history' didn't have them, so that when this is done, we get 
> a double trailing slash.
>
> The two instances are: 1) when the completion function is actually 
> called:
>
> #+begin_src emacs-lisp
> (setq answ (funcall cfunc prompt tbl nil (not new-nodes)
>   nil 'org-refile-history
>   (or cdef (concat (car org-refile-history) 
>   extra
> #+end_src
>
> 2) And three lines bellow, on the let binding:
>
> #+begin_src emacs-lisp
> (let* ((last-refile-loc (car org-refile-history))
>(last-refile-loc-path (concat last-refile-loc extra)))
>   ...)
> #+end_src
>
> In both instances, we are getting the `car' of `org-refile-history' 
> which now already has `extra' (that is, the trailing slash) and adding 
> it again.
>
> My suggested fix is to remove these `extra's in duplicity, they are 
> remnants of when `org-refile-history' didn't have them already.  That 
> is:
>
> #+begin_src emacs-lisp
> (setq answ (funcall cfunc prompt tbl nil (not new-nodes)
>   nil 'org-refile-history
>   (or cdef (car org-refile-history
> #+end_src
>
> And:
>
> #+begin_src emacs-lisp
> (let* ((last-refile-loc (car org-refile-history))
>(last-refile-loc-path last-refile-loc))
>   ...)
> #+end_src
>
> Of course, the second opens some opportunity to simplify the code that 
> follows considering `last-refile-loc-path' and `last-refile-loc' are now 
> identical.
>
>
> Why I think this is the problem and the correct way to fix it:
>
> 1) If you add inspection points at the appropriate locations for the 
> sexps =(concat (car org-refile-history) extra)= and =(concat 
> last-refile-loc extra)= you will find the double trailing slash there, 
> and it shouldn't be there.
>
> 2) The visual manifestation of this double trailing slash in the default 
> candidate with `ivy-mode' is there 

[PATCH] Re: Bug: org-cycle stops working on Org files with empty lines at end of buffer [9.4 (9.4-elpaplus @ /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Ihor Radchenko]

> Also, if you can provide a patch, please go ahead.

Here it is.

>From 8e99e5dea780041d314f666f506a120224f064eb Mon Sep 17 00:00:00 2001
From: Ihor Radchenko 
Date: Wed, 23 Sep 2020 21:54:47 +0800
Subject: [PATCH] Do not remove trailing newline when deleting planning info
 line.

* lisp/org.el (org-add-planning-info): Remove front newline instead of
trailing newline when deleting planning info is completetly removed
from a heading.  Fixes "Cycling through TODO workflow joins the next
line onto the current one".

The old behaviour affected folded headlines containing only planning
info in the body:

Before deletion:
* DONE Headline
  CLOSED: [2020-09-23 Wed 21:39]
* test

After deletion:
* DONE Headline
* test

The newline after the first headline is hidden making both the
headlines appear at the same visual line.

New behaviour:
After deletion:
* DONE Headline
* test

All the folded text is completely removed.
---
 lisp/org.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index a9fdc7b77..845920a71 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10684,8 +10684,8 @@ WHAT entry will also be removed."
 	 ;; If there is nothing more to add and no more keyword is
 	 ;; left, remove the line completely.
 	 (if (and (looking-at-p "[ \t]*$") (not what))
-	 (delete-region (line-beginning-position)
-			(line-beginning-position 2))
+	 (delete-region (line-end-position 0)
+			(line-end-position))
 	   ;; If we removed last keyword, do not leave trailing white
 	   ;; space at the end of line.
 	   (let ((p (point)))
-- 
2.26.2



Bastien  writes:

> Hi,
>
> stardiviner  writes:
>
>> I also did a bisect debug. Found the function ~org-cycle-show-empty-lines~ 
>> in hook
>> ~org-cycle-hook~ caused this problem.
>
> Did you find the commit that introduces this bug?
>
> Also, if you can provide a patch, please go ahead.
>
> Thanks!
>
> -- 
>  Bastien

Re: Bug: org-cycle stops working on Org files with empty lines at end of buffer [9.4 (9.4-elpaplus @ /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)]

[stardiviner]

Bastien  writes:

> Hi,
>
> stardiviner  writes:
>
>> I also did a bisect debug. Found the function ~org-cycle-show-empty-lines~ 
>> in hook
>> ~org-cycle-hook~ caused this problem.
>
> Did you find the commit that introduces this bug?

I did a git bisect test, found the bad commit.

"ee3c3b554 | * bad org.el: Allow empty subtrees to be folded back"

>
> Also, if you can provide a patch, please go ahead.
>

Can't help on this. Don't know much on regexp matching and position boundries 
etc.

Will keep improving skill.

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

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

Re: Cycling through TODO workflow joins the next line onto the current one

[Richard Kim]

Richard Kim  writes:

> Bastien  writes:
>
>> Hi Krishan,
>>
>> Krishan Kharagjitsing  writes:
>>
>>> Hello, I found the following weird behaviour. 
>>
>> What is M-x org-version RET ?
>
> Because of (setq org-log-done 'time) according to
> https://github.com/syl20bnr/spacemacs/issues/13901#issuecomment-697323151
>
>>> When I set some tasks to DONE and fold the headings with TAB, then
>>> when I cycle back from DONE to TODO it joins the next line with the
>>> current one.
>>>
>>> org_mode_bug
>>>
>>> Reproduction guide
>>>
>>> Make two TODO headings in org mode
>>> Cycle both TODO items to DONE
>>> Fold the headings (so the dots appear, because the timestamp gets
>>> folded with the heading)
>>> Cycle the first DONE heading
>>
>> Why are there timestamps?  Can you provide a test .org file where we
>> can reproduce the problem?
>>
>> Thanks,
>
> The original report at the top of
> https://github.com/syl20bnr/spacemacs/issues/13901
> has gif animation on how this problem can be seen.

On my emacs 27, following demonstrates the problem.

(let ()
  (switch-to-buffer (generate-new-buffer "*demo line joining bug*"))
  (erase-buffer)
  (org-mode)
  (setq org-log-done 'time)
  (insert "* one\n")
  (insert "* two\n")
  (goto-line 1)
  (org-todo)
  (org-todo)
  (org-todo)
  (org-cycle)
  (org-todo)
  (org-todo)
  )

Re: Cycling through TODO workflow joins the next line onto the current one

[Richard Kim]

Bastien  writes:

> Hi Krishan,
>
> Krishan Kharagjitsing  writes:
>
>> Hello, I found the following weird behaviour. 
>
> What is M-x org-version RET ?

Because of (setq org-log-done 'time) according to
https://github.com/syl20bnr/spacemacs/issues/13901#issuecomment-697323151

>> When I set some tasks to DONE and fold the headings with TAB, then
>> when I cycle back from DONE to TODO it joins the next line with the
>> current one.
>>
>> org_mode_bug
>>
>> Reproduction guide
>>
>> Make two TODO headings in org mode
>> Cycle both TODO items to DONE
>> Fold the headings (so the dots appear, because the timestamp gets
>> folded with the heading)
>> Cycle the first DONE heading
>
> Why are there timestamps?  Can you provide a test .org file where we
> can reproduce the problem?
>
> Thanks,

The original report at the top of
https://github.com/syl20bnr/spacemacs/issues/13901
has gif animation on how this problem can be seen.

RE: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[Ihor Radchenko]

> What do you think, is it to much work and where can you point out (just 
> generally) where to look in the source for the code responsible for that?

Sub/superscripts are all dumped inside org.el (together with most of
font-lock-related code).

arthur miller  writes:

> Not long time ago I posted a bug report about superscripts and subscripts not 
> rendered when in-between italics markings, '/'. I would definitely like to 
> see that code, and rest for  prettie-fying entities factored out into a minor 
> mode that can be activated in any Emacs  buffer.
>
> What do you think, is it to much work and where can you point out (just 
> generally) where to look in the source for the code responsible for that?
>
>
>
>  Originalmeddelande 
> Från: Bastien 
> Datum: 2020-09-23 10:21 (GMT+01:00)
> Till: "William Rankin via General discussions about Org-mode." 
> 
> Kopia: William Rankin , emacs-de...@gnu.org
> Ämne: Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode
>
> Hi William,
>
> thanks a lot for bringing this up.
>
> Of course, Org would benefit from code cleanup and code refactoring.
>
> And yes, we can collectively push toward (1) modularizing Org a little
> more, (2) making Org features better interact with Emacs core features
> and (3) integrating some of Org's features into Emacs core as Emacs
> features.
>
> IMHO the good examples you give fall into one of the category above,
> and I think such efforts are likely to happen in that order: 1, 2, 3.
>
> The better way to make this happen is to start a discussion with a
> patch explaining how it makes 1, 2 or 3, then discussing the patch
> here on this list - the smaller the better.
>
> If you cannot make a patch, first discuss your idea, and once the
> implementation seems clear, call for help by using a mail header:
>
>   X-Woof-Help: Help with making X a new module
>
> Thanks,
>
> --
>  Bastien

RE: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[arthur miller]

Not long time ago I posted a bug report about superscripts and subscripts not 
rendered when in-between italics markings, '/'. I would definitely like to see 
that code, and rest for  prettie-fying entities factored out into a minor mode 
that can be activated in any Emacs  buffer.

What do you think, is it to much work and where can you point out (just 
generally) where to look in the source for the code responsible for that?



 Originalmeddelande 
Från: Bastien 
Datum: 2020-09-23 10:21 (GMT+01:00)
Till: "William Rankin via General discussions about Org-mode." 

Kopia: William Rankin , emacs-de...@gnu.org
Ämne: Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

Hi William,

thanks a lot for bringing this up.

Of course, Org would benefit from code cleanup and code refactoring.

And yes, we can collectively push toward (1) modularizing Org a little
more, (2) making Org features better interact with Emacs core features
and (3) integrating some of Org's features into Emacs core as Emacs
features.

IMHO the good examples you give fall into one of the category above,
and I think such efforts are likely to happen in that order: 1, 2, 3.

The better way to make this happen is to start a discussion with a
patch explaining how it makes 1, 2 or 3, then discussing the patch
here on this list - the smaller the better.

If you cannot make a patch, first discuss your idea, and once the
implementation seems clear, call for help by using a mail header:

  X-Woof-Help: Help with making X a new module

Thanks,

--
 Bastien

Re: Bug: Unicode ORG-TODO-KEYWORDS not recognized in agenda's stuck projects [9.3.6 (9.3.6-4-gdfa7a3-elpa @ /home/andy/.config/emacs/elpa/org-20200217/)]

[Andy Drop]

Bastien writes:

> Hi Andreas,
>
> I don't see what can go wrong with unicode symbols for TODO keywords
> when listing stuck projects.
>
> ... find `org-agenda-list-stuck-projects' ...
>
> Go at the end of the function and instrument it with C-u C-M-x then
> list stuck projects and see where the function chokes?

I just had the time to give it a deeper look. I can reproduce it with a
clean install of org 9.4, and I think I found the problematic code

file org-agenda.el:

(defun org-agenda-list-stuck-projects ( ignore)

.
.
.

(todo-re (and todo
   (format "^\\*+[ \t]+\\(%s\\)\\>"
  (mapconcat #'identity todo-wds "\\|"

.
.
.

I'm no elisp expert, but it looks to me, as if it builds a list of
regular expressions for every todo keyword in org-stuck-projects (todo-re) and 
it simply puts
the keyword in place of the %s
Each regex is then matched with every line that qualifies as a project
(found by the tags-re)

That works for normal keywords
"^\\*+[ \t]+\\(NEXT\\)\\"
matches with
** NEXT Task 1

BUT
"^\\*+[ \t]+\\(▶\\)\\"
DOES NOT match with
** ▶ Task 1

now my elisp knowledge is completely gone, but as I understood the
documentation for regex in elisp, unicode symbols have to be written
something like '\u1234' (out of my head) to work in a regex.


A minimal test.org:
* Project   :project:
** ▶ Task 1
** ⸰ Task 2

A minimal init.el:
(setq org-todo-keywords '((sequence "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" 
"⏩(r)")))  
(setq org-stuck-projects '("project" ("NEXT" "▶") nil ""))
(setq org-agenda-files '("~/org/test.org"))
(setq org-tags-exclude-from-inheritance '("project"))


With this config the Project is marked as stuck even when it contains a
▶ keyword, when you change that to NEXT (which is not even a
valid todo-keyword here) it becomes unstuck.

Hope this helps
Andy





   
 

Re: ob-java and ob-haxe

[Bastien]

ian martins  writes:

> I'll submit ob-haxe to GNU ELPA after ob-java has been accepted.

Thanks - I confirm contrib/ is not the place anymore for external
elisp packages, better to go on GNU ELPA.

-- 
 Bastien

Re: Bug: Failed to render org file during first load on buffer emacs 27.1 windows binaries [9.3 (release_9.3 @ c:/ProgramFilesh/emacs-27.1-x86_64/share/emacs/27.1/lisp/org/)]

[Palak Mathur]

> On Sep 23, 2020, at 2:29 AM, Bastien  wrote:
> 
> Hi Shibu,
> 
> "Shibu N.V"  writes:
> 
>> I tried with the latest stable release org 9.4 along with emacs27.1
>> windows binaries on windows platform. The issue persists.
> 
> Thanks for reporting this again.
> 
> Can anyone using Emacs/Org on Windows help debugging this?
> 
> -- 
> Bastien
> 

I tried it on Windows with org-mode 9.3 with no issues. I will try with 9.4. 

Re: ob-java and ob-haxe

[Bastien]

Hi Ian,

ian martins  writes:

> Sure, I'd be happy to maintain ob-java.

thanks again for maintaining ob-java.el -- I've add you as the
maintainer in ob-java.el header.

Org 9.4 is out, feel free to push improvements.

Thanks!

-- 
 Bastien

Re: The Website Revamp: The final stretch

[Eric S Fraga]

2-1 for me.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-18-gaea110

Re: [PATCH] Adaptive Org faces in headings?

[Protesilaos Stavrou]

Bastien  [2020-09-23, 14:25 +0200]:

> Ihor Radchenko  writes:
>
>> The attached patch seems to fix the issue.
>
> Applied as 979e82fc3, thanks a lot!

Good news!  Thanks to everyone for their contributions!

-- 
Protesilaos Stavrou
protesilaos.com

Re: [PATCH] possible bugfix in ob-java

[Bastien]

Hi John,

Applied as a409e1033 in master.

Thanks a lot!

-- 
 Bastien

Re: [PATCH] Adaptive Org faces in headings?

[Bastien]

Ihor Radchenko  writes:

> The attached patch seems to fix the issue.

Applied as 979e82fc3, thanks a lot!

-- 
 Bastien

Re: Bug: org-cycle stops working on Org files with empty lines at end of buffer [9.4 (9.4-elpaplus @ /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Bastien]

Hi,

stardiviner  writes:

> I also did a bisect debug. Found the function ~org-cycle-show-empty-lines~ in 
> hook
> ~org-cycle-hook~ caused this problem.

Did you find the commit that introduces this bug?

Also, if you can provide a patch, please go ahead.

Thanks!

-- 
 Bastien

Re: Bug: org-cycle stops working on Org files with empty lines at end of buffer [9.4 (9.4-elpaplus @ /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Bastien]

Hi Nicholas,

"Nicholas Savage"  writes:

> I can reproduce this. 

PS: when confirming a bug, you can add either reply with "Confirmed"
at the beginning of a line, or add X-Woof-Bug: confirmed as a header,
then the bug will appeaer in https://updates.orgmode.org.

See https://github.com/bzg/woof#basic-usage

-- 
 Bastien

Re: [PATCH] Re: RFE: Capture: property prompt: default completion

[Bastien]

Phil Hudson  writes:

> On Wed, 23 Sep 2020 at 12:15, Bastien  wrote:
>>
>> Sorry, I should have mentioned this, but the patch does not apply on
>> master.  If you have time to merge recent changes and reformat it, I
>> can apply it right afterwarsds, otherwise I will try to do it myself
>> later this week.
>
> OK, herewith.

Applied, thanks!

-- 
 Bastien

Re: [PATCH] Re: RFE: Capture: property prompt: default completion

[Phil Hudson]

On Wed, 23 Sep 2020 at 12:15, Bastien  wrote:
>
> Sorry, I should have mentioned this, but the patch does not apply on
> master.  If you have time to merge recent changes and reformat it, I
> can apply it right afterwarsds, otherwise I will try to do it myself
> later this week.

OK, herewith.
org-capture.el: Give a default value when prompting for a property

* lisp/org-capture.el (org-capture-templates, org-capture-fill-template):
  Enable declaring a default value when prompting for a property during
  capture.

* lisp/org.el (org-read-property-value): Add parameter DEFAULT for an
  initial/default/suggested property value.

* doc/org-manual.org: Document declaring a default value for a prompted
  property during capture.

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 043f2ddd1..e7d25b90e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -7858,7 +7858,8 @@ here:
 
 - =%^{PROP}p= ::
 
-  Prompt the user for a value for property {{{var(PROP)}}}.
+  Prompt the user for a value for property {{{var(PROP)}}}.  You may
+  specify a default value with =%^{PROP|default}=.
 
 - =%^{PROMPT}= ::
 
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 2ef55cd5c..9ea0e9e73 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -332,6 +332,8 @@ be replaced with content and expanded:
   %^C Interactive selection of which kill or clip to use.
   %^L Like %^C, but insert as link.
   %^{prop}p   Prompt the user for a value for property `prop'.
+  A default value can be specified like this:
+  %^{prop|default}p.
   %^{prompt}  Prompt the user for a string and replace this sequence with it.
   A default value and a completion table can be specified like this:
   %^{prompt|default|completion2|completion3|...}.
@@ -1787,7 +1789,8 @@ The template may still contain \"%?\" for cursor positioning."
 	   (setq l (org-up-heading-safe)))
 	 (if l (point-marker)
 	   (point-min-marker)))
-			(value (org-read-property-value prompt pom)))
+			(value
+			 (org-read-property-value prompt pom default))) 
 		   (org-set-property prompt value)))
 		((or "t" "T" "u" "U")
 		 ;; These are the date/time related ones.
diff --git a/lisp/org.el b/lisp/org.el
index d45a789f2..ec336c723 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13300,11 +13300,12 @@ This is computed according to `org-property-set-functions-alist'."
   (or (cdr (assoc property org-property-set-functions-alist))
   'org-completing-read))
 
-(defun org-read-property-value (property  pom)
+(defun org-read-property-value (property  pom default)
   "Read value for PROPERTY, as a string.
 When optional argument POM is non-nil, completion uses additional
 information, i.e., allowed or existing values at point or marker
-POM."
+POM.
+Optional argument DEFAULT provides a default value for PROPERTY."
   (let* ((completion-ignore-case t)
 	 (allowed
 	  (or (org-property-get-allowed-values nil property 'table)
@@ -13320,7 +13321,8 @@ POM."
  (if allowed
 	 (funcall set-function
 		  prompt allowed nil
-		  (not (get-text-property 0 'org-unrestricted (caar allowed
+		  (not (get-text-property 0 'org-unrestricted (caar allowed)))
+		  default nil default)
(let ((all (mapcar #'list
 			  (append (org-property-values property)
   (and pom

Re: [PATCH] Re: RFE: Capture: property prompt: default completion

[Bastien]

Phil Hudson  writes:

> On Wed, 23 Sep 2020 at 08:21, Bastien  wrote:
>> It looks good to me.
>>
>> Can you update your patch by adding a proper commit message?
>
> Herewith. Hope I've got it right. I've signed the FSF papers.

Sorry, I should have mentioned this, but the patch does not apply on
master.  If you have time to merge recent changes and reformat it, I
can apply it right afterwarsds, otherwise I will try to do it myself
later this week.

Thanks,

-- 
 Bastien

Re: [PATCH] Re: RFE: Capture: property prompt: default completion

[Phil Hudson]

On Wed, 23 Sep 2020 at 08:21, Bastien  wrote:
> It looks good to me.
>
> Can you update your patch by adding a proper commit message?

Herewith. Hope I've got it right. I've signed the FSF papers.
org-capture.el: Give a default value when prompting for a property

* lisp/org-capture.el (org-capture-templates, org-capture-fill-template):
  Enable declaring a default value when prompting for a property during
  capture.

* lisp/org.el (org-read-property-value): Add parameter DEFAULT for an
  initial/default/suggested property value.

* doc/org-manual.org: Document declaring a default value for a prompted
  property during capture.

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 46498bd22..659e3ffaf 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -7854,7 +7854,8 @@ here:
 
 - =%^{PROP}p= ::
 
-  Prompt the user for a value for property {{{var(PROP)}}}.
+  Prompt the user for a value for property {{{var(PROP)}}}.  You may
+  specify a default value with =%^{PROP|default}=.
 
 - =%^{PROMPT}= ::
 
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index d9c8472b9..de2e19a8b 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -331,8 +331,10 @@ be replaced with content and expanded:
   %^C Interactive selection of which kill or clip to use.
   %^L Like %^C, but insert as link.
   %^{prop}p   Prompt the user for a value for property `prop'.
+  A default value can be specified like this:
+  %^{prop|default}p.
   %^{prompt}  Prompt the user for a string and replace this sequence with it.
-  A default value and a completion table ca be specified like this:
+  A default value and a completion table can be specified like this:
   %^{prompt|default|completion2|completion3|...}.
   %?  After completing the template, position cursor here.
   %\\1 ... %\\N Insert the text entered at the nth %^{prompt}, where N
@@ -1782,7 +1784,8 @@ The template may still contain \"%?\" for cursor positioning."
 	   (setq l (org-up-heading-safe)))
 	 (if l (point-marker)
 	   (point-min-marker)))
-			(value (org-read-property-value prompt pom)))
+			(value
+			 (org-read-property-value prompt pom default)))
 		   (org-set-property prompt value)))
 		((or "t" "T" "u" "U")
 		 ;; These are the date/time related ones.
diff --git a/lisp/org.el b/lisp/org.el
index 3264694aa..4077530f1 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13300,11 +13300,12 @@ This is computed according to `org-property-set-functions-alist'."
   (or (cdr (assoc property org-property-set-functions-alist))
   'org-completing-read))
 
-(defun org-read-property-value (property  pom)
+(defun org-read-property-value (property  pom default)
   "Read value for PROPERTY, as a string.
 When optional argument POM is non-nil, completion uses additional
 information, i.e., allowed or existing values at point or marker
-POM."
+POM.
+Optional argument DEFAULT provides a default value for PROPERTY."
   (let* ((completion-ignore-case t)
 	 (allowed
 	  (or (org-property-get-allowed-values nil property 'table)
@@ -13320,7 +13321,8 @@ POM."
  (if allowed
 	 (funcall set-function
 		  prompt allowed nil
-		  (not (get-text-property 0 'org-unrestricted (caar allowed
+		  (not (get-text-property 0 'org-unrestricted (caar allowed)))
+		  default nil default)
(let ((all (mapcar #'list
 			  (append (org-property-values property)
   (and pom

Re: org-tables with monetary amounts

[Russell Adams]

I often use this for summing columns.

| Column | Column |
|+|
| a  |1.2 |
| b  |  3 |
| c  |   4.56 |
|+|
||   8.76 |
#+TBLFM: @>$2=vsum(@-I..@-II);%0.2f

This does last row (@>$2), and the sum between dividers, and outputs
to fixed precision.

On Tue, Sep 22, 2020 at 04:57:42PM +0200, Daniele Nicolodi wrote:
> Hello,
>
> I often use org-tables to work with monetary amounts. It would be very
> nice to have a couple of functionalities common in this domain:
>
> - fixed precision arithmetic, namely derive the precision of the results
> from the precision of the arguments (I think that calc can do this),
>
> - support for parsing numbers followed by currencies,
>
> - correct alignment for monetary values.
>
> I had a quick look around, but I haven't found anything that implements
> those things. Has anyone some secret code that they would like to share?
>
> Thank you!
>
> Cheers,
> Dan
>


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Help administer code.orgmode.org: moderate user access and manage the gogs instance

[Bastien]

Bastien  writes:

> code.orgmode.org is the place where we host Org's code and Worg
> collaborative documentation.
>
> There are two tasks involved in administering code.orgmode.org:
>
> 1. Creating accounts and let users get write access to org/worg.
> 2. Maintaining the gogs instance on the server.
>
> Both tasks are unrelated.
>
> Is anyone willing to help with (1) and/or (2)?

We now have two volunteers helping with both tasks, TEC and Amin.

Thanks!

-- 
 Bastien

Re: The Website Revamp: The final stretch

[Lars Chr. Duus Hausmann]

Hi,

TEC  writes:


Hello everyone,

I'm pleased to announce that after chatting with Bastien, my 
little
revamp project seems to be nearing the point where it may 
replace the

current site.

Two things that would be good to get sorted:
1. Translation of the index page to French/Japanese ::
   I'm english only, and Bastien is busy, so volunteers would be
   much appreciated!


Is there a specific set of languages, that is/must be
supported. Otherwise - depending on the format, I could do a 
Danish

translation, when English pages are in place.

[]

/LCH

Re: Help administer code.orgmode.org: moderate user access and manage the gogs instance

[Bastien]

Hi Adam,

Adam Spiers  writes:

> It's not nearly as generous an offer, but as I don't have a gogs
> account yet, I volunteer to be a guinea pig if TEC wants to practice
> giving (1) a shot ;-)

please let TEC know what username you want on Worg.

> I think I used to have push access to Worg many years ago, and I've
> noticed one or two issues which I'd be happy to fix if I regained
> that.  Or is Worg also subject to a peer review process these days?

Nope, Worg is in "optimistic merge" mode, so feel free to go ahead
and improve it!

Thansk in advance,

-- 
 Bastien

Re: Getting Org-Crypt to work (doc bug?)

[Bastien]

Hi David,

David Masterson  writes:

> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index 3eb745b5d..775af7a13 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org

Applied as e2bb60581:
https://code.orgmode.org/bzg/org-mode/commit/e2bb60581

I'm attaching the patch so that you can see how to format the
ChangeLog for future contributions.

Best,

-- 
 Bastien
>From e2bb60581b489f92c9f2479994d484d2104968db Mon Sep 17 00:00:00 2001
From: David Masterson 
Date: Wed, 23 Sep 2020 11:03:24 +0200
Subject: [PATCH] doc/org-manual.org (Org Crypt): Add info links to epa and
 GnuPG

* doc/org-manual.org (Org Crypt): Add info links to epa and GnuPG.

TINYCHANGE
---
 doc/org-manual.org | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 229575b13..043f2ddd1 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -19697,8 +19697,8 @@ an Org file that is part of a publishing project.
 :END:
 
 Org Crypt encrypts the text of an entry, but not the headline, or
-properties.  Behind the scene, it uses the Emacs EasyPG library to
-encrypt and decrypt files.
+properties.  Behind the scene, it uses the [[info:epa][Emacs EasyPG Library]] to
+encrypt and decrypt files, and EasyPG needs a correct [[info:gnupg][GnuPG]] setup.
 
 #+vindex: org-crypt-tag-matcher
 Any text below a headline that has a =crypt= tag is automatically
-- 
2.25.1

Re: [PATCH] org.el: Allow transparent background in latex images

[Bastien]

Hi Roshan,

Applied as 2f9e1569f in master.

Thanks!

-- 
 Bastien

Re: [PATCH] Add %L (the link content *not* as a full link) to Capture expansions

[Bastien]

Hi Samuel,

"Samuel W. Flint"  writes:

> Marked as TINYCHANGE.

Applied as d06aa486d, thanks!

Can you provide a patch to announce this in etc/ORG-NEWS?

-- 
 Bastien

Re: [PATCH] Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

[Bastien]

Ihor Radchenko  writes:

>> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new
>> option la mission.
>
> Do I miss something or the need to add ORG-NEWS entry is not mentioned
> in the contribution page?

If you can, please go ahead and fix this.  Thanks,

-- 
 Bastien

Re: [PATCH] Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

[Ihor Radchenko]

> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new
> option la mission.

Do I miss something or the need to add ORG-NEWS entry is not mentioned
in the contribution page?

Best,
Ihor

Bastien  writes:

> Ihor Radchenko  writes:
>
>> See the attached.
>
> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new
> option la mission.  Can you add it in the same patch?
>
> -- 
>  Bastien

Re: [PATCH] Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

[Bastien]

Ihor Radchenko  writes:

> Done.

Applied as 6c75b0021, thanks!

-- 
 Bastien

Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[Bastien]

Hi Russell,

Russell Adams  writes:

> Rather than a huge refactoring or pushing code back into other Emacs
> modes, my thought was that Org should be trimmed into the "core" of
> Org functions and that other things should be implemented as modules
> available in MELPA outside of the official Org core. That way the
> limited maintainer time can be focused on the core of Org and
> maintaining strong interfaces for components made and maintained by
> others.

Yes.  

I agree with this goal, as long as Org modules are maintained too.

Picking up the example I gave above in this thread of modularizing
org-table.el, it will be a good think iff it gets as much attention
than Org's core itself.

2 cents,

-- 
 Bastien

Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[Bastien]

Hi Nicholas,

"Nicholas Savage"  writes:

> If I am looking to do that though, would I be submitting a patch both
> to Emacs and one to Org Mode?

If the patch is against Org, submit it first to emacs-orgmode@gnu.org.

If the patch is integrated into Org it will be merged into Emacs core
at some point.  If the change in the patch, allows for an improvement
in Emacs, then send a patch to the emacs-devel list.

E.g.: if you manage to make to modularize org-table.el so that it can
work on both .org and .md files, first propose the change to this list
then to the markdown-mode developers on Emacs.

Thanks!

-- 
 Bastien

Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[Bastien]

Hi William,

thanks a lot for bringing this up.

Of course, Org would benefit from code cleanup and code refactoring.

And yes, we can collectively push toward (1) modularizing Org a little
more, (2) making Org features better interact with Emacs core features
and (3) integrating some of Org's features into Emacs core as Emacs
features.

IMHO the good examples you give fall into one of the category above,
and I think such efforts are likely to happen in that order: 1, 2, 3.

The better way to make this happen is to start a discussion with a
patch explaining how it makes 1, 2 or 3, then discussing the patch
here on this list - the smaller the better.

If you cannot make a patch, first discuss your idea, and once the
implementation seems clear, call for help by using a mail header:

  X-Woof-Help: Help with making X a new module

Thanks,

-- 
 Bastien

Re: official orgmode parser

[Bastien]

Hi Gerry,

"Gerry Agbobada"  writes:

> Having a tree-sitter parser would be really great in my opinion

1+

Thanks for working on this, let us know how it goes!

-- 
 Bastien

Re: official orgmode parser

[Bastien]

Hi Przemysław,

Przemysław Kamiński  writes:

> I oftentimes find myself needing to parse org files with some external
> tools (to generate reports for customers or sum up clock times for
> given month, etc). Looking through the list
>
> https://orgmode.org/worg/org-tools/

Can you help on making the above page more useful to anyone?

Perhaps we can have a separate worg page just for parsers, reporting
the ones that seem to fully work.

I disagree that a parser is too difficult to maintain because Org is 
a moving target.  Org core syntax is not moving anymore, a parser can
reasonably target it.  That's what is done with the Ruby parser, in
use in this small project called github.com :)

So I'd say:

- let's enhance Worg's documentation
- yes, please go for enhancing parsing tools

I don't think we need official tools.  The official Org parser exists,
it is Org itself.

Thanks,

-- 
 Bastien

Re: [PATCH] Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

[Ihor Radchenko]

Done.

>From c479d8b229140029a3a8454dd933dab7322fafc4 Mon Sep 17 00:00:00 2001
From: Ihor Radchenko 
Date: Fri, 11 Sep 2020 15:42:53 +0800
Subject: [PATCH] Allow customised ID format for `ts' `org-id-method'

* lisp/org-id.el (org-id-new): Use `org-id-ts-format' as ID format for
`ts' ID generation method.
(org-id-ts-format): New custom variable for `ts' ID format.  The
default value is the same as old hard-coded ID format string.
* etc/ORG-NEWS (New option ~org-id-ts-format~): Announce the new
custom variable.
---
 etc/ORG-NEWS   | 6 ++
 lisp/org-id.el | 6 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 87c5696d8..7e3957c10 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -363,6 +363,12 @@ HTML.
 
 Functions in this hook are run after ~org-agenda-filter~ is called.
 
+*** New option ~org-id-ts-format~
+
+Earlier, IDs generated using =ts= method had a hard-coded format (i.e. =20200923T160237.891616=).
+The new option allows user to customise the format.
+Defaults are unchanged.
+
 ** Removed or renamed functions and variables
 *** Deprecated ~org-flag-drawer~ function
 
diff --git a/lisp/org-id.el b/lisp/org-id.el
index f8af52964..512703269 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -128,6 +128,10 @@ nil   Never use an ID to make a link, instead link using a text search for
   :group 'org-id
   :type 'string)
 
+(defcustom org-id-ts-format "%Y%m%dT%H%M%S.%6N"
+  "Default format for IDs generated using `ts' `org-id-method'.
+The format should be suitable to pass as an argument to `format-time-string'.")
+
 (defcustom org-id-method 'uuid
   "The method that should be used to create new IDs.
 
@@ -380,7 +384,7 @@ So a typical ID could look like \"Org:4nd91V40HI\"."
 			(concat "@" (message-make-fqdn))
 	(setq unique (concat etime postfix
  ((eq org-id-method 'ts)
-  (let ((ts (format-time-string "%Y%m%dT%H%M%S.%6N"))
+  (let ((ts (format-time-string org-id-ts-format))
 	(postfix (if org-id-include-domain
 			 (progn
 			   (require 'message)
-- 
2.26.2



Bastien  writes:

> Ihor Radchenko  writes:
>
>> See the attached.
>
> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new
> option la mission.  Can you add it in the same patch?
>
> -- 
>  Bastien

Re: [PATCH] Bug: Fontification: Heading following a comment

[Bastien]

FWIW, I'm marking this bug as fixed in 38fbd161e4.

Thanks,

-- 
 Bastien

Re: [PATCH] Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

[Bastien]

Ihor Radchenko  writes:

> See the attached.

Thanks, but you forgot the note to etc/ORG-NEWS announcing the new
option la mission.  Can you add it in the same patch?

-- 
 Bastien

[PATCH] Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

[Ihor Radchenko]

See the attached.

>From bc492bd2fb87912289c135006b6fbeaca93ba181 Mon Sep 17 00:00:00 2001
From: Ihor Radchenko 
Date: Fri, 11 Sep 2020 15:42:53 +0800
Subject: [PATCH] Allow customised ID format for `ts' `org-id-method'

* lisp/org-id.el (org-id-new): Use `org-id-ts-format' as ID format for
`ts' ID generation method.
(org-id-ts-format): New custom variable for `ts' ID format.  The
default value is the same as old hard-coded ID format string.
---
 lisp/org-id.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index f8af52964..512703269 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -128,6 +128,10 @@ nil   Never use an ID to make a link, instead link using a text search for
   :group 'org-id
   :type 'string)
 
+(defcustom org-id-ts-format "%Y%m%dT%H%M%S.%6N"
+  "Default format for IDs generated using `ts' `org-id-method'.
+The format should be suitable to pass as an argument to `format-time-string'.")
+
 (defcustom org-id-method 'uuid
   "The method that should be used to create new IDs.
 
@@ -380,7 +384,7 @@ So a typical ID could look like \"Org:4nd91V40HI\"."
 			(concat "@" (message-make-fqdn))
 	(setq unique (concat etime postfix
  ((eq org-id-method 'ts)
-  (let ((ts (format-time-string "%Y%m%dT%H%M%S.%6N"))
+  (let ((ts (format-time-string org-id-ts-format))
 	(postfix (if org-id-include-domain
 			 (progn
 			   (require 'message)
-- 
2.26.2


Bastien  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>>> However, I just (strongly) prefer the shorter "ISO-like" ID for many
>>> reasons, as already mentioned (shorter, meaningful, etc.).  I just find
>>> that style much, much more elegant.
>>
>> I guess it does not take much to add this functionality.
>>
>> Patch attached.
>
> Thanks.  Can you update the patch with a correct Changelog entry and a
> note to etc/ORG-NEWS announcing the new option?
>
> See https://orgmode.org/worg/org-contribute.html#commit-messages if it 
> helps.
>
> -- 
>  Bastien

Re: Control where files are emitted during block eval

[Bastien]

Hi George,

George Mauer  writes:

> I would like to create a playground.org file inside my node project
> where I will put bits of code that I'm playing with during
> development.
>
> The problem is that when I actually evaluate a source block it gets
> written into a temporary location that I do not control - I therefore
> cannot `require` my project's node modules as they will not be found.
>
> Is there a way to control the location the temp file is written?
> Maybe - assuming it uses `with-temp-file` - a way to control its
> directory and file name generation algorithm via a header?

One problem is that *every* ob-*.el in Org uses with-temp-file for
executing source code.

Also, it seems to be a very peculiar use case, so I would not go
for a new org-with-temp-file macro allowing such control, but that
maybe something you want to explore?

-- 
 Bastien

Re: Bug: Org-mode v3.8 tag hierarchy [9.3.3 (release_9.3.3 @ /home/user/.emacs.d/org-mode/lisp/)]

[Ihor Radchenko]

> Can you reproduce the problem with latest stable, aka 9.4 ?

I can.


Bastien  writes:

> Hi Leon,
>
> Leon Weber  writes:
>
>> Hi together, I recently updated from org-mode version 9.1.8 to 9.3. I 
>> noticed a problem with group tags / tag hierarchy in the agenda-view 
>> (Agenda for current week or day).
>
> Can you reproduce the problem with latest stable, aka 9.4 ?
>
> -- 
>  Bastien

Confirmed

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Bastien]

Hi,

hj-orgmod...@hj.proberto.com writes:

> I do not have much insight into all the possible outcomes (i.e. I am
> clueless about such outcomes) except one outcome - orgmode MIME type
> gets registered.  

If there is absolutely zero burden put on the shoulders of Org's
maintainers, then I'm all for it.

> I think it would serve well the proliferation and
> popularization of org-mode. 

Agreed.

Is anyone willing to check that there are no constraints?

Is anyone willing to move forward with this registration?

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

> Can you share this gist as a patch against Org's current master?

That is not possible. The underlying reason of the bug in the patch is
different from master.

On master, the overlays for folded drawers and headlines are merged
together - when folded headline is opened by isearch, everything is
revealed. The fix would involve special logic re-hiding drawers when
necessary.

On the org-fold feature branch, the drawers and headlines are folded
independently. The reason why the bug persisted was my mistake in
org-hide-drawers - I skipped drawers inside folded headlines, even when
the drawers themselves were not folded. In my case the fix was trivial -
I replaced condition when to skip drawer at point:

[any fold is present at point] -> [drawer fold is present at point]
(org-fold-get-folding-spec) -> (org-fold-get-folding-spec 
(org-fold-get-folding-spec-for-element 'drawer))

So, the fix is only relevant to the whole org-fold branch.

Best,
Ihor

Bastien  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>> Thanks for reporting! I accidentally reintroduced the bug because of
>> mistake when converting org-hide-drawers to new folding library.
>> (:facepalm:).
>>
>> Should be fixed in the gist now.
>
> Can you share this gist as a patch against Org's current master?
>
> -- 
>  Bastien

Re: How to refer to remote table, in another file, as a source block variable?

[Bastien]

Hi William,

William Denton  writes:

> I'll try to do a patch for the docs so this is clearer there.

TIA!

-- 
 Bastien

Re: Bug: Failed to render org file during first load on buffer emacs 27.1 windows binaries [9.3 (release_9.3 @ c:/ProgramFilesh/emacs-27.1-x86_64/share/emacs/27.1/lisp/org/)]

[Bastien]

Hi Shibu,

"Shibu N.V"  writes:

> I tried with the latest stable release org 9.4 along with emacs27.1
> windows binaries on windows platform. The issue persists.

Thanks for reporting this again.

Can anyone using Emacs/Org on Windows help debugging this?

-- 
 Bastien

Re: Texinfo in Org-Mode but with texinfo syntax highlighting

[Bastien]

Hi Christopher,

Christopher Dimech  writes:

> I am writing a document in texinfo, but I also have some commands in
> Org-Mode so that if I change my Emacs Major Mode to Org-Mode
> I get an easy way to traverse my texinfo code. However I would like
> to keep the syntax highlighting as the use set for texinfo, rather than
> that of org-mode. I share a way to do that?

There is some code out there to let you run multiple major modes in
Emacs, I would look into that:

See https://www.emacswiki.org/emacs/MultipleModes and perhaps check
for https://github.com/purcell/mmm-mode

2 cents,

-- 
 Bastien

Re: newline or no newline at end of capture: expected behavior

[Bastien]

Hi Samuel,

Samuel Wales  writes:

> basically i am getting unwanted newlines all over the place when i
> capture.  but i want to confirm expected behavior for all 4 questions.

Let's take this one by one.  

Can you provide the *worst* use case of Org going completely insane
regarding empty lines after captured notes?

-- 
 Bastien

Re: [PATCH] Re: RFE: Capture: property prompt: default completion

[Bastien]

Hi Phil,

Phil Hudson  writes:

> Sorry, should have changed the subject. Re-sending patch (no alterations).

It looks good to me.

Can you update your patch by adding a proper commit message?

See https://orgmode.org/worg/org-contribute.html#commit-messages

Thanks a lot,

-- 
 Bastien

Fwd: Slow to open certain file

[Peter Bienstman]

Attached the profile when i open with 'find-file'. It still seems to
call ivy-read, but the interesting thing is that now a lot of time is
apparently spent in 'url-http' functions. The file contains lots of
web links, so it seems emacs is trying to do something with them when
it really shouldn't...

Cheers,

Peter

PS: this is not a permanent paper archive, but rather an ephemeral
collection of journal rss feeds

On Wed, Sep 23, 2020 at 3:48 AM Ihor Radchenko  wrote:
>
> I have no issue opening your file (under 1 second).
>
> > I also attach the profile.
>
> Looking at the profile, the problem seems to be with ivy. Can you try
> opening the file without ivy. Something like
>
> M-: (find-file "~/Org/notes.org") 
>
> P.S. You can also add notes to papers from org-ref. That is a great help
>  when your paper database grow bigger.
>
> Best,
> Ihor
>
> Peter Bienstman  writes:
>
> > Opening this file takes more than 10 seconds:
> >
> > https://www.dropbox.com/s/tg7pr6tetlh7jwb/toc%2020200922%2007.00.01.org?dl=0
> >
> > I also attach the profile.
> >
> > I have org files which are much bigger, and they open almost instantly.
> >
> > This is on Windows 10, emacs 26.3, all packages updated to the latest 
> > version.
> >
> > Is there anything I can do to speed this up?
> >
> > Thanks!

Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

>> However, I just (strongly) prefer the shorter "ISO-like" ID for many
>> reasons, as already mentioned (shorter, meaningful, etc.).  I just find
>> that style much, much more elegant.
>
> I guess it does not take much to add this functionality.
>
> Patch attached.

Thanks.  Can you update the patch with a correct Changelog entry and a
note to etc/ORG-NEWS announcing the new option?

See https://orgmode.org/worg/org-contribute.html#commit-messages if it 
helps.

-- 
 Bastien

Re: Cycling through TODO workflow joins the next line onto the current one

[Bastien]

Hi Krishan,

Krishan Kharagjitsing  writes:

> Hello, I found the following weird behaviour. 

What is M-x org-version RET ?

> When I set some tasks to DONE and fold the headings with TAB, then
> when I cycle back from DONE to TODO it joins the next line with the
> current one.
>
> org_mode_bug
>
> Reproduction guide
>
> Make two TODO headings in org mode
> Cycle both TODO items to DONE
> Fold the headings (so the dots appear, because the timestamp gets
> folded with the heading)
> Cycle the first DONE heading

Why are there timestamps?  Can you provide a test .org file where we
can reproduce the problem?

Thanks,

-- 
 Bastien

Re: Bug: DOI links are broken in HTML exports

[Bastien]

Hi,

yarnton--- via "General discussions about Org-mode."
 writes:

> I've found a small bug in org-html-export-to-html. Minimal document to 
> reproduce:
>
> ---
>
> Foo [fn:1]
>
> * Footnotes
>
> [fn:1] doi:10.1186/s12864-016-2377-z
>
> ---

Do you use a link abbreviation for doi: links ?

> When I export this document to HTML the DOI link gets converted into a
> broken hyperlink. It should be converted into
> https://doi.org/10.1186/s12864-016-2377-z as explained
> in https://www.doi.org/. 

If you use a link abbreviation.

> Following the link from the org file with C-c C-o works fine, though.
>
> It'd be great if this could get fixed, as DOI links are incredibly
> helpful when dealing with bibliographic items.

What version of Emacs and Org are you using?

-- 
 Bastien

Re: Bug: Org-mode v3.8 tag hierarchy [9.3.3 (release_9.3.3 @ /home/user/.emacs.d/org-mode/lisp/)]

[Bastien]

Hi Leon,

Leon Weber  writes:

> Hi together, I recently updated from org-mode version 9.1.8 to 9.3. I 
> noticed a problem with group tags / tag hierarchy in the agenda-view 
> (Agenda for current week or day).

Can you reproduce the problem with latest stable, aka 9.4 ?

-- 
 Bastien

Re: [PATCH] Expanded ob-python results handling and plotting

[Bastien]

Hi Jack,

Jack Kamm  writes:

> For now, I think I prefer to keep ob-python leaner, so am going to hold
> off on this.

The leaner the less maintainance ahead :)

> I'll wait a week or so for comments before merging this new, more
> limited patch into master.

LGTM, thanks!

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> Thanks for reporting! I accidentally reintroduced the bug because of
> mistake when converting org-hide-drawers to new folding library.
> (:facepalm:).
>
> Should be fixed in the gist now.

Can you share this gist as a patch against Org's current master?

-- 
 Bastien

Re: Help with moderating non-subscribers messages on the Org mailing list

[Bastien]

Bastien  writes:

> We could use the help of more mailing list maintainers.

Thanks for those who volunteered!  

We now have 8 moderators, it really helps.

I'm closing this call for help right now.

-- 
 Bastien

Re: Org-Crypt and HTML export

[Bastien]

Hi David,

David Masterson  writes:

> I take it that, when you do an HTML export on an Org file, it is assumed
> that all items that have been encrypted with org-crypt will have been
> decrypted, correct?

Is it what you get?

> Is there a way to create an HTML file with Org that includes some
> encrypted data to be decrypted by whoever views the file (with
> appropriate password)?

Nope, unless someone coded this in some corner of the web.

-- 
 Bastien

Re: The Website Revamp: The final stretch

[Bastien]

Hi Devin,

Devin Prater  writes:

> I'm just going over the site to check accessibility with screenn
> readers

Thanks for reporting these issues, we need to make the website fully
accessible before making the switch.

-- 
 Bastien

Re: The Website Revamp: The final stretch

[Bastien]

Hi Timothy,

thanks for all your work!

The only variant that I like is 2-1.

Also, let's remove the mini-unicorn in the top bar, it is redundant
and reminds me of the opening of IT Crowd.


:)

For the translations, as discussed IRL, we don't need to translate
everything, perhaps just the index page would do.

Let me restate some of the directions I shared with you privately:

- I believe there are too many pages: I'd love the website to be just
  one HTML page.  Rich contents should go to Worg and yes, we need to
  upgrade Worg's design too. Let's try moving such contents to Worg as
  soon as we can -- but this is not a blocker for the switch.

- For the manual, I'd prefer to use the same design that the one used
  on the gnu.org website:

  https://www.gnu.org/software/emacs/manual/html_node/org/index.html

  The proposed one (https://orgmode.tecosaur.com/manual) looks good
  but it is too fancy and too narrow.  This is a blocker.

That's all for me -- thanks again!  Happy to help with the switch
when blockers are behind us.

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

> Apologies for maybe changing the subject, but earlier this summer you
> mentioned[1] you were working on a patch to the folding system that
> would fix an issue I have[2] with LOGBOOKs since 9.4.  AFAICT the patch
> you are sharing now does not fix that; is this issue still on your
> radar?

Thanks for reporting! I accidentally reintroduced the bug because of
mistake when converting org-hide-drawers to new folding library.
(:facepalm:).

Should be fixed in the gist now.

Best,
Ihor

Kévin Le Gouguec  writes:

> Ihor Radchenko  writes:
>
 then M-x toggle-debug-on-error and M-: (org-make-manuals), but I can't
 get a stacktrace.  I'm guessing this is because this error (which IIUC
 originates from org-back-to-heading in org.el) is a user-error; however,
 if I change the function to raise a "regular error", then everything
 compiles fine… 
>>>
>>> I suspect that you forgot to run =make clean= (to remove old untracked
>>> .elc files).
>>
>> I was wrong. It was actually a problem with org-back-to-heading. Should
>> be fixed now.
>
> Thanks!  The new patch applies cleanly (to aea1109ef), and "make" runs
> to completion.
>
> I have seen no obvious breakage so far; I'll make sure to report if
> anything funny shows up.
>
>
> Apologies for maybe changing the subject, but earlier this summer you
> mentioned[1] you were working on a patch to the folding system that
> would fix an issue I have[2] with LOGBOOKs since 9.4.  AFAICT the patch
> you are sharing now does not fix that; is this issue still on your
> radar?
>
>
> At any rate, thank you for your work!
>
>
> [1] https://orgmode.org/list/87r1ts3s8r.fsf@localhost/
> [2] https://orgmode.org/list/87eepuz0bj@gmail.com/
>
> tl;dr even with #+STARTUP: overview, isearching opens all logbooks
> near search results, even though there are no matches inside
> logbooks themselves.

Re: Help with moderating non-subscribers messages on the Org mailing list

[Jeremie Juste]

Hello Dominique,

Many thanks for this info. I'll give it a try.

Best regards,
Jeremie


Dominique Dumont  writes:

> Hi
>
> On mercredi 16 septembre 2020 11:04:42 CEST Bastien wrote:
>> The task is to check the mailman administration page and to discard
>> messages that should not be sent to the list, while allowing those
>> sent by non-subscribers who ask relevant questions.
>
> For what's it's worth, I use listadmin [1] to moderate a few Debian mailing 
> list. 
>
> I feel this is much faster than checking mailman pages: I run listadmin in a 
> terminal and then mostly hit return to discard spam.
>
> HTH
>
> [1] https://sourceforge.net/projects/listadmin/

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Kévin Le Gouguec]

Ihor Radchenko  writes:

>>> then M-x toggle-debug-on-error and M-: (org-make-manuals), but I can't
>>> get a stacktrace.  I'm guessing this is because this error (which IIUC
>>> originates from org-back-to-heading in org.el) is a user-error; however,
>>> if I change the function to raise a "regular error", then everything
>>> compiles fine… 
>>
>> I suspect that you forgot to run =make clean= (to remove old untracked
>> .elc files).
>
> I was wrong. It was actually a problem with org-back-to-heading. Should
> be fixed now.

Thanks!  The new patch applies cleanly (to aea1109ef), and "make" runs
to completion.

I have seen no obvious breakage so far; I'll make sure to report if
anything funny shows up.


Apologies for maybe changing the subject, but earlier this summer you
mentioned[1] you were working on a patch to the folding system that
would fix an issue I have[2] with LOGBOOKs since 9.4.  AFAICT the patch
you are sharing now does not fix that; is this issue still on your
radar?


At any rate, thank you for your work!


[1] https://orgmode.org/list/87r1ts3s8r.fsf@localhost/
[2] https://orgmode.org/list/87eepuz0bj@gmail.com/

tl;dr even with #+STARTUP: overview, isearching opens all logbooks
near search results, even though there are no matches inside
logbooks themselves.