Re: eldoc recursion error

[Kyle Meyer]

Matt Price writes:

> On Tue, Sep 8, 2020 at 11:27 AM Matt Price  wrote:

>> On Tue, Sep 8, 2020 at 10:53 AM Bastien  wrote:
>>
>>> Matt Price  writes:
>>>
>>> > In a new org file, add these lines:
>>> >
>>> > #+begin_src python
>>> > print
>>> > #+end_src
>>> >
>>> > position cursor inside block and the error message occurs.
>>>
>>> I can't reproduce the bug.  What version of Emacs are you using?
>>>
>>> Can you give a recipe starting with emacs -q?
>>
>> I htink I have it now.
>>
>> $ emacs -q
>>
> I forgot to say, this is emacs git (2.8.0.50 from yesterday) and org-mode
> master (current)

I can trigger it with Emacs's master.  Rather than being an issue with
the two recent compatibility kludges (47f26b1e7 and b2b587387), I think
this comes down to an additional (and hopefully last) spot,
org-eldoc-get-mode-local-documentation-function, needing to be adjusted,
(as suggested in ).

Taking a quick look, I think it will need to be a bit more involved than
the other kludges.

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

[TRS-80]

On 2020-09-10 21:06, Ihor Radchenko wrote:

I do appreciate all the replies so far.  However as I plan on relying
on this to implement some quite critical functionality for a package I
am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you
will) I would feel a lot more comfortable with some additional
reassurences that what I am planning is not some crazy or bad idea.


Is there any particular reason why you even need to display :ID: value 
to

the user? If only id: links are concerned, link description can be made
short and human-readable.

Best,
Ihor


Yes, most of the time I expect I will be using Orgmode double bracket 
style

links which will, as you say, hide the id: from the user, allowing to
replace it with whatever desired text in the form of the link 
description.


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.

Besides, as an ID, they are plenty "Unique" for my use case, with the
default minute resolution (however even that, is configurable in my
implementation, by way of a time-format variable, should anyone need 
more).


I suppose if we ever get to a world where people start linking to each
others' individual publicly published zettel, I may regret the decision.
However Ted Nelson has already been working on such a thing for some
decades already, and we are still not there yet, so I don't think I will
need to worry about that any time soon.  ;)  Even if so, it would be a 
very

small implementation change anyway.

Cheers,
TRS-80

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

[Ihor Radchenko]

> I do appreciate all the replies so far.  However as I plan on relying
> on this to implement some quite critical functionality for a package I
> am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you
> will) I would feel a lot more comfortable with some additional
> reassurences that what I am planning is not some crazy or bad idea.

Is there any particular reason why you even need to display :ID: value to
the user? If only id: links are concerned, link description can be made
short and human-readable.

Best,
Ihor

TRS-80  writes:

> On 2020-09-10 18:20, Samuel Wales wrote:
>> this or something similar has definitely been discussed on this
>> mailing list.  so you are not alone.
>
> Yes, I also thought certainly this must have been discussed before.  I
> did try searching the list, but I think the relevant search terms are
> too common, short ("ID", etc.) and/or too close to unrelated things
> (i.e. CUSTOM_ID when I am looking for "custom ID", etc.) to produce
> any good results.  Or maybe my search-fu is just bad.
>
>> although i undersatnd the whole thing as readable id's.  dunno if that
>> is the prupose.
>
> Essentially, yes, more readable.  But also shorter, and perhaps most
> importantly, /meaningful/.
>
>> maybe something like a timestamp and then the usual id would give you
>> pretty good uniqueness.
>
> The uniqueness I outlined in OP (down to minute) is plenty enough for
> my use-case.  The /last/ thing I want to do is to go the other way, and
> make the ID even longer!
>
> I do appreciate all the replies so far.  However as I plan on relying
> on this to implement some quite critical functionality for a package I
> am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you
> will) I would feel a lot more comfortable with some additional
> reassurences that what I am planning is not some crazy or bad idea.
>
> Thanks,
> TRS-80

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

[TRS-80]

On 2020-09-10 18:20, Samuel Wales wrote:

this or something similar has definitely been discussed on this
mailing list.  so you are not alone.


Yes, I also thought certainly this must have been discussed before.  I
did try searching the list, but I think the relevant search terms are
too common, short ("ID", etc.) and/or too close to unrelated things
(i.e. CUSTOM_ID when I am looking for "custom ID", etc.) to produce
any good results.  Or maybe my search-fu is just bad.


although i undersatnd the whole thing as readable id's.  dunno if that
is the prupose.


Essentially, yes, more readable.  But also shorter, and perhaps most
importantly, /meaningful/.


maybe something like a timestamp and then the usual id would give you
pretty good uniqueness.


The uniqueness I outlined in OP (down to minute) is plenty enough for
my use-case.  The /last/ thing I want to do is to go the other way, and
make the ID even longer!

I do appreciate all the replies so far.  However as I plan on relying
on this to implement some quite critical functionality for a package I
am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you
will) I would feel a lot more comfortable with some additional
reassurences that what I am planning is not some crazy or bad idea.

Thanks,
TRS-80

Re: Delay all occurences for a heading scheduled with repeater not work.

[Samuel Wales]

i see the problem.  but i get confused about the real-world purpose of
this feature.  is the idea that technically someplace in the real
world you are supposed to work on it but you have decided not to and
you don't want the agenda to show it until you will work on it?

On 9/10/20, Bastien  wrote:
> Hi,
>
> h...@protonmail.com writes:
>
>> It says:
>> "If you want to delay the display of this task in the agenda, use
>> ‘SCHEDULED: <2004-12-25 Sat -2d>’: the task is still scheduled on the
>> 25th but will appear two days later. In case the task contains a
>> repeater, the delay is considered to affect all occurrences; if you
>> want the delay to only affect the first scheduled occurrence of the
>> task, use ‘--2d’ instead."
>>
>> With headings below:
>> * delay in scheduled with repeater
>> ** TODO delay all occurences
>>SCHEDULED: <2020-01-30 Thu -1d +2d>
>> ** TODO delay only the first occurence
>>SCHEDULED: <2020-01-30 Thu --1d +2d>
>>
>> Both headings display in today's agenda (today is <2020-01-31>).
>> Which is correct.
>>
>> Then both display in agenda of <2020-02-01>.
>> Which is not correct for 'delay all occurences'.
>> It should display in agenda of <2020-02-02>.
>>
>> Please help check if this should be fixed.
>
> Just bumping up this thread to confirm the bug is still there.
>
> --
>  Bastien
>
>


-- 
The Kafka Pandemic

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

Re: bug#42484: org-mode should display value of links in mini-buffer

[Samuel Wales]

the problem for eldoc for me is that for some reason it gets pretty
confusing trying to implement lots of things all at once, at least
when emacs is already using it for something, or so.

here is my current jumble of code.  it does work.  and has comments
but idk if it is of any use.  or even understandable to anybody.

one other use for it that i have not gotten to in yeras but woulkd be
good is to have hovering over timestamps show you the number of days
from now to that timestamp.

so lots of uses for eldoc.

;; hover text
(with-no-warnings
  (if (< emacs-major-version 24)
  (setq tooltip-use-echo-area t)
(tooltip-mode -1)))

(unless (version< emacs-version "25")
  ;; i find this annoying in at least elisp, and prefer my
  ;; function enabled in elisp, which does interesting things for
  ;; org-link-minor-mode.  emacs 25 enables this by default.  it
  ;; might be itneresting to see where eldoc is useful.
  (global-eldoc-mode -1))
