Re: [BUG] org-open-at-point broken when on headline [9.6.1 (release_9.6.1-208-g0c0059 @ /home/b/s/org/org-mode/lisp/)]

[Marco Wahl]

Hello Ihor!

>> AFAICS org-open-at-point is broken in the case when point is on a
>> headline: org-open-at-point does not open any link.

> * This is test
> [[https:/orgmode.org]]

> C-c C-o works for me on current main.

Gaa!  Reported too quickly!  Again!

I guess the actual issue was located somewhere in front of the monitor.

Sorry for the noise!


Thanks!
-- 
Marco Wahl




On 2/1/23, Ihor Radchenko  wrote:
> Marco Wahl  writes:
>
>> AFAICS org-open-at-point is broken in the case when point is on a
>> headline: org-open-at-point does not open any link.
>
> * This is test
> [[https:/orgmode.org]]
>
> C-c C-o works for me on current main.
>
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

[BUG] org-open-at-point broken when on headline [9.6.1 (release_9.6.1-208-g0c0059 @ /home/b/s/org/org-mode/lisp/)]

[Marco Wahl]

Hi!

AFAICS org-open-at-point is broken in the case when point is on a
headline: org-open-at-point does not open any link.

I checked the older version 0c00590606325e6f6f4756f567e36c074da0e890 and
I think it's okay.

Branch main.


Thanks!



Emacs  : GNU Emacs 30.0.50 (build 23, x86_64-pc-linux-gnu, GTK+
Version 3.24.34, cairo version 1.16.0)
 of 2023-02-01
Package: Org mode version 9.6.1 (release_9.6.1-208-g0c0059 @
/home/b/s/org/org-mode/lisp/)
-- 
Marco Wahl

Re: [please check] Add RET to go from overlay to edit buffer

[Marco Wahl]

Hi Ihor!

Ihor Radchenko  writes:

> Marco Wahl  writes:
>
>> Just pushed the little feature "RET to go from overlay to edit buffer".
>
> Two comments:
> 1. It would make sense to mention the new key binding in NEWS
> 2. org-edit-src-goto  binding is slightly confusing given the
>behaviour of C-c ' on a src-block being edited. C-c ' achieves the
>same, but queries a question to discard/not discard the edits.

Gaa!  I missed the functionality of C-c ' when the overlay is in place.
And by customizing org-src-ask-before-returning-to-edit-buffer the
confusing (at least for me) question goes away.

I think C-c ' is the natural binding.  No need for another one AFAICT.

I'll revert the changes.  Sorry for the fuss.


Thank you.
-- 
Marco

[please check] Add RET to go from overlay to edit buffer

[Marco Wahl]

Dear Orgers,

Just pushed the little feature "RET to go from overlay to edit buffer".

As always complaints and comments are welcome.


Ciao,
-- 
Marco

Re: [PATCH] Fix outdated o-blog link

[Marco Wahl]

thecashewtrader  writes:

>  org-blog-wiki.org | 2 +-
>  
> -- [[http://renard.github.com/o-blog][o-blog]] :: Stand-alone blogging system 
> that does not require any external
>
> +- [[https://renard.github.io/o-blog-v2/][o-blog]] :: Stand-alone blogging 
> system that does not require any external

Applied, thanks!

Re: [BUG] Typo in manual [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]

[Marco Wahl]

Ignacio Casso  writes:

> I would like to report a minor typo in the manual, although I'm not sure
> if this is the right place (please point me to it if it's not).

Confirmed.

And this is the right place to report this bug.  Thanks!

> In the section Appendix A Hacking -> Using the Mapping API
> (https://orgmode.org/manual/Using-the-Mapping-API.html), it says that
> org-map-entries returns an alist, but it actually returns a list (as
> correctly stated by C-h f org-map-entries).

To me this looks like the documentation in the manual started from the
documentation of the function.  and with time these two documentations
diverged.

What about removing the (diverged) duplication of the documentation of
function org-map-entries from the manual?

Test failure in test-org-colview

[Marco Wahl]

Hello!

Is this just me or does anybody else see these failures with the latest
checkout of main?  

#v+
make test
...
Ran 908 tests, 903 results as expected, 5 unexpected (2022-02-07 12:23:35+0100, 
55.200528 sec)
16 expected failures

5 unexpected results:
   FAILED  test-org-colview/columns-move-left  "Cannot shift this column 
further to the right"
   FAILED  test-org-colview/columns-move-right  "Cannot shift this column 
further to the right"
   FAILED  test-org-colview/columns-new  consp
   FAILED  test-org-colview/columns-next-allowed-value  "Invalid column 
specification format: nil"
   FAILED  test-org-colview/columns-update  "Invalid column specification 
format: nil"
#v-


Thanks in advance for checking,
-- 
Marco

Re: Minor patch for org-attach.el

[Marco Wahl]

Stefan Monnier  writes:

> Here's a patch which cleans up some magic numbers in
> `org-attach.el` and gets rif of the use of the second arg of `commandp`,
> by making `org-attach-commands` accept any commands (including keyboard
> macros).
>
>
> Stefan
>
>
> diff --git a/lisp/org/org-attach.el b/lisp/org/org-attach.el
> index 36c21b7021..bba7fd7690 100644
> --- a/lisp/org/org-attach.el
> +++ b/lisp/org/org-attach.el
> @@ -314,14 +314,14 @@ org-attach
>(concat (mapcar #'caar org-attach-commands)
>   (message msg)
>   (while (and (setq c (read-char-exclusive))
> - (memq c '(14 16 22 134217846)))
> + (memq c '(?\C-n ?\C-p ?\C-v ?\M-v)))
> (org-scroll c t)))
> (and (get-buffer "*Org Attach*") (kill-buffer "*Org Attach*"
>(let ((command (cl-some (lambda (entry)
>   (and (memq c (nth 0 entry)) (nth 1 entry)))
> org-attach-commands)))
> - (if (commandp command t)
> - (call-interactively command)
> + (if (commandp command)
> + (command-execute command)
> (error "No such attachment command: %c" c))
>  
>  (defun org-attach-dir ( create-if-not-exists-p no-fs-check)

Thanks Stefan!

I pushed this to the development branch 'main' of Org.


Bye,
-- 
Marco

Re: how to copy a column of a table (with content)

[Marco Wahl]

Uwe Brauer  writes:

> I sometime have to deal with table that contains large columns and I
> want to copy that columns and modify them a bit.
>
> So I usually just insert an empty column and use kill-rectangle and 
> yank-rectangle.
>
> I am wondering, there seems no 
> org-table-kill-this-column and org-table-yank-this-column.
>
> I found 
>
> https://emacs.stackexchange.com/questions/28270/how-to-select-and-copy-a-column-of-an-org-table-without-rectangle-selection#:~:text=Just%20mark%20the%20beginning%20of,table%2Dpaste%2Drectangle%20).
>
> But it did not work for me.
>
> Any ideas?

I use the following function occasionally.  Possibly it helps in your case.

(defun mw-org-table-mark-column ()
  "Mark the column containing point."
  (interactive)
  (unless (org-at-table-p) (user-error "Not at a table"))
  (org-table-find-dataline)
  (org-table-check-inside-data-field)
  (let* ((col (org-table-current-column))
 (beg (org-table-begin))
 (end (org-table-end)))
(goto-char beg)
(org-table-goto-column col)
(re-search-backward "|" nil t)
(push-mark)
(goto-char (1- end))
(org-table-goto-column (1+ col))
(re-search-backward "|" nil t)
(exchange-point-and-mark)
(forward-char)))

Copy a column would be:

1. Put the cursor into that column.
2. M-x mw-org-table-mark-column
3. Move the cursor onto the |.  E.g. { C-b }.
4. M-x copy-rectangle-as-kill
5. Move the cursor to a suitable position in the first line of the table.
6. M-x yank-rectangle

BTW rectangle-mark-mode -- possibly activated with { C-x SPC } -- can
help with the copy and yank in this case.


HTH,
-- 
Marco

Re: [PATCH] Fix parallel build failure for Texinfo manual

[Marco Wahl]

Max Nikulin  writes:

> On 21/12/2021 19:48, Marco Wahl wrote:
>> 
>>  From my point of view using singuar targets for org.texi and
>> orgguide.texi is the clearest path to go.
>
> It matter of taste. I do not like code duplication.
>
>> I already committed a fix along these lines.  (Hopefully it's okay.)
>
> Thank you for the fix.
>
>> Please let me know if I missed something.
>
> I do not see any really serious issues. However there are room for 
> improvements
>
> %:%.texi org-version.inc
>   $(MAKEINFO) --no-split $< -o $@.info
>
> likely should be
>
> %.info:   %.texi org-version.inc
>   $(MAKEINFO) --no-split $< -o $@
>
> Org files have
>
> #+setupfile: doc-setup.org
>
> but there is no dependency on doc-setup.org in the Makefile
>
> I would prefer to see names of output files specified in the Makefile 
> rather than in org files:
>
> #+export_file_name: orgguide.texi
>
> Ideally it should be a function with input org file and output texi file 
> names as arguments. Currently it is a bit puzzling while reading the 
> Makefile and .el, it is unclear why name of output files are different.
>
> Since nobody complained before, such issues are not urgent.

I think so too.

If someone finds the muse to deal with any of these issues she might
give it a go, please.

Re: [PATCH] Fix parallel build failure for Texinfo manual

[Marco Wahl]

Hi Max!

Max Nikulin  writes:

> On 21/12/2021 04:39, Marco Wahl wrote:
>> Possibly a split of function org-make-manuals in org-make-manual and
>> org-make-guide and further create two single targets instead of the
>> current double target is more clear.
>
> Marco, have you considered the following idea (I have not tested it)?
>
> org.texi orgguide.texi:
>   $(BATCH)  \
> --eval '(add-to-list `load-path "../lisp")' \
> --eval '(load "../mk/org-fixup.el")'\
> --eval '(org-to-texi argv)' $<
> org.texi: org-manual.org
> orgguide.texi: org-guide.org
>
>
> (defun org-to-texi (org-files)
>   "Generate the Texinfo files out of Org manuals."
>(require 'ox-texinfo)
>   (dolist (manual org-files)
> (find-file manual)
> (org-texinfo-export-to-texinfo)))
>
>
> P.S. Frankly speaking I was surprised that make runs command for every
> target, I believed that is a way to specify multiple output files for
> recipes. I had to look into info "(make) Multiple Targets" to realize
> that I was wrong.

Thanks for the idea.  I did not think about the issue this way.

>From my point of view using singuar targets for org.texi and
orgguide.texi is the clearest path to go.  

I already committed a fix along these lines.  (Hopefully it's okay.)

Please let me know if I missed something.

Re: [PATCH] Fix parallel build failure for Texinfo manual

[Marco Wahl]

Ulrich Mueller  writes:

>>>>>> On Mon, 20 Dec 2021, Marco Wahl wrote:
>
>> Possibly a split of function org-make-manuals in org-make-manual and
>> org-make-guide and further create two single targets instead of the
>> current double target is more clear.
>
>> See the patch.
>
>> WDYT?
>
> Sure, that's much cleaner. (I didn't dare to change the elisp code
> because it is also more intrusive.)
>
>> -org.texi orgguide.texi: org-manual.org org-guide.org
>> +org.texi:   org-manual.org org-guide.org
>
> Shouldn't it have only org-manual.org as prerequisite?
>
>>  $(BATCH)  \
>>--eval '(add-to-list `load-path "../lisp")' \
>>--eval '(load "../mk/org-fixup.el")'\
>> -  --eval '(org-make-manuals)'
>> +  --eval '(org-make-manual)'
>> +
>> +orgguide.texi:  org-manual.org org-guide.org
>
> Similar here, only org-guide.org?
>
>> +$(BATCH)  \
>> +  --eval '(add-to-list `load-path "../lisp")' \
>> +  --eval '(load "../mk/org-fixup.el")'\
>> +  --eval '(org-make-guide)'

Yes, thanks.

The issue should be fixed with a slightly more defensive change than
stated in the last patch (by keeping function org-make-manuals.)


Thanks again,
-- 
Marco

Re: [PATCH] Fix parallel build failure for Texinfo manual

[Marco Wahl]

Ulrich Müller  writes:

> * doc/Makefile (org.texi, orgguide.texi): Fix parallel build failure.
> ---
>
> Forwarding Gentoo Linux bug #829055 <https://bugs.gentoo.org/829055>.
> When doing a parallel build (make -j16), a failure was observed when
> building the Texinfo documentation:
>
> make -C doc info
> make[1]: Entering directory 
> '/var/tmp/portage/app-emacs/org-mode-9.5/work/org-mode-release_9.5/doc'
> emacs  -Q -batch --eval '(setq vc-handled-backends nil org-startup-folded 
> nil)' \
>   --eval '(add-to-list `load-path "../lisp")' \
>   --eval '(load "../mk/org-fixup.el")'  \
>   --eval '(org-make-manuals)'
> emacs  -Q -batch --eval '(setq vc-handled-backends nil org-startup-folded 
> nil)' \
>   --eval '(add-to-list `load-path "../lisp")' \
>   --eval '(load "../mk/org-fixup.el")'  \
>   --eval '(org-make-manuals)'
> Loading 
> /var/tmp/portage/app-emacs/org-mode-9.5/work/org-mode-release_9.5/mk/org-fixup.el
>  (source)...
> Loading 
> /var/tmp/portage/app-emacs/org-mode-9.5/work/org-mode-release_9.5/mk/org-fixup.el
>  (source)...
> ...lease_9.5/doc/org.texi locked by portage@local... (pid 55): (s, q, p, ?)? 
> Cannot resolve lock conflict in batch mode
> make[1]: *** [Makefile:31: orgguide.texi] Error 255
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory 
> '/var/tmp/portage/app-emacs/org-mode-9.5/work/org-mode-release_9.5/doc'
> make: *** [mk/targets.mk:127: info] Error 2
>
> Fix by making org.texi a prerequisite of orgguide.texi, with an empty
> recipe.
>
>  doc/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/doc/Makefile b/doc/Makefile
> index 96fda1445..7f996deae 100644
> --- a/doc/Makefile
> +++ b/doc/Makefile
> @@ -27,12 +27,14 @@ guide::   orgguide.texi org-version.inc
>   ../mk/guidesplit.pl $@/*
>  endif
>  
> -org.texi orgguide.texi:  org-manual.org org-guide.org
> +org.texi:org-manual.org org-guide.org
>   $(BATCH) \
> --eval '(add-to-list '"'"'load-path "../lisp")' \
> --eval '(load "../mk/org-fixup.el")' \
> --eval '(org-make-manuals)'
>  
> +orgguide.texi:   org.texi
> +
>  org-version.inc: org.texi
>   @echo "org-version: $(ORGVERSION) ($(GITVERSION))"
>   @echo "@c automatically generated, do not edit"  > org-version.inc

Thanks for the report and the suggestion.

Possibly a split of function org-make-manuals in org-make-manual and
org-make-guide and further create two single targets instead of the
current double target is more clear.

See the patch.

WDYT?


>From cc89632186d63b2078baf446e44ed1425974be5e Mon Sep 17 00:00:00 2001
From: Marco Wahl 
Date: Mon, 20 Dec 2021 22:27:50 +0100
Subject: [PATCH] Fix parallel make of docs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/Makefile: Split multiple target "org.texi orgguide.texi".
* mk/org-fixup.el (org-make-manual, org-make-guide):  New functions.
  (org-make-manuals): Removed.

Reported by Ulrich Müller.  https://list.orgmode.org/uee67g...@gentoo.org/
---
 doc/Makefile| 10 --
 mk/org-fixup.el | 15 ++-
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/doc/Makefile b/doc/Makefile
index 7fb96e65d..5b8639330 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -27,11 +27,17 @@ guide::		orgguide.texi org-version.inc
 	../mk/guidesplit.pl $@/*
 endif
 
-org.texi orgguide.texi:	org-manual.org org-guide.org
+org.texi:	org-manual.org org-guide.org
 	$(BATCH)   \
 	  --eval '(add-to-list `load-path "../lisp")' \
 	  --eval '(load "../mk/org-fixup.el")' 	  \
-	  --eval '(org-make-manuals)'
+	  --eval '(org-make-manual)'
+
+orgguide.texi:	org-manual.org org-guide.org
+	$(BATCH)   \
+	  --eval '(add-to-list `load-path "../lisp")' \
+	  --eval '(load "../mk/org-fixup.el")' 	  \
+	  --eval '(org-make-guide)'
 
 org-version.inc:	org.texi
 	@echo "org-version: $(ORGVERSION) ($(GITVERSION))"
diff --git a/mk/org-fixup.el b/mk/org-fixup.el
index c0eef23cb..e910f0b52 100644
--- a/mk/org-fixup.el
+++ b/mk/org-fixup.el
@@ -27,12 +27,17 @@
 (require 'autoload)
 (require 'org-compat "org-compat.el")
 
-(defun org-make-manuals ()
-  "Generate the Texinfo files out of Org manuals."
+(defun org-make-manual ()
+  "Generate the Texinfo file out of the Org manual."
   (require 'ox-texinfo)
-  (dolist (manual '("../doc/org-manual.org" "../doc/org-guide.org"))
-(find-file manual)
-(org-texinfo-export-to-texinfo)))
+  (find-file "../doc/org-manual.org")
+  (org-texinfo-export-to-texinfo))
+
+(defun org-make-guide ()
+  "Generate the Texinfo file out of the Org guide."
+  (require 'ox-texinfo)
+  (find-file "../doc/org-guide.org")
+  (org-texinfo-export-to-texinfo))
 
 (defun org-make-org-version (org-release org-git-version)
   "Make the file org-version.el in the current directory.
-- 
2.25.1

Re: [BUG] `org-fill-paragraph' doesn't respect formatting

[Marco Wahl]

Tor Kringeland  writes:

> Applying `org-fill-paragraph' to /e.g./
>
>   /Some text./  Some more text.
>
> when `sentence-end-double-space' is t removes the double space to a
> single space.  The same happens with other formatting like *bold* and
> _underline_.  In other instances it is more context aware.  /E.g./
> applying it to
>
>   (Some text.)  Some more text.
>
> does nothing, which is correct.

Confirmed.

This should bring the issue to https://updates.orgmode.org/ I think.


Thanks!

Re: Org-syntax: Intra-word markup

[Marco Wahl]

Hi!

>>> Currently, org syntax doesn't officially seem to support intra-word 
>>> emphasis. Am I missing something?
>>
>> intra-*word* works just fine for me.
>>
>> Best,
>> Ihor
>
> I think what Denis is referring to is a construction of the type
> *intra*word, which, if I'm not mistaken, is not supported and can only
> be achieved by inserting a zero width space.

Is there a recommended way to insert a zero with space?

BTW occasionally I use

(defun mw-insert-zero-width-whitespace ()
  "Insert a space with zero width."
  (interactive)
  (insert ?\x200B))


Thanks and ciao,
-- 
Marco

Re: [PATCH] Fix org-comment-line-break-function

[Marco Wahl]

Tim and all!

>> diff --git a/lisp/org.el b/lisp/org.el
>> index 1a1375461..fdeec0d67 100644
>> --- a/lisp/org.el
>> +++ b/lisp/org.el
>> @@ -19695,7 +19695,8 @@ non-nil."
>>(save-excursion (forward-char -1) (delete-horizontal-space))
>>(delete-horizontal-space)
>>(indent-to-left-margin)
>> -  (insert-before-markers-and-inherit fill-prefix))
>> +  (when fill-prefix
>> +(insert-before-markers-and-inherit fill-prefix)))
>>  
>> I don't have anything better.  I think this is a good patch.  It makes
>> M-j work again.
>>
>> Possible refinements and improvements can follow.
>>
>> +1 for applying of your patch.
>
> I was finally able to reproduce the error. It depends to some degree on
> the text in the buffer and where the cursor is when you hit M-j. Adding
> some additional text and moving the cursor to different locations
> enabled me to reproduce the error and I now agree it is a bug in
> org-comment-line-break-function.
>
> I don't know if your patch is the right fix or not because I don't
> understand what the purpose of insert-before-marks-and-inherit is - in
> fact, the doc string for that function doesn't even state what the @rest
> args argument is for, so I don't understand why it is passing in
> fill-prefix. For example, is it safe to assume
> insert-before-merks-and-inherit does not need to be called if
> fill-prefix is nil? Why is that function even called with the
> fill-prefix as an argument? 

Thanks for staying critical!

I can't answer your questions.  I agree that we should deepen the
understanding.  Your questions are a start.

Pragmatically I still vote for applying the patch immediately since it
is a step in the right direction AFAICS.


Ciao,
-- 
Marco

Re: [PATCH] Fix org-comment-line-break-function

[Marco Wahl]

Hi Richard and all,

[...]

> Just to be extra, super sure, I built Emacs this afternoon from a
> checkout of the repo, and the error is *still* there, with the same
> cause. In that build, with emacs -Q, I have:
>
> (org-version)
> "9.5"
>
> (emacs-version)
> "GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo 
> version 1.16.0)
>  of 2021-11-30"
>
> At this point I've replicated the bug on my machine in four different
> builds of Emacs (version 26.1 from Debian, 27.2 and "emacs-next" from
> Guix, and version 29.0.50 I built myself from source) with several
> versions of Org (the built-in ones in these Emacsen and a recent build
> of the bugfix branch). It is robustly reproducible for me, and the cause
> is clear: default-indent-new-line calls org-comment-line-break-function,
> which calls
>
> (insert-before-markers-and-inherit nil)
>
> which is a type error. I'm looking for help figuring out what the right
> fix is. I attach a patch for the simplest fix I can think of; please let
> me know if something else would be better.

diff --git a/lisp/org.el b/lisp/org.el
index 1a1375461..fdeec0d67 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19695,7 +19695,8 @@ non-nil."
   (save-excursion (forward-char -1) (delete-horizontal-space))
   (delete-horizontal-space)
   (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
+  (when fill-prefix
+(insert-before-markers-and-inherit fill-prefix)))
 
I don't have anything better.  I think this is a good patch.  It makes
M-j work again.

Possible refinements and improvements can follow.

+1 for applying of your patch.


Ciao,
-- 
Marco

Re: epresent font increase ?

[Marco Wahl]

Jean-Christophe Helary  writes:

> I'm trying to increase the overall font for an epresent slide show
> that I'm presenting in 37 minutes and I keep getting this
> "face-attribute: Invalid face: epresent-content-face" message...
>
> My screen is a 15" and running that full screen makes the contents difficult 
> to read.
>
> Any solution ?

Switch to the newer epresent at https://github.com/eschulte/epresent.


Shooting into the dark,
-- 
Marco

Re: how to get verbatim text with line breaks

[Marco Wahl]

"Christopher W. Ryan"  writes:

> I have this in an org file
>
> 0,Mon [start_plus_0] at 03:00 PM
> 30,Mon [start_plus_0] at 03:30 PM
> 60,Mon [start_plus_0] at 04:00 PM
> 90,Mon [start_plus_0] at 04:30 PM
> 120,Mon [start_plus_0] at 05:00 PM
>
> I want to export to ASCII text and have it look exactly like that, 5 lines.
>
> Doing nothing, I get 3 lines
>
> 0,Mon [start_plus_0] at 03:00 PM 30,Mon [start_plus_0] at 03:30 PM
> 60,Mon [start_plus_0] at 04:00 PM 90,Mon [start_plus_0] at 04:30 PM
> 120,Mon [start_plus_0] at 05:00 PM

(info "(org) Paragraphs")

Paragraphs are separated by at least one empty line.  If you need to
enforce a line break within a paragraph, use ‘\\’ at the end of a line.


HTH,
-- 
Marco

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Marco Wahl]

Thanks Eric and Max!

> On Wednesday, 13 Oct 2021 at 19:23, Max Nikulin wrote:
>> Does someone have settings that pins help buffer to particular
>> window/frame of location in a frame (e.g. bottom of "sidebar")?
>
> This is what I use, which is slightly more complex because I have a wide
> landscape monitor and a tall portrait one and want different behaviour
> in each:
>
> #+begin_src emacs-lisp
>   (defun esf/display-buffer-in-side-window (buffer alist)
> (let ((fw (/ 80.0 (frame-width
>   (display-buffer-in-side-window buffer
>  (if (> (frame-width) 120)
>  (list (cons 'window-width fw)
>'(side . left)
>'(slot . 0))
>'((window-height . 0.25)
>  (side . bottom)
>  (slot . 0))
>   (setq display-buffer-alist
> '(("^\\*Async Shell Command*" . (display-buffer-no-window))
>   ("^magit-[a-z]+: " . (esf/display-buffer-in-side-window))
>   ("\\*\\(Backtrace\\|Compile-Log\\|DICT 
> .*\\|grep\\|[Hh]elp.*\\|Messages\\|Occur\\|tex-shell\\|vc-\\(diff\\|change-log\\)\\|Warnings\\|WoMan
>  .*\\)\\*"
>(esf/display-buffer-in-side-window
> #+end_src
>
> This doesn't pin to a specific frame but does make the pop-ups appear in
> the same place always in each respectively frame.  By the way, I use
> exwm so I have one frame per monitor, full screen, generally.

Thanks for the example and the implied teaching!

I experimented with the use of display-buffer-alist and the org-goto UI.
E.g. with the config:

(defun experiment/202110141141 (buffer alist)
  (display-buffer-in-side-window
   buffer
   (list '(window-width . 23)
 '(side . right)
 '(slot . 0

(setq display-buffer-alist
  '(("\\*Org Help\\*" . (experiment/202110141141

AFAICS this has an effect for org-goto.  The user can control the
appearance of the org-goto UI.

BTW I think the name *Org Help* for the UI buffer could be better.

Since org-goto in main is still broken I'll commit the fix for org-goto
which kicks out the use of the macro org-no-popups (but not the macro
itself since it's used elsewhere AFAICS.)

Max, Ihor!  If you see the necessity of refinement please keep going!  


Best regards,
-- 
Marco

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Marco Wahl]

Thanks Ihor!

> Marco Wahl  writes:
>
>> My feeling is that the "protection" is good intention but brings more
>> harm than good.  I think it's not a good idea to enforce a certain
>> window setting.  I guess the knowing user has an easier path to fine
>> tune the org-goto user interface when there is less "protection".
>
> I fully agree. That was the motivation behind removing
> dislpay-buffer-alist in 399481bad1. It is indeed not a good idea to
> overwrite user customisations. They can be deliberate. For example, see
> https://orgmode.org/list/87h7ij12t8.fsf@localhost
>
> Max Nikulin  writes:
>> However current version of macro does not protect against
>> 
>>(setq display-buffer-base-action
>>   '((display-buffer-reuse-window display-buffer-pop-up-frame)
>> (reusable-frames . 0)))
>> 
>> The example is taken from (info "(elisp) Choosing Window Options"). I 
>> have no idea if such customization can be considered as shooting a foot.
>
> display-buffer-base-action, if customised by user, can later be
> fine-tuned using display-buffer-alist. If necessary, the user can easily
> add org-goto popup as an exception. At least, it is my understanding
> from reading docs.
>
> However, pop-up-frames and pop-up-windows are different beasts. They
> cannot be fine-tuned by the user to not affect org-goto.  AFAIK, the
> only way for the user to overcome the problem would be advicing
> org-goto.
>
>> Summary: The org-goto interface today is somewhat broken.  I vote for
>> taking the occasion and kicking out the macro org-no-popups entirely.
>> This way the org-goto interface is functional AFAICS.  If problems occur
>> on that path we'll take care and action.
>>
>> Do you agree?
>
> My second version of the patch also fixes org-goto interface :)

Indeed, thanks.

> On the other hand, kicking org-no-popups macro completely may be an
> option. pop-up-windows and pop-up-frames are obsolete and should not be
> used anymore.
>
> Also, a compromise could be changing org-no-popups to just
> (let (pop-up-frames) ...)
>
> WDYT?

Clearly I'm for kicking out org-no-popups completely.  Many details have
been mentioned already.  The big argument for that change for me is that
the code gets simpler.

But that's just me.  All the other fixes may have advantages too.  In
the first place I want back a usable org-goto interface.

I'd like to leave it to you to commit a fix.


Best regards,
-- 
Marco

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Marco Wahl]

Hi Max and all!

> On 08/10/2021 17:22, Marco Wahl wrote:
>> Max Nikulin writes:
>>> On 05/10/2021 23:32, Ihor Radchenko wrote:
>>>> Max Nikulin writes:
>>>> I tried come up with the reason why org-no-popup was used in the
>>>> initial
>>>> implementation. I think, the reason is avoiding situation like what you
>>>> may see after running
>>>> (let ((pop-up-frames t)) (funcall-interactively #'org-goto))
>>>> So, removing the macro completely is not a good idea.
>>>> I have updated the patch that should work without dropping the
>>>> macro.
>>>> See the attached.
>>
>> Please note the documentation of variable `pop-up-windows'.
>>
>>  This variable is provided mainly for backward compatibility and
>>  should not be used in new code.
>>
>> The same holds for `pop-up-frames'.
>>
>> The drop of the macro looks like a good idea to me.  Can someone please
>> describe the price for dropping macro `org-no-popups'?
>>
>> @Ihor I do not understand what "situation" you mean.
>
> Marco, have you tried
>   (setq pop-up-frames t)
> with first version of patch? It shows help in a new separate frame.
> Unsure if it is expected behavior even with such customization.
>
> However current version of macro does not protect against
>
>   (setq display-buffer-base-action
> '((display-buffer-reuse-window display-buffer-pop-up-frame)
>   (reusable-frames . 0)))
>
> The example is taken from (info "(elisp) Choosing Window Options"). I
> have no idea if such customization can be considered as shooting a foot.

TBH I don't fully understand that display-buffer stuff.  I experimented
a little with regards to org-goto.

AFAICT org-goto does a good job without macro org-no-popups.  

IIUC the use of macro org-no-popups in org-goto shall "protect" the
org-goto user interface in some sense.  You already mentioned that.

My feeling is that the "protection" is good intention but brings more
harm than good.  I think it's not a good idea to enforce a certain
window setting.  I guess the knowing user has an easier path to fine
tune the org-goto user interface when there is less "protection".

> http://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=399481bad10845a77f210c9320ff1efee9a312c8
> that caused the current problem changed namely `pop-up-windows'

Thanks for the link!

AFAICT the change in org-macs.el should not be in that commit since it
has nothing to do with org links -- which are the actual concern of that
commit.  And indeed the change in org-macs.el of that commit broke the
org-goto interface some.

Summary: The org-goto interface today is somewhat broken.  I vote for
taking the occasion and kicking out the macro org-no-popups entirely.
This way the org-goto interface is functional AFAICS.  If problems occur
on that path we'll take care and action.

Do you agree?


Regards,
-- 
Marco

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Marco Wahl]

Max Nikulin  writes:

> On 05/10/2021 23:32, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> I tried come up with the reason why org-no-popup was used in the
>> initial
>> implementation. I think, the reason is avoiding situation like what you
>> may see after running
>> (let ((pop-up-frames t)) (funcall-interactively #'org-goto))
>> So, removing the macro completely is not a good idea.
>> I have updated the patch that should work without dropping the
>> macro.
>> See the attached.
>
> Thank you, Ihor.
>
> Your updated patch works in default configuration (-Q). I am not
> familiar with knobs of `display-buffer' function so I have no idea if
> someone may complain that such variant overrides his setup or works
> incorrectly with his preferences.

Please note the documentation of variable `pop-up-windows'.

This variable is provided mainly for backward compatibility and
should not be used in new code.

The same holds for `pop-up-frames'.

The drop of the macro looks like a good idea to me.  Can someone please
describe the price for dropping macro `org-no-popups'?

@Ihor I do not understand what "situation" you mean.

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: shrink table in columnmode view (poor man's issue system)

[Marco Wahl]

Hi all!

Bastien  
> Uwe Brauer  writes:
>> Thank you for the code! As I said, your code should be included. If you
>> have write access please push it.

Thanks Uwe.

> It's up to the maintainers to decide for pushing changes, and to
> regular contributors, for areas they feel confident they can push,
> like Marco does regularily (thanks).

Thanks Bastien.

> I don't see any patch in this thread - am I missing something?

There is no patch yet.  But I think the idea of Uwe is worthy to be
discussed.

Let me present the idea of Uwe with his columnview dynamic block example
(a little bit simplified.)

With the current state in Org one could get the following columnview
block in a respective Org file.

#+BEGIN: columnview :format "%10ITEM(Problem) %5Is(Issue)"
| Problem   | Issue |
| Issues|   |
| Why is this item s wide ? | 9 |
#+END:

The idea is to add a line with width indicators taken from the column
format.  Here (it is the first table line):

#+BEGIN: columnview :format "%10ITEM(Problem) %5Is(Issue)"
| <10>  | <5>   |
| Problem   | Issue |
| Issues|   |
| Why is this item s wide ? | 9 |
#+END:

This would allow to use the C-c TAB feature to control the widths of the
columns.

We realized this using a newly defined personal dynamic block as
described in (info "(org) Dynamic Blocks").  Concretely:

(defun org-dblock-write:columnview2 (params)
  "Write the column view table.

Like org-dblock-write:columnview but write a line with shrink widths 
taken from the
column view format.

PARAMS is the same as in `org-dblock-write:columnview'."
  (insert (format "|%s|\n"
  (mapconcat
   (lambda (x) (concat "<" (number-to-string x) ">"))
   (mapcar (lambda (x) (nth 2 x)) 
(org-columns-compile-format
  (plist-get params 
:format)))
   "|")))
  (org-dblock-write:columnview params))

I think the idea is good.  But possibly the extra line is too much for
some people.  Further I'm sure that the code can be improved and I don't
feel 100% confident in this dynamic block area.


Best regards!

Re: behavior of (org-insert-heading-respect-content)

[Marco Wahl]

Bastien!

> Marco Wahl  writes:
>
>> Would be great if you could test the fix.
>
> If you're confident with the fix, please go ahead and push the commit.

This has been committed some days ago.  See


https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=069bcba529142bdb91647258924513f0fb0f3fa1

Re: shrink table in columnmode view (poor man's issue system)

[Marco Wahl]

Hi!

Uwe Brauer  writes:
> I use the following org file to organise my issues.
> It works quite well, however I would like to have a shrink option
> automatically in my columnview.

Your suggestion looks quite useful to me.

> Any idea how to achieve that?

One possibility is to write your own dynamic block writer function.
Find documentation at (info "(org) Dynamic Blocks") .

> File starts here:
>
> #+begin_src 
> #+STARTUP: shrink
>
> * Issues
>:PROPERTIES:
>:COLUMNS:  %50ITEM(Problem) %10Is(Issue Nr) %7TODO(Status) %26TAGS(Which) 
> %17Date(Date) %7STATUS(Status){X/} 
>:ID:   Issues
>:END:
>
> ** TODO Why is  \eqref{eq:section4-sh15}: not used in the proof of 
> proposition 5 (section 4)
>:PROPERTIES:
>:ID:   Issues
>:Date: <2021-09-25 sáb>
>:STATUS:   [ ]
>:Is:   9
>:END:
>
> The table is generated like this
> #+BEGIN: columnview  :hlines 2 :skip-empty-rows t :indent nil  :format 
> "%5ITEM(Problem) %5Is(Issue) %12TODO  %12Date %7Status(Status){X/}"
> | Problem 
>  | Issue | TODO | Date | Status |
> |--+---+--+--+|
> | Issues  
>  |   |  |  | [0/1]  |
> |--+---+--+--+|
> | Why is  \eqref{eq:section4-sh15}: not used in the proof of proposition 5 
> (section 4) | 9 | TODO | <2021-09-25 sáb> | [ ]|
> #+END:
>
>
> But I would like to have this
>
> #+BEGIN: columnview  :hlines 2 :skip-empty-rows t :indent nil  :format 
> "%5ITEM(Problem) %5Is(Issue) %12TODO  %12Date %7Status(Status){X/}"
> |<45>
> | Problem 
>  | Issue | TODO | Date | Status |
> |--+---+--+--+|
> | Issues  
>  |   |  |  | [0/1]  |
> |--+---+--+--+|
> | Why is  \eqref{eq:section4-sh15}: not used in the proof of proposition 5 
> (section 4) | 9 | TODO | <2021-09-25 sáb> | [ ]|
> #+END:
>
> #+end_src 

Concretely check out this proposition (tested with your example).  Have

(defun org-dblock-write:columnview2 (params)
  "Write the column view table.

Like org-dblock-write:columnview but write a line with shrink widths 
taken from the
column view format.

PARAMS is the same as in `org-dblock-write:columnview'."
  (insert (format "|%s|\n"
  (mapconcat
   (lambda (x) (concat "<" (number-to-string x) ">"))
   (mapcar (lambda (x) (nth 2 x)) 
(org-columns-compile-format
  (plist-get params 
:format)))
   "|")))
  (org-dblock-write:columnview params))

defined.  E.g. type C-x C-e after the last paren.

Then use "columnview2" instead of "columnview" and get

#+BEGIN: columnview2  :hlines 2 :skip-empty-rows t :indent nil  :format 
"%5ITEM(Problem) %5Is(Issue) %12TODO  %12Date %7Status(Status){X/}"
| <5>   
   | <5>   | <12> | <12> | <7>|
| Problem   
   | Issue | TODO | Date | Status |
|--+---+--+--+|
| Issues
   |   |  |  | [0/1]  |
|--+---+--+--+|
| Why is  \eqref{eq:section4-sh15}: not used in the proof of proposition 5 
(section 4) | 9 | TODO | <2021-09-25 sáb> | [ ]|
#+END:


HTH

[PATCH] CONTRIBUTE: Update to follow the new structure of doc/

[Marco Wahl]

---
 CONTRIBUTE | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CONTRIBUTE b/CONTRIBUTE
index a68771703..94d471a0f 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -42,7 +42,7 @@ Org maintenance is detailed on Worg: see 
[[https://orgmode.org/worg/org-maintena
  applies are:
 
  - all *.el files in the lisp directory of the repository
- - org.texi, orgcard.tex in the doc/ directory
+ - orgcard.tex and all *.org files in the doc/ directory
 
- Before making any significant changes, please explain and discuss
  them on the mailing list 
[[mailto:emacs-orgmode@gnu.org][emacs-orgmode@gnu.org]].
-- 
2.17.1

Re: [PATCH] Fix some typos

[Marco Wahl]

Please don't top post!  Hopefully there is consent about using the
bottom posting style on this list.

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 patch!

I agree to change the Shakespeare part to have a reference and be
corrected accordingly.

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.

AFAICS thy patch mught apply!

Re: Switching to new Git repositories

[Marco Wahl]

William Denton  writes:

> I'm seeing exactly the same, and the suggested rebase commands didn't change 
> it.
>
> I wonder if it's related to a problem I have on one of the two
> machines (both Ubuntu, with identical setups) where I run Org from
> source.
>
> On one, when I switched to the new repo, I got this on startup:
>
> Error (use-package): org/:catch: Invalid version syntax: ‘9.5-dev’
>
> I can't see what causes that.  I use use-package to set up Org in my
> init file¹ but it seems to be some internal problem, because I don't
> mention anything about versions.
>
> What's more, on my other machine, where everything about Emacs is
> identical, it works without any problem (even though there are no
> tags).

Sounds like a weird issue.  I don't think this 9.5-dev tag is something
from the Org repo.

Have you already tried to turn it off and on again?  I.e. delete your
local repo and start with a fresh clone?

Of course take care not to loose any data important to you!


HTH

Re: Switching to new Git repositories

[Marco Wahl]

Hi!

Colin Baxter  writes:

>> Nick Dokos  writes:
>
> > FWIW, I get $ git remote -v upstream
> > https://git.savannah.gnu.org/git/emacs/org-mode.git (fetch)
> > upstream https://git.savannah.gnu.org/git/emacs/org-mode.git
> > (push)
>
> > $ git tag | wc -l 386
>
> > Maybe do
>
> > $ git remote update $ git rebase
>
> > and try again?
>
> Doesn't work for me. I did all above but still get zero for git tag | wc

What about adding the still existing Org repo temporarily and fetching
the tags from there?

Example:

cd PATHTOORGMODE
git remote -v
git remote add olderrepo https://code.orgmode.org/bzg/org-mode.git
git remote -v
git fetch olderrepo 'refs/tags/*:refs/tags/*'
git remote remove olderrepo
git remote -v

Enjoy the tags in your local repo!

I guess the maintainers will push the right tags to the new repo soon.

Re: [PATCH] Fix some typos

[Marco Wahl]

Max Nikulin  writes:

> Please, forgive my ignorance of Shakespeare's poetry.

Ignorance is bliss!  (Sophocles)

> On 17/09/2021 17:05, Marco Wahl wrote:
>>> On 17/09/2021 04:40, Stefan Kangas wrote:

>>>> Please find attached another clean-up patch that fixes a small
>>>> number of typos. > > Thou shall not change "memeory" to "memory" tho

> I think, a bit more is required to avoid recurring attempts to change
> spelling if you would like to see such variant. Static code analyzers
> usually have a feature that allows to ignore specific warning at a
> particular line, see e.g.
> https://flake8.pycqa.org/en/latest/user/violations.html#in-line-ignoring-errors
> for Python's flake8.
>
> Maybe "LocalWords:" could do a similar trick for ispell.el at least for
> the whole file. Unsure if it is possible to add an exception for the
> quote only.

Interesting ideas!  

> However there is namely "memory" in the "1609 Quarto", see e.g.
> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
> as in the Org manual do not mention the source (particular edition). I
> hope, I just do not know what is considered as the canonical variant for
> not so old language.

Same here.  I have no idea.

What I found suspicious, was the correction occurring in a quote
section.  But you are right.  Since there is no reference to the source
the correction is worthy AFAICS.

If I'd be the only committer, I'd leave the "memeory" anyway.  But go
ahead and change the occurance to "memory" if you like.  I won't try to
stop you.

Re: Switching to new Git repositories

[Marco Wahl]

Thanks you both!

Thanks to you I use a suitable reference to the repo now!  My first
tiny commit landed in the new repo AFAICS.

Note that I had wrongly filled out the form for the ssh-key on the
savannah platform.  Clearly this is my fault.  BTW the documentation is
all there on the savannah page (or linked.)

Eli and friends added me to the system a while ago--professional as
always.

Further I'll also try to have a look at the CONTRIBUTE file after it
will have been updated.  Of course!


Thanks again and have a nice day!

Re: Switching to new Git repositories

[Marco Wahl]

Hi Bastien,

Thanks for all!

> from now on, here are the official Org repositories:
>
> - org-mode: https://git.savannah.gnu.org/cgit/emacs/org-mode.git
> - worg: https://git.sr.ht/~bzg/worg
> - orgweb: https://git.sr.ht/~bzg/orgweb
>
> org-contrib will continue to be on https://git.sr.ht/~bzg/org-contrib
> until it disappears, thanks to volunteers taking over maintainance of
> the various packages.
>
> You can forget code.orgmode.org.
>
> If you commit to code.orgmode.org by mistake instead of using the new
> repos, just merge the commit from the old repo that you can set up as
> a remote branch: I won't delete code.orgmode.org until Org 9.6.
>
> If you don't have write access to the new repos and think you should,
> please send me an email.

My first attempt to commit to the new repo
https://git.savannah.gnu.org/cgit/emacs/org-mode.git failed.

Would you mind to describe what preconditions are needed to be able to
commit?  Is it just a question of using the right URL at clone time?

Would you even update file CONTRIBUTE respectively? (Which still refers
to code.orgmode.org.)

Re: behavior of (org-insert-heading-respect-content)

[Marco Wahl]

Victor!

> Le 13 Sep 2021, Marco Wahl  a écrit :
>
>> As far is I see it, the intended behavior of
>> org-insert-heading-respect-content with point before the first heading
>> is to
>>
>> - insert the new heading immediately before the first heading.  Respect
>>   the content!
> Hi Marco !
>
> I agree with you. But this does not work. Say I have a buffer with this 
> content :
>
> put point HERE and C-
> Some more stuff 
> * Heading
> content
>
>
> When point is at HERE and I C-, org inserts a new asterisk on
> the after "stuff", but  on the same line → not a proper heading.
>>
>> - If there is no heading at all in the file the heading shall be
>>   inserted at the bottom of the file.
>
> Yes. But I get the same behavior with 
>
> put point HERE and C-
> Some more stuff 
>
> The asterisk is inserted right after "stuff", on the same line → not
> a proper heading.
>
>>
>> Do we agree on the desired behavior of
>> org-insert-heading-respect-content?
>
> Yes, we do!
>>
>> With your proposition the respect for the content gets lost,
>> doesn't it?
>
> Yes, you’re right. It currently does not respect the content before
> first heading. Therefore it’s not a fix for the behavior of
> org-insert-heading-respect-content.
> It’s just the quickest workaround I’ve come up with to make my own
> function work (in my use-case, when I call that function, either point
> is at point-min in a brand new buffer, or point is below the first
> heading).

Okay, thanks for clarifying.

Would be great if you could test the fix.


Thank you!

Re: [PATCH] Fix some typos

[Marco Wahl]

Timothy and Stefan!

Praise thy effort!

Thou shall not change "memeory" to "memory" tho!


Thy nittpicker!

Re: [PATCH] Various minor docfixes found by checkdoc

[Marco Wahl]

Stefan Kangas  writes:

> The attached patch cleans up some style errors in docstrings and
> comments that were found by checkdoc.

Thanks Stefan!

Your patch has been applied.

Re: Bug: doc string for "org-end-of-meta-data"

[Marco Wahl]

Hi Tom,

> You make sense. What you propose to substitute is easier to understand and
> concise: 
>
>  When FULL is non-nil but not t, skip planning information, 
>  properties, clocking lines and logbook drawers.

Thank you for the report and the confirmation!

I just committed accordingly.


Bye

Re: Bug: doc string for "org-end-of-meta-data"

[Marco Wahl]

Hello Tom,

> I believe the last paragraph of the doc string for the function
> "org-end-of-meta-data" contains an error. That one-sentence paragraph
> currently reads:
>
> When FULL is non-nil but not t, skip planning information, 
> clocking lines and only non-regular drawers, i.e. properties 
> and logbook drawers.
>
> I believe that should be "regular drawers," not "non-regular drawers." IMO,
> the last paragraph could be clearer were it rewritten as follows:
>
>When FULL is non-nil but not t, skip only planning information, 
>clocking lines and regular drawers, i.e. properties and logbook 
>drawers. If any non-regular drawers exist and do not follow the 
>two regular drawers, stop at the first non-regular drawer instead.
>
> I believe that this expansion of the paragraph corrects the error and adds
> coverage of a rare case.

I think the use of the word "regular" is not a good idea in their
documentation of org-end-of-meta-data.  I could not find any occurance
of the term "regular drawer" in the org-info manual.  There is a section
where the property drawer is called "special".

In conclusion I'd say that the logic of the recent documentation is okay
with "regular" meaning "non-special".

Finally I propose to remove completely the categorisation due to
"regular" from the documentation.  Which reads:

 When FULL is non-nil but not t, skip planning information, 
 properties, clocking lines and logbook drawers.

WDYT?

Re: behavior of (org-insert-heading-respect-content)

[Marco Wahl]

Hi Victor,

> Le 09 Sep 2021, Marco Wahl  a écrit :
>
>> My impression is that org-insert-heading-respect-content should be
>> called only with point in a subtree.
>>
>> The fix would be to signal an error when point is not located in a
>> subtree.
>>
>> Does this sound reasonable?
>
> In a way, yes. I guess that the error would not appear too often.
> But falling back gracefully to org-insert-heading could be even
> better, especially when org-insert-heading-respect-content is called
> from Lisp (rather than interactively).
>
> For now, I use this and it seems to do the job:
>
> #+begin_src elisp
>   (if (equal 1 (line-number-at-pos nil t))
> (org-insert-heading)
>   (org-insert-heading-respect-content))
> #+end_src
>
> If I’m not mistaken, org-insert-heading-respect-content works as
> expected even when point is not in a subtree. It seems to only fail if
> point is on the 1st line.

As far is I see it, the intended behavior of
org-insert-heading-respect-content with point before the first heading
is to

- insert the new heading immediately before the first heading.  Respect
  the content!

- If there is no heading at all in the file the heading shall be
  inserted at the bottom of the file.

Do we agree on the desired behavior of
org-insert-heading-respect-content?

With your proposition the respect for the content gets lost, doesn't it?


Ciao!

Re: behavior of (org-insert-heading-respect-content)

[Marco Wahl]

Hi!

"Victor A. Stoichita"  writes:

> I see the following behavior which seems erroneous to me :
> - When I issue (org-insert-heading-respect-content) in a brand new org
>   buffer, with point at point-min I get the error "Beginning of buffer"
>   and no heading is inserted.
> - If I write something on the 1st line, say "test", but no newline, and
>   then issue (org-insert-heading-respect-content), the result is :
>   "test  * " which is not a properly formatted heading
> - Only if there is a newline before point does
>   (org-insert-heading-respect-content) insert a proper heading. 
>
> Am I getting something wrong or is this a bug ?

I think so.

My impression is that org-insert-heading-respect-content should be
called only with point in a subtree.

The fix would be to signal an error when point is not located in a
subtree.

Does this sound reasonable?

Re: Bug: Error making documentation 9.4.6

[Marco Wahl]

>> [... issue with make doc ...]

> Sorry about that, I'm new in contributing to org. I found the solution
> in the mailing list[1]. There was an old version of `makeinfo'.

> [1]
> 

Good to know.


Thanks Daniel!
-- 
Marco

Re: Bug: Error making documentation 9.4.6

[Marco Wahl]

Daniel Fleischer  writes:

> Hi,
>
> Pulling master @ 1690fbd88, calling `make doc' leads to error:
>
>
> org-version: 9.4.6 (release_9.4.6-635-g1690fb)
> makeinfo --no-split org.texi -o org.info
> org.texi:6: warning: unrecognized encoding name `UTF-8'.
> org.texi:810: Unknown command `arrow'.
> org.texi:810: Misplaced {.
> org.texi:810: Misplaced }.
> org.texi:810: Unknown command `arrow'.
> org.texi:810: Misplaced {.
> org.texi:810: Misplaced }.
> org.texi:821: Unknown command `arrow'.
> org.texi:821: Misplaced {.
> org.texi:821: Misplaced }.
> org.texi:2627: Unknown command `arrow'.
> org.texi:2627: Misplaced {.
> org.texi:2627: Misplaced }.
> org.texi:2629: Unknown command `arrow'.
> org.texi:2629: Misplaced {.
> org.texi:2629: Misplaced }.
> org.texi:3548: Unknown command `arrow'.
> org.texi:3548: Misplaced {.
> org.texi:3548: Misplaced }.
> org.texi:3548: Unknown command `arrow'.
> org.texi:3548: Misplaced {.
> org.texi:3548: Misplaced }.
> makeinfo: Removing output file `org.info' due to errors; use --force to 
> preserve.
> make[1]: *** [org] Error 1
> make: *** [info] Error 2

Can't reproduce this on my machine.


Best regards
-- 
Marco

Re: org-attach-sync uses directory-empty-p (new in Emacs 28)

[Marco Wahl]

Maxim Nikulin  writes:

>>> Compiling single /home/ubuntu/org-mode/lisp/org-compat.el...
>>>
>>> In end of data:
>>> org-compat.el:1255:1:Warning: the function ‘directory-empty-p’ is not
>>> known to
>>>  be defined.

> I have never fought with this kind of problem. After looking at the
> other constructs in the org-compat.el file, I have tried
>
> (if (fboundp 'directory-empty-p)
> (defalias 'org-directory-empty-p #'directory-empty-p)
>   (defun org-directory-empty-p (dir)
> ; ...
>
> I have no idea if there are any drawbacks of such approach, I can only
> say that such form suppresses the warning.

Thanks Maxim and Kyle!

The latter suggestion landed in master a few minutes ago.


Have a great day!
--
Marco

Re: org-attach-sync uses directory-empty-p (new in Emacs 28)

[Marco Wahl]

Maxim Nikulin  writes:

> On 11/08/2021 03:52, Marco Wahl wrote:
>>> Kyle Meyer  writes:
>>>
>>>> In 61e083732 (org-attach: Possibly delete empty attach directory,
>>>> 2021-07-09), you added a call to directory-empty-p.  This function was
>>>> introduced in Emacs's 0806075520 (Add directory-empty-p and new argument
>>>> COUNT for directory-files-*, 2020-11-02) and hasn't yet made it into a
>>>> release.
>>>>
>>>> Could you update org-attach-sync to avoid using directory-empty-p (e.g.,
>>>> by inlining it or by adding a compatibility alias)?
>> Starting from Arthur's suggestion and Kyle's hint to the
>> compatibility
>> alias I put org-directory-empty-p into org-compat.el.  So there is
>> org-directory-empty-p now which provides the functionality of
>> directory-empty-p from Emacs 28 for smaller version Emacsen.
>
> Unfortunately current code causes a compiler warning at least when
> Emacs-25.2 is used:
>
> Compiling single /home/ubuntu/org-mode/lisp/org-compat.el...
>
> In end of data:
> org-compat.el:1255:1:Warning: the function ‘directory-empty-p’ is not
> known to
> be defined.

Thanks.

How make the compiler happy?

What about adding a declare-function for directory-empty-p?  Suggestion
for org-compat.el:

#+begin_src emacs-lisp
;;; Emacs < 28.1 compatibility
(if (version< emacs-version "28")
(defun org-directory-empty-p (dir)
  "Return t if DIR names an existing directory containing no other files."
  (and (file-directory-p dir)
   (null (directory-files dir nil directory-files-no-dot-files-regexp 
t
  (declare-function directory-empty-p "files" (dir)) ; <-- NEW LINE TO MAKE THE 
COMPILER HAPPY.
  (defalias 'org-directory-empty-p #'directory-empty-p))
#+end_src

Could you please check the compile with this modification?


Best regards,
-- 
Marco

Re: org-attach-sync uses directory-empty-p (new in Emacs 28)

[Marco Wahl]

Arthur Miller  writes:

> Kyle Meyer  writes:
>
>> In 61e083732 (org-attach: Possibly delete empty attach directory,
>> 2021-07-09), you added a call to directory-empty-p.  This function was
>> introduced in Emacs's 0806075520 (Add directory-empty-p and new argument
>> COUNT for directory-files-*, 2020-11-02) and hasn't yet made it into a
>> release.
>>
>> Could you update org-attach-sync to avoid using directory-empty-p (e.g.,
>> by inlining it or by adding a compatibility alias)?

> Can this help:
>
> #+begin_src emacs-lisp
>
> (when (version< emacs-version "28")
>   (defun directory-empty-p (file-name)
> "Check if a directory contains any other files then dot-files"
> (when (file-directory-p file-name)
>   (null (directory-files file-name nil
>  directory-files-no-dot-files-regexp t)
>
> #+end_src

Thanks Kyle and Arthur!

Starting from Arthur's suggestion and Kyle's hint to the compatibility
alias I put org-directory-empty-p into org-compat.el.  So there is
org-directory-empty-p now which provides the functionality of
directory-empty-p from Emacs 28 for smaller version Emacsen.

org-directory-empty-p is defined in org-compat.el.  From there
org-directory-empty-p can (and hopefully will) be easily dropped when
the minimum required Emacs version for Org switches to 28.


Thanks again and best regards,
--
Marco

Re: Headings and Headlines

[Marco Wahl]

André A. Gomes  writes:

> The project's documentation refers to headings and headlines as
> synonyms.  Relying on a single definition would be beneficial.

Agreed.  E.g. no more thinking waste about the question if it is
headline or heading?

> If I had to choose between the two, I'd go with heading.

+1

> If the community finds this valuable, I could prepare a patch.

+1

Re: [WDYT] org-attach-sync better remove an empty attachment directory?

[Marco Wahl]

Colin Baxter  writes:

>> Tim Cross  writes:
>
 We could introduce multiple possibilities to choose from.
> >>>
> >>> 1. Ask in case of an empty directory if it should be deleted.
> >>> 2. Don't ask.  Don't touch an empty directory.  (The state now.)
> >>> 3. Don't ask.  Delete empty directory.
> >>>
> >>> We could also make 3. the default setting.
> >>
> >> I made a mistake here.
> >>
> >> If we do this I vote for option 1. (not 3.) as default (following
> >> the suggestion by Colin) since it is the most interactive
> >> variant.  If the question gets annoying the user can switch to
> >> one of the other options.
> >>
>
> > That seems quite resonable to me.
>
> And me.

Thanks!

I pushed respective code.  Critique is always welcome.

Re: [WDYT] org-attach-sync better remove an empty attachment directory?

[Marco Wahl]

Marco Wahl  writes:

> Marco> Please recall that only empty attachment directories would be
> Marco> removed, so removal of a directory--and in particular one
> Marco> that existed before its interpretation as Org
> Marco> attachment--wouldn't be a big deal AFAICS.
>
> Tim> Not as confident here. I can imagine workflows and other
> Tim> external scripts which might expect a specific directory
> Tim> structure that could be broken if a directory was removed (even
> Tim> when empty). Hence my suggestion it needs to be something you
> Tim> can turn off.
>
> Tim> Likely this is something which should be controllable via a
> Tim> custom setting?
>
> Marco> To be honest I'd rather not make another customizable thing
> Marco> out of it to keep the overall complexity low.
> Marco> 
> Marco> OTOH we could easily introduce e.g. customizable
> Marco> org-attach-delete-empty-dirs-on-sync.
>
> Tim> Appreciate the problem with far too many customization options,
> Tim> but when it comes to software 'automatically' doing something,
> Tim> like removal of an empty directory, especially when it might
> Tim> not have been responsible for creation of the directory, it is
> Tim> better to provide some way to allow the user to turn off the
> Tim> behaviour. I would default to having it enabled though.
>
> Colin> I'm afraid I for one often have empty attach directories
> Colin> which I leave alone knowing that one day soon - sometimes
> Colin> very soon - they will be used again. Cannot the user be asked
> Colin> if he wants the directory removed?
>
> Thanks Tim and Colin.
>
> We could introduce multiple possibilities to choose from.
>
> 1. Ask in case of an empty directory if it should be deleted.
> 2. Don't ask.  Don't touch an empty directory.  (The state now.)
> 3. Don't ask.  Delete empty directory.
>
> We could also make 3. the default setting.

I made a mistake here.

If we do this I vote for option 1. (not 3.) as default (following the
suggestion by Colin) since it is the most interactive variant.  If the
question gets annoying the user can switch to one of the other options.

Sorry for the confusion.

Re: [WDYT] org-attach-sync better remove an empty attachment directory?

[Marco Wahl]

Marco> Please recall that only empty attachment directories would be
Marco> removed, so removal of a directory--and in particular one
Marco> that existed before its interpretation as Org
Marco> attachment--wouldn't be a big deal AFAICS.

Tim> Not as confident here. I can imagine workflows and other
Tim> external scripts which might expect a specific directory
Tim> structure that could be broken if a directory was removed (even
Tim> when empty). Hence my suggestion it needs to be something you
Tim> can turn off.

Tim> Likely this is something which should be controllable via a
Tim> custom setting?

Marco> To be honest I'd rather not make another customizable thing
Marco> out of it to keep the overall complexity low.
Marco> 
Marco> OTOH we could easily introduce e.g. customizable
Marco> org-attach-delete-empty-dirs-on-sync.

Tim> Appreciate the problem with far too many customization options,
Tim> but when it comes to software 'automatically' doing something,
Tim> like removal of an empty directory, especially when it might
Tim> not have been responsible for creation of the directory, it is
Tim> better to provide some way to allow the user to turn off the
Tim> behaviour. I would default to having it enabled though.

Colin> I'm afraid I for one often have empty attach directories
Colin> which I leave alone knowing that one day soon - sometimes
Colin> very soon - they will be used again. Cannot the user be asked
Colin> if he wants the directory removed?

Thanks Tim and Colin.

We could introduce multiple possibilities to choose from.

1. Ask in case of an empty directory if it should be deleted.
2. Don't ask.  Don't touch an empty directory.  (The state now.)
3. Don't ask.  Delete empty directory.

We could also make 3. the default setting.

Re: [WDYT] org-attach-sync better remove an empty attachment directory?

[Marco Wahl]

>> org-attach-sync can be used to "Synchronize the current outline node
>> with its attachments."  Which is great AFAICT.
>>
>> What do you think about letting org-attach-sync remove the attachment
>> directory if it's empty?
>>
>> Rationale: Nobody needs an empty attachment directory.
>>   
>
> This seems pretty reasonable to me provided it only removes an
> attachments directly which was created by org-attach-sync. If the
> directory existed or was created by something external, then removing it
> probably should not be done.

I think it's too much effort to keep a list of attachment directories
which have been created by Org attachment commands.  Complexity!  (BTW
org-attach-sync does not create an attachment directory.  It rather
checks the state of the directory and acts accordingly.)

Please recall that only empty attachment directories would be removed,
so removal of a directory--and in particular one that existed before its
interpretation as Org attachment--wouldn't be a big deal AFAICS.

> Likely this is something which should be controllable via a custom
> setting?

To be honest I'd rather not make another customizable thing out of it to
keep the overall complexity low.

OTOH we could easily introduce e.g. customizable
org-attach-delete-empty-dirs-on-sync.

[WDYT] org-attach-sync better remove an empty attachment directory?

[Marco Wahl]

Hi,

org-attach-sync can be used to "Synchronize the current outline node
with its attachments."  Which is great AFAICT.

What do you think about letting org-attach-sync remove the attachment
directory if it's empty?

Rationale: Nobody needs an empty attachment directory.
  

Ciao,
-- 
Marco

[mini, special, fyi] Speed Key g change

[Marco Wahl]

Dear Org people,

It's almost nothing, but the default for speed key "g" in
org-speed-commands changed slightly in master.

Instead of the recent, irritating--at least for me--text "Refile...to"
there is now "Goto" displayed in the minibuffer.  The latter expresses
that the action to be done is a jump rather than changing something.

Objections to the list, please.


Best regards,
-- 
Marco

Re: org-agenda no longer clocks out then in

[Marco Wahl]

Tory, Dave D  write:

>...> issues with org-log-note-clock-out...

> this commit
> https://code.orgmode.org/bzg/org-mode/commit/8e3e2f667f0b28b85845204b708c3f0aebc9152b
> probably fixes the issue. Could you perhaps give it a test?

Yes, please!

I also guess that the commit by Nicolas is a fix for the issue.

Thanks Nicolas, Dave and Tory.


Ciao,
-- 
Marco

Re: org-agenda no longer clocks out then in

[Marco Wahl]

torys.ander...@gmail.com (Tory S. Anderson) writes:

> For years my workflow has centered in org-agenda and I would go from
> one clocked item to the next.  For instance, I would be clocked into
> my "Emails" task, which never closes, and then eventually move down in
> the agenda to "Task B". Then I hit C-x TAB to clock in. It correctly
> queries for a comment on the task I'm leaving but no longer clocks me
> in to the new task as I'd asked. Is this a bug or am I missing a new
> setting?

This should work AFAICT and it does for me.  (With key {I} or {C-c C-x
TAB} in the agenda opposed to your setting with {C-x TAB}.)

Could you provide a complete mini example?  Possibly this helps to see
more clearly.


Best regards,
-- 
Marco

Re: Calendar vs. org-agenda exit

[Marco Wahl]

Hi.

> is org mode rebinding keys in the calendar?

Yes.  "c" calls the Org agenda.

"i" in the calendar calls org-agenda-diary-entry when
org-agenda-diary-file has been configured.  (See function
org--setup-calendar-bindings.)

> I ask, because I've been using traditional calendar+diary; now,
> when I try to insert an entry (i-d in calendar), I get
>
>   "Wrong type argument: commandp, org-agenda-diary-entry"

> The following experiment points in Org's general direction:
>
>   - emacs -Q
>   - M-x calendar
>   - with point on some date, i-d
>   - diary buffer is open, with a new line primed with date
>   - M-x load-library  "org"
>   - again, in calendar, i-d
>   - the above error results.
>
> I'm not sure yet whether I fat-fingered something, so I'd like
> some hints in investigating before declaring this to be a bug.

Thanks for providing a detailed path to the error.  But I can't
reproduce this error; I get

- diary buffer is open, with a new line primed with date

instead of the error.

Since you start with -Q and command org-agenda-diary-entry is a command
in org-agenda this looks suspicious AFAICT.

Does the

- M-x load-library  "org"

mix in some weird Org version and/or setting?  And btw why load Org a
second time?


Best regards,
-- 
Marco

Re: Using lexical-binding

[Marco Wahl]

> Kyle Meyer writes:
>> Stefan Monnier writes:
>>
>>> Since I'm not using it, I can't really test the result in any meaningful
>>> way.  Furthermore, just like `calendar.el`, it relies on dynamic scoping
>>> and `eval` in all kinds of ways, so it's very difficult to be sure the
>>> result is "sufficiently similar" to the old behavior not to break some
>>> funky use somewhere out there.
>>
>> I probably don't use many fancy agenda features, but I do work regularly
>> from it.  Running with these changes throughout today, I didn't notice
>> any issues.  Within the next few days, I'll try to test some non-default
>> settings and more obscure features that I don't use as part of my normal
>> workflow, and see if I can find any problems.
>
> I've continued to run with these changes and still haven't noticed any
> problems.  I've also tested various features (sticky agendas, block
> agendas, option setting from custom commands) and didn't spot anything.
>
>> I'll also push the current changes to scratch/sm/agenda-lexical with the
>> hope that others will test and report back.
>
> Has anyone else tried this out?

I'm using that branch for several days now without any problem.  LGTM!

I did nothing special for the test though.  At least I use column mode,
Org habits and interaction with calendar.


Thanks!
-- 
Marco

Re: [WDYT, mini] key h in agenda for quick help

[Marco Wahl]

Samuel Wales  writes:

> are there precedents?  calc?  h in dired does c-h m.

Looks to me like calc shines brightest with its help system which btw
one enters with key h.

Up to now I see the precedents

- dired
- help-mode
- view-mode 
- Buffer-menu-mode

They all have h be the same as C-h m (describe-mode) AFAICS.

> just a brainstorm but maybe c-h m and c-h b can be more friendly for all 
> modes?

I don't get this.  Would you like to elaborate, please?


Ciao,
-- Marco

Re: [WDYT, mini] key h in agenda for quick help

[Marco Wahl]

Robert Pluim  writes:

>>>>>> On Fri, 05 Feb 2021 11:34:41 +0100, Marco Wahl  
>>>>>> said:
>
> Marco> Hi all!
> Marco> What do you think about binding key h to function describe-mode in 
> Org
> Marco> agenda?  Basically pressing key h would open a window showing the 
> key
> Marco> bindings in the agenda.  There would also be additional 
> information.
>
> Marco> The implementation could be just the line
>
> Marco> (org-defkey org-agenda-mode-map (kbd "h") #'describe-mode)
>
> Marco> Also not that key h has no default binding in Org agenda yet!
>
> Itʼs bound to 'org-agenda-holidays'

OMG!  How could I not see this?  Thanks!

> Marco> The connoisseur of course knows that describe-mode is already just 
> a
> Marco> {C-h m} away from the Org agenda.  Anyway I think having {h} in the
> Marco> agenda would be nice.  This would also be consistent with
> Marco> e.g. help-mode.
>
> Meh. People should learn. Bah humbug ;-)

:)

I just see that with the Org default org-agenda-holidays can be called
with either key h or key H.

What luxury for org-agenda-holidays is this?!

I recreate this suggestion and propose to sacrifice the current default
binding of h.  Let h open the quick help!


Ciao,
-- 
Marco

[WDYT, mini] key h in agenda for quick help

[Marco Wahl]

Hi all!

What do you think about binding key h to function describe-mode in Org
agenda?  Basically pressing key h would open a window showing the key
bindings in the agenda.  There would also be additional information.

The implementation could be just the line

(org-defkey org-agenda-mode-map (kbd "h") #'describe-mode)

Also not that key h has no default binding in Org agenda yet!

The connoisseur of course knows that describe-mode is already just a
{C-h m} away from the Org agenda.  Anyway I think having {h} in the
agenda would be nice.  This would also be consistent with
e.g. help-mode.


Thanks for reading and best regards, 
-- 
Marco

Request to backport from Emacs 28

[Marco Wahl]

Hello,

The Emacs guys changed the signature of define-obsolete-function-alias.

Eli Zaretskii:

The use of this (and a couple of other) functions without the WHEN
argument has been obsolete since Emacs 23.1.

The packages should adapt.

AFAICS there is only usage of the obsolete usage in Org in
org-refile.el.

This is fixed already in Emacs 28. So I think that fix should be merged
into the Org maint and master branches.

Kyle! Are you the one who'll do that?

In a further step I think the critical line should move to org-compat as
all the other similar lines.


HTH,
-- 
Marco

Re: Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v

[Marco Wahl]

> 1. Capture Option Selection
> ===
>
> C-n, C-p, C-v work well and one can go through the capture menu easily.
>
> Below the capture buffer, I am seeing another buffer that is displaying events
> from the mouse (triple-mouse-1, down-mouse 5, ...) and keyboard (down up up, 
> ...)
> that ends getting bigger and bigger and bigger.
>
> It is the buffer in which the user  enters the option.  It does get
> bigger than one line, finally taking up most of the frame.  And the
> user can do nothing about that - that is you cannot drog the mouse
> to resize it.  Not being able to resize the window can become a very
> big bother when using org-capture.

This is hopefully fixed with the latest commit. Also M-v has been added
to the family of navigation keys.

> 2. Problem with %^{prompt|default|completion2|completion3...}
> 3 Default Completion Prompt

TBH I don't see problems here. But that's just me. Let's see what others
think.

Does Nowayman's hint help?


Best regards,
-- 
Marco

Re: Org Capture Menu cannot be fully viewed

[Marco Wahl]

pie...@caramail.com writes:

>> Would be great if you could check out the fix.
>
> Of coarse.  Is the following command the right way to get the fix
> for testing?
>
> git clone https://code.orgmode.org/bzg/org-mode.git

This is a step in the right direction. With this line you get a fresh
clone of the latest code.

If you just start using Org from the repo you could check the
instructions for the install over at orgmode.org ~~> Install. In the
long run this is the best way, I think.

In the case of this fix, for which only function org-mks has been
changed, I'd recommend to just evaluate that function.

This means the following. Have the newest function org-mks in an Emacs
buffer. This could be the function org-mks in file org-macs.el from your
fresh clone. Then place the cursor behind the very last paren of
function org-mks and do C-x C-e. And then check the thing.


Best regards,
--
Marco

Re: Org Capture Menu cannot be fully viewed

[Marco Wahl]

Hi Pietru and all,

> When making a relatively long Org Capture Menu for Archaeological Field 
> Management,
> the relevant capture window cannot be scrolled down.  This becomes 
> particularly
> problematic with small field laptops.

Thanks for reporting.

I just committed a fix along the lines of the similar exporter-UI and
the agenda chooser-UI. Now there is at least C-n, C-p, C-v when the
window is too small for all the items.

Unfortunately these similar UIs are not unified when looking at the code
base. E.g. I could not find a simple way to add key M-v to scroll one
page up for the capture menu.

Possibly these UIs could be unified or Org could even switch to
something different. I think you already discussed some ideas. Sorry if
I did not read the whole thread. That was too much information for me.

Would be great if you could check out the fix.


Thanks and HTH,
--
Marco

Re: Using org-agenda-time-grid with lists

[Marco Wahl]

Hi Steve!

> I have made two versions for calling org-agenda-time-grid, but the first does 
> not
> comply with what the last call does.  Yet the parameters are identical.
>
> (setq grid-displ '(today daily require-timed))
> (setq tm '(number-sequence 800 2000 100))
> (message "tm: %s" tm)
> (setq org-agenda-time-grid '('grid-displ 'tm
>".." ""))
>
> (setq org-agenda-time-grid '((today daily require-timed)
>(800 900 1000 1100 1200 1300 1400 1500 1600 1700  1800 2000)
>".." ""))

Possibly my last answer was not so clear.

IIUC you want to use some variables (concretely grid-displ and tm)
instead of the hardcoded values in the setting of org-agenda-time-grid.

This is a Lisp question AFAICT.

(setq org-agenda-time-grid '((today daily require-timed)
(800 900 1000 1100 1200 1300 1400 1500 1600 1700  1800 2000)
".." ""))

evaluates (C-x C-e) to

((today daily require-timed) (800 900 1000 1100 1200 1300 1400 1500 1600
1700 1800 2000) ".." "")

and the agenda appears as expected, I guess.

Let's check the details and use some variables.

(number-sequence 800 2000 100)

evaluates to

(800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000)

LGTM.

Introduce variables grid-displ and tm

(setq grid-displ '(today daily require-timed))
(setq tm '(number-sequence 800 2000 100))

Ok.

Let's check some variants using those variables

(setq org-agenda-time-grid '(grid-displ
tm
".." ""))

evaluates to

(grid-displ tm ".." "")

which is not the wanted value i.e. the hardcoded version above.

Somehow the variables grid-displ and tm need to get evaluated before the
setting of org-agenda-time-grid.

Next try

(setq org-agenda-time-grid (list grid-displ
tm
".." ""))

This evaluates to ((today daily require-timed) (number-sequence 800 2000
100) ".." "") which is closer to the hardcoded
version above. But the number-sequence call did not happen.

Function eval can do that.

(setq org-agenda-time-grid (list grid-displ
(eval tm)
".." ""))

This evaluates (almost) to the hardcoded version above.

Note that function eval is considered rather bad style and should be
avoided if possible.

Possibly you can use the setting

(setq tm (number-sequence 800 2000 100))

instead of

(setq tm '(number-sequence 800 2000 100))

and then just use tm instead of (eval tm) to get the list of numbers.

If you want to dig deeper you can study the backtick notation of lisp
which provides an elegant notation for variable evaluation in lists.


HTH,
-- 
Marco

Re: Using org-agenda-time-grid with lists

[Marco Wahl]

steve-humphr...@gmx.com writes:

> I am trying to insert finer timings in org-agenda with the following code.
> Haw can one pass a list in a list?
>
> (setq tm '(number-sequence 800 2000 30))
> (setq org-agenda-time-grid '((daily today require-timed)
>tm ".." ""))
>
>
> But this works well
>
> (setq org-agenda-time-grid '((daily today require-timed)
>(800 900 1000 1100 1200 1300 1400 1500 1600 1700  1800 2000)
>".." ""))

What about

(setq tm '(number-sequence 800 2000 30))

vs.

(setq tm (number-sequence 800 2000 30))

?


HTH,
-- 
Marco

[FYI] valign.el: Align tables containing variable-pitch font and the like

[Marco Wahl]

Hi!

Yuan Fu proposed valign.el to be included in ELPA over at the emacs
devel newsgroup.

If you like aligned tables containing non-monospace items then valign.el
might be something like. valign.el does a good job AFAICS.

The project repo is https://github.com/casouri/valign.


Best regards,
-- 
Marco

Re: [HELP} Capture Template

[Marco Wahl]

Tim Cross  writes:

> I'm trying to get a capture template to work, but without luck. Not sure
> what I'm doing wrong, but figured someone on this list could help by
> pointing out my probably obvious error.
>
> The template is
>
>  ("e" "expense" entry
>   (file+headline "~/Documents/org-data/refile.org" "Expenses")
>   "* Expense: %^{Description} :EXPENSE:\n\n | Date | %u |\n | Description | 
> %\1 |\n | Amount | %^{Amount} |\n"
>   :empty-line-after 1)
>
> The problem is with the %\1 expansion. According to the docs, the %\N
> expansion is replaced with the Nth %^{PROMPT} input. i.e. %\1 should be
> the data from the 1st %^{PROMPT} expansion (in this case
> %^{Description}.
>
> The problem is, it isn't. Instead, I get %^A as the result instead of
> the text I enter with the first %^{Description} expansion. The rest of
> the template works fine.
>
> Anyone got any ideas?

What about a further backslash? I.e. use %\\1 instead of %\1?


Ciao, Marco

[Marco Wahl] Re: [Feature Request] More flexibility in org-speed-commands customization

[Marco Wahl]

Hi Gustavo,

>>> I don't know if there is a strong reason to hard-code the set of keys
>>> in `org-speed-commands-default'.  But, if there isn't, could you
>>> consider (somehow) exposing the whole set of `org-speed-commands' to
>>> user customization?
>>
>> This sounds like a good idea to me.
>>
>> Do you already have a respective patch?
>>
>
> thank you for considering this suggestion.  But, no, I haven't tried
> to prepare a patch, because even if I got it working, I wouldn't be
> able to contribute it.  Unfortunately, I cannot sign the papers given
> my current employment contract's terms.  So, for the foreseeable
> future, I'm stuck with this situation, and can only contribute with
> ideas, reports and such.

What a pity about the contribution blocker! But thanks for being clear.

I put this change on my personal todo list. Possibly a public todo list
would be a better place, but that's another story, I guess. 


Best regards,
--
Marco

Re: [Feature Request] More flexibility in org-speed-commands customization

[Marco Wahl]

Hi Gustavo,

> Org's speed keys are a very interesting feature to which I've long
> been attracted to.  And indeed, I've flirted with it a number of times
> in the past.  But every time I do so, I end up stepping back, because
> I get weary of fat fingering my documents.  The whole set of speed
> keys is more powerful than what I would wish.  I'd love to have speed
> keys for navigation and visibility, but I would also gladly refrain
> from these "too handy" editing keys.
>
> As things stand, the speed keys are defined by combining
> `org-speed-commands-default', a defconst, and
> `org-speed-commands-user', a defcustom.  But the former already
> contains a large set of speed keys, including some quite powerful
> editing ones.  And it is thus hard to remove these keys.
>
> Of course, it is possible.  We could shadow the same key in
> `org-speed-commands-user' to do nothing.  Or, though a defconst, 
> `org-speed-commands-default' can be redefined after loading Org.  The
> first is clumsy, and renders the `org-speed-command-help' buffer quite 
> confusing.  The second feels wrong (because it is).
>
> I don't know if there is a strong reason to hard-code the set of keys
> in `org-speed-commands-default'.  But, if there isn't, could you
> consider (somehow) exposing the whole set of `org-speed-commands' to
> user customization?

This sounds like a good idea to me.

Do you already have a respective patch?


Best regards,
-- Marco

Re: [Discuss] separate (recenter window-line) out of org-agenda-redo

[Marco Wahl]

"numbch...@gmail.com"  writes:

> I try to add an idle timer to auto refresh org agenda views.
>
> Here is what I code:
>
> #+begin_src emacs-lisp
> ;;; auto refresh `*Org Agenda*' buffer
> (defun my/org-agenda-auto-refresh ()
>   "Rebuild all agenda views buffers."
>   (org-agenda-redo-all t))
>
> (run-with-idle-timer (* 60 20) t #'my/org-agenda-auto-refresh)
> #+end_src
>
>
> But I got error:
>
> #+begin_example
> Error running timer ‘my/org-agenda-auto-refresh’: (error "‘recenter’ing a
> window that does not display current-buffer.")
> #+end_example

Coming back to your original issue. Possibly it's enough to just
suppress the error.

You could change the function to

--8<---cut here---start->8---

(defun my/org-agenda-auto-refresh-1 ()
  "Rebuild all agenda views buffers."
  (ignore-errors (org-agenda-redo-all t)))

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


HTH,
-- 
Marco

Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]

[Marco Wahl]

Hi Gustavo,

> The Org line commands -- `org-beginning-of-line', `org-end-of-line', and
> `org-kill-line' -- all take due care for the presence of
> `visual-line-mode' to do the right thing if it is turned on.  However,
> when `visual-line-mode' is indeed on, the bindings on
> `visual-line-mode-map' shadow Org's bindings, so that we actually get
> `beginning-of-visual-line', `end-of-visual-line', and `kill-visual-line'
> for the usual keybindings, instead of the much nicer specialized Org
> commands.
>
> To check this, start with =emacs -Q=, set load-path to get the proper
> version of Org (as your case may be):
>
> #+begin_src emacs-lisp
> (add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200727")
> #+end_src
>
>
> Then visit an Org file, and enable "M-x visual-line-mode", and check the
> bindings with "C-h k C-a", "C-h k C-e", and "C-h k C-k" to get:
>
> #+begin_example
> beginning-of-visual-line
> end-of-visual-line
> kill-visual-line
> #+end_example
>
> I'm not sure this is a "bug", strictly speaking, or if it is correct
> unfortunate behavior.  Anyway, is there something that could be done
> from Org's side?

Also not sure if this is a bug. But you can configure the desired
behavior by hooking in at activation of visual line mode AFAICS.

You could e.g. add

--8<---cut here---start->8---

(add-hook 'visual-line-mode-hook
  (lambda () (when (derived-mode-p 'org-mode)
   (local-set-key (kbd "C-a") #'org-beginning-of-line)
   (local-set-key (kbd "C-e") #'org-end-of-line)
   (local-set-key (kbd "C-k") #'org-kill-line

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

to your config.


Best,
-- Marco

Re: [Discuss] separate (recenter window-line) out of org-agenda-redo

[Marco Wahl]

"numbch...@gmail.com"  writes:

[...]

> I dive into source code of ~org-agenda-redo~ function.
> Found this error is caused by ~(recenter window-line)~.
>
> I'm thinking what about to separate this code out? So function
> ~org-agenda-redo~ can be used to non-interactive usage?

My gut feeling says this is a good idea.

Do you have a concrete implementation yet?


Best regards,
-- 
Marco

New function org-hide-entry

[Marco Wahl]

Hi,

I just comitted function org-hide-entry which is a counterpart to
org-show-entry.

Critique, praise etc. welcome, as always.


Best regards,
--
Marco

Re: [PATCH] manual: Fix minor typo

[Marco Wahl]

Kyle Meyer  writes:

>> Up to now I thought only a 'format-patch' can be applied easily. Would
>> you please share a way to apply an inline patch? Or at least give a hint?
>
> Sure.  For an inline patch, you feed the entire message, rather than the
> attachment, to 'git am'.  It looks like Gnus is your MUA, so you may be
> interested in gnus-summary-pipe-output.
>
> For those that don't use an Emacs-based mail client, something like this
> might be more convenient than getting the message out of your reader:
>
>   $ # in org repo
>   $ curl -fSsL https://orgmode.org/list/MSGID/raw | git am
>
> In this particular case
>
>   $ curl -fSsL
> https://orgmode.org/list/20200705112846.16510-1-arunis...@systemreboot.net/raw
> | git am

Thanks Kyle!

Re: [PATCH] manual: Fix minor typo

[Marco Wahl]

Hi Kyle and Arun,

>> To make the handling of patches easier please use "format-patch".
>
> It looks like this was sent with git-send-email (which is fed
> format-patch output either explicitly or underneath), and it applied
> cleanly for me.

Okay, good. Thanks for sharing!

Apologies for demanding too much, Arun. 

> My understanding is that, even though this project accepts patches as
> attachments [*], inline patches are fine as well (and very much my
> personal preference).  git-send-email is explicitly mentioned at
> .
>
> [*] I believe there was a thread recently on emacs-devel that stated a
> preference for attachments, but I'd be sad if we as a project
> adopted the same stance.

Up to now I thought only a 'format-patch' can be applied easily. Would
you please share a way to apply an inline patch? Or at least give a hint?


Thanks and best regards,
-- 
Marco

Re: [rfc] Call agenda finalize hook a little bit later

[Marco Wahl]

Hello all,

> What do you think about calling the agenda finalize hook a little bit
> later so that the cursor position can be changed?
>
> E.g. this would allow to hook in a function that attempts to move point
> to the current clock.

Since there was neither opposition nor discussion and since the change
is small, I just pushed it.


Best regards,
--
Marco

Re: [PATCH] manual: Fix minor typo

[Marco Wahl]

Hi Arun,

Thanks for the patch. I applied it.

> * doc/org-manual.org (Clocking Work Time): Replace "to that you can"
> with "so that you can".

To make the handling of patches easier please use "format-patch". More
details from the Emacs CONTRIB:

--8<---cut here---start->8---
To email a patch you can use a shell command like 'git format-patch -1'
to create a file, and then attach the file to your email.  This nicely
packages the patch's commit message and changes, and makes sure the
format and whitespace are not munged in transit by the various mail
agents.
--8<---cut here---end--->8---


Thanks again,
-- 
Marco

Re: Habit error

[Marco Wahl]

Hello Colin,

Colin Baxter  writes:
> With the latest pull of org-mode I now find habits are not displayed
> correctly in agenda. The graph bar is missing, with the error
>
> org-habit-insert-consistency-graphs: Wrong type argument:
> number-or-marker-p, nil

I guess this was due to my attempt to fix of the color of the first done
date for a habit. Sorry for any inconvenience.

Didn't check the case when no done dates are available. I hope that's
been the issue.

Thanks for reporting. Please check again with the latest from the repo.


Best regards,
-- Marco

[rfc] Call agenda finalize hook a little bit later

[Marco Wahl]

Hello,

What do you think about calling the agenda finalize hook a little bit
later so that the cursor position can be changed?

E.g. this would allow to hook in a function that attempts to move point
to the current clock.

Find a proposition for a patch for master below.


Thanks for reading,
-- 
Marco
>From 37f2e1519915a0476bb4d15328473541236d4890 Mon Sep 17 00:00:00 2001
From: Marco Wahl 
Date: Tue, 30 Jun 2020 13:02:19 +0200
Subject: [PATCH] agenda: Call finalize-hook later

* lisp/org-agenda.el (org-agenda-finalize): Call the hooks after the
save-excursion.

This opens the way for hooks to position the cursor after agenda
generation.
---
 lisp/org-agenda.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 9fbeb2a1e..90129b23e 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3858,8 +3858,8 @@ This function is called just before displaying the agenda.  If
 you want to add your own functions to the finalization of the
 agenda display, configure `org-agenda-finalize-hook'."
   (unless org-agenda-multi
-(save-excursion
-  (let ((inhibit-read-only t))
+(let ((inhibit-read-only t))
+  (save-excursion
 	(goto-char (point-min))
 	(save-excursion
 	  (while (org-activate-links (point-max))
@@ -3927,8 +3927,8 @@ agenda display, configure `org-agenda-finalize-hook'."
 	(when (get 'org-agenda-effort-filter :preset-filter)
 	  (org-agenda-filter-apply
 	   (get 'org-agenda-effort-filter :preset-filter) 'effort))
-	(add-hook 'kill-buffer-hook 'org-agenda-reset-markers 'append 'local)
-	(run-hooks 'org-agenda-finalize-hook)
+	(add-hook 'kill-buffer-hook 'org-agenda-reset-markers 'append 'local))
+  (run-hooks 'org-agenda-finalize-hook
 
 (defun org-agenda-mark-clocking-task ()
   "Mark the current clock entry in the agenda if it is present."
-- 
2.17.1

Join lines in region with M-^ in Org

[Marco Wahl]

Hello all,

With my last tiny commit on master org-delete-indentation (M-^) behaves
as good old plain delete-indentation in the case when a region is
active. Concretely the lines get joined. Before the region has not been
taken into account by org-delete-indentation.

I guess and hope this change is consensual.

If not, please speak out.


Best regards,
-- 
Marco

Re: New mailing list archive at https://orgmode/list/

[Marco Wahl]

Hi!

> with Kyle's help, I've set up a new mailing list archive:
>
> https://orgmode/list/
>
> References in https://orgmode.org and https://orgmode.org/list
> that pointed to gmane.org are now using this, so many links are
> functional again.

Thanks!

May I take the occasion to ask naively about the "Archived-At:" line in
the header of mails on the orgmode mailing list, please?

E.g. I see the line

Archived-At: 

Could this line be forged to point to the newly created location within
https://orgmode.org/list?

I think this would be beneficial since

1. there is nothing at
http://permalink.gmane.org/gmane.emacs.orgmode/129773 AFAICS.

2. one could easily reference emails.


Best regards and thanks again,
-- Marco

Document level property drawer position

[Marco Wahl]

Hi,

With file

#v+
:PROPERTIES:
:CATEGORY: Org
:END:
#+TITLE: Stuff related to Org

* TODO a task
#v-

the category is "Org" as expected. (This can be seen in the agenda.)

Moving the property drawer below the title line breaks this behavior.
Concretely see this with file

#v+
#+TITLE: Stuff related to Org
:PROPERTIES:
:CATEGORY: Org
:END:

* TODO a task
#v-

(The filename is chosen as category.)

Is this a bug?


Best regards,
-- Marco

[idea] Dynamic agenda filtering

[Marco Wahl]

Hi,

These are a few lines of experimental code to bring dynamic filtering to
the agenda. I think it's not too bad already.

I'd like to invite you to check it out.  Just mark the code and do
{M-x eval-region RET}.  Then you have the "dynamic filtering" on key "&"
in the agenda.  Just type to see the effect.

BTW recall key "|" to remove all filters.

#+begin_src emacs-lisp
(defun org-agenda-dynamic-filter-minibuffer-contents ()
  "Return the contents of the minibuffer when it is active."
  (when (active-minibuffer-window)
(with-current-buffer (window-buffer (active-minibuffer-window))
  (minibuffer-contents

(defun org-agenda-dynamic-filter-update-regexp ()
  (with-current-buffer "*Org Agenda*"
(org-agenda-remove-filter 'regexp))
  (setq org-agenda-regexp-filter
(if (string= "" (org-agenda-dynamic-filter-minibuffer-contents))
nil
  (list (concat "+" (org-agenda-dynamic-filter-minibuffer-contents)
  (with-current-buffer "*Org Agenda*"
(cl-flet ((recenter ( arg redisplay) nil))
  (org-agenda-finalize

(defun org-agenda-dynamic-filter-regexp-read ()
  "Read string with PROMPT and display results dynamically.
See also `org-agenda-filter-by-regexp'."
  (interactive)
  (unwind-protect
  (catch 'click
(add-hook 'post-command-hook #'org-agenda-dynamic-filter-update-regexp)
(read-string "Regexp: "))
(remove-hook 'post-command-hook #'org-agenda-dynamic-filter-update-regexp)))

(org-defkey org-agenda-mode-map "&" #'org-agenda-dynamic-filter-regexp-read)
#+end_src

As always comments and all are very much appreciated.  Possibly this can be
developed into something useful.

BTW for the implementation I glanced at the--in my opinion very
nice--org-velocity.el .


Ciao,
--
Marco

Re: $LR in Table Formula

[Marco Wahl]

Carsten Dominik  writes:

>> If the Org code shall iterate towards clarity then the question would be
>> resurrection or elimination of the Last Row (LR) feature AFAICS.
>
> Elimination should be fine in this case since it does not work anymore
> anyway.

Okay, I eliminated the LR parts from the code.


Thanks,
-- Marco

Re: [RFC] Change default value for `org-startup-folded'?

[Marco Wahl]

> Reading a recent message on Emacs devel list, I stumbled upon this:
>
> I needed to go and look up to figure out how to read the org file
> that came with pdf-tools. It isn't that much text, and the annoying
> folding that org does for what amounts to a simple README file is
> gratuitous at best.
>
> it struck me that our default value for `org-startup-folded', which
> t (or `overview') may not be nice for people not used to Org.
>
> It would make sense to make it easier for non-Org users who have to deal
> with Org files to set this variable to `showeverything'. This would also
> be on par with Outline mode, the major mode used to handle, e.g., NEWS
> file.
>
> Even though I think `overview' is a nice value, the logic behind my
> suggestion is that it is easier for an Org user to set
> `org-startup-folded' once and for all than for a non-Org user to
> discover Org folding the hard way.
>
> WDYT?

+1 for the change.

Re: Failing tests

[Marco Wahl]

Kyle Meyer  writes:

> Marco Wahl  writes:
>
>> When building with "make test" I get
>>
>> #v+
>> 2 unexpected results:
>>FAILED  ob-tangle/jump-to-org
>>FAILED  test-org-attach/dir
>> #v-
>>
>> does this ring a bell for anybody?
>
> FWIW I don't see either failure on my end (Emacs 26.3).  Do they fail
> for you consistently?

Good to know that the tests pass on your side.

I'll check again and report in the case I find something interesting.


Thanks!
-- Marco

Re: $LR in Table Formula

[Marco Wahl]

Carsten Dominik  writes:

> This was an old way to refer to fields in the last row.  It was already
> deprecated in 2011.  I also does not seem to work anymore.
>
> I had forgotten all about it and only found it back with
>
> git log -S \$LR --source --all | less
>
> which pointed me to commit 8237c9ae6d587a22646333e0315683675e2db538

Thanks for the eludication!  

If the Org code shall iterate towards clarity then the question would be
resurrection or elimination of the Last Row (LR) feature AFAICS.


My 2 ct,
-- Marco

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Marco Wahl]

Hi,

And thanks, Eric!

Eric S Fraga  writes:

> Now, I might be pushing my luck so apologies but: it would be nice if
> the kill row/column behaviour were also consistent.  Right now, if you
> kill a row, it leaves point where it was; if you kill a column, it moves
> point to the previous column.  That is, for instance, if point is in row
> 2 column 2, deleting a row will leave point in row 2, column 2. Deleting
> a column moves point to row 2 column 1.  The row killing behaviour seems
> more usable so I wonder whether we could have the column behaviour
> changed as well?

Indeed, why not?  I pushed a respective change.  I introduced a subtlety
when deleting from the rightmost column or from immediately right of the
table.  That was not needed with point moving to the left, as it has
been before.

The change is small, only two lines.  So this could be easily reverted.

Please check it out.


Thanks and best regards,
-- Marco

$LR in Table Formula

[Marco Wahl]

Hi!

By accident at browsing the code I stumbled over "$LR" in column
formulas.  TBH I don't understand "$LR" and I haven't found a bit about
it in the documentation.

What is the meaning of $LR?


Ciao,
-- Marco

Failing tests

[Marco Wahl]

Dear all,

When building with "make test" I get

#v+
2 unexpected results:
   FAILED  ob-tangle/jump-to-org
   FAILED  test-org-attach/dir
#v-

does this ring a bell for anybody?


Best regards,
-- Marco

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Marco Wahl]

Nicolas Goaziou  writes:

>> Where shall the change go?  maint (and master) or just to master?
>
> I think maint is fine.

Okay, pushed.


Thanks,
-- Marco

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Marco Wahl]

Hi,

Carsten Dominik  writes:

>> > I just pulled the lates master, and I think the creation of a new
>> > column has not been set back to the way it used to be, even though
>> > Nicolas agreed to do so.  Am I missing something?

>> As I understood, we practice some patience now to see if someone votes
>> for keeping the current behavior.  And then act according to the
>> discussion (or non-discussion.)

> For the record, I am in favor of the old workings, as described
> by Eric.  It is more consistent in several ways.

Hereby I declare patience to be over!  AFAICT no one spoke up to keep
the insertion of a new column with org-table-insert-column to the right
of the current column.

I had a look at the issue and I think I can take over the
implementation.  It's not a big deal AFAICS.

Where shall the change go?  maint (and master) or just to master?


Best wishes,
-- Marco

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Marco Wahl]

Hi Carsten,

> I just pulled the lates master, and I think the creation of a new column
> has not been set back to the way it used to be, even though Nicolas agreed
> to do so.  Am I missing something?

As I understood, we practice some patience now to see if someone votes
for keeping the current behavior.  And then act according to the
discussion (or non-discussion.)


Best regards,
-- Marco

Re: 'org-structure-template-alist' is only partially working...

[Marco Wahl]

Sharon Kimble  writes:

> I'm having great difficulty in getting 'org-structure-template-alist' to work 
> properly.
>
> This is what I'm using -  
>
> #+BEGIN_SRC emacs-lisp
> ;(require 'org-tempo)
> (setq org-structure-template-alist
>'('("s" . "src emacs-lisp")
> ;("e" . "example")
> '("q" . "quote")
> '("v" . "verse")
> '("C" . "comment")
> '("b" . "src latex")
> ;("m" "#+begin_src latex-mode\n?\n#+end_src" " lang=\"latex-mode\">\n?\n")
> ;("t" "#+latex: " "?")
> ;("x" "#+BEGIN_SRC latex\n?\n#+END_SRC" " lang=\"latex\">\n?\n")
> ;("h" "#+begin_html\n?\n#+end_html" " style=\"html\">\n?\n")
> ;("a" "#+begin_ascii\n?\n#+end_ascii")
> ;("s" "#+BEGIN_SRC sh\n?+\n#+END_SRC" " lang=\"shell\">\n?\n")
> '("l" . "emacs-lisp")
> ;("u" "#+begin_src emacs-lisp\n\(use-package %0\n\:ensure 
> t)\n\#+end_src")
> '("i" . "index")
> ;("p" "#+BEGIN_COMMENT\n?\n#+END_COMMENT" "\n?\n")
> '("f" . "src file")))
> #+END_SRC
>
> 
> but 
> So how can I get it to actually work please?

AFAICS the evaluation of (require 'org-tempo) makes the structure
templates working in the sense you expect.

If you want this permanently you could add the line (require 'org-tempo)
to your Emacs init file.

Alternatively you could customize variable org-modules { M-x
customize-variable RET org-modules RET } and choose org-modules, I
think.


HTH,
-- Marco

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Marco Wahl]

Nicolas Goaziou  writes:

> Eric S Fraga  writes:
>
>> And I believe that a reasonable expectation is symmetry with inserting a
>> row.  The way I think of it is the arrow indicates to make space by
>> moving columns/rows in that direction.  Most spreadsheets work in this
>> way, in my experience (but I could be wrong).
>
> I understand now. Thanks.
>
> Then I agree with you, it would be better to change the behaviour
> instead of the documentation.

Okay, this is all understandable.

For the record: A few days ago I changed the documentation so that it's
in a consistent state with the current code.

Since the change has been in place since 2017 what's the right thing to
do?

- Wait a while for someone speaking out to keep the state as it is now?
  If nobody shows up, just change back to inserting to the left?
  
- Introduce a customizable variable for inserting to the left?

- Add a parameter to org-table-insert-column to control insertion
  left/right and possibly even the number of columns?

- Something else?


Best regards,
-- Marco

Re: Preventing org-cycle from scrolling the buffer

[Marco Wahl]

Dmitrii Korobeinikov  writes:
> When calling org-cycle on a collapsed section which contains a lot of
> text, the headline is adjusted to the top of the page. Collapsing it
> doesn't revert the scroll, which makes it hard to quickly peek at
> what's in the section without getting disoriented. Is there a flag or
> some other way of turning off this autoscroll?

AFAICS this behavior can be controlled via customizable variable
org-cycle-hook { M-x customize-variable RET org-cycle-hook RET } by
removing entry org-optimize-window-after-visibility-change.

> Scroll revert wouldn't be so bad to have either, by the way (in
> addition to, not instead of, though). Since org knows when the cursor
> moves away from the headline after tabbing, it seems this feature can
> be implemented without too much hassle. I would even go as far as to
> suggest making it a default if it gets done.
>
> What do you think?

IDK.  AFAICS you are right with your argumentation.  I don't see the
need of that feature, though, yet.  But that's just me.  I think you are
the best candidate to try an implementation of the feature.


Best regards,
-- Marco

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Marco Wahl]

Yu Han Quek  writes:

> Calling org-table-insert-column in a table with formulas wrongly increments
> the column number left of the newly inserted column.
>
> Minimal example:
>
> | 1 | 2 | 3 |
>
> #+TBLFM: $3=$1+$2
>
> With cursor in the `1` cell, call `M-x org-table-insert-column`.
>
> Expected output:
>
> | 1 |   | 2 | 3 |
>
> #+TBLFM: $4=$1+$3
>
> Actual output ($1 wrongly changed to $2):
>
> | 1 |   | 2 | 3 |
>
> #+TBLFM: $4=$2+$3
>
> The bug seems to be in the last 2 lines of the
> function org-table-insert-column:
>
>   (org-table-fix-formulas "$" nil (1- col) 1)
>   (org-table-fix-formulas "$LR" nil (1- col) 1)
>
> Changing `(1- col)` to `col` solves the issue.

Thanks.  I committed your fix with the TINYCHANGE marker.

I find it slightly suspicious that the documentation says

#v+
‘M-S-’ (‘org-table-insert-column’)
 Insert a new column to the left of point position.
#v-

But actually the new column goes to the right and this is also fused by
the tests.  Has there been a stealth shift to the right?  Anyway, I
guess the documentation text should be updated as well.

Any objections or comments about this?


Ciao,
-- Marco

Re: Bug: :completion-function no longer takes a lambda [9.3.6 (9.3.6-elpa @ /home/arne/.guix-profile/share/emacs/site-lisp/)]

[Marco Wahl]

Arne Babenhauserheide  writes:

> Hi,
>
> I set up my publishing workflow with org-project using lambdas in the
> :completion-function, but I now receive errors when I try to publish.
>
> Example Setup:
>
> (setq org-publish-project-alist
>   '(("guile-basics"
>  :base-directory "~/eigenes/py2guile"
>  :publishing-directory (concat private-publish-ftp-proj 
> "guile-basics/")
>  :base-extension "org"
>  :publishing-function org-html-publish-to-html
>  :completion-function (lambda () (private-publish-rename-to-index 
>(concat private-publish-ftp-proj 
> "guile-basics/") 
>"guile-basics.html"))
>  :section-numbers nil
>  :with-toc t
>  :html-preamble t
>  :exclude ".*"
>  :include ["guile-basics.org"])))
> 
>
> This used to work, but now it breaks with
>
> org-publish-projects: Invalid function: lambda

An additional pair of parens should help as workaround.  Concretely try

:completion-function ((lambda () (private-publish-rename-to-index 
(concat private-publish-ftp-proj 
"guile-basics/") 
"guile-basics.html")))

This works since it's possible to use a list of functions also.

I'll commit a fix against master in a second to be able to use a lambda
instead of a list containing one lambda.


Thanks,
-- Marco

Re: ob-calc duplicate stack-element issue

[Marco Wahl]

Eric S Fraga  writes:

> On Wednesday, 18 Mar 2020 at 15:47, Marco Wahl wrote:
>> AFAICS at the org babel calc evaluation the last value of the calc stack
>> gets dropped.
>>
>> So your workaround is okay, I think.  You can just write any dummy
>> element at the bottom of each block e.g. just 0.  No need of
>> duplication.  Looks a bit hackish to me but so what?
>
> Indeed hackish.  But it does beg the question: why does ob-calc pop the
> stack?  I cannot see any use case given that the stack is essentially
> infinite and can be safely ignored (in most if not all cases).
>
> Could the solution be to simply remove the =(calc-pop 1)= line at the
> end of =org-babel-execute:calc= function?
>
> Just a thought.

Possibly the originators thought about the typical use of calc blocks as
units which reduce to the top element of the stack.  In this case the
calc-pop would be the right step to clean the stack.

Just another thought.


Ciao,
-- Marco