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

[Ihor Radchenko]

> I understand from your answer to Bastien's query that this fix is
> specific to your branch; would it be hard to backport it to Org's maint
> branch?  Otherwise IIUC Org 9.4 will keep this regression, and users
> will have to wait until Org 9.5 for a fix.

The problem is that fix in my branch has nothing to do with main branch.
The bugs were inherently different even though looked same from user
point of view. If one wants to make the fix work on master, the whole
branch must be applied.

However, I can try to suggest a way to fix the issue on master. The way
isearch handles folded text in org is set from org-flag-region
(org-macs.el):

(overlay-put o
   'isearch-open-invisible
   (lambda ( _) (org-show-context 'isearch)))

It means that isearch calls org-show-context (org.el) to reveal hidden
text. Then, it calls org-show-set-visibility with argument defined in
org-show-context-detail (now, it is 'lineage). With current defaults,
the searched text is revealed using org-flag-heading, which reveals both
heading body and drawers.

The easiest way to write the fix would be changing org-flag-heading
directly, but there might be unforeseen consequences on other folding
commands.

Another way would be changing the way org-show-set-visibility handles
'lineage argument. Again, it may affect other things.

Finally, one can add an extra possible argument to
org-show-set-visibility and alter default value of
org-show-context-detail accordingly.

The last way will have least risk to break something else.

I guess, patches welcome ;)

> Bastien asked for the /gist/ as a patch against master, whereas your
> answer explained why you couldn't share the /fix/ as a patch against
> master.  If Bastien did mean the whole gist, here is the corresponding
> patch against master:

Well. The gist is a patch applying the whole feature/org-fold branch to
master. That's not yet something we can do. The plan is to apply the
org-fold feature in several steps, as discussed in earlier messages. So,
I thought that it would just create confusion if I share the gist as is.

Sorry if I was not clear.

Best,
Ihor


Kévin Le Gouguec  writes:

> Ihor Radchenko  writes:
>
>> Thanks for reporting! I accidentally reintroduced the bug because of
>> mistake when converting org-hide-drawers to new folding library.
>> (:facepalm:).
>>
>> Should be fixed in the gist now.
>
> Can confirm, thanks!
>
> I understand from your answer to Bastien's query that this fix is
> specific to your branch; would it be hard to backport it to Org's maint
> branch?  Otherwise IIUC Org 9.4 will keep this regression, and users
> will have to wait until Org 9.5 for a fix.
>
> Also, just in case there's been a misunderstanding:
>
> Bastien  writes:
>
>> Can you share this gist as a patch against Org's current master?
>
> Bastien asked for the /gist/ as a patch against master, whereas your
> answer explained why you couldn't share the /fix/ as a patch against
> master.  If Bastien did mean the whole gist, here is the corresponding
> patch against master:
>
> https://gist.githubusercontent.com/yantar92/6447754415457927293acda43a7fcaef/raw/7e43948e6c21220661534b79770bc1a6784b7893/featuredrawertextprop.patch
>
> Apologies if I'm the one misunderstanding, and thank you for all your
> efforts!

Re: The Website Revamp: The final stretch

[Samuel Wales]

i am lost about a and b and 1-2 and so on.

but  i went to a tecosaur site and noticed that the old unicorn
covering text when you use large fonts or have a low dpi monitor is no
longer a problem, whihc is good.  i'd suggest high contrast, light on
dark, preferably with no glaring whites anywhere.

i probably didn't address any of hte questions though.  :)


On 9/24/20, Ihor Radchenko  wrote:
>> You can find the final 3 concepts here: https://0x0.st/ilFH.pdf, once
>> again I'd like to encourage any feedback, and ranking of the options.
>
> I like A and B with slight preference towards B.
>
> Also, the website renders strangely in qutebrowser (see the attached
> screenshot). Firefox renders everything just fine on the same system.
>
> Best,
> Ihor
>
>


-- 
The Kafka Pandemic

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

Re: The Website Revamp: The final stretch

[Ihor Radchenko]

> You can find the final 3 concepts here: https://0x0.st/ilFH.pdf, once
> again I'd like to encourage any feedback, and ranking of the options.

I like A and B with slight preference towards B.

Also, the website renders strangely in qutebrowser (see the attached
screenshot). Firefox renders everything just fine on the same system.

Best,
Ihor



TEC  writes:

> An update.
>
> 1. We have a volunteer for a Japanese translator (yay!),
>still looking for a french one
> 2. Following the community opinions and feedback on the designs
>presented, further iteration has occurred and 20 concepts have been
>reduced to the three most promising candidates.
>I now have a final 3 - the first two are the best ideas from the
>last selection, the third is a new idea.
>
> You can find the final 3 concepts here: https://0x0.st/ilFH.pdf, once
> again I'd like to encourage any feedback, and ranking of the options.
>
> Unless anything else crops up, I don't anticipate any other major
> changes being made.
>
> All the best,
>
> Timothy.

Bug: (bug?) org-id-find-id-in-file doesn't close files after finding id [9.4 (9.4-7-g3eccc5-elpaplus @ ~/spacemacs/elpa/develop/org-plus-contrib-20200921/)]

[this nkk]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.

** what happened
when running org-id-find-id-in-file on an id and an unvisited file, the
buffer it creates to visit file isn't
closed after finding id.

** what should have happened
I was expecting it to close the buffer if the
file wasn't already visited by another buffer.

Is this desired behavior?

** background info and possible fix
I stumbled on this while looking at an issue with org-roam at
https://github.com/org-roam/org-roam/issues/1129.

For now a guard clause like the following in the calling function closes the
buffer if need be.

  (let (file-already-open-p return-val)
(setq file-already-open-p (find-buffer-visiting file))
(setq return-val (org-id-find-id-in-file id file markerp))
(unless file-already-open-p (kill-buffer (find-buffer-visiting file)))
(print return-val))

This logic can be propagated to the function to squash this possible
bug.


Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, 
cairo version 1.17.3)
 of 2020-08-20
Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @ 
~/spacemacs/elpa/develop/org-plus-contrib-20200921/)

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

[Kyle Meyer]

Samuel W. Flint writes:

>> Bastien  writes:
>
> B> Can you provide a patch to announce this in etc/ORG-NEWS?
>
> Please see the attached patch.

Thanks.  Applied (488076e0a).

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

[Kyle Meyer]

Matt Huszagh writes:

> This patch looks good. I've tested it and it works well for me. Thanks
> for coming up with a good solution!

Thanks for testing it out.

> I think the one thing still missing is some documentation in the info
> manual. Something along the lines of [...]

Yep, the manual should definitely be updated in a final patch.  What you
suggest looks good to me.

> Feel free to add this (or something else) to your patch. Or, if you'd
> prefer that I created a patch for it, let me know.

I'd be happy for you to take what I sent and work it into a proper
patch.  Here are some other loose ends in addition to the manual update
you mentioned:

  * a NEWS entry for 9.5

  * decide whether (:file-desc . []) should be handled explicitly rather
than the current "any value that org-babel-read doesn't map to nil
or a string"

  * check that there's a test case for each :file-desc scenario

Thanks.

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

[Samuel W. Flint]

> Bastien  writes:

B> Hi Samuel, "Samuel W. Flint"  writes:

>> Marked as TINYCHANGE.

B> Applied as d06aa486d, thanks!

Thanks!

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

Please see the attached patch.

B> -- Bastien

Sam

-- 
Samuel W. Flint
4096R/FA13D704
  (F50D 862B 4F65 5943 A8C2  EF0E 86C9 3E7A FA13 D704)
λs.(s s) λs.(s s)
>From b1242c2af3d5ab16ddcec52d3b3f47bb60895d9a Mon Sep 17 00:00:00 2001
From: "Samuel W. Flint" 
Date: Thu, 24 Sep 2020 17:57:32 -0500
Subject: [PATCH] Describe new %L formatting for org-capture

* etc/ORG-NEWS (New formatting directive ~%L~ for org-capture):

Describe new %L formatting for org-capture

TINYCHANGE
---
 etc/ORG-NEWS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index eed3871d4..f036aa6a5 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -11,6 +11,12 @@ See the end of the file for license conditions.
 Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.5 (not yet released)
+** New options and settings
+*** New formatting directive ~%L~ for org-capture
+
+The new ~%L~ formatting directive contains the bare link target, and
+may be used to create links with programmatically generated
+descriptions.
 * Version 9.4
 ** Incompatible changes
 *** Possibly broken internal file links: please check and fix
-- 
2.18.1

Re: org-babel support for haxe

[ian martins]

with ob-java I assumed I shouldn't change ob-core, so I advised/overrode
ob-core instead of changing it. But it would be much better to change
ob-core. I'll submit those changes as a separate patch that modifies
ob-core.

On Sun, Sep 13, 2020 at 4:04 PM Kyle Meyer  wrote:

> ian martins writes:
>
> > ob-haxe and ob-java both involve a few changes to ob-core to allow temp
> > directories instead of just temp files. Should I submit that as a
> separate
> > patch?
>
> It looks like that change is included with your ob-java patch [0], which
> will be considered after 9.4 is released [1], so I think it's fine as
> is.  (In my opinion, splitting up that patch would have been nice, but I
> don't think it's worth a reroll, at least until some initial comments
> come in.)
>
> [0]
> https://orgmode.org/list/CAC=rjb7ahmnrq9nc4ao07qk3qzf4lvatmu_r1fwqr+97npn...@mail.gmail.com
> [1] https://orgmode.org/list/87sgbwgvx6@gnu.org
>

Re: org-table-sum

[Kyle Meyer]

Kyle Meyer writes:

> Here's what org-table-sum does underneath:
>
>   (apply #'+
>  (list 171.0 4.07 4.44 2.61 12.21 6.69 19.72 23.09 6.23 15.28 78.85))
>   ;; => 1094.18998

Sorry, I pasted the wrong snippet (that one above has some numbers
pruned and returns "344.189994").  Here's the snippet that would
match the your table:

  (apply #'+ (list 171.0 4.07 4.44 2.61 12.21 6.69 19.72 23.09 6.23
   15.28 250.0 250.0 250.0 78.85))

