Re: Using lexical-binding

2021-03-04 Thread 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

2021-02-05 Thread 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

2021-02-05 Thread 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

2021-02-05 Thread 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

2021-01-06 Thread 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

2020-12-16 Thread 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

2020-12-14 Thread 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

2020-12-14 Thread 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

2020-12-11 Thread 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

2020-12-11 Thread 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

2020-11-30 Thread 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

2020-11-19 Thread 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

2020-08-17 Thread 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

2020-08-17 Thread 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

2020-07-28 Thread 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/)]

2020-07-28 Thread 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

2020-07-27 Thread 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

2020-07-21 Thread 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

2020-07-07 Thread 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

2020-07-05 Thread 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

2020-07-05 Thread 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

2020-07-05 Thread 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

2020-07-04 Thread 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

2020-06-30 Thread 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

2020-06-17 Thread 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/

2020-06-05 Thread 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

2020-05-04 Thread 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

2020-05-02 Thread 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

2020-05-01 Thread 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'?

2020-04-30 Thread 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

2020-04-21 Thread 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

2020-04-18 Thread 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/)]

2020-04-18 Thread 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

2020-04-17 Thread 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

2020-04-17 Thread 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/)]

2020-04-17 Thread 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/)]

2020-04-17 Thread 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/)]

2020-04-01 Thread 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...

2020-04-01 Thread 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/)]

2020-04-01 Thread 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

2020-03-31 Thread 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/)]

2020-03-30 Thread 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/)]

2020-03-30 Thread 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

2020-03-18 Thread 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




Re: ob-calc duplicate stack-element issue

2020-03-18 Thread Marco Wahl
Heiko Schmidt  writes:

> - problem: When evaluating the calc snippets the top of stack element
>    is dropped. Because every "begin/end_src calc" block drops the top
>    of stack, one can't reuse the result in following blocks.

> Number of cars (PKW) in germany:
>
> #+begin_src calc :exports both
> 45e6
> #+end_src
>
>
> #+RESULTS:
> : 4500.
>
> Yearly mileage in [km/y]
>
> #+begin_src calc :exports both
> 15000
> #+end_src
>
>
> #+RESULTS:
> : 15000
>
> Calculate amount of complete km per year
>
> #+begin_src calc :exports both
> '*
> #+end_src
>
>
> #+RESULTS:
> : 6750.

> - problem: babel removes the resulting top stack element from the
>    stack
>
> - tried solution: duplicate the last stack-element on evaluation with
>    "' " (emulate  press to duplicate the top element of the
>    stack in calc)

