Below update is after I updated to the latest org master:
On Thu, May 25, 2017 at 10:53 PM Kyle Meyer <[email protected]> wrote:
> Ah, right ... 'make compile' uses a single Emacs instance, while 'make
> single' uses a separate Emacs instance for each file.
>
I wasn't even doing that. I was doing M-x byte-compile-file and selecting
org.el.
That gives me (without applying your patch):
Compiling file
/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/org-mode/lisp/org.el
at Fri May 26 14:04:52 2017
In org-goto-map:
org.el:7412:9:Warning: function org-goto-map used to take 0+ arguments, now
takes 0
In org-todo:
org.el:12398:12:Warning: function org-todo used to take 0+ arguments, now
takes 0-1
In org-store-log-note:
org.el:13635:8:Warning: function org-store-log-note used to take 0+
arguments,
now takes 0
In org-at-timestamp-p:
org.el:17909:40:Warning: reference to free variable
‘org-agenda-include-inactive-timestamps’
In org-self-insert-command:
org.el:19910:32:Warning: function org-self-insert-command used to take 0+
arguments, now takes 1
With 'make single' on master, I get a compile error due to the
> eval-when-compile's added in 53ee147f4 (Add support for new switches to
> org-get-heading, 2017-01-17) and 6dc6eb3b0 (Fix failing test,
> 2017-01-19).
> In toplevel form:
> org.el:7914:51:Error: Symbol’s value as variable is void:
> org-comment-string
>
I get that too.
> Your patch is only the appropriate fix if we're confident that
> org-agenda will be loaded at the time that the
> org-agenda-include-inactive-timestamps code path of org-at-timestamp-p
> is executed. Otherwise, we're just silencing a warning about a possible
> run-time void variable error. Have you looked this?
No, I didn't.. your bound-and-true-p patch makes more sense.
So.. should we consider the warnings output by simple byte-compile-file?
Even if not, the warnings do not make sense.. just taking this example:
In org-goto-map:
org.el:7412:9:Warning: function org-goto-map used to take 0+ arguments, now
takes 0
Nowhere is org-goto-map defined to take 0+ arguments (meaning have
"&optional arg" as signature) and then redefined to have 0 arguments (which
is the actual case). Wondering why the compiler thinks that. I had a quick
look at byte-compile-arglist-warn function that outputs this warning.. but
couldn't understand the logic for sig1 in there.
--
Kaushal Modi
