The align of time is not beautiful as 9.4 when I update to org 9.5.

[tumashu]

Hello:


When I update to org 9.5,  I find that  the align of time like "7:00" has been 
changed.

I think the new style is not beautiful as old style.
 
1. New style look like not align to  the first char, for the width of 9 looks 
like > 1
2. the old style is align ":"


Feng.

test-org/auto-repeat-maybe depends on locale

[Axel Kielhorn]

Hello,

I have just installed Org mode 9.5 and get a few failing tests:

Which LANG = de_DE.UTF-8 I get:

4 unexpected results:
   FAILED  ob-sed-test/cmd-line-header-argument
   FAILED  ob-shell/bash-uses-assoc-arrays
   FAILED  test-org-table/sort-lines
   FAILED  test-org/auto-repeat-maybe


But which LANG = C I get:

3 unexpected results:
   FAILED  ob-sed-test/cmd-line-header-argument
   FAILED  ob-shell/bash-uses-assoc-arrays
   FAILED  test-org-table/sort-lines

The result of test-org/auto-repeat-maybe depends on the locale used.

I’m using emacs 27.1 on MacOS 10.13 in case that matters.

(I actually expected test-org-table/sort-lines to depend on LANG, that’s why I 
tried with C)

I attached both fails.

Greetings 
Axel