Re: org-table-sum

[Kyle Meyer]

Kein Test writes:

> Hi,
>
> I found out about org-table-sum yesterday, but I quickly ran into a
> problem, where the result is not right.
>
> For example:
>
> | 171.00 |
> |   4.07 |
> |   4.44 |
> |   2.61 |
> |  12.21 |
> |   6.69 |
> |  19.72 |
> |  23.09 |
> |   6.23 |
> |  15.28 |
> | 250.00 |
> | 250.00 |
> | 250.00 |
> |  78.85 |
> ||
>
> If point is at the last cell, org-table-sum evaluates to 1094.18998.

Here's what org-table-sum does underneath:

  (apply #'+
 (list 171.0 4.07 4.44 2.61 12.21 6.69 19.72 23.09 6.23 15.28 78.85))
  ;; => 1094.18998

> I did not find a way to reproduce this with other numbers, but the
> order seems to matter.

See .

Re: org-table-sum

[Mark Janes]

I can reproduce this with org 9.3.1.  I imagine the decimal numbers
have precision problems when converted to binary floating point.

A simpler table to reproduce:

|  83.6 |
|.1 |
|---|
| 83.69 |


Kein Test  writes:

> Hi,
>
> I found out about org-table-sum yesterday, but I quickly ran into a
> problem, where the result is not right.
>
> For example:
>
> | 171.00 |
> |   4.07 |
> |   4.44 |
> |   2.61 |
> |  12.21 |
> |   6.69 |
> |  19.72 |
> |  23.09 |
> |   6.23 |
> |  15.28 |
> | 250.00 |
> | 250.00 |
> | 250.00 |
> |  78.85 |
> ||
>
> If point is at the last cell, org-table-sum evaluates to 1094.18998.
>
> I did not find a way to reproduce this with other numbers, but the
> order seems to matter.
>
> Best wishes

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