;; make pointer emit help-echo
;;   over org links
;; (setq eldoc-idle-delay 8.0)
;; (setq eldoc-idle-delay 0.0)
;; (add-hook 'prog-mode-hook 'eldoc-mode)
;; [[http://google.com][test]]
;; fixme why does this not work in either org or elisp?
;;   because there is no help-echo
;;   fixme add help-echo
;; [2017-01-16 Mon 12:48]
;; fixme why does this work on links in elisp without this hook?
;; (add-hook 'prog-mode-hook 'alpha-eldoc-help-echo-mode)
;; (add-hook 'org-link-minor-mode-hook 'alpha-eldoc-help-echo-mode)
(add-hook 'org-mode-hook 'alpha-eldoc-help-echo-mode)
;; in elisp we might want both link eldoc and elisp eldoc
;;   we also want org ts eldoc
(defun hoka-eldoc-help-echo-at-point ()
  "Eldoc thingy for help-echo text properties.
This works for links, should work for tses in at least
org-link-minor mode and org mode, and is/was broken by emacs 25
enabling eldoc at some point.  Fixing these things one by one."
  ;; does this mean we do this every movement?
  ;;   apparently eldoc does
  (let ((val
 (or (get-text-property (point) 'help-echo)
 ;; fixme if at a timestamp (alpha-eldoc-time-span)
 ;; adding help echo time span to every timestamp
 ;; seems like it would require org
 ;; ;; (add-hook 'alpha-eldoc-non-help-echo-hook
'alpha-eldoc-timestamp-hook)
 ;; (run-hooks alpha-eldoc-non-help-echo-hook)
 )))
val))
;; (alpha-eldoc-help-echo-mode)
(defun alpha-eldoc-help-echo-mode ()
  "Enable eldoc mode with e.g. org links to display in minibuffer
when cursor is over them.  Call in the relevant buffer.  M-x
eldoc-mode to turn off.  /Add this to mode hooks/."
  (interactive)
  (eval-when-compile (require 'eldoc))
  (setq-local eldoc-documentation-function 'hoka-eldoc-help-echo-at-point)
  (eldoc-mode))




On 9/10/20, Maxim Nikulin  wrote:
> 06.09.2020 21:18, Kévin Le Gouguec wrote:
>>> Boruch Baum  writes:
>>>
 In org-mode, when POINT is moved over an org-mode link, wouldn't it be
 reasonable for the value of that link to appear in the mini-buffer? The
 advantage of that is the user would know where the link points and what
 would happen if the link is opened (eg. would an external program open,
 would the network be queried).
>>
>> That would be very welcome, IMO.  FWIW, markdown-mode does that (when
>> markup is hidden) using ElDoc; cf. markdown-eldoc-function.
>
> There was a similar question in May. A message in the middle of that
> thread:
> https://orgmode.org/list/CAJ51ETo0x=zrav7lfudvap7d2pz-duhzcrut+guby0slssw...@mail.gmail.com/
>
>
>


-- 
The Kafka Pandemic

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

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

[Gustav Wikström]

Hi TRS-80,

Your approach should work just fine. So fine, in fact, that it's already kind 
of built in! Configure org-id-method and set it to 'ts and you'll get 
timestamps as ID instead of uuid.

I do believe the manual lacks a description for this. Not entirely sure though, 
and can't check atm. But the configuration is there none the less, and 
supported.

Kind regards
Gustav

From: Emacs-orgmode  on behalf of 
TRS-80 
Sent: Thursday, September 10, 2020 10:02:45 PM
To: emacs-orgmode@gnu.org 
Subject: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

First, I want to express my sincere and heart-felt gratitude to Carsten
(and other contributors) for making and sharing this wonderful piece of
software.  I have come to refer to it as "one of the gateway drugs to
Emacs" (the other being Magit, IMHO).  It was certainly one of (if not
/the/) main reason(s) why I started using Emacs initially.

I could in fact gush all day, however people are busy, so, on to the
main issue...  :)

It seems to me that there is nothing really stopping me from inserting
whatever value I like for value of "ID" Property.  Based on brief
experimentation, org-store-link and org-insert-link seem to happily
accept whatever value is already there (which I entered manually, for
testing purposes).

However I seem to recall reading some warning somewhere about this,
although I cannot seem to find it right now.

What I would like to do, is generate my own ID values in a more human
readable format, something "ISO-like" for example "2020-09-10-1433" (as
opposed to the default "uuid" method).  These sort of ID are still
"Unique" (well, within my own system, anyway) as long as I am not
generating them more often than once per minute[0].  And they have the
advantages of being shorter, human readable, and meaningful.

Even when org-id-link-to-org-use-id and org-id-track-globally are both
set to "t", org-id seems happy to insert my "ISO-like" ID right into the
hash table and org-id-locations-file.

I do need the "across files" functionality.  My understanding is that
this is main difference between ID and CUSTOM_ID (the latter being local
only to the file).  Unless I am misunderstanding?

So, what am I missing here?  Any reason(s) /not/ to use my own custom ID
value?

In addition to the general case, one particular area I am unsure about
(as I have yet to get it working) is how this all works out with HTML
export, as that is something I also wanted to get working at some point.

I tried studying some of the related sources (as well as mailing list
archive), but could not seem to reach a conclusive answer.  I was hoping
that some more knowledgeable people could confirm
whether this is a really bad idea, or not.  Any feedback would be
greatly appreciated!

Cheers!

TRS-80

[0] It could easily be extended to second (or further) resolution, if
needed.  For me, minute resolution will be fine.

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

[Samuel Wales]

this or something similar has definitely been discussed on this
mailing list.  so you are not alone.

although i undersatnd the whole thing as readable id's.  dunno if that
is the prupose.

maybe something like a timestamp and then the usual id would give you
pretty good uniqueness.


On 9/10/20, TRS-80  wrote:
> First, I want to express my sincere and heart-felt gratitude to Carsten
> (and other contributors) for making and sharing this wonderful piece of
> software.  I have come to refer to it as "one of the gateway drugs to
> Emacs" (the other being Magit, IMHO).  It was certainly one of (if not
> /the/) main reason(s) why I started using Emacs initially.
>
> I could in fact gush all day, however people are busy, so, on to the
> main issue...  :)
>
> It seems to me that there is nothing really stopping me from inserting
> whatever value I like for value of "ID" Property.  Based on brief
> experimentation, org-store-link and org-insert-link seem to happily
> accept whatever value is already there (which I entered manually, for
> testing purposes).
>
> However I seem to recall reading some warning somewhere about this,
> although I cannot seem to find it right now.
>
> What I would like to do, is generate my own ID values in a more human
> readable format, something "ISO-like" for example "2020-09-10-1433" (as
> opposed to the default "uuid" method).  These sort of ID are still
> "Unique" (well, within my own system, anyway) as long as I am not
> generating them more often than once per minute[0].  And they have the
> advantages of being shorter, human readable, and meaningful.
>
> Even when org-id-link-to-org-use-id and org-id-track-globally are both
> set to "t", org-id seems happy to insert my "ISO-like" ID right into the
> hash table and org-id-locations-file.
>
> I do need the "across files" functionality.  My understanding is that
> this is main difference between ID and CUSTOM_ID (the latter being local
> only to the file).  Unless I am misunderstanding?
>
> So, what am I missing here?  Any reason(s) /not/ to use my own custom ID
> value?
>
> In addition to the general case, one particular area I am unsure about
> (as I have yet to get it working) is how this all works out with HTML
> export, as that is something I also wanted to get working at some point.
>
> I tried studying some of the related sources (as well as mailing list
> archive), but could not seem to reach a conclusive answer.  I was hoping
> that some more knowledgeable people could confirm
> whether this is a really bad idea, or not.  Any feedback would be
> greatly appreciated!
>
> Cheers!
>
> TRS-80
>
> [0] It could easily be extended to second (or further) resolution, if
> needed.  For me, minute resolution will be fine.
>
>


-- 
The Kafka Pandemic

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

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

[TRS-80]

On 2020-09-10 18:00, Gustav Wikström wrote:

Hi TRS-80,

 Your approach should work just fine. So fine, in fact, that it's
already kind of built in! Configure org-id-method and set it to 'ts
and you'll get timestamps as ID instead of uuid.

 I do believe the manual lacks a description for this. Not entirely
sure though, and can't check atm. But the configuration is there none
the less, and supported.

 Kind regards

 Gustav


Hi Gustav,

Thanks for the fast reply.

I am aware of the 'ts' option to org-id-method which does not seem to
be documented in manual, only docstring of its defcustom in org-id.el.
I had left that detail out for the sake of brevity.  :)

My problem with that is that I do not like the format it outputs which
is "%Y%m%dT%H%M%S.%6N" (in other words, output which looks like
"20200910T180910.747026").  Only a little bit better than the "uuid"
option, IMHO!  :)

It would be great if that format-time-string was a configurable
variable, instead of hard coded, but alas it is not.  Well, since we
are now on that subject, perhaps I should ask is there some reason for
this?  Or would Bastien perhaps consider something like that?  :)))