> ** hope for a solution or work around from the community
>
> - preferred: Is there a way to leave the top of stack from one snippet
>    to the next (which I don't know)?
> - alternative: Is there a way to duplicate the top of stack element
>    between begin/end_src calc blocks?
> - any advice is appreciated.

Okay.  I take here the "any advice is appreciated" part.

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?

Another approach could be "noweb".  Example (you would just evaluate the
block at the bottom):

--8<---cut here---start->8---
Number of cars (PKW) in germany:

#+name: numcars
#+begin_src calc :exports both
45e6
#+end_src

Yearly mileage in [km/y]

#+name: mileage
#+begin_src calc :exports both
15000
#+end_src

Calculate amount of complete km per year

#+begin_src calc :noweb yes
<>
<>
'*
#+end_src
--8<---cut here---end--->8---


HTH,
-- Marco












Re: [SOLVED] Re: Can Org Mode tag support dash character "-"?

2020-03-15 Thread Marco Wahl


stardiviner  writes:

> Carsten Dominik  writes:
>
>> On Fri, Mar 13, 2020 at 3:08 PM stardiviner  wrote:
>>
>>  I found Org Mode tags does not support tag like "COVID-9", The dash 
>> character "-" is not supported.
>>
>>  Can Org Mode support the dash char because it is very often used.
>>
>> This is not a good idea, because searches can be built with +tag and -tag .
>>
>> Use COVID9 or COVID_9 instead.
>
> I see, thanks.

BTW you could use some kind of decoration for the visual representation
of tags e.g. an image of a corona-virus.  This is the idea of
https://melpa.org/#/org-pretty-tags.  You could even use "COVID-19" as
replacement for "COVID19" but possibly this brings too much confusion.


Hopefully not too shameless at plugging,
-- Marco



Re: Binding literal tab to C-Tab

2020-03-06 Thread Marco Wahl
Hi.

Josh  writes:

> I have a need to insert literal tab characters into my org-mode files
> frequently. I would like to bind a key to insert literal tabs (ASCII
> 9). I thought Control-TAB would be a good option. So I inserted the
> following lines into my .emacs file. It works when in normal emacs,
> but not in org-mode. Is there a way to get this to work in org-mode?
> If this is a bad key combination for org-mode, I'm ok switching to
> another key combo.

What about using quoted-insert?  C-q TAB


Ciao,
-- Marco



Re: "peculiar" error with countdown timer in org-agenda

2020-03-03 Thread Marco Wahl


> I will check.  However I am on Windows 7-64 and to the best of my knowledge
> Dbus is not available for this platform.  There were some efforts to make
> it work but I don't think they are current.

Okay.

> In any case, as the error message said, this version of emacs isn't
> compiled with Dbus, which makes sense for a Windows version.
> I will try to create my own handler and figure out why dbus notification is
> being attempted on a version of Emacs compiled without it.

Okay.  And yes, please check setting the handler.  E.g. evaluate

(setq org-show-notification-handler #'message)

or add the line your init file.

AFAICS the condition with the dbus stuff is ignored if the handler is
set.  In any case please report the outcome of your testing.


Thanks,
-- Marco



Re: "peculiar" error with countdown timer in org-agenda

2020-03-03 Thread Marco Wahl
Hi Ian,

Thanks for reporting.

> In Org-Agenda, I press ';' to start a countdown timer.
> I enter 1 minute to test.
> When timer reaches zero, I see this error in minibuffer
>
> dbus-call-method: peculiar error: "Emacs not compiled with dbus support"
>
> Also, timer display is not removed from mode-line as expected.

I checked this some and I think the problem lies in function
org-show-notification.  That function references and possibly uses
function notifications-notify which depends on a proper setup of the
dbus stuff.  I guess this is the gist of the bug.

You can place your own handler though.  For this set variable 

org-show-notification-handler

to e.g. function

   message

Can you please try this out?

About hunting the bug: possibly it would be good to add a check if the
dbus system is up.  Can this be done easily?  Or add a further
configuration item to indicate that the dbus system shall be used.


Best,
-- Marco





Re: bug: ';' gets error starting countdown timer in agenda

2020-03-01 Thread Marco Wahl
Ian Garmaise  writes:

> Thanks for that, it is indeed true that picking a heading is a workaround.
> I was confused because as far as I can tell there is no relationship
> between the countdown timer and any headline.  I assume you mean the
> docstring for org-timer-set-timer, but maybe it is for some function in
> org-agenda.el

Sorry, I've not been clear.  I mean the docstring of
org-timer--get-timer-title.

For some reason a name gets associated with each timer.  The creation of
that name is done in function org-timer--get-timer-title.  Called from
the agenda the function trys to provide the name of the headline for the
current agenda line and it raises an error in some cases when this is
not possible.  And you found such a case FWIW.


Ciao!



Re: bug: ';' gets error starting countdown timer in agenda

2020-03-01 Thread Marco Wahl
Ian Garmaise  writes:

> In Agenda, I issue the ';' command to start a countdown timer.
> I am asked how many minutes, then I get the following error
>
>
> user-error: Command not allowed in this line
>
> Timer doesn't start.  I have no problem starting a timer with C-c C-x ;

Thanks for the report.

AFAICS this issue occurs if you press ; on a line which is not
associated to a heading.  So a workaround is to pick a headline before
the press on ;.

I installed a fix in the master branch which looks natural to me.
Concretely the name of the buffer is taken when no associated heading
can be identified (instead of erroring.)  BTW this completely complies
with the docstring AFAICS.


Best regards,
-- Marco









Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Marco Wahl
Hi Bastien and all,

>> Subject: [PATCH 1/2] org: Fix corner case for org-kill-line
>>
>> * lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the 
>> tags part.
>
> There is a problem with this patch: when on a empty heading with tags,
> killing the tags will let the cursor back right after the last "*".
> Not a big deal in most headlines, but when on the first headline, this
> leads to an error.

Okay.  Thanks for this finding.

> I think org-kill-line should not try to do too much, and kill only
> parts of the tags when the cursor is in the middle of tags is the
> right thing to do.

Fair enough.  I tried to implement the sentence "When after the headline
text, kill the tags" from the documentation for org-special-ctrl-k,
which I interpreted as kill _all_ tags.  Just to make clear my decision
for the patch.

> As for the other patch, I think it's important to explain that the
> whole subtree will be killed, even if not visible -- that's the whole
> point of this variable after all.

AFAICS the kill of a folded (invisible) subtree is also performed
without having set org-special-ctrl-k.  So I'd rather say that there is
no need for pointing out that behavior in the documentation.

> So I'm sorry but these patches can't make it.
>
> Thanks anyway!

You are welcome.  That's fine with me.


Ciao!



Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Marco Wahl
Hi!

>>> - org-loop-over-headlines-in-active-region => t
>>
>> I vote for => 'start-level.  Loop over headlines with same level as the
>> first.
>
> Yes, good suggestion.

Let's see what others say.

>>> - org-special-ctrl-k => t
>>>
>>>   The default value for the sister option org-special-ctrl-a is set to
>>>   reversed and while this changes a fundamental Emacs command behavior
>>>   it feels useful.  I'd argue this is the same for org-special-ctrl-k:
>>>   setting it to t will feel natural.
>>
>> AFAICS there is a contradiction between the documentation of
>> org-special-ctrl-k and the code!  Doc: kill the tags.  Code:
>> (org-align-tags).
>>
>> Further I propose to delete the part " and possible the folded subtree
>> below the line" from the documentation.
>
> Can you propose a patch against the maint branch for the fixes above?

Sure.  See the attachments.

>>> - org-src-tab-acts-natively => t
>>> - org-allow-promoting-top-level-subtree => t
>>
>> Just an idea for the "reverse": provide a function to convert a comment
>> line to a heading (one level below the current level) and demote the
>> subtrees below.
>
> I don't think converting a comment to a headline is a common use case.

Ok.  That was just an idea.

>>>   * We have regular meetings with https://www.emacs-doctor.com/
>>
>> What are these meetings?
>
> We gather with fellow Emacsers in Paris once in a while.

Ahhh!  Paris!  Thanks for the information.  Paris is out of my reach, though.

>From 49b00d2cf7ca4b8484e0a9679b39b62873ee30b6 Mon Sep 17 00:00:00 2001
From: Marco Wahl 
Date: Wed, 19 Feb 2020 13:48:01 +0100
Subject: [PATCH 1/2] org: Fix corner case for org-kill-line

* lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the tags part.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index f7547eba1..f4fe76f82 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20392,7 +20392,7 @@ depending on context."
 		 (skip-chars-backward " \t")
 		 (point
   (if (<= end (point))		;on tags part
-	  (kill-region (point) (line-end-position))
+	  (kill-region end (line-end-position))
 	(kill-region (point) end)))
 (org-align-tags))
(t (kill-region (point) (line-end-position)
-- 
2.25.1

>From a81744de15f42d1817482f2209f555a959e9e66c Mon Sep 17 00:00:00 2001
From: Marco Wahl 
Date: Wed, 19 Feb 2020 13:51:01 +0100
Subject: [PATCH 2/2] org: Remove irritating documentation line

* lisp/org.el (org-special-ctrl-k): Omit irritating documentation line.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index f4fe76f82..7327bfe21 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1575,7 +1575,7 @@ When nil, `C-k' will call the default `kill-line' command.
 When t, the following will happen while the cursor is in the headline:
 
 - When the cursor is at the beginning of a headline, kill the entire
-  line and possible the folded subtree below the line.
+  line.
 - When in the middle of the headline text, kill the headline up to the tags.
 - When after the headline text, kill the tags."
   :group 'org-edit-structure
-- 
2.25.1



Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Marco Wahl
Bastien  writes:

> while Org 9.4 is on its way, I am considering changing a few default
> settings (10 options in total).  I have created a survey here:
>
> https://framadate.org/Ufc42EVxS2jO1Ajz
>
> Can you take a few minutes and express your opinion there?

Ok.  I'll go there in a minute.

> Here is the list of options and a line of justification - feel free to
> discuss this on the mailing list too, of course.

These changes look good to me.  Thanks for bringing this up.  Find a few
comments and a question below.

> - org-loop-over-headlines-in-active-region => t

I vote for => 'start-level.  Loop over headlines with same level as the
first.

> - org-agenda-loop-over-headlines-in-active-region => t
> - org-fontify-done-headline => t
> - org-hide-emphasis-markers => t
> - org-hide-macro-markers => t
> - org-refile-use-cache => t

> - org-special-ctrl-k => t
>
>   The default value for the sister option org-special-ctrl-a is set to
>   reversed and while this changes a fundamental Emacs command behavior
>   it feels useful.  I'd argue this is the same for org-special-ctrl-k:
>   setting it to t will feel natural.

AFAICS there is a contradiction between the documentation of
org-special-ctrl-k and the code!  Doc: kill the tags.  Code:
(org-align-tags).

Further I propose to delete the part " and possible the folded subtree
below the line" from the documentation.

> - org-src-tab-acts-natively => t
> - org-allow-promoting-top-level-subtree => t

Just an idea for the "reverse": provide a function to convert a comment
line to a heading (one level below the current level) and demote the
subtrees below.

> - Add org-tempo to org-modules

>   * We have regular meetings with https://www.emacs-doctor.com/

What are these meetings?


Thanks.




Re: [rfc] Make column view less rigid for rescale?

2020-02-17 Thread Marco Wahl
Hi Bastien,

>> I think this rigidity is unnecessary and I'd like to see org columns
>> follow text rescaling.
>
> Agreed.

Fine!

>> AFAICS the change is easy.  (Just set `font' to nil in
>> `org-columns--display-here'.)
>
> The change is a bit more complex, because you also need to adjust the
> size of the header-line.

Ahh, right, good catch.

> I've pushed this change in master, please test it and report.

LGTM!  Thanks!



[rfc] Make column view less rigid for rescale?

2020-02-17 Thread Marco Wahl
Dear all,

Up to now the text-scale of org columns sticks to one size disrespecting
text rescaling.  (E.g. via C-x C-+ .)

I think this rigidity is unnecessary and I'd like to see org columns
follow text rescaling.

AFAICS the change is easy.  (Just set `font' to nil in
`org-columns--display-here'.)

What do you think?


Ciao!




Re: Bug: org-read-date ignores hours?

2020-02-11 Thread Marco Wahl
Bastien  writes:

> I tried 
>
> (progn
>   (setq org-popup-calendar-for-date-prompt t)
>   (org-read-date t))
>
> (progn
>   (setq org-popup-calendar-for-date-prompt nil)
>   (org-read-date t))
>
> from master and could not reproduce the problem (not having the
> inserted time string taken into account).
>
> Marco, can you reproduce the problem in master?

I get back a date with a time in each case.

Concretely find the return values below if I do

C-u C-x C-e 11:55 RET

after each of the two sexp's below.

(progn
  (setq org-popup-calendar-for-date-prompt t)
  (org-read-date t))

"2020-02-11 11:55"

(progn
  (setq org-popup-calendar-for-date-prompt nil)
  (org-read-date t))

"2020-02-11 11:55"

In summary I can say that this LGTM and I can't reproduce the problem.


Ciao!







Re: A new, "org-bullets"-like minor mode

2020-02-01 Thread Marco Wahl
D  writes:

> On 01.02.20 21:32, Marco Wahl wrote:
>> AFAICS org-bullets is released under GPL3.  Doesn't this mean that you
>> can use org-bullets as a base for further development if you leave the
>> license intact and also keep the original authors next to your name?
>
> That is correct, I just don't mean to come off as rude making a still
> rather derivative mode like that without trying to get the guy's
> blessing.  I am likely overthinking the matter.

I see and I think that's fine that you want to contact the original
author first.

> Would it be appropriate to share the link here? I think it would be
> great to get feedback before trying to get it on melpa.

I would say yes, but it's just me.  For sure there is no guarantee for
feedback.  But there is some potential since at least some people
playing with Org hang out on this list.


Best regards,
-- 
Marco



Re: A new, "org-bullets"-like minor mode

2020-02-01 Thread Marco Wahl
D  writes:

> However, since the mode still contains code snippets from org-bullets, I
> have tried to contact the original author (sabof) of the package in the
> hopes of getting an official approval before making the thing public.
> The problem with /that/ however is that the author has been inactive for
> several years now, with the package being maintained by Jonas Bernoulli,
> who I did not yet contact.

AFAICS org-bullets is released under GPL3.  Doesn't this mean that you
can use org-bullets as a base for further development if you leave the
license intact and also keep the original authors next to your name?


Best regards,
--
Marco



Re: [RFC] C-c C-c in agenda

2020-02-01 Thread Marco Wahl
Samuel Wales  writes:

> i think it can be confusing to new users to have column mode
> accidentally activated.  what are the things they will try to get out
> of it?  maybe worth considering all the panic commands they'd try, and
> either deactivate or message what to do to deactivate?

Indeed.  Ease the breakout from column view was the main motivation for
the binding.

> if c-c c-c is being weighed, maybe consider it as one of those things
> to possibly tip the balance?  i do not use column mode (drawers are
> slow, too disorrganized to make a contact list with it), so cannot
> say.
>
> some things they might try are: q, c-c c-c, c-c c-k, esc esc esc, c-g,
> undo, whatever they tried last, c-u on whatever they tried last,
> revert, kill buffer, ? as a speed command, look at mode line, skim the
> manual [for what?], c-z, whatever vim does, spacemacs?.

The inspiration for the C-c C-c to quit column view was the removal of
highlightings hanging around from a sparse tree with those keys C-c C-c.

BTW C-c C-c is also a way out of the macro editing buffer.  { M-x
kmacro-edit-macro }

> similar for things like outline search view and org agenda restriction
> lock, but in my experience, those are less commonly accidentally
> activated.

I also think so for restriction lock.


Ciao,
--
Marco



Re: [RFC] C-c C-c in agenda

2020-02-01 Thread Marco Wahl
Hi Adam,

Adam Porter  writes:

>> For some days now C-c C-c disables column view in Org files.  This helps
>> me a bit and never got in my way.  And I thought it would be quite
>> natural and consistent to use this binding for the agenda too.
>>
>> What do you think about all that?
>
> Hi Marco,
>
> I've always had the impression that the "C-c C-c" binding was intended
> to do the most obviously useful or natural action in the current
> context.  For example, in a capture or log buffer, it completes the
> capture.  With point on a #+ line, it resets buffer properties
> accordingly.
>
> I don't use column view very often, so I may be biased, but anyway: in
> the general context of an Agenda buffer, I don't feel like enabling or
> disabling column view is the most obviously useful or natural thing to
> do, so "C-c C-c" doesn't seem like an appropriate binding to me.

Yes, it might not be 100% natural.

But as Samuel pointed out accidentially turned on column view can be a
trap in particular for new users.  And C-c C-c often is a way out not
only in Org mode.  And also recall Bastien's observation that C-c C-c
already all the time quit column view when triggered on a line in column
view state.


Best regards,
--
Marco



Re: [RFC] Document level property drawer

2020-02-01 Thread Marco Wahl


>> Sebastian Miele  writes:

>>> I would like to be able to make a clear distinction between properties
>>> that are visible by default and properties that are not. Maybe it would
>>> be possible to allow some #+.. syntax following headings for subtree
>>> properties that are visible by default. A requirement could be made that
>>> such property specifications always have to be followed by a property
>>> drawer, even if that is empty. Then everything #+.. that is before the
>>> property drawer would belong to the heading/subtree, and everything #+..
>>> that follows the drawer would be treated as it is until now.
>>>
>>> Please tell me if I missed something and Org is already capable of
>>> something like that. If not, are there others who would like
>>> visible-by-default property specifications for headings/subtrees in
>>> addition to invisible-by-default property specifications in drawers,
>>> too?
>>
>> I don't think Org is capable of this out of the box right now.  Further
>> I don't feel the need for a visible-by-default property, but that's just
>> me.
>
> After a few more months of living without that feature I must say that I
> basically live perfectly well without that, too. I just do not define
> source block header args in property drawers. It gets a bit verbose at
> times. But not to the degree of being painful.

Sounds good to me.

>>> Finally, I would like to state an opinion: If there is
>>> visible-by-default (by #+..) and invisible-by-default (by drawers)
>>> syntax for headings/subtrees, including level 0, it may be viable to
>>> require them to be disjoint for each heading/subtree. Most probably it
>>> would be good practice, anyway. And the precedence question raised
>>> previously in this thread would be eliminated.
>>
>> I may not feel the need for the visible/invisible-by-default properties
>> but actually I like the idea of #+ properties parallel to the property
>> drawers as visible by default properties.  But since the #+ properties
>> may appear anywhere in the Org file and affect the whole file it would
>> be difficult or even impossible to give them reliable meaning for
>> subtrees AFAICS.
>
> In the meantime I had a look into worg/dev/org-syntax.org. From the
> document: "Property drawers are a special type of drawer containing
> properties attached to a headline. They are located right after a
> headline and its planning information."

Thanks for the quote.

> So, currently, #+ properties may not appear between a heading and a
> property drawer. At least not without turning the property drawer into a
> non-special drawer. So, in principle, it would be possible to change the
> syntax of Org to allow #+ properties between headings and (possibly
> empty) property drawers in order to denote visible-by-default
> properties attached to a heading.

Sounds true AFAICS.

> Moreover, this change probably would introduce very little to no
> backwards incompatibility. With the change it would not be possible to
> turn property drawers into non-special drawers by putting a #+ property
> before them. Now it is possible to sort of uncomment property drawers by
> putting #+ properties before them. This "feature" probably is hardly
> used, if at all.

I also think this is very corner case-y.

All in all I think your idea is good.  But the masses did not scream for
that change so I think your idea is something for a wishlist to wait for
further discussion.


Best regards,
-- 
Marco



Re: [RFC] C-c C-c in agenda

2020-01-28 Thread Marco Wahl
Bastien  writes:

>> Thanks - I still don't see any real usecase.
>
> Ok, I constructed one:
>
> #+COLUMNS:  %30ITEM %MYPROP
> #+PROPERTY: MYPROP_ALL "[x]" "[ ]"
>
> * NEXT Rien
>   :PROPERTIES:
>   :MYPROP:  [ ]
>   :END:
>
> In this case, when the cursor is on the MYPROP column in column
> (agenda or not) view, C-c C-c will toggle the value.

Yes!  Seeing your example I remember!  Find this example more or less in
section (info "(org) Column attributes").  Just FYI.







Re: [RFC] C-c C-c in agenda

2020-01-28 Thread Marco Wahl


>> You miss the lines which have not been transformed into columns by
>> column view, and I think that's all.
>
> When I turn on `org-agenda-columns', all the lines of my agenda are
> transformed into columns.  Can you give me an example where some lines
> are not transformed into columns?  My experience is certainly peculiar.

Examples of non-transformed lines are

- The first line, which here is "Day-agenda (W05):".

- `org-agenda-block-separator' lines which I have set to ^L.

- Grid lines (key G)

>>> (I'm not sure what org-columns--toggle does, but that's another
>>> story.)
>>
>> Yes, but maybe this fits in here as a sub story.  The function does the
>> toggling part described in the manual
>>
>> #v+
>> ‘C-c C-c’ (‘org-columns-toggle-or-columns-quit’)
>>  When there is a checkbox at point, toggle it.  Else exit column
>>  view.
>> #v-
>
> I will investigate and possible remove this, if it is not useful.

Possibly it's difficult to realize checkbox toggle otherwise in column
view mode.  (Just my spontaneous 2ct thought.)


Bye!



Re: [RFC] C-c C-c in agenda

2020-01-28 Thread Marco Wahl
Bastien  writes:

>> I've now tested this and see how it can be useful, but having C-c C-c
>> perform this unique deactivation in agenda view seems unfinished.
>
> Also, when columns are activated in an agenda view, org-columns-map
> already bind C-c C-c to org-columns-toggle-or-columns-quit, so C-c C-c
> already deactivate the column view in agenda buffer.
>
> Or do I miss something?

You miss the lines which have not been transformed into columns by
column view, and I think that's all.

> (I'm not sure what org-columns--toggle does, but that's another
> story.)

Yes, but maybe this fits in here as a sub story.  The function does the
toggling part described in the manual

#v+
‘C-c C-c’ (‘org-columns-toggle-or-columns-quit’)
 When there is a checkbox at point, toggle it.  Else exit column
 view.
#v-

This functionality looks very special to me but possibly someone enjoys
this behavior daily.

>> I suggest C-c C-c can also call `org-agenda-set-tags' when the column
>> view is not activated.
>
> I just added this.

Okay, thanks.



[RFC] C-c C-c in agenda

2020-01-28 Thread Marco Wahl
Hello community,

Off list I have politely been pointed to possibly have gone too far with
a recent commit to master.  Thanks for that.

To the issue:  With the current master branch C-c C-c disables column
view in the agenda.

For some days now C-c C-c disables column view in Org files.  This helps
me a bit and never got in my way.  And I thought it would be quite
natural and consistent to use this binding for the agenda too.

What do you think about all that?


Best regards,
-- 
Marco




Re: noweb

2020-01-22 Thread Marco Wahl
Nuno Salgado  writes:

> My question was to figure out what's the point to tangle the code
> without substituition!

Your imagination is the limit.  E.g. this could be useful to document
the ":noweb eval" behavior opposed to ":noweb yes".





Re: noweb

2020-01-22 Thread Marco Wahl
Nuno Salgado  writes:

>   Vars definition:
>   #+NAME:DEFVARS
>
>   #+BEGIN_SRC shell :tangle yes
> v1=1;
> v2=2;
>   #+END_SRC
>
>   Script1:
>
>   #+BEGIN_SRC shell :tangle yes :noweb eval
> <>
> echo $v1;
>   #+END_SRC
>
> This works great when I do C-c C-c in each script.
>
> But when I do org-babel-tangle, the code gets two <>.
>
> Does it makes sense? Since I set noweb = eval why does it exports
> <>?
>
> Could you please help me turning around this problem without removing every 
> reference <>

You can find the answer in the documentation, I think.  See e.g. (info
"(org) Noweb Reference Syntax").


HTH
-- 
Marco



Re: [RFC] Document level property drawer

2020-01-13 Thread Marco Wahl
Sebastian Miele  writes:

> But for such properties to satisfactorily work for me, they would have
> to be visible by default. E.g. I would want the header-args to be
> immediately visible just like they are when they are written after
> #+BEGIN_SRC or #+HEADER. Otherwise I would find myself constantly
> wondering whether this or that property drawer contains something
> essential and every TAB on a collapsed headline would have be followed
> by an accompanying move to the property drawer and a TAB there.
>
> On the other hand, there are properties that are very good candidates
> for remaining hidden by default, like ID.
>
> I would like to be able to make a clear distinction between properties
> that are visible by default and properties that are not. Maybe it would
> be possible to allow some #+.. syntax following headings for subtree
> properties that are visible by default. A requirement could be made that
> such property specifications always have to be followed by a property
> drawer, even if that is empty. Then everything #+.. that is before the
> property drawer would belong to the heading/subtree, and everything #+..
> that follows the drawer would be treated as it is until now.
>
> Please tell me if I missed something and Org is already capable of
> something like that. If not, are there others who would like
> visible-by-default property specifications for headings/subtrees in
> addition to invisible-by-default property specifications in drawers,
> too?

I don't think Org is capable of this out of the box right now.  Further
I don't feel the need for a visible-by-default property, but that's just
me.

> Finally, I would like to state an opinion: If there is
> visible-by-default (by #+..) and invisible-by-default (by drawers)
> syntax for headings/subtrees, including level 0, it may be viable to
> require them to be disjoint for each heading/subtree. Most probably it
> would be good practice, anyway. And the precedence question raised
> previously in this thread would be eliminated.

I may not feel the need for the visible/invisible-by-default properties
but actually I like the idea of #+ properties parallel to the property
drawers as visible by default properties.  But since the #+ properties
may appear anywhere in the Org file and affect the whole file it would
be difficult or even impossible to give them reliable meaning for
subtrees AFAICS.


My 2ct,
-- 
Marco



Re: problem with org-toggle-inline-images

2019-12-31 Thread Marco Wahl
Nicolas Goaziou  writes:

> Hello,
>
> Marco Wahl  writes:
>
>> A natural fix is committed, I think.  Would be great if you could test
>> this fix.
>
> Thank you for the fix.
>
> Could you refactor it so belongs to org-compat.el? For example, we could
> create image-map keymap there if Emacs < 26.

Okay, I make a TODO out of this and try to work on the task soon.  Right
now I'm on my way outside... :)


Ciao



Re: Bug: C-c C-k show branches also expands archived headings [9.3.1 (9.3.1-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20191226/)]

2019-12-31 Thread Marco Wahl
Allen Li  writes:

> The command org-kill-note-or-show-branches bound to C-c C-k when used to
> show branches also expands headings tagged with :ARCHIVE:.  This is
> contrary to expectations, as the manual states:
>
> ‘C-c C-k’ (‘outline-show-branches’)
>  Expose all the headings of the subtree, CONTENTS view for just one
>  subtree.
>
> CONTENTS view when using TAB cycling does not expand archived headings.
>
> Can be reproduced with a .org file containing:
>
> * Foo
> ** Bar :ARCHIVE:
> *** Baz
>
> Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
>  of 2019-08-29
> Package: Org mode version 9.3.1 (9.3.1-elpaplus @ 
> /home/ionasal/.emacs.d/elpa/org-plus-contrib-20191226/)

Please check out the git heads or a future Org vorsion for the
fix.


Thanks.








Re: problem with org-toggle-inline-images

2019-12-31 Thread Marco Wahl
Johannes Brauer  writes:

> Typing C-c C-x C-v the image is displayed in the org buffer
> correctly. Typing C-c C-x C-v again the image does not disappear and I
> get the error message:
>
> org-toggle-inline-images: Symbol’s value as variable is void: image-map
>
> Any hints what is going wrong?
>
> I am using
> Aquamacs 3.5  GNU Emacs 25.3.50.1 (x86_64-apple-darwin16.7.0, NS
> macOs 10.15.2
> Org mode version 9.3 (9.3-8-geab7c4-ELPA

IIUC variable image-map was introduced with Emacs 26.  This looks like a
good explanation of the behavior in your environment.

A natural fix is committed, I think.  Would be great if you could test
this fix.

If you want to use the image key map to rotate and zoom inline images in
Org you need to upgrade to Emacs 26, though.


Thanks again and best regards.






Re: How to get parsed output of org-eww-copy-for-org-mode ?

2019-12-24 Thread Marco Wahl
stardiviner  writes:

> I try to get the parsed HTML content into Org format content for org capture
> template.
>
> #+begin_src emacs-lisp
> (require 'org-eww)
> (with-temp-buffer
>   (insert html)
>   (org-eww-copy-for-org-mode)
>   ;; FIXME does not yank converted content, inserted original HTML instead.
>   (current-kill 0)
>   (org-yank))
> #+end_src
>
> But in upper code snippet, the ~current-kill~ or ~org-yank~ (or
> ~yank~) can't get the
> output. I try to use *advice-add*, but I don't know which advice
> combinator can
> archive the purpose that get the parsed output of
> ~org-eww-copy-for-org-mode~ and
> save it somewhere like variable or register. So that I can yank in capture
> buffer again.

org-eww-copy-for-org-mode works reasonably only on a buffer that has
been prepared by the shr library.  The typical example for such buffer
is the output of eww.

If plain html is given and you want to use org-eww-copy-for-org-mode you
could prepare a suitable buffer along the lines of shr-render-buffer, I
think.


HTH






Re: problem with org-toggle-inline-images

2019-12-24 Thread Marco Wahl
Hi Johannes,

Thanks for the report.

> Typing C-c C-x C-v the image is displayed in the org buffer
> correctly. Typing C-c C-x C-v again the image does not disappear and I
> get the error message:
>
> org-toggle-inline-images: Symbol’s value as variable is void: image-map
>
> Any hints what is going wrong?

Possibly variable image-map is not used correctly in Org or should not
be used at all.  The easiest fix would be to drop the usage of that
variable within Org, I guess.

Does the issue disappear when you do

M-: (require 'image) RET

before the image toggling?


Ciao,
 Marco




Re:

2019-12-12 Thread Marco Wahl
Tim Visher  writes:

> On Thu, Dec 12, 2019 at 4:14 AM Marco Wahl  wrote:
>
>> Justin Vallon  writes:
>>
>> > When I use "emacs --no-init-file", I get the default distribution org
>> > packages, and "> > in my downloaded-melpa-install of org, it does not work.
>> >
>> > Distro org-version is 9.1.9, melpa is 9.3.  describe-key TAB shows
>> > org-cycle, which is a kitchen-sink function.  The docs of the function
>> > has not changed between the versions.
>> >
>> > I believe "> > but I don't have any version besides 9.3 in ~/.emacs.d/elpa.
>>
>> Possibly you want to switch to the new feature (accessible C-c C-,)
>> which BTW allows to wrap regions.
>>
>> The "> See the documentation in section Structure Templates.
>>
>
> What feature are you referring to, Marco? My `C-c C-,` sets the heading
> priority.

This is a reference to the feature announced in ORG-NEWS
e.g. https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS.

Org 9.2 comes with a new template expansion mechanism, combining
~org-insert-structure-template~ bound to ~C-c C-,~.

And also the feature is described in the info documentation in section
"Structure Templates".

Possibly you have defined your personal "C-c C-," Tim?


HTH



Re:

2019-12-12 Thread Marco Wahl
Justin Vallon  writes:

> When I use "emacs --no-init-file", I get the default distribution org
> packages, and " in my downloaded-melpa-install of org, it does not work.
>
> Distro org-version is 9.1.9, melpa is 9.3.  describe-key TAB shows
> org-cycle, which is a kitchen-sink function.  The docs of the function
> has not changed between the versions.
>
> I believe " but I don't have any version besides 9.3 in ~/.emacs.d/elpa.

Possibly you want to switch to the new feature (accessible C-c C-,)
which BTW allows to wrap regions.

The "

[ANN] C-c C-c to quit column-view

2019-12-05 Thread Marco Wahl
Hi,

I just committed a little bit of code that allows to quit column-view
with C-c C-c with the cursor almost everywhere in an Org buffer.  Until
then there was no such key offered.

The behavior is very similar to C-c C-c removing the highlights created
by a sparse tree action.

In particular C-c C-c can not be used for setting the tags on a line in
column view state any more.  But there is still C-c C-q to do this.
Another way is using C-c C-c C-c C-c and then switching back to column
view.

AFAICT this is a little step to more consistency and it makes quitting
column view more convenient.

Please let me know if there are any issues with that change.


Thanks,  Marco




Re: Support for something like org-image-max-width

2019-12-02 Thread Marco Wahl
Terje Larsen  writes:

> There is already org-image-actual-width but the problem with that one is
> that images that have quite small width, but are tall will be scaled and
> become very tall.

> I think it would make sense to introduce something like
> org-image-max-width, which would scale images that are larger than this
> width, but leave images within this width alone.

I think this is doable since there is already a max-width parameter for
images IIRC.  But this means some work AFAICS.  A way could be to allow
a pair like (max-width . 555) as org-image-actual-width with the meaning
to downsize any image wider than 555 and let the smaller images alone.

Could you invest some energy and possibly suggest a patch?  You have all
the time.

> Another interesting thing would be to be able to adjust the max-width to
> the width of the buffer, but not sure how well that will play in all
> cases and how complex that would be.

This looks also doable AFAICT.

FWIW I use a little extension of the image-map which allows to adjust
the image width with the window-width with key "W" on the image.  (Quite
a bunch of w's in that sentence.)

This is the respective code from my init file:
#v+
(defun mw-image-change-width-to-window-width ()
"Resize image width to match window-width."
  (interactive)
  (let* ((image (image--get-image))
 (new-image (image--image-without-parameters image)))
(setcdr image (cdr new-image))
(plist-put (cdr image) :width (nth 2 (window-inside-pixel-edges)

(define-key image-map "W" #'mw-image-change-width-to-window-width)
#v-




Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

2019-12-02 Thread Marco Wahl
Karl Fogel  writes:

> On 02 Dec 2019, Marco Wahl wrote:
>>What about numeric prefix arg 0 to reveal the whole buffer (aka
>>'widen')?  I think this would be a logical completion to the feature.
>
> Since `widen' itself is already available via C-x n w, it might be
> better to save a special flag value like that for some special
> behavior that we (or someone else) might think of in the future.  I'm
> pretty sure that anyone using `org-narrow-to-subtree' must also know
> about the `widen' command, too.

Okay, this sounds sound.

Let me be a bit more explicit about my wish: I vote for the prefix arg 0
to widen because this fits to the logic to view the whole file as level
0 subtree.  With this perspective on the feature the effect of a numeric
prefix argument is clear as day:

...
C-u 2 M-x org-narrow... => Narrow to the level-2 subtree containing point.
C-u 1 M-x org-narrow... => Narrow to the level-1 subtree containing point.
C-u 0 M-x org-narrow... => Narrow to the level-0 subtree containing point.

The last line stands in opposition to the current behavior.

C-u 0 M-x org-narrow... => Narrow to the level-1 subtree containing point.
^  ^







Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

2019-12-02 Thread Marco Wahl
Karl Fogel  writes:

> It allows you to choose what level subtree to narrow to.  There are
> two ways to specify the subtree: use repeated C-u's to select "upward"
> from the current subtree, or use a direct numeric prefix arg to
> specify the subtree "downward" from level 1.  (This is a somewhat
> unusual prefix argument usage, but it's useful to be able to choose
> from either direction, and the convenience of using C-u to select
> upward is quite enormous -- I expect it to be the common case, and
> it's pretty much the only way I use the feature.)
>
> The prefix arg is optional, of course: if you don't pass it, then
> `org-narrow-to-subtree' behaves the same way it has always behaved.

What about numeric prefix arg 0 to reveal the whole buffer (aka
'widen')?  I think this would be a logical completion to the feature.







Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

2019-12-01 Thread Marco Wahl
Hi Karl,

>>I think your enhancement is great and worth a news entry.  What about
>>pushing your code if nobody objects within one week?
>
> Thanks, Marco; I'm glad you like it.  I'll wait a week and then push
> (unless there's discussion, in which case we'll see what the outcome
> of the discussion is first, of course).

This sounds right to me.

> I just created a "kfogel" account at https://code.orgmode.org/ and
> uploaded my SSH key.  Should I mail Bastien about push access, or is
> posting here enough?

I guess it's a good idea to write to Bastien explicitly.

> Regarding a news entry: that means the 9.3 section of etc/ORG-NEWS,
> right?  I will add a news entry to the commit at push time.

Great!

Thanks for asking about the version.  AFAICT there is a feature freeze
right now for version 9.3.  This means you would commit to the 'next'
branch which shall be the next master branch after the release.  And
also you would add the news entry in section [Version Next] in
etc/ORG-NEWS.


Ciao,  Marco



Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

2019-12-01 Thread Marco Wahl
Karl Fogel  writes:

> This is the enhancement to `org-narrow-to-subtree' that I suggested back in 
> May [1].
>
> It allows you to choose what level subtree to narrow to.  There are
> two ways to specify the subtree: use repeated C-u's to select "upward"
> from the current subtree, or use a direct numeric prefix arg to
> specify the subtree "downward" from level 1.  (This is a somewhat
> unusual prefix argument usage, but it's useful to be able to choose
> from either direction, and the convenience of using C-u to select
> upward is quite enormous -- I expect it to be the common case, and
> it's pretty much the only way I use the feature.)
>
> The prefix arg is optional, of course: if you don't pass it, then
> `org-narrow-to-subtree' behaves the same way it has always behaved.

+1

I think your enhancement is great and worth a news entry.  What about
pushing your code if nobody objects within one week?


Ciao,  Marco







Re: is this a known issue in clocktable output?

2019-12-01 Thread Marco Wahl
Soubzriquet  writes:
>> [...]

>> > odd issue with using "day" steps where the date is getting offset
>> > sometimes.
>> >
>> > I saw the issue with 26.1, was not fixed by updating  to current
>> > environment with an empty init.el on OS X:

>> [...]
>>
>> > * Day 1
>> >   :LOGBOOK:
>> >   CLOCK: [2019-11-01 Fri 10:00]--[2019-11-01 Fri 11:00] =>  1:00
>> >   :END:
>> > * Day 2
>> >   :LOGBOOK:
>> >   CLOCK: [2019-11-02 Sat 10:00]--[2019-11-02 Sat 12:00] =>  2:00
>> >   :END:
>> > * Day 3
>> >   :LOGBOOK:
>> >   CLOCK: [2019-11-03 Sun 10:00]--[2019-11-03 Sun 13:00] =>  3:00
>> >   :END:
>> > * Day 4
>> >   :LOGBOOK:
>> >   CLOCK: [2019-11-04 Mon 10:00]--[2019-11-04 Mon 14:00] =>  4:00
>> >   :END:
>> > * Day 5
>> >   :LOGBOOK:
>> >   CLOCK: [2019-11-05 Tue 10:00]--[2019-11-05 Tue 15:00] =>  5:00
>> >   :END:
>> > * Day 6
>> >   :LOGBOOK:
>> >   CLOCK: [2019-11-06 Wed 10:00]--[2019-11-06 Wed 16:00] =>  6:00
>> >   :END:
>> >
>> > #+BEGIN: clocktable :scope file :maxlevel 2 :block thismonth :step day
>> :stepskip0 t
>> >
>> > Daily report: [2019-11-01 Fri]
>> > | Headline | Time   |
>> > |--+|
>> > | *Total time* | *1:00* |
>> > |--+|
>> > | Day 1| 1:00   |
>> >
>> > Daily report: [2019-11-02 Sat]
>> > | Headline | Time   |
>> > |--+|
>> > | *Total time* | *2:00* |
>> > |--+|
>> > | Day 2| 2:00   |
>> >
>> > Daily report: [2019-11-03 Sun]
>> > | Headline | Time   |
>> > |--+|
>> > | *Total time* | *3:00* |
>> > |--+|
>> > | Day 3| 3:00   |
>> >
>> > Daily report: [2019-11-03 Sun]
>> > | Headline | Time   |
>> > |--+|
>> > | *Total time* | *4:00* |
>> > |--+|
>> > | Day 4| 4:00   |
>> >
>> > Daily report: [2019-11-04 Mon]
>> > | Headline | Time   |
>> > |--+|
>> > | *Total time* | *5:00* |
>> > |--+|
>> > | Day 5| 5:00   |
>> >
>> > Daily report: [2019-11-05 Tue]
>> > | Headline | Time   |
>> > |--+|
>> > | *Total time* | *6:00* |
>> > |--+|
>> > | Day 6| 6:00   |
>> >
>> > #+END:
>>
>> I can not reproduce this behavior.

> Hi, sorry I was not more clear - the issue occurs also with emacs -Q  or
> with empty init.el on my system.

Okay, thanks.  I think I'm at the end of my abilities to investigate the
issue further.

I suggest you dig a little deeper for better understanding.  E.g.:

- Try make the example of failure as small as you can.

- Check with a newer version of Org.

- Debug the issue.


Possibly someone else can confirm the issue.
 

HTH,  Marco









Re: is this a known issue in clocktable output?

2019-11-30 Thread Marco Wahl
Soubzriquet  writes:

> I'm new to using org-mode for time tracking, and have run into an odd issue
> with using "day" steps where the date is getting offset sometimes.
>
> I saw the issue with 26.1, was not fixed by updating  to current
> environment with an empty init.el on OS X:

[...]

> * Day 1
>   :LOGBOOK:
>   CLOCK: [2019-11-01 Fri 10:00]--[2019-11-01 Fri 11:00] =>  1:00
>   :END:
> * Day 2
>   :LOGBOOK:
>   CLOCK: [2019-11-02 Sat 10:00]--[2019-11-02 Sat 12:00] =>  2:00
>   :END:
> * Day 3
>   :LOGBOOK:
>   CLOCK: [2019-11-03 Sun 10:00]--[2019-11-03 Sun 13:00] =>  3:00
>   :END:
> * Day 4
>   :LOGBOOK:
>   CLOCK: [2019-11-04 Mon 10:00]--[2019-11-04 Mon 14:00] =>  4:00
>   :END:
> * Day 5
>   :LOGBOOK:
>   CLOCK: [2019-11-05 Tue 10:00]--[2019-11-05 Tue 15:00] =>  5:00
>   :END:
> * Day 6
>   :LOGBOOK:
>   CLOCK: [2019-11-06 Wed 10:00]--[2019-11-06 Wed 16:00] =>  6:00
>   :END:
>
> #+BEGIN: clocktable :scope file :maxlevel 2 :block thismonth :step day 
> :stepskip0 t
>
> Daily report: [2019-11-01 Fri]
> | Headline | Time   |
> |--+|
> | *Total time* | *1:00* |
> |--+|
> | Day 1| 1:00   |
>
> Daily report: [2019-11-02 Sat]
> | Headline | Time   |
> |--+|
> | *Total time* | *2:00* |
> |--+|
> | Day 2| 2:00   |
>
> Daily report: [2019-11-03 Sun]
> | Headline | Time   |
> |--+|
> | *Total time* | *3:00* |
> |--+|
> | Day 3| 3:00   |
>
> Daily report: [2019-11-03 Sun]
> | Headline | Time   |
> |--+|
> | *Total time* | *4:00* |
> |--+|
> | Day 4| 4:00   |
>
> Daily report: [2019-11-04 Mon]
> | Headline | Time   |
> |--+|
> | *Total time* | *5:00* |
> |--+|
> | Day 5| 5:00   |
>
> Daily report: [2019-11-05 Tue]
> | Headline | Time   |
> |--+|
> | *Total time* | *6:00* |
> |--+|
> | Day 6| 6:00   |
>
> #+END:

I can not reproduce this behavior.

Could you please check again with emacs -Q?


Thanks.





Re: Cannot display local images with orgmode under macOS

2019-11-18 Thread Marco Wahl
Jack Kamm  writes:

> I've attached a patch which I believe fixes the issue.

Thanks.

> The problem appears to be that, when imagemagick is installed and the
> image width is unset, that the image will be created by an elisp
> expression like
>
> (create-file "some/image.png" 'imagemagick nil :width nil)
>
> which doesn't work, maybe because imagemagick tries to create a 0-width
> image.
>
> The attached patch reverts to the old behavior of only using imagemagick
> when width is non-nil, fixing the bug introduced by 48da60f47.

Your patch is on the branches master and next now.  I added the word
TINYCHANGE to your commit message.


Ciao



Re: org-timer-set-timer from any buffer

2019-11-05 Thread Marco Wahl
ian martins  writes:

> Is it intentional that org-timer start, stop, and pause-or-continue all
> work from any buffer, but org-timer-set-timer only works from an org buffer?

I bet $1 that this is unintentional.  If it was intentional this should
have been documented, I think.  Possibly you are the first noticing this
inconsistency.







Re: Bug: org-read-date ignores hours?

2019-10-29 Thread Marco Wahl
agzam.ibragi...@gmail.com writes:

> While fooling around with capture templates, I have also noticed this:
>
> (progn
>   (setq org-popup-calendar-for-date-prompt t)
>   (read-date t)))
>
> When prompted, if you type something like "13:00" - it returns correct,
> expected datetime.
>
> But, if you do:
>
> (progn
>   (setq org-popup-calendar-for-date-prompt nil)
>   (read-date t)))
>
> And again, type some time value in the prompt - it returns date with no
> time. This seems to be a bug.

I can confirm this behavior with org-read-date instead of read-date.
And at first glance I also think this is a bug.

I capture this issue for someday.  But of course anyone please feel free
to fix this.

The same holds for the idea to add "h" (hours) and possibly "M"
(minutes) as a further way to specify the hour via org-read-date.


Thanks!



Re: [RFC] Document level property drawer

2019-10-25 Thread Marco Wahl
>> One issue for me is the positioning of the level 0 property drawer.
>> Having the requirement for that drawer starting in the very first
>> line is too strong for me. I guess one would at least like to have
>> the option to add some configuration with the ‘-*-...-*-’ construct
>> which currently only works in the first line.
>
> Hmm, that should work right now. 0..n comment lines are supposed to be
> allowed anyways. I can debug that a bit later to see if something has
> gone amiss.

You are right!  No need to debug anything.  I had #+: lines before the
first property drawer.  Sorry for the confusion.

>> Further I think one would also like to place #+: configuration lines
>> there in particular the #+title: line. What about allowing lines
>> starting with character # above the level 0 property drawer? And put
>> a newly created level 0 property drawer below the first line in the
>> file that does not start with #?
>
> The first patch allowed both coments ("# "-lines) and keyword lines
> (#+...:) as well. But I removed keyword lines for now to start with a
> bit more strict definition, per request from Nicolas. I think the
> parser will be happy if there is as little information abouve the
> drawer as possible, since it will have to retrace itself from the
> first line of the buffer every time it needs to verify that the drawer
> actually is the "proper" property drawer. If that makes sense. So the
> more restrictive we can allow us to be, the better the performance and
> the easier it will be to understand where the drawer goes. And less
> complexity.

Okay.  I keep going with this setting.

I can imagine that the parser is happy with less possibilities
and the user is happy with fast parsing.

But I'm not 100% convinced that #+: lines should not be allowed before
the level 0 property drawer.  E.g. #+title: in the first line looks nice
AFAICT.

> Happy to get more feedback on that decision though!

Hopefully some more feedback comes in...


Best regards,
-- 
Marco




Re: [O] Bug: org-read-date ignores hours?

2019-10-24 Thread Marco Wahl
Hi Ag,

> When I use (org-read-date t) and type something like "+2m" it works as 
> expected, but for
> some reason if I type something like "+2h" it returns datetime with no
> changes. Expected - two hours in the future. Am I missing something?

AFAICS your expectation is not implemented.  See function
org-read-date-get-relative.

+1 for someone trying to implement this idea.


HTH,
-- 
Marco



Re: [O] [RFC] Document level property drawer

2019-10-23 Thread Marco Wahl
> Sooo, a separate branch is created in the Org mode repository named
> "next". I'm not entirely sure how we're supposed to work with it. But
> I've anyways pushed my (non-breaking) patch there.

Thanks again.

One issue for me is the positioning of the level 0 property drawer.
Having the requirement for that drawer starting in the very first line
is too strong for me.

I guess one would at least like to have the option to add some
configuration with the ‘-*-...-*-’ construct which currently only works
in the first line.

Further I think one would also like to place #+: configuration lines
there in particular the #+title: line.

What about allowing lines starting with character # above the level 0
property drawer?  And put a newly created level 0 property drawer below
the first line in the file that does not start with #?






Re: [O] Scroll Agenda Dispatcher window

2019-10-22 Thread Marco Wahl
Hello Nate,

> Sometimes (recently) I have quite a few custom agenda commands and if
> the window is not large enough, I can't view all of the available
> agenda custom commands - what is the keyboard shortcut to scroll /
> display the lower section of the custom agenda commands?

AFAICS there are no commands for scrolling for that case yet.  FWIW in
branch "master" (and "next") C-n, C-p, SPC and DEL work in the agenda
dispatcher like in the export dispatcher, hopefuly.

Possibly { M-x customize-variable RET org-agenda-menu-two-columns }
can help ease your case somewhat if you don't use master.


Ciao,
--
Marco




Re: [O] [RFC] Document level property drawer

2019-10-22 Thread Marco Wahl
Gustav Wikström  writes:

[...]

> Sooo, a separate branch is created in the Org mode repository named
> "next". I'm not entirely sure how we're supposed to work with it. But
> I've anyways pushed my (non-breaking) patch there.

Okay, thanks.  I try to follow the development on the 'next' branch.

[...]

>> Noteworthy observations AFAICT:
>>
>> 1. I could not translate my personal "#+TODO: . N ~ | x c g >" into a
>> respective :TODO: property.
>
> Yes, that's true. The reason is that there is no TODO-property that
> fits in property drawers right now. I.e. special properties such as
> TODO, TAGS, priority, scheduling and deadlines that have special
> syntax for the outline still have no defined meaning for outline level
> 0. I ofc. think that's an oversight ;) But I may also be a bit crazy.
>
> A conclusion to draw from that, that may be worth writing more about,
> is that the property drawer for node level 0 will not be able to
> replace all file-level keywords that exist today.  Only properties that
> currently can also be defined in property drawers in the outline will
> work in the property drawer on level 0.  Makes sense?

Absolutely.

> The idea I had for all the other keywords that apply for the whole
> file was to create another drawer, what I called a settings drawer.
> Because the TODO-keyword you refer to above really is a setting that
> you're making for the current file, much the same as when you make
> changes in global, folder local or file local variables using the
> standard emacs framework.

The idea of a settings drawer makes sense AFAICS.

For the special case of TODO-keywords one could think about defining
them per subtree.  Possibly there are some low hanging fruit among the
whole-file-properties that have a natural interpretation per subtree.

> I've attached an investigation I did of the world of Org mode
> keywords. It was done quite a while back and some things in there are
> subjective and may not represent my current picture of the "ideal".
> Nonetheless, maybe an interesting read for the ... other crazy people
> out there?

Okay, I'll have a look at your investigation. ;)

BTW this document looks great to me at the first glance.


Thanks,
-- 
Marco





Re: [O] [RFC] Document level property drawer

2019-10-16 Thread Marco Wahl
Gustav Wikström  writes:

> I'd like to take the next step with this patch. I'm hesitant to do it
> without wider support though, since only a few people have commented.
>
> @Marco Wahl; As I understand you've applied the patch and tried it
> out. Have you found any issues yet? What do you think of the patch
> after having used it for a while?

Indeed I applied your patch and have it applied still.  Please note that
I did nothing fancy and in particular I did not try to break the patch.

The patch works good for me.

Noteworthy observations AFAICT:

1. I could not translate my personal "#+TODO: . N ~ | x c g >" into a
respective :TODO: property.

2. With org-ids turned on and point before the first heading, function
org-store-link creates an org-id property at the document level.

Regarding number 1. I think a list of document-level properties which
don't behave the same when used in the document property drawer would be
nice.  Ideally this list is empty AFAICT.  Maybe I overlook something.
Is this an issue?

I think observation 2. is just a little surprise but turns out to be
natural when the document level property drawer is enabled.


Still +1 for the inclusion of the patch and HTH,
-- 
Marco





Re: [O] [RFC] Document level property drawer

2019-10-07 Thread Marco Wahl
Adam Porter  writes:

> Marco Wahl  writes:
>
>> One could even think about letting fade out the "#+"-file-wide
>> property definition syntax or at least think about a good place within
>> a file or a subtree for those definitions.  (There is at least
>> Sebastian Miele who wants to keep that syntax as he stated in another
>> thread AFAIR.)
>
> You do realize, don't you, how much software and how many documents such
> a change would break?  One of the primary reasons Org users use Org is
> that its file format is very long-lived and flexible.  There are even
> academic papers written in Org, exported to LaTeX, and a change such as
> that would break them, creating needless work for their authors or other
> interested parties to fix them up in order to still be exportable.

Please let's forget about fading out the "#+"-file-wide property for
now.  I understand that the file-wide properties in their current
meaning need to stay a good while, maybe even as long as Org lives.

Back to the issue of the document level property drawer: could it be we
talk about literally nothing when talking about the "breaking"?

What is an example which shows how the introduction of a document level
property drawer breaks something in the Org universe?  (I think there is
none.)


Ciao,
-- 
Marco




Re: [O] [RFC] Document level property drawer

2019-10-04 Thread Marco Wahl
Adam Porter  writes:

> Marco Wahl  writes:

>> You say the visibility is better for the #+-property keywords.  I say
>> they can occur _anywhere_ in the file and even in some drawers.  See
>> above "#+CATEGORY:  cat-doc-prop-keyword-2".
>>
>> Further you say 
>>
>>>>> - However, it seems to me that the simplest, most natural protocol would
>>>>>   be for later declarations to override earlier ones.
>>
>> This means that cat-doc-prop-keyword-2 from the example defines the
>> CATEGORY property which at least I find not so natural.  And I already
>> stated what I find natural.

> Org may allow #+KEYWORD: lines to appear anywhere in a file, including
> in arbitrary drawers, but that's up to the user.  If the user chooses to
> hide them in drawers, it's his responsibility.
>
> AFAICT that's not a common or generally recommended thing to do.  Most
> Org files have such lines at the top of the file, and some under a
> heading at the bottom of the file with other settings.  Such lines don't
> need to be in drawers, and this proposal wouldn't change that.
>
> So I think it would be confusing if settings in a drawer at the top of
> the file were to absolutely override settings outside of drawers (which
> would mean that hidden settings could override plainly visible ones).
> The most natural protocol would be like written language: later
> declarations override earlier ones.

Hi Adam,

Just I got the idea that for a good part this discussion is about
personal preferences.  For me for example it's not a big deal if a
property is placed within a drawer or not.  I don't care much about the
"visibility" of a property setting.  Of course I respect other views
about this.

What I really find irritating is that "Org ... allows #+KEYWORD: lines
to appear anywhere in a file" (This sentence is from you) with the
meaning that the settings apply to the whole file.  I think this
interpretation of #+KEYWORD: lines is unnecessary and confusing.

BTW I find it completely natural that--let's for simplicity assume an
Org file without any drawers--#+KEYWORD: settings that appear later in
a file replace earlier settings.


Best regards,
-- 
Marco




Re: [O] [RFC] Document level property drawer

2019-10-04 Thread Marco Wahl
Adam Porter  writes:

> Gustav Wikström  writes:
>
>> I'd argue that precedence already works that way. One has to take
>> inheritance into account. With inheritance turned on, tell me which
>> value for Property1 is used for the nodes in the following example:
>>
>> #+begin_src org
>>   ,* Node 1
>>   ,* Node 2
>>   :PROPERTIES:
>>   :Property1: Value1
>>   :END:
>>
>>   ,#+PROPERTY: Property1 Value2
>> #+end_src
>>
>> As you'll see line number already isn't the deciding factor.
>>
>> With two ways to define properties it makes sense to first think of
>> which syntax to promote as "more important" and then to think of
>> precedence rules for duplicates within each syntax.
>>
>> Having the same syntax for node level 0 as for regular nodes makes the
>> property functionality easy to understand and congruent. Something I
>> think is worth promoting by saying that property blocks on file-level
>> has precedence over the keyword syntax.
>
> I think this example illustrates the issue better.  This is how Org
> currently works:
>
> #+BEGIN_SRC org
>   # Category here is "Alpha"
>
>   ,* Node 1
>
>   # Category here is "Alpha"
>
>   ,* Node 2
>   :PROPERTIES:
>   :CATEGORY: Beta
>   :END:
>
>   # Category here is "Beta"
>
>   ,#+CATEGORY: Alpha
> #+END_SRC
>
>
> IIUC, your proposal would work like this:
>
> #+BEGIN_SRC org
>   :PROPERTIES:
>   :CATEGORY: Gamma
>   :END:
>   
>   # Category here is "Gamma"
>
>   ,* Node 1
>
>   # Category here is "Gamma"
>
>   ,* Node 2
>   :PROPERTIES:
>   :CATEGORY: Beta
>   :END:
>
>   # Category here is "Beta"
>
>   ,#+CATEGORY: Alpha
> #+END_SRC
>
> So the #+CATEGORY: line has no effect because of the first-line property
> drawer.
>
> In Org, some keywords are special, like #+CATEGORY.  For many years,
> such keywords have had file-wide effects regardless of their placement
> in the file.  IIUC, your proposal would change that, and that would
> still be a major, breaking change.

IIUC Org files not using a file level property drawer would not be
affected from the change at all.  With the proposition the user gets a
further option to define a file wide property.

>> If you think of the document as an outline, something Org mode is all
>> about, it makes sense to also think of things before the first
>> headline as "node level 0". And with that way of conceptually thinking
>> of the document it makes perfect sense to have a property drawer fixed
>> at the top - in the same way as it is required for all other node
>> levels.
>
> What you're proposing is actually a fundamental change to the way Org
> documents are interpreted.  Org documents are not currently an outline,
> just a series of elements which may include an outline.  Text and
> elements before a first heading are not part of a node, they're just
> text and elements in the document.
>
> If Org were a new project, I think your proposal might be very
> suitable.  But at this point, it would be a significant, breaking
> change, even without the org-element parser changes.
>
> Consider as well that the Org format has recently been seeing wider use,
> with more implementations becoming available in several languages and on
> several platforms.  Fundamental changes like this would affect more than
> just the official Org software, and the costs of breaking software in
> the wider Org community should be carefully considered.

The proposal is an extension leaving all operations and tools intact for
Org files not using the file wide property drawer AFAICS.  If a tool
depends on a file wide property then it needs to be adapted.  Possibly
this could be called "breaking" but I think this should not hold back
the proposal.

One could even think about letting fade out the "#+"-file-wide property
definition syntax or at least think about a good place within a file or
a subtree for those definitions.  (There is at least Sebastian Miele who
wants to keep that syntax as he stated in another thread AFAIR.)

Personally I think it's a good idea to work for an Org mode where an Org
file behaves very much like an Org subtree.


Ciao,
-- 
Marco




Re: [O] [RFC] Document level property drawer

2019-10-02 Thread Marco Wahl
Adam Porter  writes:

> Marco Wahl  writes:
>
>> Adam Porter  writes:
>>
>>> Gustav Wikström  writes:
>>>
>>>> 3) Properties defined in a property drawer will have precedence over
>>>>properties defined as a property keyword, if the same property is
>>>>defined using both conventions.
>>>
>>> That protocol seems unnatural and confusing to me:
>>>
>>> - If precedence were to be defined by something other than file-order,
>>>   it seems to me that those defined with #+ keywords should have
>>>   precedence, because they are more visible, while those in drawers are
>>>   hidden.
>>> - However, it seems to me that the simplest, most natural protocol would
>>>   be for later declarations to override earlier ones.
>>
>> I think it would be quite natural to use the tree structure of Org.  A
>> property setting in a subtree overrides the setting in a parent (which
>> could be the document(= the whole file.))
>
> Hi Marco,
>
> I think you misunderstood his point #3 and my objection to it.  :)

Hi Adam,

that's possible but I don't think so.  But I'm willing to learn if
I didn't get it. :)

Possibly a concrete example can help.  Let's take Org property CATEGORY
for illustration.

First to Gustav's statement 3):

Let the file be this:

--8<---cut here---start->8---
#+title: file
:PROPERTIES:
:CATEGORY: cat-doc-prop-drawer
:END:

* foo
SCHEDULED: <2019-10-02 Wed>

#+CATEGORY:  cat-doc-prop-keyword-1

** bar

:somedrawer:
#+CATEGORY:  cat-doc-prop-keyword-2
:END:
--8<---cut here---end--->8---

With Gustav's proposition the CATEGORY of task foo is
cat-doc-prop-drawer.

Next to your statements:

You say the visibility is better for the #+-property keywords.  I say
they can occur _anywhere_ in the file and even in some drawers.  See
above "#+CATEGORY:  cat-doc-prop-keyword-2".

Further you say 

>>> - However, it seems to me that the simplest, most natural protocol would
>>>   be for later declarations to override earlier ones.

This means that cat-doc-prop-keyword-2 from the example defines the
CATEGORY property which at least I find not so natural.  And I already
stated what I find natural.


Best regards,  Marco




Re: [O] [RFC] Document level property drawer

2019-09-30 Thread Marco Wahl
Adam Porter  writes:

> Gustav Wikström  writes:
>
>> 3) Properties defined in a property drawer will have precedence over
>>properties defined as a property keyword, if the same property is
>>defined using both conventions.
>
> That protocol seems unnatural and confusing to me:
>
> - If precedence were to be defined by something other than file-order,
>   it seems to me that those defined with #+ keywords should have
>   precedence, because they are more visible, while those in drawers are
>   hidden.
> - However, it seems to me that the simplest, most natural protocol would
>   be for later declarations to override earlier ones.

I think it would be quite natural to use the tree structure of Org.  A
property setting in a subtree overrides the setting in a parent (which
could be the document(= the whole file.))

>> 4) The position for the document level property drawer is:
>>- At the first line in a file that is not a comment or a keyword.
>>
>>  I.e. the following will work:
>>
>>  #+begin_src org
>># -*- mode: org -*-
>>,#+TITLE: Test
>>:PROPERTIES:
>>:CATEGORY: Test
>>:END:
>>
>>Preamble
>>
>>,* Some heading
>>Some content
>>  #+end_src

[...]

> That feels unintuitive to me.  Document-level property keywords may
> appear anywhere in a file, so it seems inconsistent for document-level
> property drawers to be limited in this way, as if there were an implied
> headline at the top of the file.  If it were so, I would expect to see
> many mailing list posts by users asking why the properties defined in
> their document-level property drawers aren't working.  Given that there
> is no enforcement in Org's UI to keep such drawers in certain places, I
> think the implementation should be tolerant of users' preferences and
> mistakes (cf. Postel's Law).

TBH allowing document-level properties anywhere in an Org file looks
rather messy to me.  When a user is interested in all the document-level
properties she needs to scan the whole file.  Also the spread out
document-level properties introduce a distinction between a whole Org
file and an Org subtree.

I think the distinction between Org file and Org subtree should be kept
to a minimum.  Wouldn't it be nice if Org files can be considered as Org
subtrees?  In this sense a property drawer for the document is a step in
the right direction.


Ciao,
--
Marco




Re: [O] [RFC] Document level property drawer

2019-09-29 Thread Marco Wahl
Hi,

> This patch introduces a document level property drawer. 

[...]

> What do you say?

I'll install the patch and have a look how it feels in my little
personal Org universe.


Thanks,
-- 
Marco




Re: [O] Cannot display local images with orgmode under macOS

2019-09-27 Thread Marco Wahl
Zhengyu Duan  writes:

> My image display problem was fixed with this commit
>
> https://github.com/hlissner/doom-emacs/commit/87b7a8da052601c51bc0577484916856364401cb

Thanks for the information!


Ciao,
-- 
Marco






  1   2   3   4   >