[Andrea]

Hi,

What are the pros?

About the cons: maybe we need to look more into the requirements.

I am looking at https://tools.ietf.org/html/rfc2048 and the one that
concerns me a little is 2.2.6: I guess somebody would need to write a
bit of docs about security concerns. Or you can go the way Markdown did
it: from https://tools.ietf.org/html/rfc7763#section-2

"Security considerations:

  Markdown interpreted as plain text is relatively harmless.  A text
  editor need only display the text.  The editor SHOULD take care to
  handle control characters appropriately and to limit the effect of
  the Markdown to the text-editing area itself; malicious Unicode-
  based Markdown could, for example, surreptitiously change the
  directionality of the text.  An editor for normal text would
  already take these control characters into consideration, however.

  Markdown interpreted as a precursor to other formats, such as
  HTML, carries all of the security considerations as the target
  formats.  For example, HTML can contain instructions to execute
  scripts, redirect the user to other web pages, download remote
  content, and upload personally identifiable information.  Markdown
  also can contain islands of formal markup, such as HTML.  These
  islands of formal markup may be passed as they are, transformed,
  or ignored (perhaps because the islands are conditional or
  incompatible) when the Markdown is processed.  Since Markdown may
  have different interpretations depending on the tool and the
  environment, a better approach is to analyze (and sanitize or
  block) the output markup, rather than attempting to analyze the
  Markdown.
"

Do they have an org-babel?

Thanks,

Andrea

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

[Andrea]

Hi,

What are the pros?

About the cons: maybe we need to look more into the requirements.

I am looking at https://tools.ietf.org/html/rfc2048 and the one that
concerns me a little is 2.2.6: I guess somebody would need to write a
bit of docs about security concerns. Or you can go the way Markdown did
it: from https://tools.ietf.org/html/rfc7763#section-2

"Security considerations:

  Markdown interpreted as plain text is relatively harmless.  A text
  editor need only display the text.  The editor SHOULD take care to
  handle control characters appropriately and to limit the effect of
  the Markdown to the text-editing area itself; malicious Unicode-
  based Markdown could, for example, surreptitiously change the
  directionality of the text.  An editor for normal text would
  already take these control characters into consideration, however.

  Markdown interpreted as a precursor to other formats, such as
  HTML, carries all of the security considerations as the target
  formats.  For example, HTML can contain instructions to execute
  scripts, redirect the user to other web pages, download remote
  content, and upload personally identifiable information.  Markdown
  also can contain islands of formal markup, such as HTML.  These
  islands of formal markup may be passed as they are, transformed,
  or ignored (perhaps because the islands are conditional or
  incompatible) when the Markdown is processed.  Since Markdown may
  have different interpretations depending on the tool and the
  environment, a better approach is to analyze (and sanitize or
  block) the output markup, rather than attempting to analyze the
  Markdown.
