Re: [PATCH] x11idle: Make installation a little smoother

[Kyle Meyer]

Adam Spiers writes:

> Fix a -Wimplicit-int compiler warning, and make it more obvious how to
> obtain scrnsaver.h on three of the most popular Linux distros.

Thanks, sounds good.

Note that commits in the Org repo typically follow the Emacs convention
of including a changelog-like entry.  But that doesn't matter for this
case because it's contrib/ (which, by the way, is slated for removal
from this repo: ).

> Signed-off-by: Adam Spiers 

That doesn't carry any meaning in this project :)

Pushed (2b3bbf361).

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Kyle Meyer]

吴锐扬 writes:

> The author explained his motivation for the commit in the mailing list before 
> it got applied:
>
>> That's because lob calls get wrapped internally in an anonymous
>> emacs-lisp source block that then feeds through the result from the
>> actual call as elisp.  The attached patch should suppress the
>> confirmation for the wrapper call.  To the best of my knowledge nothing
>> dangerous can happen with that evaluation and all confirmations for the
>> call stack down from there have already taken place according to the
>> users' setup.

Just for reference: it looks like that's

  https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid

> If I understand correctly, executing a lob call would trigger two user
> confirmations in the past, and this commit was meant to suppress one
> of the two confirmations. (I may be wrong since I am a fairly new user
> of org mode.)

Thanks for digging.  Indeed, if you go back to the parent of 56bf3d789
(Babel: avoid superfluous confirmation for internal wrapper,
2013-04-10), there are two queries.  On that commit, there is one.

> Now there is no confirmation at all. IMHO, there should be exactly
> one confirmation ideally.

It looks like the query went away with dbb375fdf (Simplify Babel calls
evaluation, 2016-06-16), which was included in the 9.0 release.  Based
on a quick glance at that commit, I don't think that was an intentional
change.

I won't take a closer look at this until at least this weekend, though.
I'd be very happy if someone beat me to it.

Re: Default fold state of property drawers?

[Kyle Meyer]

Gustav Wikström writes:

> Hi,
>
> This may be a stupid question but I didn't find anything conclusive in
> the manual or online after a (albeit fairly quick) scan.
>
> Is there currently a way to declare that property drawers (and the
> file level property drawer in particular) should be hidden when
> opening a new Org file, no matter the startup keyword setting? I.e is
> it possible to control the open/closed state of the property drawer
> separate from the outline folding?

I may be missing something too, but I'm not aware of a way to do this
that's distinct from setting org-startup-folded and friends.  But
doesn't org-startup-folded's showall/showeverything distinction cover
your usecase?

Re: Proposal: do not align tags in Agenda

[Kyle Meyer]

Michaël Cadilhac writes:

> My problem wasn't at all, as you point out, that the tag would erase the 
> entry.
>
> It has to do with habits: The habit graph overwrites anything else.  I
> like having org-agenda-tags-column to a low value (wide screen), but
> tags are crucial to my workflow, so them being overwritten is
> problematic.
>
> My previous patch is completely overkill for that purpose (it's even
> misguided since it does stem from a misunderstanding of tags
> alignment).  Here's a simpler patch.  It may be a matter of taste,
> though.

I see (and sorry for the slow reply).  I've never used habits, but that
does sound good to avoid.  Would you mind 1) wrapping the change below
into a patch (see ) and 2)
providing a minimal example like the one in my last reply so that
reviewers have something to quickly test?

No Wayman, I see that you replied [1] that your patch at
 would allow working
around this issue [2], but do you still think the change below is a good
idea?  Thanks.


  [1] Note that it's detached from this thread because the References
  and In-Reply-To headers weren't preserved.

  [2] Sorry that that patch hasn't gotten any attention yet.

> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index e4a334dbd..a80123853 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -9080,6 +9080,10 @@ current line."
>   (goto-char (match-beginning 1))
>   (delete-region (save-excursion (skip-chars-backward " \t") (point))
>  (point))
> + (when (get-text-property (point) 'org-habit-p)
> +   (setq c (max c (+ 1 org-habit-graph-column
> + org-habit-preceding-days
> + org-habit-following-days

I haven't applied this to check, but I suspect you'll need some amount
of guarding (e.g. with boundp) to silence the byte-compiler here.

>   (insert (org-add-props
>   (make-string (max 1 (- c (current-column))) ?\s)
>   (plist-put (copy-sequence (text-properties-at (point)))

Re: org-marker vs. org-hd-marker

[Kyle Meyer]

Michael Heerdegen writes:

> Do you know whether I can assume that one of those is always present
> (org-marker probably, since org-hd-marker is not always present) when
> examining the result of `org-agenda-get-day-entries'?  I don't care
> about the exact location in an entry.

Going through each of the collection functions at the end of
org-agenda-get-day-entries, it looks like they all set org-marker.
Plus, I can spot places in org-agenda.el that rely on agenda entries
having org-marker (e.g., org-agenda-goto and org-agenda-todo), so I
think that assumption would be safe.

Re: [PATCH] change the ob-java default back to scripting mode

[Kyle Meyer]

ian martins writes:

> Subject: [PATCH] ob-java.el: Change the default back to scripting mode
>
> * lisp/ob-java.el: Change the default to scripting mode.  Add name to
> authors.

The changelog entry should explicitly list the variables/functions that
are modified.  So in this case

* lisp/ob-java.el (org-babel-default-header-args:java): ...

> A recent commit added functional mode and made it default, but this
> would break java source blocks for anyone that relied on the old
> default.  This sets the default back to scripting mode.

Thanks for restoring the behavior.

> I missed a name when I put the authors of ob-C and ob-python as the
> authors of ob-java.  Added it.

Please move this unrelated change to a separate commit.

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[吴锐扬]

The author explained his motivation for the commit in the mailing list before 
it got applied:

> That's because lob calls get wrapped internally in an anonymous
> emacs-lisp source block that then feeds through the result from the
> actual call as elisp.  The attached patch should suppress the
> confirmation for the wrapper call.  To the best of my knowledge nothing
> dangerous can happen with that evaluation and all confirmations for the
> call stack down from there have already taken place according to the
> users' setup.

If I understand correctly, executing a lob call would trigger two user 
confirmations in the past, and this commit was meant to suppress one of the two 
confirmations. (I may be wrong since I am a fairly new user of org mode.) Now 
there is no confirmation at all. IMHO, there should be exactly one confirmation 
ideally.

But you are right, I should just copy the author on this.

Thanks,
Ruiyang

> On Oct 28, 2020, at 10:26 AM, Berry, Charles  wrote:
> 
> FWIW, it doesn't seem like an accident. You might ping the author of this 
> commit:
> 
> $ git log -S "(let (org-confirm-babel-evaluate)"
> commit 56bf3d789146fcd3c9f82d875de28c394fe593a0
> Author: Achim Gratz 
> Date:   Wed Apr 10 20:28:31 2013 +0200
> 
>Babel: avoid superfluous confirmation for internal wrapper
> 
>* lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation
>  of the emacs-lisp wrapper execution around a lob call.
> 
>* lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation
>  of the emacs-lisp wrapper execution around a lob call.
> 
> 
> 
> HTH,
> 
> Chuck
> 
>> On Oct 28, 2020, at 4:32 AM, Eric S Fraga  wrote:
>> 
>> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
>>> I have org-confirm-babel-evaluate set to t by default. With this, I
>>> expect to be queried with the execution of every code block or lob
>>> call. However, this does not happen when exporting lob calls (to latex
>>> for example). Here is an example:
>> 
>> Confirmed with fairly recent org from git with
>> org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
>> doesn't bother me much as I don't export org files that I haven't
>> created myself but it does appear to be a hole.
>> 
>> -- 
>> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
>> 
>> 
> 

[PATCH] New "project" option for org-link-file-path-type

[Jack Kamm]

The attached patch adds a "project" option for org-link-file-path-type.

When this is set, links to files under the current project root will be
relative, while links elsewhere are absolute.

It relies on project.el, which appears to have been added in emacs 25. I
used fboundp to check whether the functionality is available, and to
silence compiler warnings. I'm not sure if this is the correct way to do
it.

>From c5f9d4043a6cf6a325d122be24214356f36446f1 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Wed, 28 Oct 2020 17:29:04 -0700
Subject: [PATCH] ol.el: New option "project" for org-link-file-path-type

* lisp/ol.el (org-link-file-path-type): Add new option.
(org-insert-link): Handle project option for org-link-file-path-type.
---
 etc/ORG-NEWS |  8 
 lisp/ol.el   | 17 +++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7f935bf52..b9adc9089 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -88,6 +88,14 @@ package, to convert pandas Dataframes into orgmode tables:
 | 2 | 3 | 6 |
 #+end_src
 
+*** New option to use relative paths for links in same project
+
+If =org-link-file-path-type= is =project=, inserted links under the
+current project root will use relative paths.
+
+If not in a project, or if =project.el= is not available (as in older
+versions of Emacs), links behave as default (=adaptive=).
+
 * Version 9.4
 ** Incompatible changes
 *** Possibly broken internal file links: please check and fix
diff --git a/lisp/ol.el b/lisp/ol.el
index 951bb74e7..9c48bd9b5 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -212,13 +212,17 @@ (defcustom org-link-file-path-type 'adaptive
 absolute  Absolute path, if possible with ~ for home directory.
 noabbrev  Absolute path, no abbreviation of home directory.
 adaptive  Use relative path for files in the current directory and sub-
-  directories of it.  For other files, use an absolute path."
+  directories of it.  For other files, use an absolute path.
+project   Use relative path for files in the current project and sub-
+  directories of it. For other files, usue an absolute path.
+  If project.el is not available, behave as adaptive."
   :group 'org-link
   :type '(choice
 	  (const relative)
 	  (const absolute)
 	  (const noabbrev)
-	  (const adaptive))
+	  (const adaptive)
+	  (const project))
   :safe #'symbolp)
 
 (defcustom org-link-abbrev-alist nil
@@ -1876,6 +1880,15 @@ (defun org-insert-link ( complete-file link-location description)
 	(setq path (expand-file-name path)))
 	   ((eq org-link-file-path-type 'relative)
 	(setq path (file-relative-name path)))
+	   ((and (fboundp 'project-current)
+		 (fboundp 'project-root)
+		 (project-current)
+		 (eq org-link-file-path-type 'project))
+	(if (string-prefix-p (expand-file-name (project-root
+		(project-current)))
+ (expand-file-name path))
+		(setq path (file-relative-name path))
+	  (setq path (abbreviate-file-name (expand-file-name path)
 	   (t
 	(save-match-data
 	  (if (string-match (concat "^" (regexp-quote
-- 
2.29.1

Re: New website - back to the old unicorn!

[TEC]

Hi Stefan,

This seems very suspicious for one reason. I cannot see "Canvas"
anywhere in the entire codebase of the website, or any loaded 
resources.
So I have no idea where on earth the JS you're finding has come 
from -
I'm guessing it's improperly injected by a extension. FWIW I also 
run

Decentraleyes in Firefox and fail to see your issue.

--
Timothy

Stefan Nobis  writes:


Hi.

Thanks for your great work and the wonderful new page!

A minor detail: I use the plugin "Decentraleyes" and with this
activated there is quite a bit JavaScript garbage at the end of 
the
page (below the "Created by" footer). The part below the footer 
is

this:

#+begin_src js
{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }

#+end_src

When I deactivate Decentraleyes and reload the page, the above 
code
snippet vanishes. This glitch is present both on the official 
page and

on https://orgmode.tecosaur.com. It seems, there is some weird
interaction with some script from a CDN (maybe loaded partially 
due to

constraints from the plugin) or something like that.

Re: New website - back to the old unicorn!

[Stefan Nobis]

Hi.

Thanks for your great work and the wonderful new page!

A minor detail: I use the plugin "Decentraleyes" and with this
activated there is quite a bit JavaScript garbage at the end of the
page (below the "Created by" footer). The part below the footer is
this:

#+begin_src js
{ const iframes = window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }
#+end_src

When I deactivate Decentraleyes and reload the page, the above code
snippet vanishes. This glitch is present both on the official page and
on https://orgmode.tecosaur.com. It seems, there is some weird
interaction with some script from a CDN (maybe loaded partially due to
constraints from the plugin) or something like that.

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

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Berry, Charles]

FWIW, it doesn't seem like an accident. You might ping the author of this 
commit:

$ git log -S "(let (org-confirm-babel-evaluate)"
commit 56bf3d789146fcd3c9f82d875de28c394fe593a0
Author: Achim Gratz 
Date:   Wed Apr 10 20:28:31 2013 +0200

Babel: avoid superfluous confirmation for internal wrapper

* lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation
  of the emacs-lisp wrapper execution around a lob call.

* lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation
  of the emacs-lisp wrapper execution around a lob call.



HTH,

Chuck

> On Oct 28, 2020, at 4:32 AM, Eric S Fraga  wrote:
> 
> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
>> I have org-confirm-babel-evaluate set to t by default. With this, I
>> expect to be queried with the execution of every code block or lob
>> call. However, this does not happen when exporting lob calls (to latex
>> for example). Here is an example:
> 
> Confirmed with fairly recent org from git with
> org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
> doesn't bother me much as I don't export org files that I haven't
> created myself but it does appear to be a hole.
> 
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
> 
> 

Re: New website - back to the old unicorn!

[Daniele Nicolodi]

On 28/10/2020 17:59, TEC wrote:
> 
> Let's do two at once:
> 
> Daniele Nicolodi  writes:
> 
>> Great work! it looks very nice and informative at the same time.
> That's the idea! :D
> 
>> If I can bikeshed a bit more: I like the lighter page background 
>> that is
>> currently on http://orgomode.org more than the darker one in the 
>> new
>> version.
> 
> See the current. It's slightly tweaked, but you're not getting 
> #fff :P

I like this version. Thank you.

>> 2 and more important) Use the most popular language to get the 
>> most people interested. There are probably a lot more Python 
>> programmers than shell scripters. I suggest the code example 
>> should be a minimal (~6 lines?) of Python that produces either 
>> (or both) a simple graph or ~3 column table.
> 
> Hmmm. This seems sensible. I've tweaked the example. I may make it
> something website-related later (to fit in with the other 
> content).
> Suggestions welcome.

The source block now says that the code is shell, but it looks like
Python to me :-)

Cheers,
Dan

Re: Headline generation as in diary?

[Michael Heerdegen]

I  wrote:

> With diary, I can use arbitrary Lisp expressions to generate dates, and
> those expressions can also return a string to use as non-nil return
> value to generate non-constant headlines including certain numbers for
> example. [...]

My solution so far: I've set up my `org-capture-templates' so that when
I hit T (instead of t) I am prompted for time+headline and optionally a
number of days for a reminder, and, for example, when I enter "21:00
Test" and a "2" I get an entry like

| ** TODO Special entry: "21:00 Test"
| %%(diary-remind
|'(and
|  (dg-it-is "[2020-10-31 Sa]")
|  "TODO 21:00 Test")
|2)

`dg-it-is' is a function that tests whether "it is" the given date
specified as an inactive org time stamp.  The nice thing about this is
that org recognizes the stamp and I can click on it with the mouse to
change it etc.

And I can freely edit the whole expression.  The entry gets listed in
the agenda correctly (also the reminder) and I get two appt.el
appointments (or rather, my substitution for it).

Cons: The headline is ignored, I use a dummy headline.  I don't have
emacs-lisp bindings to edit the expression in the Capture or Org buffer,
so if I want something more complicated I probably need to use *scratch*
as intermediate step  (I tried to use a source block, but then the %%()
expression is not recognized any more, and the time stamps are not
clickable any more).

And for whatever reason, the agenda doesn't fontify the word "TODO".

If anyone has ideas for improvements, I'm curious!


Regards,

Michael.

Re: New website - back to the old unicorn!

[TEC]

Let's do two at once:

Daniele Nicolodi  writes:


Great work! it looks very nice and informative at the same time.

That's the idea! :D

If I can bikeshed a bit more: I like the lighter page background 
that is
currently on http://orgomode.org more than the darker one in the 
new

version.


See the current. It's slightly tweaked, but you're not getting 
#fff :P



Ken Mankoff  writes:

A few more minor comments based on the current version at 
https://orgmode.tecosaur.com/


1) Code block should use some coloring for header blocks and 
code body. The current theme highlights almost everything else 
but the header and code background.


WDYM? I took the current colouring from an Org file that I 
created.


2 and more important) Use the most popular language to get the 
most people interested. There are probably a lot more Python 
programmers than shell scripters. I suggest the code example 
should be a minimal (~6 lines?) of Python that produces either 
(or both) a simple graph or ~3 column table.


Hmmm. This seems sensible. I've tweaked the example. I may make it
something website-related later (to fit in with the other 
content).

Suggestions welcome.

Also, I just noticed you can click on the sections (sections, 
babel header, results) to collapse them! :).


Indeed! You can click on:
- the headers
- the #+begin_src and #+RESULTS
- the image and style.scss links
- oh, and the timestamp highlights

Which led me to an Org bug: The TODO Is 28 % complete, or 2/7, 
but 2/7*100 = 28.5714285714, so I think it should be 29 % 
complete.


Well, at least I'm accurate to Org :P

--
Timothy

Re: New website - back to the old unicorn!

[Dante Catalfamo]

Wow! I'm a big fan of the subtle checkered background and reduced 
"Created by" bar, along with the changed background of the top menu bar; 
it makes the homepage much easier on the eyes. The example org-mode file 
with commentary is a big improvement for letting new folks know how a 
file is laid out as well.


This new website is really incredible, thank you for all the work you've 
put into it!


On 10/28/20 8:25 AM, TEC wrote:


Daniele Nicolodi  writes:


- (minor) I would add a background to the example in the home page to
make it stand out more as an example org-mode syntax buffer

- (very minor) why does the example on the home page need to be an SVG
file? It would be very cool if it could be copy and pasted, but right
now it is not possible (with Firefox, at least)


So, I've turned these "minor" comments into a major revamp of the demo
(that I am inordinately happy with) --- following a brilliant suggestion
from someone on HN.

In case it's of interest you can see the HEAD^ + unstaged changes
version of the site at https://orgmode.tecosaur.com/ I've also tweaked
some of the styling in light of other feedback I received (the
announcement has been great for feedback!).

--
Timothy

Re: New website - back to the old unicorn!

[Ken Mankoff]

On 2020-10-28 at 08:40 -07, Daniele Nicolodi  wrote...
> If I can bikeshed a bit more: I like the lighter page background that
> is currently on http://orgomode.org more than the darker one in the
> new version.

A few more minor comments based on the current version at 
https://orgmode.tecosaur.com/

1) Code block should use some coloring for header blocks and code body. The 
current theme highlights almost everything else but the header and code 
background.

2 and more important) Use the most popular language to get the most people 
interested. There are probably a lot more Python programmers than shell 
scripters. I suggest the code example should be a minimal (~6 lines?) of Python 
that produces either (or both) a simple graph or ~3 column table.

Also, I just noticed you can click on the sections (sections, babel header, 
results) to collapse them! :).

Which led me to an Org bug: The TODO Is 28 % complete, or 2/7, but 2/7*100 = 
28.5714285714, so I think it should be 29 % complete.

  -k.

Re: New website - back to the old unicorn!

[Daniele Nicolodi]

On 28/10/2020 13:25, TEC wrote:
> 
> Daniele Nicolodi  writes:
> 
>> - (minor) I would add a background to the example in the home 
>> page to
>> make it stand out more as an example org-mode syntax buffer
>>
>> - (very minor) why does the example on the home page need to be 
>> an SVG
>> file? It would be very cool if it could be copy and pasted, but 
>> right
>> now it is not possible (with Firefox, at least)
> 
> So, I've turned these "minor" comments into a major revamp of the 
> demo
> (that I am inordinately happy with) --- following a brilliant 
> suggestion
> from someone on HN.

Great work! it looks very nice and informative at the same time.

If I can bikeshed a bit more: I like the lighter page background that is
currently on http://orgomode.org more than the darker one in the new
version.

Cheers,
Dan

RE: [PATCH] Adaptive Org faces in headings?

[Rob Davenport]

That's OK - some more searching and I believe I found the info I was asking 
for:  https://orgmode.org/worg/org-maintenance.html
Thanks anyway.

Rob

—
Rob Davenport
Consulting R Engineer
ABB Cleveland
“Don’t look the other way. Make good architecture happen.”



-Original Message-
From: Emacs-orgmode  On 
Behalf Of Rob Davenport
Sent: Tuesday, October 27, 2020 2:31
To: Ihor Radchenko 
Cc: Org-mode 
Subject: RE: [PATCH] Adaptive Org faces in headings?

Thank you very much for this patch, Ihor.   It fixes the issue on my system.   
I've only recently been getting org from the code.orgmode.org repo so Bastien 
kindly answered my first question as to why I wasn't seeing that patch yet. 
(The package I'm updating is coming from maint and not master.)   I see the fix 
in master but it is yet to be merged into maint so I don't expect to see it 
(just have to keep re-applying it).

I assume at some point commits in master will be merged into maint, correct?   
Is there a basic plan on when such merges might happen?  
Or am I doing something wrong?  I can wait - just curious about the process.  
(If it's documented somewhere I've missed, if someone can point me to it, I'll 
be quiet and go RTFM.  )

Regards,

Rob

—
Rob Davenport
Consulting R Engineer
ABB Cleveland
“Don’t look the other way. Make good architecture happen.”



-Original Message-
From: Emacs-orgmode  On 
Behalf Of Protesilaos Stavrou
Sent: Friday, September 18, 2020 5:53
To: Ihor Radchenko 
Cc: Bastien ; Protesilaos Stavrou ; 
Org-mode ; Diego Zamboni 
Subject: Re: [PATCH] Adaptive Org faces in headings?

This email originated from outside of your organization. Please do not click on 
links or open attachments unless you recognize the sender and know the content 
is safe.


Ihor Radchenko  [2020-09-17, 16:25 +0800]:

> The attached patch seems to fix the issue.
> Can anyone test?

I just tried this using the standard faces of 'emacs -Q' as well as custom 
themes.

In short, the patch fixes the issue on my side.  I tested whether faces on the 
headline would correctly inherit any of the following properties:

+ :height
+ :weight
+ :background
+ :overline

I also tested it with 'variable-pitch' headlines and, again, every construct 
that does not have a font family explicitly assigned to it will adapt to the 
underlying heading.  Excellent!

This is the kind of headline I tried:

 * TODO [#A] This is a test ~scaling-elements~ =faces-adapt= :good-stuff:

Also added links to confirm my findings.  Again, all good.

--
Protesilaos Stavrou
protesilaos.com

Re: preserving (zero-space) indenting in begin_src when exporting/publishing (to mark-down)

[Martin Steffen]

Great, thanks, That was it. It never occured to me that it's not
begin_src that I wanted, I just tried to tweak that one.

So, indeed:  #+begin_export markdown etc. is exactly what I need.

Thanks again.

Martin
> "Julius" == Julius Dittmar  writes:

Julius> Hi Martin,

Julius> if I understand correctly, you do not want to have a section
Julius> that quotes source code, but literal source code.

Re: preserving (zero-space) indenting in begin_src when exporting/publishing (to mark-down)

[Julius Dittmar]

Hi Martin,

if I understand correctly, you do not want to have a section that quotes
source code, but literal source code.

As far as I understand, that means using
#+begin_export markdown
...
#+end_export
block, not
#+begin_src markdown
...
#+end_src
block. That block will then be ignored in any other export format, and
used as-is in markdown export. (I hope "markdown" is the correct label,
I did not test it.)

Hope that helps,
Julius

Am 28.10.20 um 13:54 schrieb Martin Steffen:

I have troubles to export (or publish) some orgfiles, which contain
``src'' snippets intended for markdown. The (for me) unwelcome behavior
is the same for org-export and org-publish, I guess, since it has the
same core reason.

The problem currently for me is for the markdown format. I have seen
similar behavior for other exports, though did not care since it for
those situations, it was/is ``good enough''. Now, however, I do some
export to md, to be used for Jekyll webpages, and it's no longer good
enough.

For concreteness sake: I got some section


#+begin_src markdown
---
layout: default
title: Some Title
description: Some information
---
#+end_src


which is exported to md literally, but with 4 leading spaces as
indentation, like

 ---
 layout: default
 title: Some Title
 description: Some information
 ---

That's insofar unwelcome, as Jekyll wants those pieces of information
without indentation.

Re: Help debugging R source code block output problem with :session

[Jeremie Juste]

Hello Jack,

> Thanks for volunteering to maintain ob-R.el :)
Thanks for the encouragements and the suggestions. 

I need will take some time to dive into the existing code but
I will definitely look into it and keep you posted.

I've also noticed a [1] bug waiting to be fixed.
[1] 
https://orgmode.org/list/71761e05-7d0a-4fef-8baf-4c776a2fc...@health.ucsd.edu/

Best regards,
Jeremie 
On Wednesday, 28 Oct 2020 at 06:13, Jack Kamm wrote:
> Hi Jeremie,
>
> Thanks for volunteering to maintain ob-R.el :)
>
> I'm bumping this patch [0] to see if it could be merged into ob-R.el. It
> fixes some long-standing issues with prompt mangling for :session blocks
> with :results output.
>
> Elsewhere in the thread, Chuck had a suggestion [1] to allow :results
> value to be properly handled in remote sessions. It's not included in
> the patch, but worth adding separately IMO.
>
> It may be helpful reading the thread in full -- Chuck had several
> comments on ob-R that I found insightful, and may be useful for you to
> consider as maintainer. I'd highlight [2] in particular:
>
>> If you do decide to dig into solving this, please be sure that remote
>> sessions and graphical outputs are not broken.  test-ob-R.el does not
>> cover those cases.  In fact, it is pretty short, so there are probably
>> other things that could break without `make test' complaining.
>
> All the best,
> Jack
>
> [0] https://orgmode.org/list/87ft7t9wqk@gmail.com/
> [1] 
> https://orgmode.org/list/1e0046a6-1fab-45b5-9b08-68fe1be98...@health.ucsd.edu/
> [2] 
> https://orgmode.org/list/352c7149-743f-4944-aca5-7a1242b5a...@health.ucsd.edu/
>

Re: best practices query: non-emacs packages based on tangled source

[Greg Minshall]

Immanuel,

my take

> - Not possible to tangle all code going to a specified file

i'm not sure what this means.

> - Not possible to add line directives without major surgery

yes, that would be a problem (... if i were programming in,
e.g., C, etc., so *is* for other people).

> - Not all language modes do the correct thing

my *sense* here is that the level of standardization across different
babel languages in terms of which header arguments are supported, as
well as their meanings, is moderate.

one solution to this (which seems to have happened, at least to an
extent) is good per-language documentation of which header arguments are
supported, and what they mean within the context of the particular
language.

harder would be agreement and implementation of some "core set" of
header arguments/semantics on which one could count, followed by a list
of per-langugage extensions, or followed by places where "we agree to
disagree", or some such?  anyway, a lot of work.

> - No way to prevent overwriting an unchanged file

yes, i too have a hack i use for this (and, it would be nice if there
were something 'out of the box' that did this).

> - Special casing e.g. Don=E2=80=99t tangle to a file called =E2=80=98no=E2=
> =80=99.

somewhere, some how, fonts were lost. :)

cheers, Greg

Re: Help debugging R source code block output problem with :session

[Jack Kamm]

Hi Jeremie,

Thanks for volunteering to maintain ob-R.el :)

I'm bumping this patch [0] to see if it could be merged into ob-R.el. It
fixes some long-standing issues with prompt mangling for :session blocks
with :results output.

Elsewhere in the thread, Chuck had a suggestion [1] to allow :results
value to be properly handled in remote sessions. It's not included in
the patch, but worth adding separately IMO.

It may be helpful reading the thread in full -- Chuck had several
comments on ob-R that I found insightful, and may be useful for you to
consider as maintainer. I'd highlight [2] in particular:

> If you do decide to dig into solving this, please be sure that remote
> sessions and graphical outputs are not broken.  test-ob-R.el does not
> cover those cases.  In fact, it is pretty short, so there are probably
> other things that could break without `make test' complaining.

All the best,
Jack

[0] https://orgmode.org/list/87ft7t9wqk@gmail.com/
[1] 
https://orgmode.org/list/1e0046a6-1fab-45b5-9b08-68fe1be98...@health.ucsd.edu/
[2] 
https://orgmode.org/list/352c7149-743f-4944-aca5-7a1242b5a...@health.ucsd.edu/

preserving (zero-space) indenting in begin_src when exporting/publishing (to mark-down)

[Martin Steffen]

Hi,

I have troubles to export (or publish) some orgfiles, which contain
``src'' snippets intended for markdown. The (for me) unwelcome behavior
is the same for org-export and org-publish, I guess, since it has the
same core reason.

The problem currently for me is for the markdown format. I have seen
similar behavior for other exports, though did not care since it for
those situations, it was/is ``good enough''. Now, however, I do some
export to md, to be used for Jekyll webpages, and it's no longer good
enough.

For concreteness sake: I got some section


#+begin_src markdown
---
layout: default
title: Some Title
description: Some information
---
#+end_src


which is exported to md literally, but with 4 leading spaces as
indentation, like

---
layout: default
title: Some Title
description: Some information
---

That's insofar unwelcome, as Jekyll wants those pieces of information
without indentation.

Alright, that's the situation, and the question is:

  is there a way to get rid of that

(during org-exporting/publishing, of course, not just post-processing
the md file).

This is what I tried so far. There are some variables one can tweak

1) org-src--preserve-indentation 
2) org-src-preserve-indentation 
3) org-edit-src-content-indentation

I set the 1) and 2) to "t" (also locally to the file to export). For 3),
the docs state it's about

  "Indentation for the content of a source code block."


So that sounded like it had something to do with my issue. Actually, the
original value was 2, and I set it to 0. There was no effect, the
indentation, when doing export, is still 4, as it was before setting
that to 0.


Any ideas? Thanks, Martin

Re: New website - back to the old unicorn!

[TEC]

Daniele Nicolodi  writes:

- (minor) I would add a background to the example in the home 
page to

make it stand out more as an example org-mode syntax buffer

- (very minor) why does the example on the home page need to be 
an SVG
file? It would be very cool if it could be copy and pasted, but 
right

now it is not possible (with Firefox, at least)


So, I've turned these "minor" comments into a major revamp of the 
demo
(that I am inordinately happy with) --- following a brilliant 
suggestion

from someone on HN.

In case it's of interest you can see the HEAD^ + unstaged changes
version of the site at https://orgmode.tecosaur.com/ I've also 
tweaked

some of the styling in light of other feedback I received (the
announcement has been great for feedback!).

--
Timothy

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Eric S Fraga]

On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
> I have org-confirm-babel-evaluate set to t by default. With this, I
> expect to be queried with the execution of every code block or lob
> call. However, this does not happen when exporting lob calls (to latex
> for example). Here is an example:

Confirmed with fairly recent org from git with
org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
doesn't bother me much as I don't export org files that I haven't
created myself but it does appear to be a hole.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty

Re: Please help by becoming a maintainer for an Org Babel file

[stardiviner]

I see, contribution is sure fine.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


On Wed, Oct 28, 2020 at 4:55 PM Bastien  wrote:

> Hi stardiviner,
>
> stardiviner  writes:
>
> > I would like to be a maintainer of ob-clojure.el too.
>
> For now, I'd rather have one maintainer per file than several.
>
> Contributions are always welcome, of course.  If I don't have time to
> maintain ob-clojure.el correctly next year, I'll ask for someone else.
>
> Best,
>
> --
>  Bastien
>

Default fold state of property drawers?

[Gustav Wikström]

Hi,

This may be a stupid question but I didn't find anything conclusive in the 
manual or online after a (albeit fairly quick) scan.

Is there currently a way to declare that property drawers (and the file level 
property drawer in particular) should be hidden when opening a new Org file, no 
matter the startup keyword setting? I.e is it possible to control the 
open/closed state of the property drawer separate from the outline folding?

Thanks and best regards
Gustav

Re: [PATCH] ob-java

[Bastien]

ian martins  writes:

> But I want to follow your conventions. I will put the authors of ob-C
> and ob-python (Eric Schulte and Dan Davison) as the authors of
> ob-java and ob-haxe. The implementations are nearly the same. it
> wouldn't make sense for them to have different authors.

Thanks for doing so!

-- 
 Bastien

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Hi Ken,

Ken Mankoff  writes:

> I'll help maintain ob-screen.el

Thanks!  

I added your name as the ob-screen.el maintainer in commit b499b0827.

Best,

-- 
 Bastien

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Hi stardiviner,

stardiviner  writes:

> I would like to be a maintainer of ob-clojure.el too.

For now, I'd rather have one maintainer per file than several.

Contributions are always welcome, of course.  If I don't have time to
maintain ob-clojure.el correctly next year, I'll ask for someone else.

Best,

-- 
 Bastien

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Hi Stardiviner,

stardiviner  writes:

> I searched my name in maintainer line.
>
> Here is the complete list:
> ```
> File: lisp/ob-eshell.el
>    5  25 ;; Author: stardiviner 

I added yourself as the maintainer for ob-eshell.el (commit 1d105a429),
thanks.

My call for ob-* maintainers for Org's core, but of course it's useful
to call for maintainers for contrib/ packages too!

-- 
 Bastien

Re: best practices query: non-emacs packages based on tangled source

[Immanuel Litzroth]

I think the org way of tangling just doesn't work well for compiled languages.
Here are some reasons:
- Not possible to tangle all code going to a specified file
- Not possible to add line directives without major surgery
- Not all language modes do the correct thing
- No way to prevent overwriting an unchanged file
- Special casing e.g. Don’t tangle to a file called ‘no’.
Specific gripe:
- :prologue and :epilogue are not honoured by all modes
>>>
#+ BEGIN_SRC emacs-lisp :prologue "hello" :epilogue "goodbye" :tangle ex1.el
(+ 1 2)
#+ END_SRC


#+ BEGIN_SRC haskell :tangle ex1.hs :prologue "hello" :epilogue "goodbye"
hey
#+ END_SRC

hey

#+HEADER: :tangle ex1.cpp
#+ BEGIN_SRC cpp :prologue "hello" :epilogue "goodbye"
main()
{}
#+ END_SRC

#+ BEGIN_SRC bash :tangle ex1.bash :prologue "hello" :epilogue "goodbye"
aha
#+ END_SRC
>>>

Based on the org machinery I've written a simple tangler which addresses some
of these shortcomings. It can add line directives to recursively expanded noweb
references -- and get that right. It can also take any action at the
end of tangling
like comparing your tangled file to the one on disk and not overwrite
if it's the same,
or just sending your tangled buffer to an interpreter not writing it
to file (remember that
error references point back to the .org file). Also it can tangle all
blocks going to the
same file. This has been tested for Haskell, C++ and elisp.
It's in a private repo on github because it's not ready for release
yet, but if someone
is interested I can give them access.
Immanuel

On Tue, Oct 27, 2020 at 11:30 PM Dr. Arne Babenhauserheide
 wrote:
>
>
> TRS-80  writes:
>
> > Therefore, any stuff I plan on releasing publicly, I do not do in
> > literate style (JMHO).  However if you are dead set on doing literate
> > paradigm, then maybe my experience is invalid for your use-case.
>
> My experience is that literate style works very well for tutorials, but
> whenever I developed a larger program within org-mode, I tangled it once
> I had to start debugging and then kept it as separate source.
>
> Once the code becomes complex, I want to stay in one programming
> language without outside features that also add extra complexity.
>
> That said, for simple code the additional freedom of multi-language
> programming in org-mode is awesome. I’m using that to create random
> roleplaying characters directly from random tables in org-mode, with
> those tables being the primary source (because the book is the most
> important product, not the code).
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken



-- 
-- Researching the dual problem of finding the function that has a
given point as fixpoint.

Stale IDs

[Colin Baxter]

Hello,

I an mot sure if this is a bug or "feature".

1. emacs -Q  (using emacs-28.0.50, org-version 9.3)
2. C-x C-f test.org  (new file)
3. Enter * Test  (A new heading is created with name Test)
4. M-x org-id-get-create 
5. M-x org-id-update-id-locations 

Echo buffer: "1 files scanned, 1 files contains IDs and in total 1 IDs found."

The id is created in ~/.emacs.d/.org-id-locations as expected.

5. Visit test.org again and delete the properties, including the ID.
6. Save the file
7. M-x org-id-update-id-locations 

Echo buffer: "1 files scanned, 0 files contains IDs and in total 0 IDs found."

However, the file ~/.emacs.d/.org-id-locations still contains the ID and
does not read nil as I would have expected. The ID is only removed when
emacs is closed and then the file ~/.emacs.d/.org-id-locations reads
nil.

Best wishes,

Colin Baxter.