Regards,
TRS-80

Re: Support for simultaneous running clocks?

[Samuel Wales]

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.

i believe there is a package that allow many non-org clocks and has a
list-timers or so that shows you what you have running.  i forgot its
name.  idk if htat would be useful.  presumably counts up and down and
possibly notifies.

On 9/10/20, TRS-80  wrote:
> On 2020-09-04 13:14, Bastien wrote:
>> Hi Carlo,
>>
>>> Carlo Tambuatco  writes:
>>>
>>> how long something takes to compile
>
> I have set my shell prompt with a timestamp for exactly this reason.  I
> have also seen someone who set it to reflect elapsed time since last
> command, instead.
>
> But I guess maybe you are referring to inside Emacs / Orgmode?  I'm just
> throwing out a possible alternative.
>
> Cheers,
>
> TRS-80
>
>


-- 
The Kafka Pandemic

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

Re: Improving org-contacts performance (and state of development in general)

[TRS-80]

On 2020-09-06 22:52, Daryl Manning wrote:

PS> As an outside feature though, interoperability of the org-contact
formats with other operating system address books, most notable gnome
contacts/evolution, goog contacts, and OSX address book would be high
on my list in terms of improving org-contacts though. (eg, raw,
structued info in all address books, and say perhaps notes or similar
maintained and synced in ome manner.


Hi Daryl,

Good topic.

This is essentially the main reason I don't use org-contacts, even
though I have become a heavy Orgmode/Emacs user for almost everything
else over the past few years.

In my case, it's the Contacts on my Android phone, which seems to me
to be the primary place where I find myself adding/removing/editing my
contacts.  In my view, there /must/ be reliable and proper (/two-way/)
sync between the two.  Since that doesn't exist (that I am aware of)
my Android phone won out over org-contacts so far.

I haven't looked into it in a while, but at one point I thought that
using some common and open format would be the best idea.  Something
like CardDAV.

I actually had it working (syncing) with my NextCloud instance when I
had that up and running, but for me NextCloud proved to be to "heavy"
in general so I moved away from it, preferring instead lighter weight
tools to do the same things.  And so far I only implemented Syncthing
for the syncing part, and nothing for the CalDAV/CardDAV part (yet)
although I have had my eye on Radicale already for a while.

Maybe you know all this already, I'm just adding my $0.02.

Cheers,
TRS-80

Re: Support for simultaneous running clocks?

[TRS-80]

On 2020-09-04 13:14, Bastien wrote:

Hi Carlo,


Carlo Tambuatco  writes:

how long something takes to compile


I have set my shell prompt with a timestamp for exactly this reason.  I 
have also seen someone who set it to reflect elapsed time since last 
command, instead.


But I guess maybe you are referring to inside Emacs / Orgmode?  I'm just 
throwing out a possible alternative.


Cheers,

TRS-80

Re: [ANN] Org-webring

[Brett Gilio]

Bastien  writes:

> Hi Brett,
>
> thanks for sharing this!  I had no chance yet to test this but it
> looks useful.  I added a link to https://orgmode.org/worg/org-tools/
>
> Best,

Hello Bastien,

Thank you for the addition! I appreciate your support.

Brett Gilio

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

[TRS-80]

First, I want to express my sincere and heart-felt gratitude to Carsten 
(and other contributors) for making and sharing this wonderful piece of 
software.  I have come to refer to it as "one of the gateway drugs to 
Emacs" (the other being Magit, IMHO).  It was certainly one of (if not 
/the/) main reason(s) why I started using Emacs initially.


I could in fact gush all day, however people are busy, so, on to the 
main issue...  :)


It seems to me that there is nothing really stopping me from inserting 
whatever value I like for value of "ID" Property.  Based on brief 
experimentation, org-store-link and org-insert-link seem to happily 
accept whatever value is already there (which I entered manually, for 
testing purposes).


However I seem to recall reading some warning somewhere about this, 
although I cannot seem to find it right now.


What I would like to do, is generate my own ID values in a more human 
readable format, something "ISO-like" for example "2020-09-10-1433" (as 
opposed to the default "uuid" method).  These sort of ID are still 
"Unique" (well, within my own system, anyway) as long as I am not 
generating them more often than once per minute[0].  And they have the 
advantages of being shorter, human readable, and meaningful.


Even when org-id-link-to-org-use-id and org-id-track-globally are both 
set to "t", org-id seems happy to insert my "ISO-like" ID right into the 
hash table and org-id-locations-file.


I do need the "across files" functionality.  My understanding is that 
this is main difference between ID and CUSTOM_ID (the latter being local 
only to the file).  Unless I am misunderstanding?


So, what am I missing here?  Any reason(s) /not/ to use my own custom ID 
value?


In addition to the general case, one particular area I am unsure about 
(as I have yet to get it working) is how this all works out with HTML 
export, as that is something I also wanted to get working at some point.


I tried studying some of the related sources (as well as mailing list 
archive), but could not seem to reach a conclusive answer.  I was hoping 
that some more knowledgeable people could confirm
whether this is a really bad idea, or not.  Any feedback would be 
greatly appreciated!


Cheers!

TRS-80

[0] It could easily be extended to second (or further) resolution, if 
needed.  For me, minute resolution will be fine.

How to replace secrets during org-babel tangle/export without loosing the reproductibility of original script ?

[rey-coyrehourcq]

Hi there, 

First thanks again guys for all the works you doing on org-mode !

I'm searching a way or an example of workflow for such a thing i consider as a 
common pattern for reproductibility
(reproductible papers in science for example).

For example, i'm starting writing a blog post with org-mode and org-babel to 
deploy, for example, a nixOS system on a
VPS. I wrote some bash scripts and a configuration.nix for nixOS which contains 
my gpg key, my vps password, and so
on... When everything works right, i'm ready to publish my full working 
tutorial on web.

BUT as you imagine, i don't want to share secrets/password ... 

- A first solution was to replace password by some "foo-bar" things, but doing 
that i lost all the reproductibility of
this script in the future ... so this is silly.

- A second solution, i suppose, was to dynamically choose if i want to replace 
or not password/secrets/etc by "foo-bar"
things during tangle/export of the script. 

Because i'm not an expert in org-babel headers (so much possibilities ...), if 
you have some ready to go template/script
to do that into org-babel, i'm interested !

Best !

-- 


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: [Announcement] New package ox-leanpub

[Diego Zamboni]

Hi Bastien,

Thanks! I agree it would be nice to have a comprehensive list of org
exporters in worg - although usually a search for "org export "
points in the correct direction :)