"

Do they have an org-babel?

Thanks,

Andrea

org-table-sum

[Kein Test]

Hi,

I found out about org-table-sum yesterday, but I quickly ran into a
problem, where the result is not right.

For example:

| 171.00 |
|   4.07 |
|   4.44 |
|   2.61 |
|  12.21 |
|   6.69 |
|  19.72 |
|  23.09 |
|   6.23 |
|  15.28 |
| 250.00 |
| 250.00 |
| 250.00 |
|  78.85 |
||

If point is at the last cell, org-table-sum evaluates to 1094.18998.

I did not find a way to reproduce this with other numbers, but the
order seems to matter.

Best wishes

Re: org-tempo question

[Jeremie Juste]

Hello Nick,

Thanks for the feedback. I'm not sure I understand your setting
entirely. I have reproduced the behaviour of tempo
inside an org src block below. I don't have any comma before the
source block expansion unless I type it.

Any character except space or tab on the line of the expansion
destroys it. For example item 2 below. I have noted that the example block
on item 3 doesn not expand at all  (item 3). My normal usage is
generally the item 1 case and I get the expected behavior.


#+BEGIN_SRC org

* heading 1 (cursor position)
   writes:

> I can't say anything about indentation (I encounter problems that I
> have not reported because of lack of time to investigate combined with
> laziness - but I suspect they are, partly at least, of my own making).
>
> But when I do ` badly indented) example block, with commas before the #+begin and the
> #+end_example lines - OTOH, ` no-indent example block even if I have spaces before the ` have printable charactes before the `
> #+NAME: third
> #+begin_src org
>
> - an item
>   - subitem
>
>   ,#+begin_example
>
>   ,#+end_example
>
> #+end_src
>
> #+begin_example
>
> #+end_example
>
>
> The commas are important: are you not getting them?

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

[Kévin Le Gouguec]

Ihor Radchenko  writes:

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

Can confirm, thanks!

I understand from your answer to Bastien's query that this fix is
specific to your branch; would it be hard to backport it to Org's maint
branch?  Otherwise IIUC Org 9.4 will keep this regression, and users
will have to wait until Org 9.5 for a fix.

Also, just in case there's been a misunderstanding:

Bastien  writes:

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

Bastien asked for the /gist/ as a patch against master, whereas your
answer explained why you couldn't share the /fix/ as a patch against
master.  If Bastien did mean the whole gist, here is the corresponding
patch against master:

https://gist.githubusercontent.com/yantar92/6447754415457927293acda43a7fcaef/raw/7e43948e6c21220661534b79770bc1a6784b7893/featuredrawertextprop.patch

Apologies if I'm the one misunderstanding, and thank you for all your
efforts!

Re: The Website Revamp: The final stretch

[Carsten Dominik]

Hi

A or B, no strong preference.

About the text, maybe we can change the "there are dozens of them", that
struck me as a bit odd.  Because what is a "feature".

Maybe
Features - which subset will you use?
Features - something for everyone
Features - start digging

I don't know...

Cheers

Carsten

On Thu, Sep 24, 2020 at 6:42 PM Nick Dokos  wrote:

> Nix on variant C from me.
>
> Slight lean towards B, but I personally would be happy with either A or B.
>
> Thanks!
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>

Re: org-tempo question

[Jeremie Juste]

Hello Bruno,

Thanks for your mail. I have been missing this feature that was taken
out of core. I will have to keep up with the modulation of org-mode but
it is for the better.


Regarding your concern 
> In the same spirit if before trying that I type tabulation then = then tabulation again, nothing is inserted, aka org-tempo seems to work
> only when cursor is at the beginning of line.
I cannot reproduce it. That is

#+BEGIN_SRC
* headline 1
   - item
   https://orgmode.org/manual/Structure-Templates.html

Re: org-tempo question

[Nick Dokos]

I can't say anything about indentation (I encounter problems that I
have not reported because of lack of time to investigate combined with
laziness - but I suspect they are, partly at least, of my own making).