Test test-org-table/sort-lines backtrace:
  signal(ert-test-failed (((should (equal "| a | x |\n| B | 4 |\n| c |
  ert-fail(((should (equal "| a | x |\n| B | 4 |\n| c | 3 |\n" (org-te
  (if (unwind-protect (setq value-15460 (apply fn-15458 args-15459)) (
  (let (form-description-15462) (if (unwind-protect (setq value-15460 
  (let ((value-15460 'ert-form-evaluation-aborted-15461)) (let (form-d
  (let* ((fn-15458 #'equal) (args-15459 (condition-case err (let ((sig
  (progn (fset 'string-collate-lessp vnew) (let* ((fn-15458 #'equal) (
  (unwind-protect (progn (fset 'string-collate-lessp vnew) (let* ((fn-
  (let* ((vnew #'(lambda (s1 s2  locale ignore-case) (funcall
  (let ((original-string-collate-lessp (symbol-function 'string-collat
  (lambda nil (let* ((fn-15448 #'equal) (args-15449 (condition-case er
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name test-org-table/sort-lines :documentat
  ert-run-or-rerun-test(#s(ert--stats :selector "\\(org\\|ob\\)" :test
  ert-run-tests("\\(org\\|ob\\)" #f(compiled-function (event-type 
  ert-run-tests-batch("\\(org\\|ob\\)")
  ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
  (let ((org-id-track-globally t) (org-test-selector (if org-test-sele
  org-test-run-batch-tests("\\(org\\|ob\\)")
  eval((org-test-run-batch-tests org-test-select-re) t)
  command-line-1(("--eval" "(setq vc-handled-backends nil org-startup-
  command-line()
  normal-top-level()

Test test-org-table/sort-lines condition:
(ert-test-failed
 ((should
   (equal "| a | x |
| B | 4 |
| c | 3 |
"
  (org-test-with-temp-text "| a | x |
| c | 3 |
| B | 4 |
" ... ...)))
  :form
  (equal "| a | x |
| B | 4 |
| c | 3 |
"
 #("| B | 4 |
| a | x |
| c | 3 |
" 0 9
(face org-table)
10 19
(face org-table)
20 29
(face org-table)))
  :value nil :explanation
  (array-elt 2
 (different-atoms
  (97 "#x61" "?a")
  (66 "#x42" "?B")


Test test-org/auto-repeat-maybe backtrace:
  signal(ert-test-failed (((should (string-match-p (rx "* TODO Read bo
  ert-fail(((should (string-match-p (rx "* TODO Read book\nSCHEDULED: 
  (if (unwind-protect (setq value-21267 (apply fn-21265 args-21266)) (
  (let (form-description-21269) (if (unwind-protect (setq value-21267 
  (let ((value-21267 'ert-form-evaluation-aborted-21268)) (let (form-d
  (let* ((fn-21265 #'string-match-p) (args-21266 (condition-case err (
  (lambda nil (let* ((fn-21161 #'string-prefix-p) (args-21162 (conditi
  ert--run-test-internal(#s(ert--test-execution-info :test ... :result
  ert-run-test(#s(ert-test :name test-org/auto-repeat-maybe :documenta
  ert-run-or-rerun-test(#s(ert--stats :selector "\\(org\\|ob\\)" :test
  ert-run-tests("\\(org\\|ob\\)" #f(compiled-function (event-type 
  ert-run-tests-batch("\\(org\\|ob\\)")
  ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
  (let ((org-id-track-globally t) (org-test-selector (if org-test-sele
  org-test-run-batch-tests("\\(org\\|ob\\)")
  eval((org-test-run-batch-tests org-test-select-re) t)
  command-line-1(("--eval" "(setq vc-handled-backends nil org-startup-
  command-line()
  normal-top-level()
Test test-org/auto-repeat-maybe condition:
(ert-test-failed
 ((should
   (string-match-p
(rx "* TODO Read book
SCHEDULED: <2021-06-16 Wed +1d>
:PROPERTIES:
:LAST_REPEAT:" ... "
:END:
- State \"DONE\"   from \"TODO\"" ... buffer-end)
(let ... ...)))
  :form
  (string-match-p "\\* TODO Read book
SCHEDULED: <2021-06-16 Wed \\+1d>
:PROPERTIES:
:LAST_REPEAT:.+
:END:
- State \"DONE\"   from \"TODO\".+\\'"
  #("* TODO Read book
SCHEDULED: <2021-06-16 Mi +1d>
   ^^
It says Mittwoch instead of Wednesday.


:PROPERTIES:
:LAST_REPEAT: [2021-09-30 Do 07:14]
:END:
- State \"DONE\"   from \"TODO\"   [2021-09-30 Do 07:14]" 0 1
(face org-level-1 org-todo-head "TODO")
1 7
(org-todo-head "TODO")
7 16
(face org-level-1 org-todo-head "TODO")
17 27
(face org-special-keyword)
130 134
(face ...)))
  :value nil))

Re: Grabbing the link to a message on the archive

[Timothy]

#+OPTIONS: html-postamble:nil H:5 num:nil ^:{} toc:nil author:nil email:nil tex:dvipng d:nil
#+STARTUP: hidestars indent inlineimages
:PROPERTIES:
:reply-to: nil
:attachment: nil
:alternatives: (utf-8 org)
:END:

Hi Greg,

> i love the searching on list.orgmode.org, but i have this recurrent
> dream: that some day each e-mail message will come with a header listing
> the URL for that message on https://list.orgmode.org.  (though i also
> worry this might open us up to some sort of spam, or other, attack?)
>
> and, i'll add my thanks and congratulations on 9.5!
>
> cheers, Greg

If you use mu4e, the following may be of some interest:
#+begin_src elisp
(defun +mu4e-ml-message-link (msg)
  (cond
   ((string= "emacs-orgmode.gnu.org" (mu4e-message-field msg :mailing-list))
(message "Link %s copied to clipboard" (gui-select-text (format "https://list.orgmode.org/%s; (mu4e-message-field msg :message-id)
   (t (user-error "Mailing list %s not supported" (mu4e-message-field msg :mailing-list)
(add-to-list 'mu4e-view-actions (cons "link to message ML" #'+mu4e-ml-message-link t))
#+end_src

I expect this could be adapted to other clients (notmuch, gnus, etc.)
without much trouble :)

#+begin_signature
All the best,\\
@@html:@@Timothy@@html:@@
#+end_signature

Re: orgmode.org setup

[Greg Minshall]

Bastien,

thanks very much for all of this information.

> I plan to work on improving Woof! in the next months to make it more
> stable and (hopefully) usable and useful, but it helps a lot already.

if Woof! is even part of how you have managed to keep track, and manage,
the myriad of mailing list requests, it's already more valuable than its
weight in whatever measure.  watching over the last couple of weeks as
you've wrangled through the set of issues has been awe-inspiring.

> https://list.orgmode.org is the public-inbox archive of the mailing
> list.  It's hosted and maintained by Kyle.  The mailing list archives
> are also here: https://lists.gnu.org/archive/html/emacs-orgmode/

i love the searching on list.orgmode.org, but i have this recurrent
dream: that some day each e-mail message will come with a header listing
the URL for that message on https://list.orgmode.org.  (though i also
worry this might open us up to some sort of spam, or other, attack?)

and, i'll add my thanks and congratulations on 9.5!

cheers, Greg

[BUG) filling bullet list

[Samuel Wales]

I have tried this with -Q in Emacs 25 and recent Org maint.  Also with
my usual setup.  I have not tested the Org released today.

I frequently try to fill bullet lists, where items are longer than fill column.

- mark the list using set-mark-command and movement.  [hre is
something to mke the item long asnd fkajsd nfkja nsdkjfn aksjdnf
kajsnd fkajsn dkfjan skdjn faksjdn fkjad nsfkjanaksj dnfkja sdkfjna
ksdjf kajsd fkjas dkfjna skdjf akjsdnf kajnsdkfjansk djfn.]
- run org-fill-paragraph interactively
- expect each item to be filled
- no filling occurs

In the past I used filladapt.el, but I think its time has mostly gone.
I still try it from time to time, such as email quotes, but it is
unloaded.  I have tried other Emacs fill functions, but I either get
no filling or the whole list becomes one paragraph.

fill-paragraph-function is a variable defined in ‘fill.el’.
Its value is ‘org-fill-paragraph’
Local in buffer executive--a.org; global value is nil

-- 
The Kafka Pandemic

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

Re: [PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

[Dávid Jakab]

Hi!

I briefly tried the patch today, and it seemed to solve the issue on my 
end, but I'm afraid a deeper analysis of the changes is beyond what I 
can do. As for it's relevance, when I didn't apply Sebastien's patch and 
disabled my temporary workaround fix I described in the original post, 
the problem it was still very much there.


Best,

David

On 9/27/21 13:01, Bastien wrote:

Hi David and Sébastien,

Sébastien Miquel  writes:


Thanks for reporting and confirming.

David, Did you have time to look at Sébastien's patch?

Sébastien, have you been able to test this patch heavily and is it
still needed, or has it been made somehow irrelevant?  (I see it does
apply well on the bugfix branch, but not on main.)

Thanks for any feedback,

Re: orgmode.org setup

[Bastien]

Hi Russell,

Russell Adams  writes:

> What's the correct way for myself and others to request access?

By sending an email to b...@gnu.org telling me what username to add.

Thanks!

-- 
 Bastien

Release 9.5

[Bastien]

Hi all,

Org 9.5 is out, available from GNU ELPA.

Thanks a lot to every contributor.

See this page to join our efforts:
https://orgmode.org/worg/org-contribute.html

See the list of changes here: 
https://orgmode.org/Changes.html

Enjoy!

-- 
 Bastien

Re: orgmode.org setup

[Russell Adams]

On Wed, Sep 29, 2021 at 10:18:02PM +0200, Bastien wrote:
> https://orgmode.org/worg/ is populated by .org pages from the Worg
> repo after each push: https://git.sr.ht/~bzg/worg
>
> Worg is maintained by Krupal and Corwin Brust.  Anyone is welcome to
> contribute: https://orgmode.org/worg/worg-about.html

I had commit access to Worg previously, and wanted to confirm I can
use it again.

I've ensured I have an account on sr.ht, but where can you request
access?

https://git.sr.ht/~bzg/worg shows only summary, tree, log, and refs
even though I'm logged in.

What's the correct way for myself and others to request access?

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com

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

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

Re: orgmode.org setup

[Bastien]

Hi Samuel,

"Samuel Banya"  writes:

> Thanks for this, will see how I can help as I would love to improve
> my Elisp skills a bit.

Go wild!

> I'll look to see if there are low-hanging fruit type issues that are
> easy to modify first on the Sourcehut repo.

SourceHut is for Worg, the collaborative documentation, and it is like
the Eden of "low-hanging fruit": many things are outdated, we always
need more tutorials, etc.  Don't hesitate to ask Krupal or Corwin for
directions on where to start.

Thanks!

-- 
 Bastien

Re: orgmode.org setup

[Samuel Banya]

Hey there, 

Thanks for the breakdown for all of this.

I'm a long time user of Org Mode in my every day work as a Technical Support 
Engineer with the past two jobs I've had, so its awesome how easy it is to 
possibly contribute to it, as I really really really do think Org Mode and 
Emacs are awesome.

Thanks for this, will see how I can help as I would love to improve my Elisp 
skills a bit.

I'll look to see if there are low-hanging fruit type issues that are easy to 
modify first on the Sourcehut repo.

Thanks,

Sam

On Wed, Sep 29, 2021, at 4:18 PM, Bastien wrote:
> Dear all,
> 
> I would like to briefly expose how things work for orgmode.org.
> 
> https://orgmode.org/worg/ is populated by .org pages from the Worg
> repo after each push: https://git.sr.ht/~bzg/worg
> 
> Worg is maintained by Krupal and Corwin Brust.  Anyone is welcome to
> contribute: https://orgmode.org/worg/worg-about.html
> 
> https://orgmode.org is populated by .org pages from the orgweb repo
> after each push: https://git.sr.ht/~bzg/orgweb
> 
> So far, only Timothy, Nicolas and me do have write access, these pages
> are not supposed to be updated very often. The Org maintainer needs to
> update the orgweb/Changes.org page for each release.
> 
> https://orgmode.org/elpa/ is here for backward compatibility and will
> be removed before the release of Org 9.6.
> 
> The https://orgmode.org contents are hosted on my machine.
> 
> https://updates.orgmode.org is also hosted on my machine.  I plan to
> work on improving Woof! in the next months to make it more stable and
> (hopefully) usable and useful, but it helps a lot already.
> 
> https://list.orgmode.org is the public-inbox archive of the mailing
> list.  It's hosted and maintained by Kyle.  The mailing list archives
> are also here: https://lists.gnu.org/archive/html/emacs-orgmode/
> 
> https://stats.orgmode.org was used to provide some stats about
> orgmode.org visitors via a Fathom instance, but it is gone.  Here is
> the interesting bit: there are ~30K visitors by month.  AFAIK, this
> number as been remarkably stable for the last ten years.
> 
> https://code.orgmode.org is gone: it was nice testing Gogs, which
> served us well for very long, but was not necessary anymore.  Also,
> using Gogs required some maintainance (spamalot) and led newcomers to
> believe they had to create an account on it to contribute, whereas we
> prefer to receive/read/review patches on the mailing list.  Relying
> on https://git.savannah.gnu.org is the way to go.
> 
> Publishing Worg pages used to involve scripts on the server that we
> don't need anymore: the HTML page are generated by a SourceHut build
> and sent to the server.  Same for orgweb.
> 
> Releasing Org also used to require actions on the server: it does not
> anymore.  Releasing Org only requires to update the "Version:" header,
> which triggers the release of the GNU ELPA package, which is now the
> preferred way of installing the last stable Org version.
> 
> This setup makes many things a lot easier!
> 
> - I'm really glad Kyle maintains list.orgmode.org: it's really cool
>   and useful, searching the list archives is lightening fast.
> 
> - Migrating the contents served by orgmode.org is just a matter of
>   rsync'ing to another server.
> 
> - No need to maintain the Gogs instance and the Fathom instance.
> 
> - Releasing is now a breeze.
> 
> Enjoy!
> 
> -- 
> Bastien
> 
> 

orgmode.org setup

[Bastien]

Dear all,

I would like to briefly expose how things work for orgmode.org.

https://orgmode.org/worg/ is populated by .org pages from the Worg
repo after each push: https://git.sr.ht/~bzg/worg

Worg is maintained by Krupal and Corwin Brust.  Anyone is welcome to
contribute: https://orgmode.org/worg/worg-about.html

https://orgmode.org is populated by .org pages from the orgweb repo
after each push: https://git.sr.ht/~bzg/orgweb

So far, only Timothy, Nicolas and me do have write access, these pages
are not supposed to be updated very often. The Org maintainer needs to
update the orgweb/Changes.org page for each release.

https://orgmode.org/elpa/ is here for backward compatibility and will
be removed before the release of Org 9.6.

The https://orgmode.org contents are hosted on my machine.

https://updates.orgmode.org is also hosted on my machine.  I plan to
work on improving Woof! in the next months to make it more stable and
(hopefully) usable and useful, but it helps a lot already.

https://list.orgmode.org is the public-inbox archive of the mailing
list.  It's hosted and maintained by Kyle.  The mailing list archives
are also here: https://lists.gnu.org/archive/html/emacs-orgmode/

https://stats.orgmode.org was used to provide some stats about
orgmode.org visitors via a Fathom instance, but it is gone.  Here is
the interesting bit: there are ~30K visitors by month.  AFAIK, this
number as been remarkably stable for the last ten years.

https://code.orgmode.org is gone: it was nice testing Gogs, which
served us well for very long, but was not necessary anymore.  Also,
using Gogs required some maintainance (spamalot) and led newcomers to
believe they had to create an account on it to contribute, whereas we
prefer to receive/read/review patches on the mailing list.  Relying
on https://git.savannah.gnu.org is the way to go.

Publishing Worg pages used to involve scripts on the server that we
don't need anymore: the HTML page are generated by a SourceHut build
and sent to the server.  Same for orgweb.

Releasing Org also used to require actions on the server: it does not
anymore.  Releasing Org only requires to update the "Version:" header,
which triggers the release of the GNU ELPA package, which is now the
preferred way of installing the last stable Org version.

This setup makes many things a lot easier!

- I'm really glad Kyle maintains list.orgmode.org: it's really cool
  and useful, searching the list archives is lightening fast.

- Migrating the contents served by orgmode.org is just a matter of
  rsync'ing to another server.

- No need to maintain the Gogs instance and the Fathom instance.

- Releasing is now a breeze.

Enjoy!

-- 
 Bastien

Re: Visibility cycling with inline tasks 2

[Michael Dauer]

Hi Ihor,

Thanks for the clarification.

I wanted to help you with testing. But I could not find a branch dev in
that repo.

Anyway, I'll wait for it to be populated into the main repo. When should I
retry there?

Regards,
Michael

Am Mi., 29. Sept. 2021 um 17:08 Uhr schrieb Ihor Radchenko <
yanta...@gmail.com>:

> Michael Dauer  writes:
>
> > Hi,
> >
> > Was something wrong with my previous report or is nobody interested in
> > inline tasks?
>
> Your report is fine, but please note the following
> (https://orgmode.org/worg/org-mailing-list.html):
>
> >> What to do if you don't receive an answer
>
> >> If your email is referenced on updates.orgmode.org, it will get the
> >> attention of the maintainers when they have enough time. (Remember
> >> they work on a volunteer basis.)
> >>
> >> If your email is not referenced there and you think it deserves more
> >> attention, you can do this:
> >>
> >> If it is a bug report, check that you provided enough information,
> >> especially the Org and Emacs versions and a step-by-step recipe to
> >> reproduce the bug.
> >>
> >> If it is a question, give more information on what you tried, why you
> >> still have the question and why the answer may be of interest for
> >> other subscribers.
> >>
> >> If you have nothing special to add to your first message and just
> >> want to "bump" the thread, please wait at least one month before
> >> doing so.
>
> Your issue is probably fixed in my personal dev branch at
> https://github.com/yantar92/org
>
> Best,
> Ihor
>

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Wed, Sep 29, 2021 at 08:18:11PM +0300, Greg Minshall wrote:
> Tomas,
> 
> in fact, i'm quite used to doing `chmod 755 foo.org`.  i do it now in
> bash, used to do it in csh, and it seems to work (as expected, afaict)
> also in sh.  all on arch linux.  (`chmod +755 foo.org` *does* seem to
> give odd results. :)

D'oh. You are right. Actually, chmod from coreutils does its own
parsing (function mode_compile, online e.g. here [1]).

Cheers

[1] https://sources.debian.org/src/coreutils/8.32-4/lib/modechange.c/#L134

 - t


signature.asc
Description: Digital signature

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Greg Minshall]

Tomas,

in fact, i'm quite used to doing `chmod 755 foo.org`.  i do it now in
bash, used to do it in csh, and it seems to work (as expected, afaict)
also in sh.  all on arch linux.  (`chmod +755 foo.org` *does* seem to
give odd results. :)

cheers, Greg

[PATCH] org-manual.org: Some correction of Installation section

[Max Nikulin]

Hi,

I have read another time "Installation" section of the Org Manual from 
main branch.  I am glad to see that contrib directory is replaced by the 
dedicated repository.  I decided to check it after looking at the 
version on the web site.  Some points might be improved though.


- I have noticed that a code snipped, assumed to be 'above', was removed 
earlier, so I restored it.
- Since Org as ELPA package is mentioned in this section, I suppose, 
org-contrib *package* deserves a similar link as well.
- I am in doubts whether "emacs -Q -L ~/src/org-mode/lisp" way to try 
version from git is important enough for the manual.  I have added a 
separate patch however to discuss such change.


If you think that some patches improve the manual, feel free to apply 
ones that you like or to suggest better variants.
>From b9ae3b156ac46b4ea76103ea9ae8e20b0014784d Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Wed, 29 Sep 2021 23:22:51 +0700
Subject: [PATCH 1/3] org-manual.el: Restore `load-path' for git version

* doc/org-manual.org (Using Org's git repository): Add example of
`load-path' adjustment that was earlier in the previous section
and was removed by commit f9cdda8234, so 'above' became a dangling
reference.
---
 doc/org-manual.org | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4366315a8..d96f9fbe6 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -121,8 +121,11 @@ Note that in this case, =make autoloads= is mandatory: it defines
 Org's version in =org-version.el= and Org's autoloads in
 =org-loaddefs.el=.
 
-Remember to add the correct load path as described in the method
-above.
+Make sure you set the load path correctly in your Emacs init file:
+
+#+begin_src emacs-lisp
+(add-to-list 'load-path "~/src/org-mode/lisp")
+#+end_src
 
 You can also compile with =make=, generate the documentation with
 =make doc=, create a local configuration with =make config= and
-- 
2.25.1

>From 743d9a76aae164fb8bc8dd16f1cfdea27223c012 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Wed, 29 Sep 2021 23:27:54 +0700
Subject: [PATCH 2/3] org-manual.org: Mention org-contrib NonGNU ELPA package

* doc/org-manual.org (Installing Org's contributed packages): Add a link
to the NonGNU ELPA package as an option to install org-contrib.  Mention
the list of external packages on Worg.
---
 doc/org-manual.org | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d96f9fbe6..b25da7889 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -141,9 +141,13 @@ Org Build System page on [[https://orgmode.org/worg/dev/org-build-system.html][W
 :END:
 
 Org's repository used to contain =contrib/= directory for add-ons
-contributed by others.  As of Org 9.5, the directory has bee moved to
-this new dedicated [[https://git.sr.ht/~bzg/org-contrib][org-contrib]] repository, which you can install
-separately.
+contributed by others.  As of Org 9.5, the directory has been moved to
+the dedicated org-contrib [[https://git.sr.ht/~bzg/org-contrib][repository]], which you can install
+separately as a [[https://elpa.nongnu.org/nongnu/org-contrib.html][package]] from NonGNU ELPA.
+
+There are enough valuable packages maintained outside of the Org repository.
+Worg has a list of [[https://orgmode.org/worg/org-contrib/index.html][org-contrib and external packages]], certainly it is not
+exhaustive.
 
 ** Activation
 :PROPERTIES:
-- 
2.25.1

>From 6358a830c4356fcbcac1d18959f5dc45f78993d1 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Wed, 29 Sep 2021 23:37:57 +0700
Subject: [PATCH 3/3] org-manual.org: Another way to run version from git

* doc/org-manual.org (Using Org's git repository): Suggest '-L' command
line option to test git version without modification of init file.
---
 doc/org-manual.org | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b25da7889..af35149ec 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -127,6 +127,12 @@ Make sure you set the load path correctly in your Emacs init file:
 (add-to-list 'load-path "~/src/org-mode/lisp")
 #+end_src
 
+Alternatively, if you intention is to test the latest version and you are
+not going to use it permanently then suppress regular initialization,
+optionally provide minimal init file and specify load path in command line:
+
+: $ emacs -Q -L ~/src/org-mode/lisp -l /path/to/init-git.el
+
 You can also compile with =make=, generate the documentation with
 =make doc=, create a local configuration with =make config= and
 install Org with =make install=.  Please run =make help= to get the
-- 
2.25.1

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Wed, Sep 29, 2021 at 10:58:43PM +0800, Timothy wrote:
> 
>  writes:
> 
> > So you favour going the "full custom special parser". You're much more
> > involved in Org, so I think your gut feeling counts more than mine here :)
> 
> Well, I'm not sure that my feeling is representative of experienced Org users,
> my opinion basically boils down to:

Given your activity of last, I'm certain that your take has
more weight than mine :)

[...]

Beautiful :)

Thanks
 - t


signature.asc
Description: Digital signature

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Jeremy Cowgar]

On 2021-09-29 10:58, Timothy wrote:
I think as long as it’s clear what’s intended, and it’s not some 
home-baked

non-standard format, or terribly annoying to support — why not?


Anyway, as an example here's a code snippet that implements everything 
I've

mentioned.

... code removed for brevity ...



I love it! Much better than my proposed patch.

--
Jeremy

Re: Visibility cycling with inline tasks 2

[Ihor Radchenko]

Michael Dauer  writes:

> Hi,
>
> Was something wrong with my previous report or is nobody interested in
> inline tasks?

Your report is fine, but please note the following
(https://orgmode.org/worg/org-mailing-list.html):

>> What to do if you don't receive an answer

>> If your email is referenced on updates.orgmode.org, it will get the
>> attention of the maintainers when they have enough time. (Remember
>> they work on a volunteer basis.)
>> 
>> If your email is not referenced there and you think it deserves more
>> attention, you can do this:
>> 
>> If it is a bug report, check that you provided enough information,
>> especially the Org and Emacs versions and a step-by-step recipe to
>> reproduce the bug.
>>
>> If it is a question, give more information on what you tried, why you
>> still have the question and why the answer may be of interest for
>> other subscribers.
>>
>> If you have nothing special to add to your first message and just
>> want to "bump" the thread, please wait at least one month before
>> doing so.

Your issue is probably fixed in my personal dev branch at
https://github.com/yantar92/org 

Best,
Ihor

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Timothy]

 writes:

> So you favour going the "full custom special parser". You're much more
> involved in Org, so I think your gut feeling counts more than mine here :)

Well, I'm not sure that my feeling is representative of experienced Org users,
my opinion basically boils down to:

>> I think as long as it’s clear what’s intended, and it’s not some home-baked
>> non-standard format, or terribly annoying to support — why not?

Rephrased: I think there are a few arguably "sensible" formats that a user could
reasonably assume, and if we can support most of them without introducing
ambiguity in parsing or interpretation (and I think we can), can't we make
everyone happy?

> `755' is the funniest one, since, strictly speaking it doesn't correspond
> to anything "out there" (note that the shell command `chmod' wants the
> leading zero, or, well, it will do surprising things if you don't
> provide it ;-)

Consider my suggestion amended to 0755 etc. :)

Anyway, as an example here's a code snippet that implements everything I've
mentioned.

#+begin_src emacs-lisp
(defvar org-tangle-default-mode #o544
  "The default mode for tangled files, as an integer.")

(defun org-interpret-file-mode (mode)
  (cond
   ((integerp mode) mode)
   ((not (stringp mode))
(user-error "File mode %S not recognised as a valid format." mode))
   ((string-match-p "^0[0-7][0-7][0-7]$" mode)
(string-to-number mode 8))
   ((string-match-p "^#o[0-7][0-7][0-7]$" mode)
(string-to-number (substring mode 2) 8))
   ((string-match-p 
"^[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\(,[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\)*$" 
mode)
(file-modes-symbolic-to-number mode 0))
   ((string-match-p "^[rwx-]\\{3\\}$" mode)
(file-modes-symbolic-to-number (concat "u=" mode) org-tangle-default-mode))
   ((string-match-p "^[rwx-]\\{9\\}$" mode)
(file-modes-symbolic-to-number (concat  "u=" (substring mode 0 3)
   ",g=" (substring mode 3 6)
   ",a=" (substring mode 6 9))
   org-tangle-default-mode))
   (t (user-error "File mode %S not recognised as a valid format." mode
#+end_src

--
Timothy

Visibility cycling with inline tasks 2

[Michael Dauer]

Hi,

Was something wrong with my previous report or is nobody interested in
inline tasks?

Inline tasks are a great feature of org-mode, very useful to include tasks
in all sorts of documents without interfering with the document structure.

I resend my report with now hopefully all information to reproduce it
quickly.

0. emacs -Q
1. Insert the below snippet into scratch buffer.
>>>
* Example
** heading 1
x
** heading 2
*** TODO Test access with provided credentials
x
*** END
** heading 3
*** TODO State "high value" targets
x
*** END
** heading 4
x

(org-mode)
(require 'org-inlinetask)
<<<

2. Execute each of the 2 elisp statements at the bottom (C-x C-e)
3. Cycle Example to show children
4. Cycle heading 2

This should show the issue: Parts of heading 3 are expanded too. This is
also true for the next to cycling steps. Then comes a correct full cycle
and the issue repeats.

This garbage shown from the next heading(s) can become huge in more complex
structures.

Org mode version 9.4.6 (9.4.6-gcf30f7

Please confirm the issue.

Regards,
Michael
AntwortenWeiterleiten

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Wed, Sep 29, 2021 at 09:48:47PM +0800, Timothy wrote:
> Hi  Jeremy,
> 
> > As an org user I would expect :tangle-mode 0660 to produce a file that
> > has user rw, group rw, other nothing. Instead, what really happens
> > currently is 0660 is treated as an integer which is actually
> > 3140. This produces unexpected file permissions.
> 
> I agree that :tangle-mode could be more user-friendly. However, I think we can
> go further. Currently, only (identity #o755 / 493) works, however I think it 
> would be
> good if it worked like chmod and accepted most of the following forms:
> ⁃ `#o755'
> ⁃ `755' (because people are used to this, as technically misleading as it may 
> be,
>   as long as we can tell “:tangle-mode 356” from “:tangle-mode (identity 
> #o544)”)
> ⁃ `rw' (equivalent to a=rw, and so #o555)
> ⁃ `a=rw,u+x' (equivalent to #o755) [hardest to support, so maybe?]

So you favour going the "full custom special parser". You're much more
involved in Org, so I think your gut feeling counts more than mine here :)

`755' is the funniest one, since, strictly speaking it doesn't correspond
to anything "out there" (note that the shell command `chmod' wants the
leading zero, or, well, it will do surprising things if you don't
provide it ;-)

But then, if it is clear that :tangle-mode is doing its own parsing,
it won't matter much.

Cheers
 - t


signature.asc
Description: Digital signature

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Timothy]

Hi  Jeremy,

> As an org user I would expect :tangle-mode 0660 to produce a file that
> has user rw, group rw, other nothing. Instead, what really happens
> currently is 0660 is treated as an integer which is actually
> 3140. This produces unexpected file permissions.

I agree that :tangle-mode could be more user-friendly. However, I think we can
go further. Currently, only (identity #o755 / 493) works, however I think it 
would be
good if it worked like chmod and accepted most of the following forms:
⁃ `#o755'
⁃ `755' (because people are used to this, as technically misleading as it may 
be,
  as long as we can tell “:tangle-mode 356” from “:tangle-mode (identity 
#o544)”)
⁃ `rw' (equivalent to a=rw, and so #o555)
⁃ `a=rw,u+x' (equivalent to #o755) [hardest to support, so maybe?]

And then I’d also be in favour of accepting
⁃ `rw-r--r--' (equivalent to #o544)

I think as long as it’s clear what’s intended, and it’s not some home-baked
non-standard format, or terribly annoying to support — why not?

All the best,
Timothy

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Wed, Sep 29, 2021 at 09:17:54AM -0400, Jeremy Cowgar wrote:
> On 2021-09-29 07:07, to...@tuxteam.de wrote:
> >On Wed, Sep 29, 2021 at 11:29:06AM +0200, Gyro Funch wrote:
> >
> >[...]
> >
> >>I don't know if it would ever be ambiguous, but could :tangle-mode
> >>have the ability to infer if it were integer- or octal-format based
> >>on checking against 'reasonable' permission settings in octal
> >>notation?
> >
> >To me, that sounds rather scary. But I'm a timid person :-)
> >
> 
> To keep things from breaking, what if the system were smart and
> if it sees #o prefix, it then parses as an octal, otherwise it keeps
> it's current behavior?

That was roughly my idea: come closer to the Emacs Lisp int
representation (whether only for this case or more generally).

But I'm not deep enough in Org to even venture a recommendation.

> Then add that to the docs. I understand about backwards compatibility
> and that was my greatest fear with this patch when creating it.
> 
> Was just using org-babel-tangle for configuration files and had some
> that I wanted to make 0700 and 0600. I soon learned, that didn't work
> out as planned :-)

I definitely understand your surprise. I know it the other way
around. Back then (TM), it was customary in Windows to write out
the leading zeros in the IPv4 octets, to fill them up to three
places. Something like 192.168.042.001 -- Heavens knows why.

Unix utilities interpret those with a leading zero as an octal
representation (that's how atoi() or strtol() in its default
mode work). I had hours of fun with my Windows colleagues ;-)

Cheers
 - t


signature.asc
Description: Digital signature

[PATCH] Prevent displayed images from being re-scaled

[Timothy]

Hello,

After my last patch providing support for proportional image width attributes
(e.g. 70% of the text width), I noticed that the results looked slightly off.
Investigating the code lead me to `create-image' which takes the liberty of
re-scaling images based on your default font size. As you might imagine, this
can be problematic when if you say determine that image should be 70% of the
text width, the text width is 1000px, and so the image should be 700px wide —
but upon being told to make the image 700 pixels wide `create-image' decides to
make it say 850 pixels wide. I personally found that images >~80% wide were
being made wider than the buffer, which isn’t good.

To make image width behave as expected, we can just specify `:scale 1' when
calling `create-image', and that will stop it from re-interpreting the `:width'
specification. See the patch attached.

All the best,
Timothy
>From 9c34dd6aba62d734f6ae9aecaffa76a0250bf495 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 29 Sep 2021 21:29:27 +0800
Subject: [PATCH] org: Don't change image size based on font size

* lisp/org.el (org--create-inline-image): When `create-image' is called
without the :scale parameter, the image size is expanded based on the
default font size (if it is larger than 10px).  When displaying images
with a specified width in Org buffers, either in pixels or proportional
to the text width, this width should not be modified according the to
font size.  Giving a :scale parameter of 1 prevents this font-size based
rescaling.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 2ec6566c0..0e7f926f0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16518,7 +16518,7 @@ (defun org--create-inline-image (file width)
 			 width
 			 'imagemagick)
 		remote?
-		:width width
+		:width width :scale 1
 
 (defun org-display-inline-images ( include-linked refresh beg end)
   "Display inline images.
-- 
2.33.0

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Jeremy Cowgar]

On 2021-09-29 07:07, to...@tuxteam.de wrote:

On Wed, Sep 29, 2021 at 11:29:06AM +0200, Gyro Funch wrote:

[...]


I don't know if it would ever be ambiguous, but could :tangle-mode
have the ability to infer if it were integer- or octal-format based
on checking against 'reasonable' permission settings in octal
notation?


To me, that sounds rather scary. But I'm a timid person :-)



To keep things from breaking, what if the system were smart and
if it sees #o prefix, it then parses as an octal, otherwise it keeps
it's current behavior?

Then add that to the docs. I understand about backwards compatibility
and that was my greatest fear with this patch when creating it.

Was just using org-babel-tangle for configuration files and had some
that I wanted to make 0700 and 0600. I soon learned, that didn't work
out as planned :-)

- Jeremy

Re: Would it be possible to color horizontal lines in org mode?

[Alper Alimoglu]

Thank you Professor Kitchin. Would something like follows would work?
#+BEGIN_SRC emacs-lisp :results silent
(add-hook 'org-mode-hook (lambda () (font-lock-add-keywords
 nil
 '(("^-\\{5,\\}"  0 '(:foreground "red"
:weight bold))
#+END_SRC

-Alper



On Tue, Sep 28, 2021 at 8:18 PM John Kitchin 
wrote:

> you can add a rule like this in an org-mode hook:
>
> #+BEGIN_SRC emacs-lisp :results silent
> (font-lock-add-keywords
>  nil
>  '(("^-\\{5,\\}"  0 '(:foreground "red" :weight bold
> #+END_SRC
>
> that will make a line starting with at least 5 - be red and bold in color.
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Tue, Sep 28, 2021 at 4:00 AM Eric S Fraga  wrote:
>
>> You could use hi-lock-mode to define your own colouring for such
>> lines.  But I'm sure those that under font-locking better might be able
>> to add appropriate rules for this horizontal line construct.
>>
>> --
>> : Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
>> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>>
>>

Re: org-no-popups overriding display-buffer-alist

[Ihor Radchenko]

"\"Joshua O'Connor\""  writes:

> Hi,
>
> I was wondering what the reason is for Org to employ the tactic of
> overriding the variable 'display-buffer-alist' in a few places, using
> the 'org-no-popups' macro?
>
> It's my understanding that this variable is to be exclusively set by
> users, and acts as the "it's my program, I'll put windows where I want
> them" setting.

For record, it has been fixed on current main by 399481bad.

Best,
Ihor

Re: Mininmal init.el on Worg for testing bleeding edge?

[Max Nikulin]

On 29/09/2021 14:52, Loris Bennett wrote:


   
https://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development

I had to fiddle around a bit to get a minimal init.el that allowed me to
test a fix made in the Savannah repo.


I am unsure, what the FAQ entry should contain. Just to test a fix, the 
following section from the manual may be handy:


(info "(org) Installation")
https://orgmode.org/manual/Installation.html

git clone https://git.savannah.gnu.org/git/emacs/org-mode.git
cd org-mode/
make autoloads

emacs -Q -L ~/src/org-mode/lisp test.org

without any init file. The only pitfall is that -q or -Q is almost 
certainly required since ~/.emacs.d/init.el is processed *before* -L 
option. In simple cases alternative init file may be loaded later 
(normal init is suppressed by -q/-Q)


emacs -Q -L ~/src/org-mode/lisp -l ~/another-init.el test.org

Actually (add-to-list 'load-path "~/src/org-mode/lisp") close to 
beginning of of ~/.emacs.d/init.el is another way to run latest Org 
version, but do not forget comment it out after testing.

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Bastien]

Hi Jeremy,

Jeremy Cowgar  writes:

> As an org user I would expect :tangle-mode 0660 to produce a file that
> has user rw, group rw, other nothing. Instead, what really happens
> currently is 0660 is treated as an integer which is actually
> 3140. This produces unexpected file permissions.

(Just re-adding this as a patch for updates.orgmode.org.)

-- 
 Bastien

Re: [patch] priorities range reversed

[Bastien Guerry]

Hi Joe,

Bastien  writes:

> See the docstring of `org-priority-highest':

I'm discarding this patch right now - feel free to submit a bug report
if there is something I missed.

Thanks,

-- 
 Bastien

Re: Empty headline titles unsupported: Bug?

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> Yet, why not simply alter the headline parser a little bit to support
> empty titles + tag? Such headlines are used in some of the tests. See
> the attached patch.

I've now applied this patch -- let's not close the discussion though,
and keep in mind Nicolas caveats.

Thanks,

-- 
 Bastien

Re: [PATCH] Fix some typos

[Bastien]

Hi Juan,

Juan Manuel Macías  writes:

> I also removed a spurious phrase that I put in that patch
> (Org-News).

Applied too!  Thanks.

-- 
 Bastien

Re: [PATCH] Fix some typos

[Bastien Guerry]

Hi Max,

Max Nikulin  writes:

> A message in this thread
> https://orgmode.org/list/87tuiaxivh@posteo.net/ (Juan Manuel
> Macías, Fri, 24 Sep 2021 12:23:14 +) contains a patch that fixes a
> Shakespeare's sonnet in org-manual.org

Thanks for bringing this to my attention: I've now applied Juan's
change in the main branch.

-- 
 Bastien

Re: [PATCH] Fix some typos

[Marco Wahl]

Max Nikulin  writes:

> Bastien,
>
> A message in this thread
> https://orgmode.org/list/87tuiaxivh@posteo.net/ (Juan Manuel
> Macías, Fri, 24 Sep 2021 12:23:14 +) contains a patch that fixes a
> Shakespeare's sonnet in org-manual.org
>
> Due to updated ORG-NEWS file, it could not be applied directly. I had
> it applied after
>
> commit d74a82448bc28dd9be7b57611038bbb4c7172bce
> Author: Sébastien Miquel 
> Date:   Fri May 28 21:14:22 2021 +0200
>
> and in such form it could be rebased to main. Alternatively ORG-NEWS
> part could be just dropped (and applied later).
>
> The story is the following:
> - 91373e15c8 doc/org-manual.org13905 (Juan Manuel Macías
>   2021-05-15 15:44:36 +0200 13906)
> a documentation for verse formatting was added with a strange variant
> (spread over net though)
> - 215d80d02b doc/org-manual.org13907 (Stefan Kangas 2021-09-16
>  14:40:12 -0700 13909)
> besides other typos, one in this verse was fixed
> - 4271f228db doc/org-manual.org13909 (Marco Wahl 2021-09-20
>  12:09:31 +0200 13909)
> reverted one edit by Stefan likely assuming old English spelling.
>
> Nobody has an idea concerning origin of current variant (particular
> edition of Shakespeare's book), so Juan Manuel created the patch with
> variant published in recent books.
>
> In https://orgmode.org/list/sin28h$ufv$1...@ciao.gmane.io/
> I tried to add the following header
> X-Woof-Patch: org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and
> another typo
> but the patch is not tracked currently on updates.orgmode.org
>
> On 25/09/2021 18:08, Marco Wahl wrote:
>> Juan Manuel Macías writes:
>> 
>>> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
>>> replaced by the version included in Wikipedia (Shakespeare, William.
>>> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
>>> p. 113). I also removed a spurious phrase that I put in that patch
>>> (Org-News).
>> Thanks for the fix of the ORGNEWS entry.  Nitpick: I'd prefer the
>> fix of
>> the ORGNEWS in a further patch for a little bit of more clarity.
>
> I agree with such remark, however I still suppose that the patch could
> be applied even in current variant.

Please go ahead with the patches as you like!  That nitpick is meant as
a hint for commits to come!


Regards,
-- 
Marco

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Wed, Sep 29, 2021 at 11:29:06AM +0200, Gyro Funch wrote:

[...]

> I don't know if it would ever be ambiguous, but could :tangle-mode
> have the ability to infer if it were integer- or octal-format based
> on checking against 'reasonable' permission settings in octal
> notation?

To me, that sounds rather scary. But I'm a timid person :-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: [SOLVED] (was: how to export checkboxes to odt?)

[Max Nikulin]

On 29/09/2021 11:07, Timothy wrote:



Any idea how to export checkboxes to odt?
I mean not just simply having [ ] in the odt document but having them 
translated as actual boxes.


Either using latex ⊠
or   UTF8 ☒


I’m wondering, would this be worth adding to ox-odt?


LibreOffice has some object called "checkbox" that could be inserted 
using "Form Controls" toolbar. I have never used this feature, so unsure 
whether it is a proper representation for Org checkboxes.

Re: [PATCH] Fix some typos

[Max Nikulin]

Bastien,

A message in this thread
https://orgmode.org/list/87tuiaxivh@posteo.net/ (Juan Manuel Macías, 
Fri, 24 Sep 2021 12:23:14 +) contains a patch that fixes a 
Shakespeare's sonnet in org-manual.org


Due to updated ORG-NEWS file, it could not be applied directly. I had it 
applied after


commit d74a82448bc28dd9be7b57611038bbb4c7172bce
Author: Sébastien Miquel 
Date:   Fri May 28 21:14:22 2021 +0200

and in such form it could be rebased to main. Alternatively ORG-NEWS 
part could be just dropped (and applied later).


The story is the following:
- 91373e15c8 doc/org-manual.org13905 (Juan Manuel Macías 
2021-05-15 15:44:36 +0200 13906)
a documentation for verse formatting was added with a strange variant 
(spread over net though)
- 215d80d02b doc/org-manual.org13907 (Stefan Kangas 
2021-09-16 14:40:12 -0700 13909)

besides other typos, one in this verse was fixed
- 4271f228db doc/org-manual.org13909 (Marco Wahl 
2021-09-20 12:09:31 +0200 13909)

reverted one edit by Stefan likely assuming old English spelling.

Nobody has an idea concerning origin of current variant (particular 
edition of Shakespeare's book), so Juan Manuel created the patch with 
variant published in recent books.


In https://orgmode.org/list/sin28h$ufv$1...@ciao.gmane.io/
I tried to add the following header
X-Woof-Patch: org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and 
another typo

but the patch is not tracked currently on updates.orgmode.org

On 25/09/2021 18:08, Marco Wahl wrote:

Juan Manuel Macías writes:


I attach a patch with Shakespeare's sonnet completely fixed: the poem is
replaced by the version included in Wikipedia (Shakespeare, William.
Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
p. 113). I also removed a spurious phrase that I put in that patch
(Org-News).


Thanks for the fix of the ORGNEWS entry.  Nitpick: I'd prefer the fix of
the ORGNEWS in a further patch for a little bit of more clarity.


I agree with such remark, however I still suppose that the patch could 
be applied even in current variant.

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Gyro Funch]

On 2021-09-29 10:22 AM, to...@tuxteam.de wrote:

On Wed, Sep 29, 2021 at 09:52:23AM +0200, dkrm wrote:


Jeremy Cowgar  writes:


[...]


Are you suggesting this currently works or that the patch should be
changed to make that work? A quick try on my local system (pre-patch),
I receive the error:

   Wrong type argument: fixnump, "#o660"


You have to use the `identity` function for it to works: :tangle-mode (identity 
#o660)


Not the original poster, but I'd understand if they think
this is "too roundabout" to just express a file mode.

I think #o would have been acceptable, but changing that
now might break a lot of stuff out there (every param
beginning with `#o'?

OTOH, adding special rules for params seems at least as
dangerous.

Are there better ideas?

Cheers
  - t



I don't know if it would ever be ambiguous, but could :tangle-mode have 
the ability to infer if it were integer- or octal-format based on 
checking against 'reasonable' permission settings in octal notation?


Kind regards,
gyro

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Wed, Sep 29, 2021 at 09:52:23AM +0200, dkrm wrote:
> 
> Jeremy Cowgar  writes:

[...]

> > Are you suggesting this currently works or that the patch should be
> > changed to make that work? A quick try on my local system (pre-patch),
> > I receive the error:
> >
> >   Wrong type argument: fixnump, "#o660"
> 
> You have to use the `identity` function for it to works: :tangle-mode 
> (identity #o660)

Not the original poster, but I'd understand if they think
this is "too roundabout" to just express a file mode.

I think #o would have been acceptable, but changing that
now might break a lot of stuff out there (every param
beginning with `#o'?

OTOH, adding special rules for params seems at least as
dangerous.

Are there better ideas?

Cheers
 - t


signature.asc
Description: Digital signature

Re: Mininmal init.el on Worg for testing bleeding edge?

[Bastien]

Hi Loris,

"Loris Bennett"  writes:

> Would it be worth expanding Point 4 to something like
>
>   This is where you configure Org-mode with Emacs. Please refer to Org
>   tutorials.  To test a locally installed version the following minimal
>   init.el will suffice:
>
> (let ((default-directory  "~/elisp/"))
>   (setq load-path
> (append
>  (let ((load-path  (copy-sequence load-path))) ;; Shadow
>(normal-top-level-add-subdirs-to-load-path))
>  load-path)))
>
>   Replace '~/elisp/' with the path in which you installed Org-mode.
>
> ?

Sure - please send a patch against latest Worg.

If you want to get write access to Worg, just create a username on
https://sr.ht and let me know what it is, I'll add you to
https://git.sr.ht/~bzg/worg

Thanks,

-- 
 Bastien

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[dkrm]

Jeremy Cowgar  writes:

> On 2021-09-29 02:39, to...@tuxteam.de wrote:
>> On Tue, Sep 28, 2021 at 10:54:48AM -0400, Jeremy Cowgar wrote:
>>> As an org user I would expect :tangle-mode 0660 to produce a file that
>>> has user rw, group rw, other nothing. Instead, what really happens
>>> currently is 0660 is treated as an integer which is actually
>>> 3140. This produces unexpected file permissions.
>>> 
>> Hm. This looks dangerous: interpreting an integer as octal just
>> due to the context?
>> I do understand why, but still...
>> Why not recommend Elisp's explicit syntax for octal representation,
>> i.e. :tangle-mode #o660? And put a prominent note in the docs,
>> of course.
>
> Are you suggesting this currently works or that the patch should be
> changed to make that work? A quick try on my local system (pre-patch),
> I receive the error:
>
>   Wrong type argument: fixnump, "#o660"

You have to use the `identity` function for it to works: :tangle-mode (identity 
#o660)

Mininmal init.el on Worg for testing bleeding edge?

[Loris Bennett]

Hi,

On the page

  
https://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development

after one has compiled and installed, Point 4 says
 
  This is where you configure Org-mode with Emacs. Please refer to Org 
tutorials.

I had to fiddle around a bit to get a minimal init.el that allowed me to
test a fix made in the Savannah repo.  Specifically rather than 

  (let ((default-directory  "~/.emacs.d/lisp/"))
(normal-top-level-add-subdirs-to-load-path))

I needed to do

  (let ((default-directory  "~/.emacs.d/lisp/"))
(setq load-path
  (append
   (let ((load-path  (copy-sequence load-path))) ;; Shadow
 (normal-top-level-add-subdirs-to-load-path))
   load-path)))

to get the path for the version of Org I wanted to test at the front of
the load path (examples taken from
https://www.emacswiki.org/emacs/LoadPath).

Would it be worth expanding Point 4 to something like

  This is where you configure Org-mode with Emacs. Please refer to Org
  tutorials.  To test a locally installed version the following minimal
  init.el will suffice:

(let ((default-directory  "~/elisp/"))
  (setq load-path
(append
 (let ((load-path  (copy-sequence load-path))) ;; Shadow
   (normal-top-level-add-subdirs-to-load-path))
 load-path)))

  Replace '~/elisp/' with the path in which you installed Org-mode.

?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Spurious spaces with oc-biblatex

[Denis Maier]

Am 25.09.2021 um 16:48 schrieb Bastien:

Hi Denis,

Denis Maier  writes:


Bump.

Can you propose a patch for this?

I would have already done if I knew how to do this.
That's maybe a nice elisp exercise so I'll have look, but I fear that's 
way beyond my capabilities, and probably something Nicolas might want to 
have a look at.




Also see
https://orgmode.org/worg/org-mailing-list.html#i-didnt-receive-an-answer
where we ask contributors to wait at least one month before bumping a
thread (thanks!)
Oh, didn't know that. Sorry. (Other lists have a "wait one week before 
bumping"-policy, and I assumed that to be the case here as well...)


Denis

Re: Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Am 29.09.2021 um 08:30 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


That won't work if you have more than one reference in a citation?

[cite:@doe 4, with some more text; @jones]

No, that won't work with more than one reference in a citation. But
this, coupled with the simple locator parsing done in oc-csl.el should
be enough in the vast majority of the cases, shouldn't it?

Well, there are even cases like this one:

[cite:@doe especially 4, 12, and 15]

[cite:@doe e.g. 4, 12, and 15]

[cite:@doe among others 4, 12, and 15]

[cite:@doe 4, but also 12 and 15]

Best,
Denis

Re: Adjust git redirect to [correct] savannah repo

[Bastien Guerry]

Hi John,

John Hendy  writes:

> $ git pull
> make clfatal: unable to update url base from redirection:
>   asked for: 
> https://code.orgmode.org/bzg/org-mode.git/info/refs?service=git-upload-pack
>redirect: 
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/?service=git-upload-pack

I've now added a new redirection so that people trying to pull from
code.orgmode.org will be redirected to the correct git.savannah.gnu.org
address.

Thanks a lot for raising this issue!

-- 
 Bastien

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Jeremy Cowgar]

On 2021-09-29 02:39, to...@tuxteam.de wrote:

On Tue, Sep 28, 2021 at 10:54:48AM -0400, Jeremy Cowgar wrote:

As an org user I would expect :tangle-mode 0660 to produce a file that
has user rw, group rw, other nothing. Instead, what really happens
currently is 0660 is treated as an integer which is actually
3140. This produces unexpected file permissions.



Hm. This looks dangerous: interpreting an integer as octal just
due to the context?

I do understand why, but still...

Why not recommend Elisp's explicit syntax for octal representation,
i.e. :tangle-mode #o660? And put a prominent note in the docs,
of course.


Are you suggesting this currently works or that the patch should be
changed to make that work? A quick try on my local system (pre-patch),
I receive the error:

  Wrong type argument: fixnump, "#o660"

--
Jeremy

Re: Release 9.5 tomorrow

[Bastien]

Hi Yasushi,

Yasushi SHOJI  writes:

> It's not that important, but if you have time would you please take a
> look at this:
> https://list.orgmode.org/44f768b5-bade-e07a-29a7-15999eefd...@binghamton.edu/t/#mc90ae0a5266fe201d44e6f8f174b2d874f7c57fd

I applied the three patches, with some modifications in the commit
message.  Please check https://orgmode.org/worg/org-contribute.html
for further contributions.

Thank you for the contribution!

-- 
 Bastien

Re: babel default header args as functions

[Bastien]

Hi Matt,

Matt Huszagh  writes:

> I've tested it, and if you revert
> 78783f4e47901255695031dae0efcbb301a40878 and apply the new patch, it
> will apply with conflicts. Let me know if you run into any difficulties,
> have any concerns, etc.

Done, thanks a lot.

> Here's the patch for the news item. Bear in mind that the last part
> about lazy evaluation is only true for the newest patch.

Applied too, thanks!

-- 
 Bastien

Re: Repeating task not repeating

[Bastien]

Hi Loris,

"Loris Bennett"  writes:

> Thanks for all your hard work and sorry for not confirming sooner.

No problem, thanks for confirming!

-- 
 Bastien

Re: Repeating task not repeating

[Loris Bennett]

Hi Bastien,

Bastien  writes:

> Hi Loris,
>
> can you confirm the bug is gone with latest Org?
>
> ~$ git clone https://git.savannah.gnu.org/git/emacs/org-mode.git

Yes, the bug has been fixed for my use-case.

Thanks for all your hard work and sorry for not confirming sooner.

Cheers,

Loris
-- 
This signature is currently under construction.

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Wed, Sep 29, 2021 at 02:55:46AM -0400, Jeremy Cowgar wrote:
> On 2021-09-29 02:39, to...@tuxteam.de wrote:
> >On Tue, Sep 28, 2021 at 10:54:48AM -0400, Jeremy Cowgar wrote:
> >>As an org user I would expect :tangle-mode 0660 to produce a file that
> >>has user rw, group rw, other nothing. Instead, what really happens
> >>currently is 0660 is treated as an integer which is actually
> >>3140. This produces unexpected file permissions.
> >>
> >
> >Hm. This looks dangerous: interpreting an integer as octal just
> >due to the context?
> >
> >I do understand why, but still...
> >
> >Why not recommend Elisp's explicit syntax for octal representation,
> >i.e. :tangle-mode #o660? And put a prominent note in the docs,
> >of course.
> 
> Are you suggesting this currently works or that the patch should be
> changed to make that work? A quick try on my local system (pre-patch),
> I receive the error:
> 
>   Wrong type argument: fixnump, "#o660"

Oh. It seems Org converts that to string based on its own
rules instead of on Elisp's.

Note that I'm not dead set /against/ your proposal. I was pointing
out a possible inconsistency and arguing for some reflection, however
it may turn out.

I'd have a slight preference for the #oXXX variant (and for Org
agreeing with Elisp on what a number is ;-) but it's just that,
a slight preference.

The UNIX shell's convention "leading zero to denote base 8" (coming 
from C, I don't know where that comes from) is one not very happy
hack, IMO. But if that's what is in people's muscle memory, so
be it ;-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Greg Minshall]

Tomas,

> Why not recommend Elisp's explicit syntax for octal representation,
> i.e. :tangle-mode #o660? And put a prominent note in the docs,
> of course.

as much as my fingers are used to "0660 ==> octal", this probably makes
sense.

on the other hand, to protect users, might it be worthwhile ("just due
to the context") to flag ":tangle-mode 0..." integers as an error for
the user to deal with?  (and point them at, e.g., #o660.)

cheers, Greg

[misunderstanding] (was: how to export checkboxes to odt?)

[Uwe Brauer]

> Hi Juan,




> Thanks very much, I saw it too late to respond yesterday. A couple of remarks

> 1. (on "\u2611 ") ; CHECK MARK: I rather prefer 2612 but this is a
>question of taste

> 2. It seems not to work, I loaded the function and Executed the
>advice, but 

I just want to clarify, that your code works.
I realized that I used the word checkbox not a the strict org mode sense.
Sorry for the confusion!

Thanks for your code


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug: Org mode fails to compile using Emacs 24.5-r10

[Bastien]

Hi Tim,

Tim Cross  writes:

> Perhaps we need to clarify that the supported versions is based on the
> version of Emacs which was stable at the time of release of the org
> version. For example, org 9.5, being released this week, means it would
> support Eamcs 27.x, 26.x and 25.x, but not Emacs 24.x. If Emacs 28 is
> released next month, this would not alter the supported versions as 9.5
> was released before Emacs 28. When org 9.6 is released, the supported
> versions would be updated to include whatever version of Emacs is stable
> at that point (likely 28.x) and the two previous versions. 

Please don't hesitate to clarify things on Worg if needed.

-- 
 Bastien

Re: Bug: Org mode fails to compile using Emacs 24.5-r10

[Bastien]

Hi Max,

Max Nikulin  writes:

> lisp/org.el:;; Package-Requires: ((emacs "24.3"))
>
> Should not it be updated?

Indeed, done, thanks.

> Ubuntu-18.04 bionic is a Long Time Support release (April 2018),
> emacs-25.2.2 provided from system repository. Maybe it should be
> supported even though next LTS release Ubuntu-20.04 focal is
> available.

Since we require Emacs 25.1, it is supported.  When Emacs 28.1 will be
out, it will mean that we don't guarantee backward-compatibility with
Emacs 25.1, but I suspect most things will work - and people using
this old Emacsen can still rely on the Org version that is packaged
with it.

-- 
 Bastien

Re: [PATCH] manual: Remove a couple of stray words from the citation handling section

[Bastien]

Dear András,

András Simonyi  writes:

> the patch which I attached removes some stray/leftover words from the
> manual's section on citations.

Applied, thank you very much.

-- 
 Bastien

Re: [BUG] [PATCH] org-id: Fix checkdoc warnings [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

No Wayman  writes:

> See attached.

Applied, thanks.

-- 
 Bastien

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Hi Tim,

Tim Cross  writes:

> Thanks Bastien. I think it is good to have a clear statement on this,
> even if not everyone agrees, as it makes things explicit. I
> suspect this will need to be reviewed after each release of a new Emacs
> version though as the effort to maintain backwards compatibility will
> depend on what has changed in Emacs. Especially given that Emacs release
> cycles seem to be getting shorter. 

Indeed - Ihor already helped with testing backward compatibility, and
yes, we shall certainly keep an eye on this.

-- 
 Bastien

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[tomas]

On Tue, Sep 28, 2021 at 10:54:48AM -0400, Jeremy Cowgar wrote:
> As an org user I would expect :tangle-mode 0660 to produce a file that
> has user rw, group rw, other nothing. Instead, what really happens
> currently is 0660 is treated as an integer which is actually
> 3140. This produces unexpected file permissions.
> 
> Prior to this patch to have rw,rw,none, one has to convert 0660 octal
> into an integer (432) and then specify :tangle-mode 432. This is counter
> intuitive and requires multiple steps.
> 
> After this patch, one just specifies the octal code as you do with
> chmod. :tangle-mode 0660 results in a file that is rw,rw,none.

Hm. This looks dangerous: interpreting an integer as octal just
due to the context?

I do understand why, but still...

Why not recommend Elisp's explicit syntax for octal representation,
i.e. :tangle-mode #o660? And put a prominent note in the docs,
of course.

Cheers
 - t


signature.asc
Description: Digital signature

Re: [SOLVED]

[Uwe Brauer]

>>> "T" == Timothy   writes:

> Hello,
>>> Any idea how to export checkboxes to odt?
>>> I mean not just simply having [ ] in the odt document but having them 
>>> translated as actual boxes.
>> 
>> Either using latex ⊠
>> or   UTF8 ☒

> I’m wondering, would this be worth adding to ox-odt?

I think Juan's solution would be nice, however it does not work for me write 
now, so I have to see what is wrong with it.


smime.p7s
Description: S/MIME cryptographic signature

Re: Suggestions for improved suffix parsing in oc-biblatex

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> That won't work if you have more than one reference in a citation?
>
> [cite:@doe 4, with some more text; @jones]

No, that won't work with more than one reference in a citation. But
this, coupled with the simple locator parsing done in oc-csl.el should
be enough in the vast majority of the cases, shouldn't it?

Regards,
-- 
Nicolas Goaziou

Re: how to export checkboxes to odt?

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  writes:

Hi Juan,

> Hi Uwe,
> Uwe Brauer writes:

>> Any idea how to export checkboxes to odt?
>> 
>> I mean not just simply having [ ] in the odt document but having them 
>> translated as actual boxes.

> You can try:

> (defun my/org-odt--checkbox (item)
>   "Return check-box string associated to ITEM."
>   (let ((checkbox (org-element-property :checkbox item)))
> (if (not checkbox) ""
>   (format "%s"
> "OrgCode" (cl-case checkbox
> (on "\u2611 ") ; CHECK MARK
> (off "\u2610 ")
> (trans "[-] ")) ;; I don't know which character 
> to choose here...

> (advice-add 'org-odt--checkbox :override  #'my/org-odt--checkbox)

Thanks very much, I saw it too late to respond yesterday. A couple of remarks

1. (on "\u2611 ") ; CHECK MARK: I rather prefer 2612 but this is a
   question of taste

2. It seems not to work, I loaded the function and Executed the
   advice, but 

When I tried to export this minimal example

* Check the conversion of checkboxes


1. Latex $\boxtimes$

2. UTF8 ☒,   ▢ □

3. Org   [ ] and   [X]

4. Org [] [-]

I obtained a odt file in which 3 and 4 were *not* converted to UTF8. I
attach the file. What do I miss?

Regards

Uwe 



checkbox.odt
Description: application/vnd.oasis.opendocument.text


smime.p7s
Description: S/MIME cryptographic signature