Best,
--Diego


On Thu, Sep 10, 2020 at 3:53 PM Bastien  wrote:

> Hi Diego,
>
> Diego Zamboni  writes:
>
> > I'm happy to announce that my package ox-leanpub is now available in
> > MELPA.
>
> I added a link to https://orgmode.org/worg/org-tools/
>
> Links to Org external exporters should perhaps have a dedicated
> section and/or page, especially if/when we will move some out of
> Org's core.
>
> Thanks for writing and sharing this!
>
> --
>  Bastien
>

Re: Bug: org-block face isn't applied to special blocks

[Sébastien Miquel]

Hi Bastien,

As far as I can tell, with 8a083514a7 from master, the situation is now 
as follows.


The org-block face is applied
 - to src blocks, when the language is recognized
 - to example, export blocks
 - to verse and quote blocks, if ~org-fontify-quote-and-verse-blocks~ 
is ~t~.


It isn't applied
 - to src blocks, when the language isn't recognized
 - to special blocks (that is, blocks with arbitrary names)


I make heavy use of special blocks and I'd like this face to apply to them.
I think it would make more sense than the current behavior, and is less 
surprising. (It is also more in line with the previous docstring).


(I also think it should apply to unrecognized src blocks)

Regards,
Sebastien




Hi Sébastien

Sébastien Miquel  writes:


Hi Bastien,

With latest org-mode master, and emacs -q,
run (defface org-block '((t (:background "#494949" :extend t))) "")
before loading org-mode,
then visit an org buffer containing the three following blocks.

When I do so, the org-block face only gets applied to the src block, and
not to the quote block, nor the special block.

Fixed in maint, as 7769518f3.  Thanks for the report again,

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

I'll keep researching and see if I can come up with anything.


This is particularly difficult.
When instrumenting `org-add-planning-info` with edebug the 
resulting timestamp always has its time portion (given and/or 
end-time) ignored.

Tried it with both my personal setup and emacs -q. No luck.
I'm more likely to hack around this than figure out a proper 
patch,
though I still consider it a bug that org-schedule is unable to be 
informed by org-time-given and org-end-time-given I originally 
described.

Re: bug#42484: org-mode should display value of links in mini-buffer

[Maxim Nikulin]

06.09.2020 21:18, Kévin Le Gouguec wrote:

Boruch Baum  writes:


In org-mode, when POINT is moved over an org-mode link, wouldn't it be
reasonable for the value of that link to appear in the mini-buffer? The
advantage of that is the user would know where the link points and what
would happen if the link is opened (eg. would an external program open,
would the network be queried).


That would be very welcome, IMO.  FWIW, markdown-mode does that (when
markup is hidden) using ElDoc; cf. markdown-eldoc-function.


There was a similar question in May. A message in the middle of that thread:
https://orgmode.org/list/CAJ51ETo0x=zrav7lfudvap7d2pz-duhzcrut+guby0slssw...@mail.gmail.com/

Re: idea for capture anywhere in x

[Maxim Nikulin]

09.09.2020 11:52, Maxim Nikulin wrote:


Capture templates allow calling of arbitrary lisp code, so you could 
take value from kill ring or call low level gui-get-selection function. 
The latter would allow separate templates for primary selection and for 
clipboard.


Today I have noticed that there are %c and %x substitutions for capture 
templates (thanks to the patch suggesting %L). With default preferences 
emacs listen to X clipboard and adds its contents to kill-ring, so 
current clipboard content is available as %c. %x at first tries primary 
selection. So there is no need to call gui-get-selection directly. By 
default both variants of selection are available through substitutions. 
If emacs is tuned to use primary selection, there is a compatibility 
function org-get-x-clipboard.

Re: [ANN] Org-webring

[Bastien]

Hi Brett,

thanks for sharing this!  I had no chance yet to test this but it
looks useful.  I added a link to https://orgmode.org/worg/org-tools/

Best,

-- 
 Bastien

Re: Reposting Elgantt announcement

[Bastien]

Hi Russell,

Russell Adams  writes:

> I saw a cool Org related project come up on Reddit, but no announcement
> here. This is a repost for community interest, I claim no credit.

I added a link in https://orgmode.org/worg/org-tools/

Thanks!

-- 
 Bastien

Re: [Announcement] New package ox-leanpub

[Bastien]

Hi Diego,

Diego Zamboni  writes:

> I'm happy to announce that my package ox-leanpub is now available in
> MELPA.

I added a link to https://orgmode.org/worg/org-tools/

Links to Org external exporters should perhaps have a dedicated
section and/or page, especially if/when we will move some out of
Org's core.

Thanks for writing and sharing this!

-- 
 Bastien

Re: New package: Org Pandoc Import

[Bastien]

Hi Timothy,

TEC  writes:

> I've just pushed the initial version of a package I think is pretty nifty (no
> bias here ;) and thought it might me nice to mention it to the mailing list.
>
> https://github.com/tecosaur/org-pandoc-import

I've added a note to https://sr.ht/~brettgilio/org-webring/

Thanks for sharing!

-- 
 Bastien

Re: Delay all occurences for a heading scheduled with repeater not work.

[Bastien]

Hi,

h...@protonmail.com writes:

> It says:
> "If you want to delay the display of this task in the agenda, use
> ‘SCHEDULED: <2004-12-25 Sat -2d>’: the task is still scheduled on the
> 25th but will appear two days later. In case the task contains a
> repeater, the delay is considered to affect all occurrences; if you
> want the delay to only affect the first scheduled occurrence of the
> task, use ‘--2d’ instead."
>
> With headings below:
> * delay in scheduled with repeater
> ** TODO delay all occurences
>SCHEDULED: <2020-01-30 Thu -1d +2d>
> ** TODO delay only the first occurence
>SCHEDULED: <2020-01-30 Thu --1d +2d>
>
> Both headings display in today's agenda (today is <2020-01-31>).
> Which is correct.
>
> Then both display in agenda of <2020-02-01>.
> Which is not correct for 'delay all occurences'.
> It should display in agenda of <2020-02-02>.
>
> Please help check if this should be fixed.

Just bumping up this thread to confirm the bug is still there.

-- 
 Bastien

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

[Bastien]

Hi Gustavo,

Gustavo Barros  writes:

> Thank you for keeping track of this.  But this issue is currently not
> affecting us any longer.

... and thanks for double-checking this.

> Some of the relevant messages are:
>
> - Kyle's message stating the commit was reverted, with the
>   corresponding   commit numbers:
>  https://orgmode.org/list/87o8rx1cmf@kyleam.com/
>
> - The issue whose fix caused this regression is mentioned at:
>   https://orgmode.org/list/87o8tim83q@kyleam.com/
>
> I think (not sure) that that issue is still pending.

It is still pending, I will mark it as pending - thanks!

-- 
 Bastien

Re: setting up 'imenu'

[Jeremie Juste]

Hello Sharon,

Unfortunately I cannot reproduce your issue. I created a list of 56 sub heading 
and I
can view the heading Still a sample 0 until Still a sample 56.


** TODO * etc and onwards
** TODO * and another one
** Still a sample 0
** Still a sample 1
** Still a sample 2
** Still a sample 3
** Still a sample 4

It might be because I am using [1] this  modification from  emacswiki
https://www.emacswiki.org/emacs/ImenuMode.

I another workflow comes to my mind when reading yours.
Instead of using "TODO * ..." I would use the TODO keywords and tell org-mode to
list all the todos.

For instance with the command M-x org-show-todo-tree.

A another way of working might be the following.

--- file - writings.org
#+TODO: TODO(t) TOWRITE(w) | DONE(d)

* TOWRITE This is article 1
* TOWRITE This is article 2
* DONE This is  article 2