But when I do `8---
#+NAME: third
#+begin_src org

- an item
  - subitem

  ,#+begin_example

  ,#+end_example

#+end_src

#+begin_example

#+end_example


--8<---cut here---end--->8---

The commas are important: are you not getting them?

-- 
Nick

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

Re: The Website Revamp: The final stretch

[Tom Gillespie]

A vote for A from me. I think that using the light background for the
section above the fold fits better with the color themes of the other
pages and will make the transition less jarring. Best!
Tom

On Thu, Sep 24, 2020 at 9:20 AM TEC  wrote:
>
>
> An update.
>
> 1. We have a volunteer for a Japanese translator (yay!),
>still looking for a french one
> 2. Following the community opinions and feedback on the designs
>presented, further iteration has occurred and 20 concepts have been
>reduced to the three most promising candidates.
>I now have a final 3 - the first two are the best ideas from the
>last selection, the third is a new idea.
>
> You can find the final 3 concepts here: https://0x0.st/ilFH.pdf, once
> again I'd like to encourage any feedback, and ranking of the options.
>
> Unless anything else crops up, I don't anticipate any other major
> changes being made.
>
> All the best,
>
> Timothy.
>

Re: The Website Revamp: The final stretch

[Nick Dokos]

"collapsable" should be "collapsible".

-- 
Nick

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

Proposal: do not align tags in Agenda

[Michaël Cadilhac]

Hello all,

I have a wide screen, which makes right edge alignment of tags in the
agenda inconvenient (they're hard to match with the main entry).
Setting org-agenda-tags-column to a specific column overwrites part of
the entry, which is not optimal.  I'd simply want the tag to be put
_after_ the entry.  The attached patch is what I've been using for the
past month, and it seems to work alright.

Thoughts for/against?

Stay safe,
M.
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index e4a334dbd..792348e4c 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -1912,6 +1912,7 @@ character screen."
   :group 'org-agenda-line-format
   :type '(choice
 	  (const :tag "Automatically align to right edge of window" auto)
+	  (const :tag "Do not align" nil)
 	  (integer :tag "Specific column" -80))
   :package-version '(Org . "9.1")
   :version "26.1")
@@ -9073,13 +9074,20 @@ current line."
  (if (memq 'org-tag prop)
  prop
    (cons 'org-tag prop))
-	(setq l (string-width (match-string 1))
-	  c (if (< org-agenda-tags-column 0)
-		(- (abs org-agenda-tags-column) l)
-		  org-agenda-tags-column))
+	(when org-agenda-tags-column
+	(setq l (string-width (match-string 1))
+		  c (if (< org-agenda-tags-column 0)
+			(- (abs org-agenda-tags-column) l)
+		  org-agenda-tags-column)))
 	(goto-char (match-beginning 1))
 	(delete-region (save-excursion (skip-chars-backward " \t") (point))
 		   (point))
+	(unless org-agenda-tags-column
+	  (setq c (if (get-text-property (point) 'org-habit-p)
+		  (+ 1 org-habit-graph-column
+			 org-habit-preceding-days
+			 org-habit-following-days)
+		(current-column
 	(insert (org-add-props
 		(make-string (max 1 (- c (current-column))) ?\s)
 		(plist-put (copy-sequence (text-properties-at (point)))

Re: The Website Revamp: The final stretch

[Nick Dokos]

Nix on variant C from me.

Slight lean towards B, but I personally would be happy with either A or B.

Thanks!
-- 
Nick

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

Re: The Website Revamp: The final stretch

[Palak Mathur]

> On Sep 24, 2020, at 8:20 AM, TEC  wrote:
> 
> 
> An update.
> 
> 2. Following the community opinions and feedback on the designs
>   presented, further iteration has occurred and 20 concepts have been
>   reduced to the three most promising candidates.
>   I now have a final 3 - the first two are the best ideas from the
>   last selection, the third is a new idea.
> 
> You can find the final 3 concepts here: https://0x0.st/ilFH.pdf, once
> again I'd like to encourage any feedback, and ranking of the options.
> 

Just keeping up with Parkinson’s Law of Triviality [1], as I don’t have any 
opinion on any other post but this, here it is:
I like both Variant A and B. C not so much. 

[1]: https://en.wikipedia.org/wiki/Law_of_triviality



> Unless anything else crops up, I don't anticipate any other major
> changes being made.
> 
> All the best,
> 
> Timothy.
> 

org-tempo question

[Bruno BEAUFILS]

Does anyone have any idea where I can look to understand that?

-- 
Bruno BEAUFILS
--- Begin Message ---
Let us imagine this simple org file :

#+NAME: first
#+begin_src org
- an item
  - subitem

#+end_src

If the cursor is at the last line and I want to insert an org block,
let's say an example, using org-tempo feature, I can type =>.

Any help would appreciated.

I use GNU Emacs 26.3 from Debian GNU bullseye (testing) and what I
think is the last org-mode version from ELPA.

#+begin_src 
Org mode version 9.3.7 (9.3.7-55-gba2405-elpa @ 
/home/bruno/.emacs.d/elpa/org-20200907/)
#+end_src

-- 
Bruno BEAUFILS


signature.asc
Description: PGP signature
--- End Message ---


signature.asc
Description: PGP signature

Re: The Website Revamp: The final stretch

[TEC]

An update.

1. We have a volunteer for a Japanese translator (yay!),
   still looking for a french one
2. Following the community opinions and feedback on the designs
   presented, further iteration has occurred and 20 concepts have been
   reduced to the three most promising candidates.
   I now have a final 3 - the first two are the best ideas from the
   last selection, the third is a new idea.

You can find the final 3 concepts here: https://0x0.st/ilFH.pdf, once
again I'd like to encourage any feedback, and ranking of the options.

Unless anything else crops up, I don't anticipate any other major
changes being made.

All the best,

Timothy.

Re: The Website Revamp: The final stretch

[Devin Prater]

Thank you very much for this. I wasn't sure if accessibility was something
you'd care about or not, but I figured I'd give it a shot, as any blind
user of Emacs, through Emacspeak or otherwise, who wanted to get into
Org-mode would appreciate it. One more small thing or two:

On the features page, the description:

Demonstration of planing with org, managing a scheduled todo list

should be:

Demonstration of planning with org, managing a scheduled todo list

After the "simple syntax" heading, the figure is empty. Is that supposed to
be the case?
Devin Prater
sent from Gmail.


On Thu, Sep 24, 2020 at 6:02 AM TEC  wrote:

>
> Hi Devin, thanks for checking up on this!
>
> Devin Prater  writes:
>
> > [no alt texts for images]
>
> This should be fixed now! (
> https://github.com/tecosaur/orgwebsite/commit/545d0c7d28)
>
> > Also, I cannot find the area to view the Org-mode source of a page.
>
> Ah, yes. This was removed at the request of Bastien.
>
>
> Thanks for your help, and please let me know if you notice anything
> else!
>
> Timothy.
>

Bug: performance issue in org-font-lock-add-priority-faces related to org-priority-regexp [9.4 (9.4-7-g3eccc5-elpaplus @ /home/standard/.emacs.d/elpa/26.3/develop/org-plus-contrib-20200921/)]

[Tim Frana]

Hello,

After updating from org-plus-contrib-20200810 to 
org-plus-contrib-20200921, opening org files has become extremely slow 
for me. As a rough estimate, a 400 KB org file of mine used to take 5 
seconds on first load in a session, and after the update needed more 
than 2 minutes. This is the case both in Emacs 27.1 in Windows, and 
Emacs 26.3 in Windows WSL1 Ubuntu 20.04 LTS, using spacemacs develop.


I can narrow it down to this change:

org-font-lock-add-priority-faces used to search for this regexp: "^\\*+ 
.*?\\(\\[#\\(.\\)\\]\\)"
Now it searches for org-priority-regexp, which by default resolves to 
".*?\\(\\[#\\([A-Z0-9]+\\)\\] ?\\)".


This is much slower, and also matches more than I expected. In the 
following example, I expect only [#A], but it will match [#B] and [#C] 
too. Is this intended?


** TODO [#A] Headline [#B]
this is matched despite not being a heading: [#C] more text

It seems plausible that the slowdown comes from the regex engine now 
doing elaborate matching on all lines, instead of fast skipping over 
non-heading lines.


This version seems to resolve my problem, where the beginning "^\\*+ " 
should narrow matches to heading lines only:

(setq org-priority-regexp "^\\*+ .*?\\(\\[#\\([A-Z0-9]+\\)\\] ?\\)")

Profiler excerpt (the other 51% were mostly eaten by spell checking 
during idling, as I got distracted waiting for the loading to finish):


- set-auto-mode 5498  49%
 - set-auto-mode-0  5498  49%
  - org-mode    5498  49%
   - run-mode-hooks 5498  49%
    - apply 5497  49%
 - run-hooks    5497  49%
  - org-superstar-mode  5493  49%
   - org-superstar--fontify-buffer  5493  49%
    - font-lock-ensure  5493  49%
 - jit-lock-fontify-now 5493  49%
  - jit-lock--run-functions 5493  49%
   - run-hook-wrapped   5493  49%
    - # 5391 48%
 - font-lock-fontify-region 5391  48%
  - font-lock-default-fontify-region    5391  48%
   - font-lock-fontify-keywords-region  5391  48%
  org-font-lock-add-priority-faces  5391  48%

Best regards,
Tim






Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-09-16
Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @ 
/home/standard/.emacs.d/elpa/26.3/develop/org-plus-contrib-20200921/)


current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

 org-after-todo-state-change-hook '(org-expiry-insert-created)
 org-link-shell-confirm-function 'yes-or-no-p
 org-blank-before-new-entry '((heading . t) (plain-list-item))
 org-babel-after-execute-hook '(spacemacs/ob-fix-inline-images)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-agenda-tags-todo-honor-ignore-options t
 org-export-with-sub-superscripts '{}
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function

 org-enforce-todo-dependencies t
 org-edit-src-content-indentation 0
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-imenu-depth 8
 org-download-annotate-function 'org-download-annotate-default
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-clock-report-include-clocking-task t
 org-modules '(org-habit ol-w3m ol-bbdb ol-bibtex ol-docview ol-gnus 
ol-info ol-irc ol-mhe ol-rmail ol-eww)
 org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent 
org-depend-block-todo)

 org-archive-location "%s_archive.org::"
 org-id-link-to-org-use-id 'create-if-interactive
 org-mode-hook '((lambda nil (setq paragraph-start "\f\\|[ ]*$" 
paragraph-separate "[     \f]*$")) turn-on-auto-fill org-tempo-setup 
org-clock-load
 #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-show-all append local] 5] flyspell-mode 
spacemacs/org-setup-evil-surround spacemacs/load-yasnippet
 #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2] toc-org-enable org-superstar-mode 
org-download-enable dotspacemacs//prettify-spacemacs-docs 
spacemacs//org-babel-do-load-languages
 #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-babel-show-result-all append local] 5] 
org-babel-result-hide-spec org-babel-hide-all-hashes 
spacemacs//evil-org-mode org-eldoc-load

 spacemacs//init-company-org-mode company-mode)
 org-clock-persist t
 

Re: org-tables with monetary amounts

[Eric S Fraga]

Christian,

thank you for this mini-tutorial.  Very helpful!  Calc is so powerful
but also has such a steep learning curve that I don't use it as much as
I should.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-29-gbc9664

Re: The Website Revamp: The final stretch

[Greg Newman]

This looks great. 2-1 is the one I prefer.

- Greg Newman



On Tue, Sep 22, 2020 at 10:56 AM TEC  wrote:

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

Re: The Website Revamp: The final stretch

[TEC]

Hi Devin, thanks for checking up on this!

Devin Prater  writes:

> [no alt texts for images]

This should be fixed now! 
(https://github.com/tecosaur/orgwebsite/commit/545d0c7d28)

> Also, I cannot find the area to view the Org-mode source of a page.

Ah, yes. This was removed at the request of Bastien.


Thanks for your help, and please let me know if you notice anything
else!

Timothy.

Re: The Website Revamp: The final stretch

[David Arroyo Menendez]

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

Thanks in advance!

-- 
https://damegender.net

Re: The Website Revamp: The final stretch

[David Arroyo Menendez]

Timothy E Chapman  writes:

> Hi Bastien,
>
> Just remembered I haven't addressed everything you mentioned here.
>
> Bastien  wrote:
>
>> Also, let's remove the mini-unicorn in the top bar, it is redundant
>> and reminds me of the opening of IT Crowd.
>
> Ah yes, I see the resemblance :P I'm not sure this is a good idea though, as
> while this can be seen as redundant on the homepage, the navbar is used on
> every page. Considering that this is a site to help people learn about Org,
> I think that the visual consistency of having it on every page, and
> how that helps reinforce the association between Org and that logo is worth 
> it.
> Having it regularly appear should help it stick.
>
>> - I believe there are too many pages: I'd love the website to be just
>>   one HTML page.  Rich contents should go to Worg and yes, we need to
>>   upgrade Worg's design too. Let's try moving such contents to Worg as
>>   soon as we can -- but this is not a blocker for the switch.
>

It seems a good idea more simple is better. There are many bootstrap
free web designs, it's a good idea for responsive, I'm using this idea
for damegender.net, damewebutils.davidam.com and
damelibraries.davidam.com. My website (davidam.com) is not using
bootstrap and I'm happy with mobiles, too.


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

Yes, it sounds a good idea. I would add documentation (manuals, worg)
and community (irc, mailing lists, emacswiki, https://emacs.stackexchange.com/,
telegram, meetups, ...)

> How does that sound to you? Of course, all of this migration to Worg
> can happen after an iniIal switch.
>
>> - For the manual, I'd prefer to use the same design that the one used
>>   on the gnu.org website:
>
> This is quite easy (and not actually part of this branch), I think we
> just need to pass
> --css-ref "https://www.gnu.org/software/emacs/manual.css;
> to the makeinfo/texi2any/texi2html command in
> https://code.orgmode.org/bzg/org-mode/src/master/doc/Makefile
>
> All the best,
>
> Timothy.
>
>

-- 
https://damegender.net

Re: org-tables with monetary amounts

[Christian Moe]

Hi,

Parsing numbers followed by currencies is sort of supported already
through Calc's operations on units. (Calc is the built-in emacs
calculator that powers the spreadsheet function of Org tables). I
haven't used this or explored it much, but my impression is that it
could be made more useful than it currently is. Here are a couple of
things you can do fairly easily.

If you're only working with one currency and just want it to show up
automatically, the following calculation will give you 59.97 USD in the
third column right out of the box, without even requiring you to define
it as a unit first.

  | 50 USD | 8.97 USD | 59.97 USD   |
  #+TBLFM: $3=$1+$2

Adding undefined currencies together will result in an expression like
"3 USD + 4 EUR". However, if you define the currencies as units based on
exchange rates, you can get conversion as part of arithmetic operations.

E.g. in Calc,
- put `1' on top of the stack
- then do `u d EUR' to define the euro as your unit currency (for
example)
- then define e.g. US dollars: Today's rate is 1 USD = 0.86 EUR.
- hit apostrophe to enter algebraic mode and enter `0.86 EUR'
  (today's rate: 1 USD = 0.86 EUR)
- now do `u d USD' to define the rate

Now, with the Calc command to simplify units, you can add dollars to
euros and get the result in whichever currency comes first in the
algebraic expression

  | 3 USD | 4 EUR | 6.58 EUR |
  #+tblfm: $3=usimplify($2+$1)

  | 3 USD | 4 EUR | 7.6511628 USD |
  #+tblfm: $3=usimplify($1+$2)

I don't use this functionality, so I don't have answers to all the
questions you'll now have -- including how to get the desired precision
without lopping off the currency unit in the last example!

There are ways to enter user-defined units permanently. But exchange
rates change, so to use this functionality on a daily basis, you'll want
to have some kind of function to pull exchange rates and update the
currency unit definitions in the Calc init file.

Apart from `usimplify', most Calc functions on units appear (?) to be
missing corresponding algebraic versions that you can use in Calc
expressions in Org tables, which limits the usefulness.

Org tables don't seem to have any specific formula syntax for leveraging
Calc unit operations apart from what happens to work out of the
box. This might be an area for improvement, though I'm not sure what to
ask for.

Yours,
Christian

Daniele Nicolodi writes:

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

Re: Bug: org-table-wrap-region incorrectly places the wrapped region [9.4 (9.4-elpaplus @ /home/marko/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Jeremie Juste]

Hello Marko,

Thanks for reporting. Unexpected behavior of (org-table-wrap-region)
confirmed.

works fine with 
> | Includes all aspects of|
> | information about  |
> | proposed project.  |


Error: user-error: Not in table data field
with header line
> ||
> | Includes all aspects of|
> | information about  |
> | proposed project.  |

Best regards
Jeremie

Org mode version 9.4
GNU Emacs 28.0.50 



Marko Schuetz-Schmuck  writes:

> 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.4 (9.4-elpaplus @ 
> /home/marko/.emacs.d/elpa/org-plus-contrib-20200914/)
>
> I'm using multi-line fields in org tables. When I wrap such a field
> there are unexpected results:
>
> Marking the region from the 'I' of "Includes" to the space just left of
> the right bottom column border and calling org-table-wrap-region
>
> | Includes all aspects of|
> | information about  |
> | proposed project.  |
>
> wraps correctly to
>
> | Includes all aspects |
> | of information about |
> | proposed project.|
>
> But when I mark the same region in this table
>
> ||
> | Includes all aspects of|
> | information about  |
> | proposed project.  |
>
> it results in an error message "Not in table data field".
>
> Initially I observed such unexpected behaviors with more complex
> situations where the field was in a column further to the right. But it
> seems it's the same problem.
>
> Best regards,
>
> Marko

Bug: org-table-wrap-region incorrectly places the wrapped region [9.4 (9.4-elpaplus @ /home/marko/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Marko Schuetz-Schmuck]

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.4 (9.4-elpaplus @ 
/home/marko/.emacs.d/elpa/org-plus-contrib-20200914/)

I'm using multi-line fields in org tables. When I wrap such a field
there are unexpected results:

Marking the region from the 'I' of "Includes" to the space just left of
the right bottom column border and calling org-table-wrap-region

| Includes all aspects of|
| information about  |
| proposed project.  |

wraps correctly to

| Includes all aspects |
| of information about |
| proposed project.|

But when I mark the same region in this table

||
| Includes all aspects of|
| information about  |
| proposed project.  |

it results in an error message "Not in table data field".

Initially I observed such unexpected behaviors with more complex
situations where the field was in a column further to the right. But it
seems it's the same problem.

Best regards,

Marko


signature.asc
Description: PGP signature

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

[Matt Huszagh]

Kyle Meyer  writes:

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

Yep, I agree. I think my phrasing could have just been better. I meant
to include the breakage as a factor against.

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

I like this solution better than mine. I guess it's still a bit of a
hack, but it doesn't seem to be one that could break a use case, whereas
the empty string could conceivably be intended, though I'm still not
sure why.

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

Yes I think you're right. I was referring to my solution of an empty
string, which I didn't see a personal use for, but felt it might be a
valid use case for someone else. I really can't think of any reason the
empty vector would otherwise be valid.

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

This patch looks good. I've tested it and it works well for me. Thanks
for coming up with a good solution! I think the one thing still missing
is some documentation in the info manual. Something along the lines of

 The ‘file-desc’ header argument defines the description (see *note
 Link Format::) for the link.  If ‘file-desc’ has no value, Org uses
 the generated file name for both the “link” and “description” parts
 of the link. If you want to omit the description (i.e., [[link]]),
 you can either omit the ‘file-desc’ header argument or provide it
 with an empty vector (i.e., :file-desc []).

Feel free to add this (or something else) to your patch. Or, if you'd
prefer that I created a patch for it, let me know.

Matt