#+begin_src elisp
   (org-agenda-file-to-front)
#+end_src
--- EOF

Add the file to the agenda ( by default C-[ ), or execute the lisp chunk
in the file writings.org. Then you can M-x org-todo-list. To view all
your todo|towrite|done articles.


Hope this help,
Jeremie

[1] ;; * imenu

(defun ido-goto-symbol ( symbol-list)
  "Refresh imenu and jump to a place in the buffer using Ido."
  (interactive)
  (unless (featurep 'imenu)
(require 'imenu nil t))
  (cond
   ((not symbol-list)
(let ((ido-mode ido-mode)
  (ido-enable-flex-matching
   (if (boundp 'ido-enable-flex-matching)
   ido-enable-flex-matching t))
  name-and-pos symbol-names position)
  (unless ido-mode
(ido-mode 1)
(setq ido-enable-flex-matching t))
  (while (progn
   (imenu--cleanup)
   (setq imenu--index-alist nil)
   (ido-goto-symbol (imenu--make-index-alist))
   (setq selected-symbol
 (ido-completing-read "Symbol? " symbol-names))
   (string= (car imenu--rescan-item) selected-symbol)))
  (unless (and (boundp 'mark-active) mark-active)
(push-mark nil t nil))
  (setq position (cdr (assoc selected-symbol name-and-pos)))
  (cond
   ((overlayp position)
(goto-char (overlay-start position)))
   (t
(goto-char position)
   ((listp symbol-list)
(dolist (symbol symbol-list)
  (let (name position)
(cond
 ((and (listp symbol) (imenu--subalist-p symbol))
  (ido-goto-symbol symbol))
 ((listp symbol)
  (setq name (car symbol))
  (setq position (cdr symbol)))
 ((stringp symbol)
  (setq name symbol)
  (setq position
(get-text-property 1 'org-imenu-marker symbol
(unless (or (null position) (null name)
(string= (car imenu--rescan-item) name))
  (add-to-list 'symbol-names name)
  (add-to-list 'name-and-pos (cons name position

(global-set-key (kbd "C-c i") 'ido-goto-symbol) ; or any key you see fit

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

[Gustavo Barros]

Hi Bastien,

On Thu, 10 Sep 2020 at 02:34, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:

As of recently, repeating tasks are no longer showing up in the 
agenda 
for future dates. Below a minimal example of the issue:


Just confirming this issue, to make sure we don't forget it.


Thank you for keeping track of this.  But this issue is currently not 
affecting us any longer.


If I recall correctly, the problem had emerged after a fix to another 
issue.  Kyle was able to identify the commit, and the discussion then 
converged to revert that commit, thus restoring the behavior which 
prompted this report of mine, until a fix for the other issue which did 
not cause this could be found.


Some of the relevant messages are:

- Kyle's message stating the commit was reverted, with the corresponding 
 commit numbers: https://orgmode.org/list/87o8rx1cmf@kyleam.com/


- The issue whose fix caused this regression is mentioned at: 
 https://orgmode.org/list/87o8tim83q@kyleam.com/


I think (not sure) that that issue is still pending.

Best,
Gustavo.

setting up 'imenu'

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


I'm having major problems with my imenu setup, and its like this.

- --8<---code one---start->8---
* Outlining and Plotting
  ** Level 2 heading
  ** etc and onwards
- --8<---cut here---end--->8---
  
- - 'Outlining and Plotting' is a level one header

- - 'Level 2 heading' is, not surprisingly, a level 2 header

Now, if the 'level 2 heading' has 50 items, it only actually shows 46
and does not show the remaining 4!

- --8<---code two---start->8---
* Outlining and Plotting
  ** Level 2 heading
  ** TODO * etc and onwards
  ** TODO * and another one
  ** Still a sample
- --8<---cut here---end--->8---

In the code snippet shown as 'code two', those showing as a 'TODO *
item' are articles that are unwritten, and all other items are written.

- - In the imenu it is very easy to see what articles are unwritten due to
  them showing with a beginning ' * '.

- - In the imenu unwritten articles show as 'From: * etc and onwards'
  where there are 10 or more items, they are folded.

So how can I get the imenu to show *all* the imenu items of written
articles please?

I've been looking in all the 'Customize group: imenu' buffers, but I
can't see where I can set it up as I want. Any ideas please?

Thanks
  Sharon.  
- -- 
Debian 10.5, fluxbox 1.3.7, emacs 27.1.50, org 9.3.7
-BEGIN PGP SIGNATURE-

iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAl9Z/+gbHGJvdWRpY2Nh
c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbiJsQAMP33tO8LSDTi/4/bxVb
rjA/eInifeHdgHGv10Jc+3/X4xzIGadv5JpN9ZtKEju1yp5PXcJWSQftnQSxqIQU
lLLx5uyMDZC7ZI2476aZZl3+KYhPaFaWnFs9JaPP+8zxff0WMrofw+YIGUzDdk4J
O9JIDNLH8/Lwsi7aNWdgM2guL3RlLuTsZzHaDPeC1dlp2zKEJY7/cA15EFp2MqGa
+RRbUYcGNUZLLqiLtZYdhIWzbEJNirj4ZuOQEKAYrfd3gChsILflwlwtwrCnDX/L
m4T62oftYC9a1xY8dS9G9rrJ9hn2Cy7fDV2vLK3q8gH4CrS66TTsiITv5rkYd2oR
frmncOM9dYwxjHvdpzA7/97NZkbsffNHvgolqLoUJDOZpA3/2N956OE+ewL8ZxFF
SzrH9ms4/XUcg2rHZizCNpovFmlJiyHFNEVBHg9iMe9FKFVvkXioEEY2Bt7ZEjvG
eg4G82OgP9INTspBVeMKl/j48iYP5Y6CqZvnzcKBxaqMfBIHlLDEs1s+wZERt9Ri
IEwQfO+/zU46dPQ4Ekf0vRxs5kp9ydSaF6H3zkn3yhpk0j5a+6JYOVvrEOvl0Vfb
iN8OoxkMMiCKXo5tSCXkV0pKt1HJm3RV8PFmK/GjLh39ePGA+nVZcUzXp4VwbM8H
QA1lWiy3oBWklRwnJKvpG/46
=oaoQ
-END PGP SIGNATURE-

Re: org-babel prepends <> expansions with the prefix of the <>? Can this be turned off?

[Vladimir Nikishkin]

Hello, Bastien,

Thanks for getting back to me.
In ob-core.el, function org-babel-expand-noweb-references, line 2747,
there is a 'mapconcat, that is commented as ";; Interpose PREFIX
between every line."
It prepends the "prefix", that is the content of the block to be
expanded from the beginning of the line where a <> reference is
encountered to the beginning of the reference itself, that is to the
first "<".

My point is that this is not the most obvious way to do the expansion.
It does work if the "prefix" is a line comment character, similar to C++ "//"

However, consider the following example:

```
# -*- mode: org; -*-

* test
  :PROPERTIES:
  :header-args::noweb yes
  :END:

#+name: block1
#+begin_src shell
printf "test1 \n"
printf "test2 \n"
printf "test3 \n"

#+end_src

#+begin_src shell :shebang "#!/bin/chibi-scheme"
#<> <>

#+end_src
```

Expanding this example gives:

```
#printf "test1 \n"
#printf "test2 \n"
#printf "test3 \n"
# printf "test1 \n"
#<> printf "test2 \n"
#<> printf "test3 \n"
#<>
```

Not a very obvious interpretation!
At least I would expect the following instead:

```
#printf "test1 \n"
printf "test2 \n"
printf "test3 \n" printf "test1 \n"
printf "test2 \n"
printf "test3 \n"
```

Because at least it wouldn't leave anything resembling a "<>"
block in the expansion result.

Thanks for looking at this issue.

Vlad

On Mon, 7 Sep 2020 at 12:33, Bastien  wrote:
>
> Hi Vladimir,
>
> Vladimir Nikishkin  writes:
>
> > That's not entirely what I want.
>
> What do you want instead?  It's not clear to me from your example.
>
> Thanks,
>
> --
>  Bastien



-- 
Yours sincerely, Vladimir Nikishkin

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

>> You are right. I missed that \\ is also a newline for LaTeX export.
>
> It is a line break in any export back-end.

I did not know this and I cannot find any reference about such behaviour
in manual (info:org#Markup for Rich Contents).

>> However, it is unused it unordered lists. We might define a note as a
>> unnumbered list item with [@note]:
>>
>> - [@note] This is note
>
> That's a reasonable syntax extension, maybe too English-centered. Maybe
> a more abstract [@!] would be better.

It also looks better for me.
Should I open separate bug report proposing this syntax extension?

>> In addition, all the list items in :LOGBOOK: drawer may be considered
>> notes (to avoid a need to change the current format of the
>> automatically added notes).
>
> Notes are not necessary stuffed into a LOGBOOK drawer, or even into
> a drawer at all. Besides, LOGBOOK is a common word, and it is not
> unreasonable to think some user could have used it for other purposes.
>
> Old notes are going to be incompatible (as in ignored by any tool
> processing notes, not invalid markup) with the new ones. I don't think
> there's a way to eschew it. It doesn't seem to be a big deal, however,
> as you don't lose anything by keeping notes in old syntax around.

That said, if we decide about the new syntax, it might be a good idea to
provide command converting items inside LOGBOOK drawers into notes.

Best,
Ihor

Nicolas Goaziou  writes:

> Hello,
>
> Ihor Radchenko  writes:
>
>> You are right. I missed that \\ is also a newline for LaTeX export.
>
> It is a line break in any export back-end.
>
>> Another possibility is re-purposing counter definition from ordered
>> lists. Currently the "\\[@[0-9]+\\]" is used to force item number in
>> ordered lists:
>>
>> 1. item
>> 5. [@5] another item
>> 6. next item
>>
>> However, it is unused it unordered lists. We might define a note as a
>> unnumbered list item with [@note]:
>>
>> - [@note] This is note
>
> That's a reasonable syntax extension, maybe too English-centered. Maybe
> a more abstract [@!] would be better.
>
>> In addition, all the list items in :LOGBOOK: drawer may be considered
>> notes (to avoid a need to change the current format of the
>> automatically added notes).
>
> Notes are not necessary stuffed into a LOGBOOK drawer, or even into
> a drawer at all. Besides, LOGBOOK is a common word, and it is not
> unreasonable to think some user could have used it for other purposes.
>
> Old notes are going to be incompatible (as in ignored by any tool
> processing notes, not invalid markup) with the new ones. I don't think
> there's a way to eschew it. It doesn't seem to be a big deal, however,
> as you don't lose anything by keeping notes in old syntax around.
>
> Regards,
> -- 
> Nicolas Goaziou

Re: Bug: Source code blocks no longer natively fontified [9.3.7 (release_9.3.7-802-g9f0af6 @ /home/nicolas/.config/emacs/straight/build/org-plus-contrib/)]

[Bastien]

Hi Nicolas,

Nicolas De Jaeghere  writes:

> As of commit 7769518f3, source code blocks are no longer natively
> fontified when org-src-fontify-natively is set to t.

Fixed, thanks. 

The original "bug" I was trying to fix with 7769518f3 seems like a
documentation bug, so I enhanced the docstring of the `org-block'
face.

Thanks,

-- 
 Bastien

Bug: Source code blocks no longer natively fontified [9.3.7 (release_9.3.7-802-g9f0af6 @ /home/nicolas/.config/emacs/straight/build/org-plus-contrib/)]

[Nicolas De Jaeghere]

As of commit 7769518f3, source code blocks are no longer natively
fontified when org-src-fontify-natively is set to t.

To reproduce, create an org-mode buffer and insert:

#+BEGIN_SRC emacs-lisp
  (setq foo 'foo)
#+END_SRC

Expected: setq is fontified according to font-lock-keyword-face. Actual:
setq is fontified according to org-block.

Unfortunately I can't think of anything else worth mentioning. Thank you
in advance.

Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, 
cairo version 1.17.3)
 of 2020-08-28
Package: Org mode version 9.3.7 (release_9.3.7-802-g9f0af6 @ 
/home/nicolas/.config/emacs/straight/build/org-plus-contrib/)


-- 
Nicolas De Jaeghere

Re: org-babel opens the error output of a block in a separate window... unless :stdin is given, but how are they connected?

[Vladimir Nikishkin]

I don't know how to debug this.
The *Org-Babel Error Output* emerges when the control flow returns
from the following sexp:
(org-babel-execute-src-block
current-prefix-arg (org-babel-get-src-block-info nil context))

It is line 17862 in the org.el

I do not understand what causes its appearance, because while the
execution continues inside the org-babel-execute-src-block, no
expression creates this buffer. I don't know "what" to instrument to
debug this behaviour.

>The example above does not work for me.  Can you provide another one?

I do have another example that is "almost" the same and does not
involve chibi-scheme.

```
# -*- mode:org; -*-
#+name: empty
#+begin_quote
1
#+end_quote

#+begin_src shell :stdin empty
printf "test\n" 1>&2
#+end_src
```

Compare the evaluation of the second block with and without the ":stdin empty".
On my machine, if no ":stdin empty" is present, the block produces no
output when C-c'd (which, I guess, is expected), since the output is
empty.
However, add ":stdin empty". The line ": test" magically appears after
the #+RESULTS: , although I suspect that it shouldn't, as "test" is
printed to the standard error, not standard output.

Apparently, adding ":stdin" somehow magically switches org from "print
code's standard output in the #+results and process errors as if they
are errors in a separate buffer if the return value is not 0" to "just
print whatever the program prints on the console, regardless of
whether it is standard output or standard error after the #+results:
line".

Hope this helps.

Added later:

I actually found that the way the script is evaluated is totally
different in the presence and in the absence of :stdin.
The line 213 of ob-shell.el checks for "(or stdin cmdline)", and the
evaluation goes into two independent routes, and does not even get
evaluated with org-babel-eval.
(org-babel-eval) is the actual function that creates the error window,
and if :stdin is not given, control flow doesn't even use this
function.

So my question, perhaps, would be "would it be possible to modify
org-babel-sh-evaluate" so that only one function be used for code
evaluation? Perhaps the one that is used with the (or stdin cmdline)
route, as it seems more functional (and can be forced by setting
:stdin to an empty block name).

Vlad

On Mon, 7 Sep 2020 at 12:32, Bastien  wrote:
>
> Hi Vladimir,
>
> Vladimir Nikishkin  writes:
>
> > #+name: empty
> > #+begin_quote
> >
> > 1
> > #+end_quote
> >
> > #+begin_src shell :shebang "#! /usr/bin/chibi-scheme :stdin empty
> > (/ 1 0)
> > #+end_src
>
> The example above does not work for me.  Can you provide another one?
>
> > Now the chibi-scheme shebang is just an example of an app writing
> > things to stderr. The actual content of the <> doesn't matter,
> > the app errs before ever having a chance to read anything from stdin.
> >
> > However, when :stdin is given (as in the MWE), the resulting error
> > output is printed in the :RESULTS , and if not, it is displayed in a
> > separate (a bit annoying) window called "*Org-Babel Error Output*.
> >
> > I would like to ask how these two things, stdin, and stderr are
> > connected. Perhaps, this is a bug?
>
> I don't know but perhaps you can instrument the relevant functions in
> ob-shell.el and see what going on, if you still have this issue?
>
> Thanks,
>
> --
>  Bastien



-- 
Yours sincerely, Vladimir Nikishkin

Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value?

[Tim Cross]

Vladimir Nikishkin  writes:

> So, my point is the following. A shebang is an almost universally
> accepted way to specify which interpreter should be used for code
> evaluation.
>
> In the ob-core.el, at line 787, the function called
> org-babel-expand-src-block makes a buffer out of the noweb-expanded
> code.
> (I am working with org 20200907)
>
> The sexp is looking like this:
>
> (org-edit-src-code
>  expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*"))
>
> I suggest replacing this sexp with
>
> (org-edit-src-code
>  (seq-concatenate 'string (or (alist-get :shebang params) "") "\n"
> expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang "
> ]*"))
>
> This way the expanded buffer would respect the shebang, and the
> resulting buffer would be saveable as a runnable file.
>
> I suspect that the second branch of the (if) should be left as it is,
> because non-interactive usage probably means that the code will be
> used later as a part of something, and therefore does not need a
> shebang.
>
> Vlad
>

I'm not sure about this one.

- I often have multiple src blocks which make up one final script once
  tangled. When editing these blocks, I don't want a shebang line for
  each of them.

- Would this work with different shells? I write scripts in multiple
  shell dialects e.g. bash, sh, zsh, ksh etc. Will this add the correct
  shebang?

- Which form of shebang e.g #!/bin/ or #!/usr/bin/env ?

The only thing worse than having to add the shebang manually is having
to remember to remove/change it when not needed :)

Perhaps this could be a user configurable option that you can turn on if
you want it rather than a default action?

-- 
Tim Cross

Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value?

[Vladimir Nikishkin]

Well, why exactly Racket people decided to introduce the #lang
directive in such a way that it looks like a shell comment or a
shebang line seems to elude my understanding.
(declare :lang 'whatever), at least to me, seems much more lispy, and
even (read) able by a standard reader (which could later be switched
to a different mode).

>because the shebang line will not actually be included when executing the code

How so? I never had problems using shebangs in my code. They seem to
be prepended to the autogenerated files in /tmp/org-* just fine (in
some other function).


>due to the addition of a prologue section

When does this happen? :prologue seems to be already included in the
'expanded variable.

>It also becomes necessary to remove the shebang line from the edit buffer

C-c C-v C-v does not make an edit buffer. It expands the buffer for a
preview. I never suggested to prepend a shebang to the C-' buffer. In
fact, saving the C-c C-v C-v buffer is the only reasonable thing you
can do to it. Editing it makes no direct sense, because expansion is a
many-to-one process, and you cannot "unexpand" the buffer (without
evil diff trickery at least).

>the need to keep what will be run by org babel in line

This actually _is_ about keeping the two things in line. When
evaluating a noweb-enabled block, and in fact, any block, org already
prepends the :shebang value. I'm just suggesting to make the preview
consistent


On Thu, 10 Sep 2020 at 15:11, Tom Gillespie  wrote:
>
> Hi Vladimir,
>I have encountered similar issues with wanting to have a racket
> #lang line included in a tangled block while also allowing org to know
> exactly which #lang it is working with. I haven't found a good
> solution. One issue with embedding the shebang when editing a buffer
> is that it is very likely to cause confusion because the shebang line
> will not actually be included when executing the code, or if it was
> included then there is a reasonable possibility that in some cases it
> would not be included as the first line due to the addition of a
> prologue section. It also becomes necessary to remove the shebang line
> from the edit buffer, which means you have to know which shebang lines
> were added automatically and which were not. Further, the need to keep
> what will be run by org babel in line with what is shown via these
> various views makes it seem unlikely that this should be implemented
> as default behavior. I have a long email that touches on these issues
> in the works for after the 9.4 release, so thank you for providing an
> excellent example. It seems like one possible solution for your
> workflow would be to advise org-babel-expand-src-block to insert the
> shebang. Best,
> Tom
>
> On Wed, Sep 9, 2020 at 11:53 PM Vladimir Nikishkin  
> wrote:
> >
> > So, my point is the following. A shebang is an almost universally
> > accepted way to specify which interpreter should be used for code
> > evaluation.
> >
> > In the ob-core.el, at line 787, the function called
> > org-babel-expand-src-block makes a buffer out of the noweb-expanded
> > code.
> > (I am working with org 20200907)
> >
> > The sexp is looking like this:
> >
> > (org-edit-src-code
> >  expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*"))
> >
> > I suggest replacing this sexp with
> >
> > (org-edit-src-code
> >  (seq-concatenate 'string (or (alist-get :shebang params) "") "\n"
> > expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang "
> > ]*"))
> >
> > This way the expanded buffer would respect the shebang, and the
> > resulting buffer would be saveable as a runnable file.
> >
> > I suspect that the second branch of the (if) should be left as it is,
> > because non-interactive usage probably means that the code will be
> > used later as a part of something, and therefore does not need a
> > shebang.
> >
> > Vlad
> >
> > On Sat, 5 Sep 2020 at 15:13, Bastien  wrote:
> > >
> > > Vladimir Nikishkin  writes:
> > >
> > > > I'll try to do one this week, but I can't submit a patch officially
> > > > because of my employer being staunchly against signing the copyright
> > > > disclaimer.
> > >
> > > :/
> > >
> > > So please just give directions on what to modify and how, and that'd
> > > be enough for someone (probably me) to get started.
> > >
> > > Thanks!
> > >
> > > --
> > >  Bastien
> >
> >
> >
> > --
> > Yours sincerely, Vladimir Nikishkin
> >



-- 
Yours sincerely, Vladimir Nikishkin

Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value?

[Tom Gillespie]

Hi Vladimir,
   I have encountered similar issues with wanting to have a racket
#lang line included in a tangled block while also allowing org to know
exactly which #lang it is working with. I haven't found a good
solution. One issue with embedding the shebang when editing a buffer
is that it is very likely to cause confusion because the shebang line
will not actually be included when executing the code, or if it was
included then there is a reasonable possibility that in some cases it
would not be included as the first line due to the addition of a
prologue section. It also becomes necessary to remove the shebang line
from the edit buffer, which means you have to know which shebang lines
were added automatically and which were not. Further, the need to keep
what will be run by org babel in line with what is shown via these
various views makes it seem unlikely that this should be implemented
as default behavior. I have a long email that touches on these issues
in the works for after the 9.4 release, so thank you for providing an
excellent example. It seems like one possible solution for your
workflow would be to advise org-babel-expand-src-block to insert the
shebang. Best,
Tom

On Wed, Sep 9, 2020 at 11:53 PM Vladimir Nikishkin  wrote:
>
> So, my point is the following. A shebang is an almost universally
> accepted way to specify which interpreter should be used for code
> evaluation.
>
> In the ob-core.el, at line 787, the function called
> org-babel-expand-src-block makes a buffer out of the noweb-expanded
> code.
> (I am working with org 20200907)
>
> The sexp is looking like this:
>
> (org-edit-src-code
>  expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*"))
>
> I suggest replacing this sexp with
>
> (org-edit-src-code
>  (seq-concatenate 'string (or (alist-get :shebang params) "") "\n"
> expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang "
> ]*"))
>
> This way the expanded buffer would respect the shebang, and the
> resulting buffer would be saveable as a runnable file.
>
> I suspect that the second branch of the (if) should be left as it is,
> because non-interactive usage probably means that the code will be
> used later as a part of something, and therefore does not need a
> shebang.
>
> Vlad
>
> On Sat, 5 Sep 2020 at 15:13, Bastien  wrote:
> >
> > Vladimir Nikishkin  writes:
> >
> > > I'll try to do one this week, but I can't submit a patch officially
> > > because of my employer being staunchly against signing the copyright
> > > disclaimer.
> >
> > :/
> >
> > So please just give directions on what to modify and how, and that'd
> > be enough for someone (probably me) to get started.
> >
> > Thanks!
> >
> > --
> >  Bastien
>
>
>
> --
> Yours sincerely, Vladimir Nikishkin
>

Re: Bug: ob-shell cannot forward empty blocks to stdin [9.3.1 (release_9.3.1-101-gc9ee3d @ /home/lockywolf/OfficialRepos/org-mode/lisp/)]

[Vladimir Nikishkin]

It still behaves as described.

Let me describe it in more detail:

suppose you have the following file

```
# -*- mode:org; -*-

#+name: empty
#+begin_quote
#+end_quote

#+begin_src shell :stdin empty
#+end_src
```

the #+end_src line should be the line number 8 in the file.
Place the point at the very beginning of line 8. This way the point is
_inside_ the code block, even though the block itself has length 0.
Type C-c C-c. Observe an error in the echo area.
The stack trace is the following:

```
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  buffer-substring-no-properties(nil nil)
  (org-remove-indentation (buffer-substring-no-properties
(org-element-property :contents-begin element) (org-element-property
:contents-end element)))
  (cond ((eq val 'fixed-width) (let ((v (org-trim
(org-element-property :value element (or
(org-babel--string-to-number v) v))) ((eq val 'table)
(org-babel-read-table)) ((eq val 'plain-list) (org-babel-read-list))
((eq val 'example-block) (let ((v (org-element-property :value
element))) (if (or org-src-preserve-indentation (org-element-property
:preserve-indent element)) v (org-remove-indentation v ((eq val
'export-block) (org-remove-indentation (org-element-property :value
element))) ((eq val 'paragraph) (skip-chars-forward " \11") (if (and
(looking-at org-link-bracket-re) (save-excursion (goto-char (match-end
0)) (skip-chars-forward " \15\11\n") (<= (org-element-property :end
element) (point (org-babel-read-link)
(buffer-substring-no-properties (org-element-property :contents-begin
element) (org-element-property :contents-end element ((pcase--flip
memq '(special-block verse-block quote-block center-block) val)
(org-remove-indentation (buffer-substring-no-properties
(org-element-property :contents-begin element) (org-element-property
:contents-end element (t nil))
  (let* ((val (org-element-type element))) (cond ((eq val
'fixed-width) (let ((v (org-trim (org-element-property :value
element (or (org-babel--string-to-number v) v))) ((eq val 'table)
(org-babel-read-table)) ((eq val 'plain-list) (org-babel-read-list))
((eq val 'example-block) (let ((v (org-element-property :value
element))) (if (or org-src-preserve-indentation (org-element-property
:preserve-indent element)) v (org-remove-indentation v ((eq val
'export-block) (org-remove-indentation (org-element-property :value
element))) ((eq val 'paragraph) (skip-chars-forward " \11") (if (and
(looking-at org-link-bracket-re) (save-excursion (goto-char (match-end
0)) (skip-chars-forward " \15\11\n") (<= (org-element-property :end
element) (point (org-babel-read-link)
(buffer-substring-no-properties (org-element-property :contents-begin
element) (org-element-property :contents-end element ((pcase--flip
memq '(special-block verse-block quote-block center-block) val)
(org-remove-indentation (buffer-substring-no-properties
(org-element-property :contents-begin element) (org-element-property
:contents-end element (t nil)))
  (pcase (org-element-type element) (`fixed-width (let ((v (org-trim
(org-element-property :value element (or
(org-babel--string-to-number v) v))) (`table (org-babel-read-table))
(`plain-list (org-babel-read-list)) (`example-block (let ((v
(org-element-property :value element))) (if (or
org-src-preserve-indentation (org-element-property :preserve-indent
element)) v (org-remove-indentation v (`export-block
(org-remove-indentation (org-element-property :value element)))
(`paragraph (skip-chars-forward " \11") (if (and (looking-at
org-link-bracket-re) (save-excursion (goto-char (match-end 0))
(skip-chars-forward " \15\11\n") (<= (org-element-property :end
element) (point (org-babel-read-link)
(buffer-substring-no-properties (org-element-property :contents-begin
element) (org-element-property :contents-end element ((or
`center-block `quote-block `verse-block `special-block)
(org-remove-indentation (buffer-substring-no-properties
(org-element-property :contents-begin element) (org-element-property
:contents-end element (_ nil))
  (save-restriction (widen) (goto-char (org-element-property
:post-affiliated element)) (pcase (org-element-type element)
(`fixed-width (let ((v (org-trim (org-element-property :value
element (or (org-babel--string-to-number v) v))) (`table
(org-babel-read-table)) (`plain-list (org-babel-read-list))
(`example-block (let ((v (org-element-property :value element))) (if
(or org-src-preserve-indentation (org-element-property
:preserve-indent element)) v (org-remove-indentation v
(`export-block (org-remove-indentation (org-element-property :value
element))) (`paragraph (skip-chars-forward " \11") (if (and
(looking-at org-link-bracket-re) (save-excursion (goto-char (match-end
0)) (skip-chars-forward " \15\11\n") (<= (org-element-property :end
element) (point (org-babel-read-link)
(buffer-substring-no-properties (org-element-property :contents-begin
element) (org-element-property :contents-end 

Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value?

[Vladimir Nikishkin]

So, my point is the following. A shebang is an almost universally
accepted way to specify which interpreter should be used for code
evaluation.

In the ob-core.el, at line 787, the function called
org-babel-expand-src-block makes a buffer out of the noweb-expanded
code.
(I am working with org 20200907)

The sexp is looking like this:

(org-edit-src-code
 expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*"))

I suggest replacing this sexp with

(org-edit-src-code
 (seq-concatenate 'string (or (alist-get :shebang params) "") "\n"
expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang "
]*"))

This way the expanded buffer would respect the shebang, and the
resulting buffer would be saveable as a runnable file.

I suspect that the second branch of the (if) should be left as it is,
because non-interactive usage probably means that the code will be
used later as a part of something, and therefore does not need a
shebang.

Vlad

On Sat, 5 Sep 2020 at 15:13, Bastien  wrote:
>
> Vladimir Nikishkin  writes:
>
> > I'll try to do one this week, but I can't submit a patch officially
> > because of my employer being staunchly against signing the copyright
> > disclaimer.
>
> :/
>
> So please just give directions on what to modify and how, and that'd
> be enough for someone (probably me) to get started.
>
> Thanks!
>
> --
>  Bastien



-- 
Yours sincerely, Vladimir Nikishkin

Check for master branch from Elisp (was: Release 9.3.8)

[Kévin Le Gouguec]

Kyle Meyer  writes:

> Can't you inspect the return value of org-git-version?

That can work out, though unless I'm missing something, I need to move
to the org-mode repository, ask "git branch --contains", and parse the
output.  Possible, but somewhat involved.

(TIL: git-describe's "{tag}-{nbcommits}-g{hash}" is actually a valid
revision format that other Git commands understand.)


For the sake of completeness, I've tried visiting org.el and evaluating

(package-desc-version (package-buffer-info))

but package-buffer-info ends up calling (version-to-list "9.4-dev"),
which chokes on "-dev".  FWIW, that can be worked around with:

(add-to-list 'version-regexp-alist (cons "^-dev$" -1))

> (Though in my
> view, distinguishing based on the functionality present with things like
> fboundp, which you mention below, is typically a better approach, if
> possible.)

Right, that's my conclusion as well :)