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

2021-05-01 Thread Kyle Meyer
Kyle Meyer writes:

> Ah, sorry for not writing that more clearly.  By the above, I wasn't
> saying that the ones I commented on were the _only_ ones I see with
> Emacs 24.5 on maint.

I've dealt with a few more.

 * ob-C.el:477:1:Error: Unknown upattern `(quote integerp)'

   Introduced by 38f87a26b (ob-C.el: Fix a number a regressions related
   to table parameters, 2021-04-29).

   Fixed by 8bd3bd093.

 * org-agenda.el:10851:1:Warning: the following functions are not known
   to be defined: [...] window-font-width

   I mentioned upthread (<87czubrqh6@kyleam.com>) that I didn't
   think this was easy to solve with a wrapper.  Instead I've added a
   fallback to the previous calculation, which was in action for a long
   time and is certainly better than a void-function error (94837fc6b).

 * Compiler-macro error for python-syntax-context: (void-function
   python-syntax--context-compiler-macro)

   I don't know what's going on here.  This is triggered by
   (python-syntax-context 'string) in ob-python.  That looks like it
   should work on Emacs 24, where python.el has
   python-syntax--context-compiler-macro.

   Despite the message from the compiler, evaluating
   (python-syntax-context 'string) directly seems to work as expected,
   so perhaps this doesn't actually cause ob-python breakage.

Aside from the harmless ol-eww warnings already mentioned, that leaves
the funcall-interactively instances.



Re: Transforming table and then exporting as CSV

2021-05-01 Thread Kyle Meyer
Pankaj Jangid writes:
[...]
> Same org file has multiple tables, so I am asking for “Table Name”. I
> want to do two improvements:
>
> 1. When asking for table name, I want to offer all the table names in
>the file as completion options.

You could collect names with something like

  (require 'subr-x)

  (let (names)
(org-table-map-tables
 (lambda ()
   (when-let ((name (org-element-property :name (org-element-at-point
 (push name names)))
 'quiet)
(nreverse names))

and then pass those as the collection to completing-read.

> 2. Current table at point as default

You could get that with

  (and (org-at-table-p)
   (save-excursion
 (goto-char (org-table-begin))
 (org-element-property :name (org-element-at-point

and pass that as the default for completing-read.

> 3. I want to run the function from command line. Like,
>
> --8<---cut here---start->8---
>emacs --batch enet_2021_22.org -l enet.el --eval="(enet-export 
> \"APR2021\")"
> --8<---cut here---end--->8---
>
>Do I need to change the (interactive...) part in any way to enable
>this?

I think that'd be the cleanest way, yes.  You could change

  (interactive "MTable Name: ")

into

  (interactive (list (completing-read ...)))



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

2021-05-01 Thread Kyle Meyer
Ihor Radchenko writes:

> Kyle Meyer  writes:
>
>> Here are a few notes on ones present in maint that I've glanced at.
>
> I confirm that there are no warning using Emacs 25.3.1 on maint.
>
> For Emacs 24.5.1, I see that following in addition to what you
> mentioned:

Ah, sorry for not writing that more clearly.  By the above, I wasn't
saying that the ones I commented on were the _only_ ones I see with
Emacs 24.5 on maint.



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

2021-04-30 Thread Kyle Meyer
Ihor Radchenko writes:

> I was recently testing Org mode using old Emacs versions. Running make
> on master fails with the following errors and warnings:

Here are a few notes on ones present in maint that I've glanced at.

> Compiling /home/yantar92/Git/org-mode/lisp/ol-eww.el...
>
> In org-eww-store-link:
> ol-eww.el:76:36:Warning: reference to free variable `eww-data'
>
> In end of data:
> ol-eww.el:182:1:Warning: the function `eww-current-url' is not known to be
> defined.

These are guarded by version checks.  Ideally the compatibility kludges
would be done in a way to avoid the warnings (e.g., with boundp/fboundp
guards) or at least wrapped in with-no-warnings, though harmless
warnings on Emacs 24 don't really matter too much at this point.

> In end of data:
> org-agenda.el:10851:1:Warning: the following functions are not known to be
> defined: funcall-interactively, window-font-width

Adding a compatibility function for window-font-width is tricky.  We
can't just add something like below to org-compat because font-info (C
code) wasn't added until Emacs 25.

  (if (fboundp 'window-font-width)
  (defalias 'org-window-font-width 'window-font-width)
(defun org-window-font-width ( window face)
  (with-selected-window (window-normalize-window window t)
(if (display-multi-font-p)
(let* ((face (if face face 'default))
   (info (font-info (face-font face)))
   (width (aref info 11)))
  (if (> width 0)
  width
(aref info 10)))
  (frame-char-width)

> In org-display-inline-images:
> org.el:16554:57:Warning: reference to free variable `image-map'

This warning is now gone (df84100d0), though functionally it was fine
due to a version check.

> In end of data:
> org.el:21292:1:Warning: the function `make-process' is not known to be
> defined.

This should be addressed by 869b7a21b.



Re: [PATCH] Fix numbering of captioned images

2021-04-30 Thread Kyle Meyer
Pablo Barraza Cornejo writes:

> Sounds good to me! I've modified the patch to reflect this change.
[...]
> Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering

Thanks.  Pushed (390063d8d).



Re: [PATCH] Fix numbering of captioned images

2021-04-29 Thread Kyle Meyer
Pablo Barraza Cornejo writes:

> When exporting to HTML, the exporter is supposed to check if there 
> are additional constraints over a paragraph using 
> `org-html-standalone-image-predicate'.  A misplaced quote causes 
> `org-html-standalone-image-p' to not apply them.

Thanks for catching the issue and for sending a patch.  This looks like
a regression introduced way back in 8.2.7 by ab1ce2a75 (ox-html: Fix
spurious "figure" divs on empty paragraphs, 2014-05-15).

> Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering.

The convention in this project is to leave off the trailing period from
the subject.

> * lisp/ox-html.el (org-html-standalone-image-p): Remove quote  which
> causes `org-html-standalone-image-p' to not check if 
> `org-html-standalone-image-predicate' is bound.

Please fill this line to ~70 characters (set in the repo's
.dir-locals.el).

>  (and (eq (org-element-type paragraph) 'paragraph)
> -  (or (not (fboundp 'org-html-standalone-image-predicate))
> +  (or (not (fboundp org-html-standalone-image-predicate))
>(funcall org-html-standalone-image-predicate paragraph))

This quote will indeed result in the fboundp call always returning nil:

  (let ((org-html-standalone-image-predicate #'org-html--has-caption-p))
(fboundp 'org-html-standalone-image-predicate))  ; => nil

  (let ((org-html-standalone-image-predicate #'org-html--has-caption-p))
(fboundp org-html-standalone-image-predicate))   ; => t

However, the proposed change will introduce another issue.
org-html-standalone-image-predicate is defined as

  (defvar org-html-standalone-image-predicate)

That means it's left uninitialized:

  (defvar my/foo)   ; => my/foo
  (boundp 'my/foo)  ; => nil
  (fboundp my/foo)  ; error: (void-variable my/foo)

What about returning to the boundp/fboundp combination that was in place
before ab1ce2a75?

  (and (boundp 'my/foo)
   (fboundp my/foo)); => nil
  
  (let ((my/foo #'ignore))
(and (boundp 'my/foo)
 (fboundp my/foo)))  ; => t



Re: Bug: org-babel only tangles first noweb reference on a line [9.4 (9.4-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20200914/)]

2021-04-27 Thread Kyle Meyer
Bastien writes:

> Hi Tom,
>
> Tom Gillespie  writes:
>
>>The 9.4 release has a bug where it will only tangle the first noweb
>> reference on a line.
>> This is also present at 9c31cba002a1ba93053aebea1f778be87f61ba06. It happens 
>> in
>> emacs-27 and emacs-28. The reproduction is below. Best!
>> Tom
>>
>> The expected content of oops-3.el should be 1 2 1, but is instead 1
>> <> <>.
>> C-c C-v C-t or C-c C-v C-v will show the issue.
>
> Do you still have this issue?  I cannot reproduce it here.

A patch upthread ()
was applied in 469ee6340 (ob-core: Fix handling of multiple noweb refs
in same line, 2020-09-15).



Re: [PATCH] org-manual.org: Fix syntax

2021-04-26 Thread Kyle Meyer
Cheong Yiu Fung writes:

> Subject: [PATCH] org-manual.org: Fix syntax
>
> * doc/org-manual.org (HTML export commands): Fix kbd representation

Thanks.  Pushed (58cacdf0e), adding a period after "representation".



Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

2021-04-26 Thread Kyle Meyer
Bastien writes:

> Hi,
>
> thanks for the patch, we do indeed need to move forward for this.
>
> Could you propose the patch against the master branch (not the maint
> branch, since this is not a bugfix) and perhaps fix *all* warnings?

Thanks, but these were already taken care of by 8c29cbdef (Backport
commit c45bfd3c4 from Emacs, 2021-04-18), which was merged into master
with 664b65344.



Re: org-contacts.el use lexical-let not defined in cl-lib

2021-04-23 Thread Kyle Meyer
Michael Eliachevitch writes:

> Dear all,
>
> I'm not sure if this is the correct mailinglist for org-contrib
> bugs.

Thanks for the report.  Yes, this is the place [*].  stardiviner (+cc)
recently took over maintaining org-contacts.el.

> I found that org-contacts.el uses `lexical-let*` which is defined in
> `cl`, but it only requires `cl-lib` where it is not defined.
[...]
> My org version is release_9.4.5-321-ge641d3. However, I see that 
> on the master branch still uses lexical-let*.
>
> Is this a bug or some error in my configuration? Should I send an 
> email elsewhere or submit a bug-report? Because (require 'cl) is 
> deprecated, test solution would be to replace the lexical-let* 
> with something else like a normal let*, but I'm not confident 
> enough in my lisp to do this by myself.

This is a bug in org-contacts.el.  Loading cl was dropped in ea238b78f
(contrib: move a few libraries to cl-lib in place of compile-time cl,
2015-11-06), and, as you note, it's still needed for lexical-let.

I haven't looked at the org-contact's lexical-let call sites closely,
but I think the way forward is to move org-contacts.el over to lexical
binding and stop using anything from cl.el.

stardiviner, what do you think?


[*] ... though sometime soon the plan is to move contrib/ packages
elsewhere, at which point I guess it mostly will depend on who is
taking care of a given contrib/ package.

https://orgmode.org/list/87wnzfy60h@bzg.fr



Re: unable to resolve link to Gnus email

2021-04-23 Thread Kyle Meyer
Seb writes:

> Hello,
>
> Attempting to export with any exporter fails if document or a subtree
> thereof contains an email link, e.g. captured from a Gnus buffer:
>
> [[gnus:GroupName#EMAIL_ID][Email from John Doe]]
>
> I get the error:
>
> user-error: Unable to resolve link: 
> "gnus:Melanie#ef90b1cff5264135a82bff491006b...@cawnsmbme105.me.mbgov.ca"

Do you have ol-gnus loaded? [*]  It doesn't define an :export function,
but it's still important so that the link is recognized as a gnus link.
Otherwise org-export-resolve-fuzzy-link will handle it, signaling
org-link-broken.

Using your example

  
[[gnus:Melanie#ef90b1cff5264135a82bff491006b...@cawnsmbme105.me.mbgov.ca][Email 
from John Doe]]

here's what I see on my end (e641d3736) with no custom configuration.

Without ol-gnus loaded:

 * (org-element-property :type (org-element-context))  ; "fuzzy"
 * export fails with "Unable to resolve link"

With ol-gnus loaded:

 * (org-element-property :type (org-element-context))  ; "gnus"
 * export succeeds


[*] If you're not tweaking org-modules, it should be loaded by default.



Re: Bug: org-caputure fails, sometimes [9.3.7 (release_9.3.7-705-gea9463 @ /home/oub/emacs/site-lisp/packages/org/)]

2021-04-23 Thread Kyle Meyer
Uwe Brauer writes:

> I am running GNU emacs and org mode, whose versions are specified below.
> Sometimes when being in a gnus message buffer and running org-capture
> I obtain an error whose bug trace I attach. Usually I have to restart
> emacs.
>
> ,
> | 
> | Debugger entered--Lisp error: (error "Capture template ‘ms’: No article on 
> current line")
> |   signal(error ("Capture template ‘ms’: No article on current line"))
> |   error("Capture template `%s': %s" "ms" "No article on current line")
> |   org-capture(nil)
> |   funcall-interactively(org-capture nil)
> |   call-interactively(org-capture nil nil)
> |   command-execute(org-capture)

With this backtrace alone (which involves org-capture catching the
internal error), I think it's going to be hard for anyone to guess
what's going on here.  It sounds like once you encounter this error,
subsequent calls reliably trigger it.  Next time you run into it, I'd
suggest re-evaluating org-capture to something like below to hopefully
see a more informative backtrace.

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 831c3e1f4..b20124ced 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -693,9 +693,7 @@ (defun org-capture ( goto keys)
  (string-prefix-p "CAPTURE-" (buffer-name)))
 (kill-buffer (current-buffer)))
   (set-window-configuration (org-capture-get :return-to-wconf))
-  (error "Capture template `%s': %s"
- (org-capture-get :key)
- (error-message-string error
+  (signal (car error) (cdr error
(when (and (derived-mode-p 'org-mode) (org-capture-get :clock-in))
  (condition-case nil
  (progn



Re: List of ob-* maintainers

2021-04-20 Thread Kyle Meyer
Thomas S. Dye writes:

> Aloha Kyle,
>
> Thanks for this.  I think the Worg list might be useful to 
> indicate which languages don't have maintainers. Or, is the 
> information in the source files sufficient?

I don't know, but adding the information to the Worg table sounds fine
to me.

Thanks.



Re: Bug: table header line mode misaligned in org-indent-mode

2021-04-19 Thread Kyle Meyer
Oorja Sandhu writes:

> Steps :
> 1. emacs -Q
> Latest Emacs cloned and built from master today.
>
> 2. Open the attached org file
>
> 3. M-x org-table-header-line-mode
>
> 4. M-x org-indent-mode
>
> 5. Resize emacs window very small such that horizontal as well as vertical 
> scrolling is required to see it fully.
>
> 6. Go to end of line in a row in the table when the header line overlay is 
> active.
>
> Observation : the header is misaligned proportional to depth of current 
> headline, attached screenshot.
>
> Expectation : header be indented as much as the table.

Thanks for the report.  I can trigger it, though I haven't been able to
come up with a fix.  It seems like it must be some interaction between
text properties (org-indent-mode) and overlays
(org-table-header-line-mode), but I don't have a good idea of what that
would be.  Perhaps others have ideas.



Re: Bug: wrong font for checkboxes in org-mouse mode org-odt-data-dir not defined correctly [9.4.4 (9.4.4-dist @ /Users/administrator/.emacs.d/packages/elpa/org-plus-contrib-20210322/)]

2021-04-19 Thread Kyle Meyer
Yaroslav Rogov writes:

> Currenty there’re following lines in org-mouse.el:
>
> (font-lock-add-keywords
>nil
>`(("^[ \t]*\\([-+*]\\|[0-9]+[.)]\\) +\\(\\[[ X]\\]\\)"
>   (2 `(face bold keymap ,org-mouse-map mouse-face highlight) 
> t)))
>t))
>
> https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-mouse.el#L893-L897
>
> Yet there’s special org-checkbox face obviously not used here.
> Relic from the past?

Thanks for noticing.  It does look like a relic, and org-checkbox should
be used here for a consistent appearance.  Updated (9b4dbe5f0).

What's the "org-odt-data-dir not defined correctly" bit in the subject
about?



Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

2021-04-19 Thread Kyle Meyer
Jorge P. de Morais Neto writes:

> Hi.  The HTML export has JavaScript that LibreJS does not recognize as
> free.

Thanks for noting this.  That's certainly not ideal.

> My first attempt at an workaround (inspired by the Org Mode mailing
> list) was merely encoding the ampersand in the magnet link, but that
> *did not make LibreJS happy*.  Then I checked LibreJS manual and saw
> this excerpt:
>
> https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1
>
> Public domain is not a license (see
> https://www.gnu.org/licenses/license-list.html#PublicDomain).  If
> you want to release your work to the public domain, the FSF
> recommends using CC0.
>
> Then I came up with a successful workaround.  I included the following
> code in my Org Mode customization file:

Hmm, the public domain switched happen with 471054136 (ox-html.el: Use
classList and put in the public domain, 2020-09-05) and the associated
thread is

  https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/

(+cc author and committer)

> ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS
> (with-eval-after-load 'ox-html
>   (setq org-html-scripts
>   (string-replace "\
> // @license 
> magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a=public-domain.txt
>  Public Domain"
>   "\
> // @license 
> magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08dn=cc0.txt 
> CC0-1.0"
>   org-html-scripts)))
>
> This works; it makes LibreJS happy.

Okay.  Anthony/Bastien/others, thoughts on using CC0 instead?



Re: List of ob-* maintainers

2021-04-19 Thread Kyle Meyer
Thomas S. Dye writes:

> Aloha all,
>
> Is there a list of current ob-* maintainers?

Bastien updated the "Maintainer" field of the source files:

  $ git grep -i maintainer lisp/ob-* | cut -d'<' -f1
  lisp/ob-C.el:;; Maintainer: Thierry Banel
  lisp/ob-J.el:;; Maintainer: Joseph Novakovich
  lisp/ob-R.el:;; Maintainer: Jeremie Juste
  lisp/ob-abc.el:;; Maintainer: William Waites
  lisp/ob-clojure.el:;; Maintainer: Bastien Guerry
  lisp/ob-dot.el:;; Maintainer: Justin Abrahms
  lisp/ob-eshell.el:;; Maintainer: stardiviner
  lisp/ob-groovy.el:;; Maintainer: Palak Mathur
  lisp/ob-haskell.el:;; Maintainer: Lawrence Bottorff
  lisp/ob-java.el:;; Maintainer: Ian Martins
  lisp/ob-mscgen.el:;; Maintainer: Justin Abrahms
  lisp/ob-perl.el:;; Maintainer: Corwin Brust
  lisp/ob-python.el:;; Maintainer: Jack Kamm
  lisp/ob-screen.el:;; Maintainer: Ken Mankoff

  $ git describe
  release_9.4.5-317-g3d5284326

The oldest addition is from September 2020, so that should be a fairly
current list.

> Perhaps it would be useful to add and populate a Maintainer column to
> the language table on Worg (org-contrib/babel/languages/index.html)?

Hmm, I suppose it's nice to have just one spot to avoid information
becoming out of sync, but that's a minor issue, so no objections from me
if you or others think it'd be helpful to have the information on Worg.



Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag

2021-04-19 Thread Kyle Meyer
Tim Visher writes:

> On Wed, Jan 20, 2021 at 11:10 PM Kyle Meyer  wrote:
>>
>> It's been applied to master (f4b9f9808).  Please report back if you
>> still encounter the problem in your use case.
>>
>
> I (finally) got around to testing this out. Initially I thought it had been
> released in 9.4.5 but AFAICT that's not the case. Does org not get released
> from `master`?

For version X.Y.Z, Z ticks happen from maint.

> Unfortunately, the title now is essentially the exact text of the org
> heading, which is awkward in terms of readability for a general audience
> (and probably for SEO etc.). I know I said in my original message that I
> think stripping all the markup characters would be going too far but now I
> think I've come full circle and rendering the title as nothing but the
> plain text without any markup information feels like the right solution
> given what the title is supposed to convey.
>
> So, would we be willing to accept a patch to that effect? :)

I don't have an informed opinion about the above, but providing a patch
might prompt those that do (including TEC, the author of the above
commit, as well as Jens, who provided reviews) to give their input.



Re: link syntax fixing bug?

2021-04-17 Thread Kyle Meyer
Samuel Wales writes:

> in recent maint, i am trying the code included with the maint release
> to update org link escaping syntax.
>
> the issue is that when i click on google, the space before "hi" does
> not show up in the earch box.  ergo, different results.
>
> *** should be orig
> [[http://www.google.com/search?q=%7E%22retroactive%20whatever%22%20%22hi%22][retro
> original]]
> *** should be fixed, is not?
> [[http://www.google.com/search?q=~"retroactive whatever" "hi"][retro
> original]]

My understanding is that the Org 9.3 changes were about moving away from
the percent-encoding that Org used to avoid "[" and "]" in the link.  It
looks like the URL you're showing above should be left as is because it
is the usual URL percent-encoding, without the pre-9.3 Org
percent-encoding on top.

Here are some threads related to this:

  https://orgmode.org/list/87tvguyohn@nicolasgoaziou.fr/T/#u
  https://orgmode.org/list/87sgvusl43@nicolasgoaziou.fr/T/#u



Re: [PATCH] Remove diary-list-entries Emacs 21 compat code

2021-04-17 Thread Kyle Meyer
Stefan Kangas writes:

> Please find attached a small cleanup patch to org-agenda.el.

Thanks.  Pushed (3a7e1c047).



Re: [PATCH] org-eldoc: Fix compatibility with eldoc 1.11 and Emacs 27

2021-04-17 Thread Kyle Meyer
Trevor Murphy writes:

> * contrib/lisp/org-eldoc.el (org-eldoc-documentation-function): Check
>   before invoking elisp eldoc functions from Emacs 28.
>
> The previous check assumed that the presence of eldoc 1.11 bindings
> implied elisp-mode bindings that come with Emacs>=28, but eldoc 1.11
> is available on GNU Elpa so the assumption doesn't always hold.

Thanks.  Pushed (7e2eba8cc).



Re: Bug: table header line mode causes next-line to reach beginning of line

2021-04-17 Thread Kyle Meyer
Oorja Sandhu writes:

[...]
> 3. M-x org-table-header-line-mode
>
> 4. Resize emacs window very small such that horizontal as well as
> vertical scrolling is required to see it fully.
> 
> Otherwise, add rows and columns in the org table in the file such that
> it exceeds window size both vertically and horizontally. This is not a
> useless example because the header line mode is most useful when you
> have a big table and heading scrolls off your visible window.
>
> 5. Go to end of line in a row in the table when the header line
> overlay is active.
>
> 6. Press C-n  (or down arrow) twice
>
> Observation : cursor is at the beginning-of-line
>
> Expected : cursor should remain at the same column as earlier

Thanks for the report and the clear steps to reproduce the issue.

> =
> My unsuccessful code analysis, if anyone is interested :
> There is a post command hook to update the overlay of table
> header. This includes the function "beginning-of-line". In more recent
> versions of org, it is (move-beginning-of-line 2).
>
> But all instances of "beginning-of-line" or "move-beginning-of-line"
> are wrapped in "save-excursion".. In fact if I invoke
> (org-table-header-set-header) instead of C-n, the cursor does not go
> to beginning of line.

Yes, it looks like the issue is that the movement in
org-table-header-set-header resets temporary-goal-column to 0, messing
with the logic in line-move-1.  This should be fixed by f12ca1a56.



Re: Bug: Display Inline Images from Subdirectory [9.4.4 (9.4.4-33-g5450d6-elpaplus @ /home/ded/.emacs.d/elpa/org-plus-contrib-20210322/)]

2021-04-10 Thread Kyle Meyer
Daniel E. Doherty writes:

> Nick,
>
> Thanks for trying this out.  I tried this again using emacs -Q with both
> emacs27 and emacs28, and I still get the same result, i.e., it produces
> the link but does not display it inline.  Both versions supported
> display of SVG graphics files.

Hmm, I see the same behavior you're describing: your custom function
doesn't trigger the inline display when :dir is used.

Let's look at the custom function...

> | (defun ded:org-babel-inline-display-subtree ()
> |   "Redisplay inline images in subtree if cursor in source block with 
> :result graphics."
> |
> |   (when (org-in-src-block-p)
> | (let (beg end)
> |   (save-mark-and-excursion
> | (org-mark-subtree)
> | (setq beg (point))
> | (setq end (mark)))
> |   (when-let ((info (org-babel-get-src-block-info t))
> |  (params (org-babel-process-params (nth 2 info)))
> |  (result-params (cdr (assq :result-params params)))
> |  ((member "graphics" result-params)))
> | (org-display-inline-images nil nil beg end)
> |
> | (add-hook 'org-babel-after-execute-hook 
>   #'ded:org-babel-inline-display-subtree)

So, org-display-inline-images is probably the place to start debugging.
You can step through its execution [1] and compare the "no :dir" vs
":dir" cases.  When I did that, I noticed that a

  (expand-file-name "dot/lehman.svg")

leads to a non-existent "/path/to/dot/dot/lehman.svg" (note the
repeating "dot/").  That's because :dir temporarily changes the
directory, and org-babel-after-execute-hook executes in that context.

To work around that, you could avoid using org-babel-after-execute-hook
and instead advise org-babel-execute-src-block so that your function is
called afterward.  Another approach would be to let-bind the
default-directory in your function:

  (when (org-in-src-block-p)
(let ((default-directory (if-let ((fname (buffer-file-name)))
 (file-name-directory fname)
   default-directory))
  ...)
  ...))


[1] (info "(elisp)Instrumenting")



Re: On the protection of emails in the archives

2021-04-09 Thread Kyle Meyer
Guillaume MULLER writes:

> Hi all,
>
> I recently sent an email on this mailing list (see
> https://orgmode.org/list/b1e778c5-acbf-8a17-c9bf-dcb6693e9...@univ-st-etienne.fr/
> )
>
> Since then, I'm receiving spams on the email address I used to send
> the message.
>
> After some research, it seems that this email address only appears on
> 2 websites, notably this orgmode.org mailing list archive.

Your email address can also be harvested from the lists.gnu.org
archives.  Inspect the output of

  $ curl -fSsL 
https://lists.gnu.org/archive/html/emacs-orgmode/2020-07/msg00125.html
  $ curl -fSsL https://lists.gnu.org/archive/mbox/emacs-orgmode/2020-07

> Would it be possible to configure the archive to obfuscate / hide the
> email addresses inorder to protect its users?

 and its upstream source
 are public-inbox
() archives.  There's an option (disabled by
default) to configure address obfuscation.  However, in my view email
obfuscation is giving you a false sense of security.  Ignoring other
ways spammers get your address, you're posting to a public space, and
your address can be harvested (and, as shown above, not just from these
public-inbox archives).

And this isn't something specific to Org mode's archives.  Just as some
examples, take a look at ,
,
, or
.

Anyway, that being said and despite my opinion on this, I'm considering
turning on obfuscation at  and
.  There's at least one issue that'd need to
be fixed before doing so though:
.



Re: how to select interactively the time in org-time-stamp

2021-04-08 Thread Kyle Meyer
Uwe Brauer writes:

> ,
> | (org-time-stamp ARG  INACTIVE)
> | 
> | Prompt for a date/time and insert a time stamp.
> | 
> | If the user specifies a time like HH:MM or if this command is
> | called with at least one prefix argument, the time stamp contains
> | the date and the time.  Otherwise, only the date is included.
> `
>
> So I run 
> C-u C-c .
>
> And org proposes me the date and time of that moment, I can change the
> date, since the calendar pops up, but how I can change *interactively*
> time time?

I don't think there's another way to specify the time aside from writing
out a time in some form described by

(info "(org)The date/time prompt")

As far as I know, C-u is just useful when you want to use the current
time (and perhaps another date).



Re: Bug: org-link-descriptive needs to be buffer-local [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]

2021-04-06 Thread Kyle Meyer
Ingo Lohmar writes:

> On Mon, Apr 05 2021 22:36 (-0400), Kyle Meyer wrote:

>> Hmm, I think a problem with `:local t' (or, equivalently,
>> make-variable-buffer-local for backward compatibility reasons) is that
>> then you'd interfere with user customization that directly sets this
>> after ol.el is loaded.  You could also still get into a mismatched state
>> like you described above if you load an Org buffer, set the value
>> through the customization interface, and then call
>> org-toggle-link-display in that buffer.
[...]
> I am not sure that I understand the problem you're describing..  Maybe
> it's because I don't use the customize interface myself, but I think any
> such customization would only set the default value, wouldn't it?

Yes.  Here are expanded descriptions for the two problems I'm referring
to above.  This is based on testing with the `:local t' diff below (on
top of bcfe6f985, before the commit I mentioned in my last message).

  * Breaks customization of direct setq callers if ol.el is already
loaded.

If

  (setq org-link-descriptive nil)

is executed after ol.el is loaded, links in a visited Org buffer
will be displayed according to the default org-link-descriptive
value of t.

  * Setting org-link-descriptive via the customization interface can get
into a mismatched state.

- Visit an Org file with a link and description.
  org-link-descriptive is at its global value of t.

- Set org-link-descriptive to nil via the customization interface,
  changing the global value to nil.  This value is in effect in the
  Org buffer because org-link-descriptive isn't yet buffer-local.
  The description is still hidden because buffer-invisibility-spec
  hasn't been changed.

- Calling org-toggle-link-display sets org-link-descriptive to t,
  making org-link-descriptive a buffer-local variable.  The
  appearance of the description doesn't change due to the mismatch
  (like described in your original report).  Calling it again aligns
  the buffer-local value and buffer-invisibility-spec.

diff --git a/lisp/ol.el b/lisp/ol.el
index d1db1683b..0e225ce4e 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -193,6 +193,7 @@ (defcustom org-link-descriptive t
 `org-toggle-link-display' or from the \"Org > Hyperlinks\" menu."
   :group 'org-link
   :type 'boolean
+  :local t
   :safe #'booleanp)
 
 (defcustom org-link-make-description-function nil



Re: Bug: org-attach-follow with wrong-number-of-arguments [ ( @ /home/sbrass/.emacs.d/elpa/org-9.4.4/)]

2021-04-05 Thread Kyle Meyer
[ Sorry for the slow reply. ]

Simon Braß writes:

> Hi all,
>
> I've tried to open an attached file (added with org-attach-attach), however,
> when I try to open it with C-c C-o I got the following backtrace:
>
> #+begin_example
> Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
>   org-attach-follow("1805.00020.pdf")
>   org-link-open((link (:type "attachment" :path "1805.00020.pdf" :format
> bracket :raw-link "attachment:1805.00020.pdf" :application nil
> :search-option nil :begin 717 :end 818 :contents-begin 746 :contents-end
> 816 :post-blank 0 :parent (paragraph (:begin 717 :end 819 :contents-begin
> 717 :contents-end 819 :post-blank 0 :post-affiliated 717 :parent (item
> (:bullet "- " :begin 708 :end 819 :contents-begin 717 :contents-end 819
> :checkbox off :counter nil :structure (... ... ... ... ...) :pre-blank 0
> :post-blank 0 :post-affiliated 708 :tag nil :parent (plain-list ...)))
> nil)
>   org-open-at-point(nil)
>   funcall-interactively(org-open-at-point nil)
>   call-interactively(org-open-at-point nil nil)
>   command-execute(org-open-at-point)
> #+end_example

Hmm, this looks like an inaccessible state for Org 9.4.4.  Here's how
org-link-open would handle an attachment type:

  (let ((f (org-link-get-parameter type :follow)))
(when (functionp f)
  ;; Function defined in `:follow' parameter may use a single
  ;; argument, as it was mandatory before Org 9.4.  This is
  ;; deprecated, but support it for now.
  (condition-case nil
  (funcall (org-link-get-parameter type :follow) path arg)
(wrong-number-of-arguments
 (funcall (org-link-get-parameter type :follow) path)

So it first calls with the expected 2 arguments and then falls back to
the single one.

Follow attachment links works okay on my end, and, aside from a mixed
installation, I can't think of a way to get into that state.

  https://orgmode.org/worg/org-faq.html#mixed-install

> After adding == to the definition of =org-attach-follow=, and
> reloading org-mode (uncompiled) I could get through org-attach-follow.
> But, then I hit another issue:
>
> #+begin_example
> Debugger entered--Lisp error: (void-function org-link-open-as-file)
>   (org-link-open-as-file (org-attach-expand file) arg)
>   org-attach-follow("0906.4487.pdf")
>   …
> #+end_example

That function was added in 9.4 and is in the same file as the caller,
org-link-open.  The fact that it's not defined also points to a mixed
install, with an older ol.el taking precedence.



Re: "#+STARTUP: hideblocks" has no effect?

2021-04-05 Thread Kyle Meyer
autofrettage writes:

> I recently read about the #+STARTUP parameter "hideblocks", but it
> doesn't seem to have any effect in my set-up. All the blocks kept
> laughing straight in my face. :-(
>
> Any ideas about what could have gone wrong?

Are you leaving org-startup-folded at showeverything (the default as of
9.4)?  That will prevent org-startup-folded and "#+startup: hideblocks"
from having an effect:

  (defun org-set-startup-visibility ()
...
(unless (eq org-startup-folded 'showeverything)
  (when org-hide-block-startup (org-hide-block-all))
  ...)

For example, try this:

--8<---cut here---start->8---
#+startup: nofold
#+startup: hideblocks

#+begin_src emacs-lisp
(message "ok")
#+end_src
--8<---cut here---end--->8---



Re: Bug: org-link-descriptive needs to be buffer-local [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]

2021-04-05 Thread Kyle Meyer
Ingo Lohmar writes:

> I stumbled upon weird behavior when using `org-toggle-link-display', and
> I finally checked what that is about.
>
> Observation:
> - use `org-toggle-link-display' in org buffer A, and (coming
>   from the defaults) links are now shown in full (not just the
>   description), but only in buffer A
> - switch to org buffer B, still only showing the description part, and
>   again use `o-t-l-d' --- nothing changes
> - the state for new org buffers is as before, onle link descriptions are
>   shown.
>
> This behavior is very confusing, IMO.  The reason is simple.  The
> display hiding comes from changing the `buffer-invisibility-spec', which
> is automatically buffer-local.  But the state of the org toggle is kept
> in `org-link-descriptive', which is global!

Thanks for the clear problem description and analysis.  I agree that
this is a bug and don't suspect that anyone is relying on
org-toggle-link-display to toggling the global value.

Gustavo reported the same issue at
, but unfortunately
it didn't get any attention back then.

> I suggest a simple fix that I just tested: make `org-link-descriptive'
> automatically buffer-local, by adding ":local t" to the defcustom.

Hmm, I think a problem with `:local t' (or, equivalently,
make-variable-buffer-local for backward compatibility reasons) is that
then you'd interfere with user customization that directly sets this
after ol.el is loaded.  You could also still get into a mismatched state
like you described above if you load an Org buffer, set the value
through the customization interface, and then call
org-toggle-link-display in that buffer.

Instead I've updated the body of `org-mode' to make org-link-descriptive
buffer-local (702e782cb).



Re: Can no longer org-set-link-parameters with "fuzzy" link types

2021-04-05 Thread Kyle Meyer
[ Sorry for the slow response. ]

Adam Sneller writes:

> I have a function that searches for broken fuzzy links in org-mode and
> applies org-warning face to anything it finds:
>
> (org-link-set-parameters
> "fuzzy"
> :face (lambda (path)
> (let ((org-link-search-inhibit-query t))
> (if (condition-case nil
> (save-excursion
> (save-match-data
> (org-link-search path (point) t)))
> (error nil))
> 'org-link 'org-warning
>
> In 9.4.4 this patch breaks this:
>
> https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba
>
> Is there some other recommended way to get this done as of 9.4.4?

I don't know enough about the change to say whether this is recommended,
but it looks like you could get the behavior you're after with something
like

  (add-to-list 'org-link-parameters
   '("fuzzy" :face (lambda (path) ...)))



Re: life on the eading bledge

2021-04-05 Thread Kyle Meyer
Greg Minshall writes:

> hi.  running c881b60593b3beeed7b8c7a2bada64157cd9940a, the following 
>
> 
> *** this =equals= that
>
> and, so on
> 
>
> exporting [C-e l o], gives
> : replace-regexp-in-string: Wrong type argument: arrayp, nil

Thanks for reporting.  The failure was introduced by bcfe6f985
(ox-latex: convert verbatim text in headings to texttt, 2021-04-04).
The below change seems to fix the issue, though Nicolas may be able to
suggest a more appropriate change.

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 932f38530..ac24f1f74 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1961,8 +1961,16 @@ (defun org-latex-headline (headline contents info)
;; commands (like \section, etc.), and this causes compilation 
to fail.
;; So, within headings it's a good idea to replace any 
instances of \verb
;; with \texttt.
-   (code . (lambda (_ c _) (org-latex--protect-texttt c)))
-   (verbatim . (lambda (_ c _) (org-latex--protect-texttt c))
+   (code . (lambda (o c i)
+ (org-latex--protect-texttt
+  (or c
+  (org-export-data
+   (org-element-property :value o) i)
+   (verbatim . (lambda (o c i)
+ (org-latex--protect-texttt
+  (or c
+  (org-export-data
+   (org-element-property :value o) i
   (text
(org-export-data-with-backend
 (org-element-property :title headline) section-back-end info))




Re: org-adapt-indentation not honored prior to Org 9.4?

2021-03-30 Thread Kyle Meyer
Tim Cross writes:

> one thing I think might help (maybe too late) would be to put the
> entries for both electric-indent-mode and org-adapt-indentation so that
> they are together in the release notes as they do interact with each
> other and often people stop looking once they see one and not the other
> (they are currently a fair 'distance' apart in the file). 

Thanks for the suggestion.  I'm not sure that it will help, but it's
easy to do, at least in the Git repo [*], so I've done so in d017cdb0a.

[*] That of course won't be in effect for the file included with Emacs
27.2.  It also won't be at .
Cc'ing Bastien in case he thinks updating 9.4's Changes.html is
worth it.



Re: [PATCH] Remove redundant #' around lambdas

2021-03-30 Thread Kyle Meyer
Stefan Kangas writes:

> Please find attached a minor cleanup patch.

Thank you.  Pushed (3089fcd69).



Re: [PATCH] org-agenda.el: Rename org-agenda-format-item parameters

2021-03-30 Thread Kyle Meyer
Renato Ferreira writes:

> On Mon, 29 Mar 2021 23:20:02 -0400, Kyle Meyer  said:
>
>> Presumably you arrived at this patch because you hit into a particular
>> issue (related the lexical binding conversion in 129c33ddd).
>> Could you provide a reproducer (or at least a description) for that
>> problem?  That'd be useful for reviewing this patch, as well as
>> assessing if the conversion has other similar issues.
>
> Sure:
>
> ```org
>
> * TODO Header [...]

Great, thanks.  Pushed (6a50e41ea).




Re: fuzzy link can't be exported when \begin{foo} is there

2021-03-29 Thread Kyle Meyer
James Powell writes:

> First time poster, long time user.  Glad to be here.

Welcome.

> This seems to a bug.
[...]
> When I add some latex in the middle:
> <>
> In Table [[tableOne]] I show that this site has AADT 143925, by 
> TVT_Detailed_2019.xlsx.
>
> \begin{landscape}
> #+NAME: tableOne
> #+CAPTION: Site 26016 has AADT 143925.
> | SITE_ID | LRM  |  BEGMP |  ENDMP | CLASS_01 | [...] |   AADT | 
> K_FACTOR | D_FACTOR | Ton_Factor |
> |   26016 | 00100I00 | 297.31 | 298.93 | 0.11 | [...] | 143925 
> |  7.5 |   52 |  4 |
> \end{landscape}
> <>
> I expect it to keep on working.  But instead, now I get
>
> :  1 high  Unknown fuzzy location "tableOne"
> in org-lint.  Latex export reports "BROKEN LINK".

I believe the above text is sent as is (i.e. that won't be processed as
an Org table).  Calling org-element-at-point on it reports that it's a
latex-environment.

Perhaps you want

--8<---cut here---start->8---
#+LATEX: \begin{landscape}
#+NAME: tableOne
#+CAPTION: Site 26016 has AADT 143925.
| SITE_ID | LRM  |  BEGMP |  ENDMP | CLASS_01 | [...] |   AADT | K_FACTOR | 
D_FACTOR | Ton_Factor |
|   26016 | 00100I00 | 297.31 | 298.93 | 0.11 | [...] | 143925 |  7.5 | 
  52 |  4 |
#+LATEX: \end{landscape}
--8<---cut here---end--->8---

> Incidentally I started this bug report with org-mode 9.3.6.  Back in
> 9.3.6, it was worse: not only would org-lint report 'unknown fuzzy'
> and latex export say "BROKEN LINK" but also C-c C-o
> (org-open-at-point) would fail to find the target and make the jump.

The type error was guarded against with 3bb073b63 (ol: Fix type error in
org-link-search corner case, 2020-11-30).  There's no name here, so it
then falls back to fuzzy search.
Compare

  (org-element-property :name (org-element-at-point))

in with point on the table in your original snippet and the suggested
one above.



Re: org-adapt-indentation not honored prior to Org 9.4?

2021-03-29 Thread Kyle Meyer
Mike Kupfer writes:

> Over the weekend I upgraded my Emacs from 27.1 (Org 9.3) to 27.2-rc2
> (Org 9.4).  I noticed that Org mode behaves differently, even with
> "emacs -Q".
>
> In 27.1, if I visit foo.org and type "* header RET", point is put in the
> first column.  In 27.2, point is put in column 3.
>
> AFAIK, I'm not using electric-indent-mode; at least it's not shown in
> the minor mode list in the modeline.

electric-indent-mode has been enabled by default since Emacs 24.  If you
run `C-h v electric-indent-mode` under emacs -Q, you should see that its
value is t.

> org-adapt-indentation is t in both Emacs 27.1 and Emacs 27.2.  Was there
> a bug fix that went into Org 9.4 such that org-adapt-indentation is now
> honored?

Not that I'm aware of.  However, Org was changed to respect the
electric-indent-mode value: d3e6b5800 (Make RET and C-j obey
`electric-indent-mode', 2020-05-05)

https://orgmode.org/list/877dxpazbo.fsf...@gmail.com/T/#u

> Could the change in behavior be documented in the ORG-NEWS
> file in Emacs?

Here's what ORG-NEWS says under the 9.4 release:

--8<---cut here---start->8---
*** =RET= and =C-j= now obey ~electric-indent-mode~

Since Emacs 24.4, ~electric-indent-mode~ is enabled by default.  In
most major modes, this causes =RET= to reindent the current line and
indent the new line, and =C-j= to insert a newline without indenting.

Org mode now obeys this minor mode: when ~electric-indent-mode~ is
enabled, and point is neither in a table nor on a timestamp or a link:

- =RET= (bound to ~org-return~) reindents the current line and indents
  the new line;
- =C-j= (bound to the new command ~org-return-and-maybe-indent~)
  merely inserts a newline.

To get the previous behaviour back, disable ~electric-indent-mode~
explicitly:

#+begin_src emacs-lisp
(add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
#+end_src

Alternatively, if you wish to keep =RET= as the "smart-return" key,
but dislike Org's default indentation of sections, you may prefer to
customize ~org-adapt-indentation~ to either =nil= or ='headline-data=.
--8<---cut here---end--->8---



Re: [PATCH] org-agenda.el: Rename org-agenda-format-item parameters

2021-03-29 Thread Kyle Meyer
Renato Ferreira writes:

> * org-agenda.el (org-agenda-format-item): Rename parameters so they
> don't clash with dynamic variables used by
> `org-prefix-format-compiled'.

Thanks.

Presumably you arrived at this patch because you hit into a particular
issue (related the lexical binding conversion in 129c33ddd).  Could you
provide a reproducer (or at least a description) for that problem?
That'd be useful for reviewing this patch, as well as assessing if the
conversion has other similar issues.



Re: Missing from org-attach buffer?

2021-03-29 Thread Kyle Meyer
Colin Baxter writes:

> Hello,
>
> I seem to recall that attaching files to an org-attach directory could
> be done by one letter commands from the M-x org-attach 
> buffer. These commands seem now to be missing, and the only way to
> attach files to the directory is via M-x org-attach-attach-cp , or
> M-x org-attach-attach-ln , etc. I wonder why the changes were made,
> or am I not understanding something here?

Hmm, the org-attach command still exists and is bound to `C-c C-a'.
I've just tried calling it (current master, 4d9dabc36), and it pops up
the expected dispatcher for me.



Re: [PATCH 0/1] Add option to delay fontification of source blocks

2021-03-28 Thread Kyle Meyer
Leo Okawa Ericson writes:

> Fontification of long code blocks can be very slow. The patch, which should be
> in another other email, mitigates this by
> adding an option to delay the fontification after the user has become idle by
> using idle timers. This seems to be faster from my limited testing, but I'm 
> not
> sure if something will go horribly wrong because of the timers.

Thanks for the patch.  My initial reaction is that I'm not sure about
adding an idle timer for a particular aspect of fontification.  If we do
go this route, I think the case needs to be made why this spot is
special, and why we don't expect or would reject follow-up patches for
this and that other area.

Have you explored whether jit-lock (e.g., jit-lock-defer-time) helps for
your use case?



Re: [PATCH 1/2] org-manual.org: Fix typo in org-protocol capture example

2021-03-28 Thread Kyle Meyer
Maxim Nikulin writes:

> * doc/org-manual.org: Use "&" as parameter separator in query part
> of example for org-protocol capture URI.

Thank you.  Pushed this and the next patch (4de2fff87), with a minor
formatting tweak to the second commit message.



Re: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex-and-related faces

2021-03-27 Thread Kyle Meyer
Sébastien Miquel writes:

> I've looked at the history of this code, and some earlier comment
> indicated that limit was ignored on purpose.

Thanks for digging.  LIMIT was dropped from the re-search-forward call
in 80268c0e0 (Fix fontification of LaTeX environments, 2019-01-01), with
the addition of the now-removed comment you mention.

The related thread is
https://orgmode.org/list/CAELgYhdcW1XnR7BTmos6vAF_YPJ4Wdp=3feahbeyfea4b2n...@mail.gmail.com/T/#u

I'm not sure about that change, but either way I think it's a good
reason to stick with your proposed approach.  Pushed (36622362d).

Thanks.



Re: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex-and-related faces

2021-03-24 Thread Kyle Meyer
Sébastien Miquel writes:

> With the current org-do-latex-and-related function, fontification of
> a region before a LaTeX fragment repeatedly adds the
> 'org-latex-and-related face to the fragment.
>
> You can reproduce with an org buffer with the following content.
[...]
> The attached patch fixes this.

Thanks for the clear reproduction steps and for the patch.

> Subject: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex faces
>
> * lisp/org.el (org-do-latex-and-related): Do not add a
> 'org-latex-and-related face beyond the fontification limit

Please add a period after the changelog entry.

  https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html

> ---
>  lisp/org.el | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 4db2dbe04..a0c703630 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -5502,6 +5502,8 @@ highlighting was done, nil otherwise."
>   (while (and (< (point) limit)
>   (re-search-forward org-latex-and-related-regexp nil t))
> (cond
> +   ((>= (match-beginning 0) limit)
> + (throw 'found nil))

Any reason not to pass limit as re-search-forward's BOUND instead?



Re: emacs27 and let: Symbol’s value as variable is void: org-table-header-line-p

2021-03-24 Thread Kyle Meyer
Santiago Mejia writes:

> Hi All,
>
> I just did a clean install of Xubuntu 20.04.  I also installed emacs27
> (from this repository:ppa:kelleyk/emacs)
>
> When I try to export any snippet from org-mode by calling
> org-export-dispatch, my freshly installed emacs complains:
>
> "let: Symbol’s value as variable is void: org-table-header-line-p"

Nothing looks off in Org's sources: org-table.el defines
org-table-header-line-p, and that is used in one spot in org.el, which
loads org-table.el.

org-table-header-line-p was added recently (v9.4).  So, it looks like in
your setup there's a mismatch with a newer org.el loading an older
org-table.el.

https://orgmode.org/worg/org-faq.html#mixed-install



Re: Bug: Hole in `org-html-format-drawer-function' variable documentation [9.4.4 (9.4.4-21-g61336f-elpaplus @ /home/jmazon/.emacs.d/elpa/org-plus-contrib-20210208/)]

2021-03-24 Thread Kyle Meyer
Jean-Baptiste Mazon writes:

> The documentation for customizable variable
> `org-html-format-drawer-function' currently reads as such:
[...]
> For example, the variable could be set to the following function
> in order to mimic default behavior:
>
> The default value simply returns the value of CONTENTS.
> 
>
> There is obviously something missing between the two last paragraphs.

Thanks for noticing.  The example was dropped in adcebf38f (2013-11-14)
but the leading "For example ..." was left behind.  I've dropped that
now too (478929ae6).



Re: [PATCH] Update example :publishing-function names in manual

2021-03-24 Thread Kyle Meyer
Greg Minshall writes:

> ---
>  doc/org-manual.org | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thanks.  Pushed (d15639944), adding a changelog entry.



Re: [PATCH] org-src.el Do not ask to revert unmodified buffers

2021-03-21 Thread Kyle Meyer
Thanks for the patch.

pillule writes:

> Hi, it is asked to the user if we want to revert changes when 
> re-entering in a org-source buffer.
> Even if the buffer have no modifications.

Hmm, that description seems to be focusing on the prompt's parenthetical
note.  When org-src-ask-before-returning-to-edit-buffer is non-nil and
there's an existing source buffer, the caller is asked whether to return
to it or regenerate/overwrite it.  The message warns that the second
option (i.e. answering "no, don't return to existing buffer") will
discard changes.

It looks like this patch assumes that, when the buffer is unmodified,
the answer to the above question necessarily becomes "yes, return to the
existing buffer", but it's not clear to me why that should be.  With an
unmodified buffer, I suppose there's less of a difference between the
two answers, but at least with the default org-src-window-setup value,
there's still a user-visible difference in terms of window organization.



Re: [PATCH] Prefer HTTPS to HTTP for links to gnu.org

2021-03-21 Thread Kyle Meyer
Stefan Kangas writes:

> Thanks.  Here's a followup patch that converts most remaining http-links
> to https.  All of them have been manually tested to avoid breakage.

Great, thank you.  Pushed (2e1c98415).



Re: [PATCH] Prefer HTTPS to HTTP for links to gnu.org

2021-03-21 Thread Kyle Meyer
Stefan Kangas writes:

> The attached patch updates all links to gnu.org to use https instead of
> http.

Pushed (8cc992f7b).

> (Such a change was made in Emacs itself already in 2017.)

Yep, I believe those came into Org's tree with ff0dcf52a (Backport
commit bc511a64f from Emacs, 2017-09-13) and d4d7cda57 (Backport commit
5da53a019 from Emacs, 2017-09-13).  I should have taken the time then to
do a tree-wide update of Org files that are not included with Emacs.

Thanks.



Re: Bug: crash exporing to html [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

2021-03-21 Thread Kyle Meyer
Greg Minshall writes:

> one line in why.org:
> 
> call_find-orgs()
> 
>
> then
> 
> emacs -Q
> 
>
> then
> 
> C-e h h
> 
>
> then
> 
> Debugger entered--Lisp error: (wrong-type-argument consp nil)
>   org-babel-exp-code(nil lob)
>   org-babel-exp-do-export(nil lob)
>   org-babel-exp-process-buffer()

Thanks for the report and reproducer.

At the very least, the failure message should be informative in this
situation (a call referencing an unknown name).  I've pushed a commit
(5450d6420) to improve the error reporting.



Re: Invalid function: org-preserve-local-variables

2021-03-21 Thread Kyle Meyer
Loris Bennett writes:

> Hi,
>
> I'm running
>
>   Org mode version 9.4.4 (9.4.4-25-g3a522a-elpaplus @ 
> /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/)
>
> and today I encountered the following error when refiling
>
>   org-refile: Invalid function: org-preserve-local-variables
>
> Despite the error, the refiling itself did however work.
>
> I am fairly sure that I have refiled without seeing this error message
> since I last updated Org, thus I am somewhat surprised by it.

org-preserve-local-variables is a macro defined in org-macs.el. That
file is loaded by org.el, which is loaded by org-refile.el.  So, I think
everything looks fine there.

My guess---especially if you're running Emacs 26 or lower, which ships
with an Org that didn't yet have org-preserve-local-variables---is that
you have a mixed installation.  list-load-path-shadows might reveal the
problem.

https://orgmode.org/worg/org-faq.html#mixed-install



Re: Using lexical-binding

2021-03-21 Thread Kyle Meyer
Greg Minshall writes:

> Kyle,
>
> thanks.  i see.  i wondered why the talk was all about agendas.
>
> since, in my (brand new, experimenting) use of
> =org-babel-map-src-blocks=, i'm calling a function, and that function is
> trying to de-reference, e.g., =beg-block=, i get an error.

Thanks for the details.

> it is (or does seem to be) the case that if the macro included all the
> valueless =defvars=, a function called from it has access to all those.
> i don't know if this would be a useful modification.

Hmm, given that the lexical-binding change to ob-core was back in Org
9.0 (November 2016), it seems like dynamic scoping wasn't really being
relied on (or, if it was, downstream code has already been adjusted).
In my view it'd be better to stick with lexical scoping for these
variables, with callers explicitly passing the subset of needed
variables to the underlying function(s).



bug#44824: [PATCH] org.el: Avoid xdg-open silent failure

2021-03-21 Thread Kyle Meyer
Maxim Nikulin writes:

> I hope, I have addressed other your comments in the updated patch.
>
> commit 5eca7764d94dd46b9f9a7792d1b786a3f03b20b6
> Author: Max Nikulin 
> Date:   Wed Feb 17 16:35:58 2021 +
>
> org.el: Avoid xdg-open silent failure

Thanks.  A note for future patches: your patch isn't in a format that's
ready to be consumed by git-am.  git-format-patch can help you here.

Applied to the Org repo (5db61eb0f), adding a TINYCHANGE cookie to the
commit message.  Please consider completing the copyright paperwork for
future patches
(see ).

If I understand correctly, this bug can be closed, but please reopen if
I'm mistaken.





Re: Using lexical-binding

2021-03-19 Thread Kyle Meyer
Greg Minshall writes:

> hi.  i just upgraded to
> : Org mode version 9.4.4 (9.4.4-27-gb712b9-elpa @ 
> /home/minshall/.emacs.d/elpa/org-20210315/)
>
> and, have also just started playing with
> (org-babel-map-inline-src-blocks), the documentation for which says
> 
> During evaluation of BODY the following local variables
> are set relative to the currently matched code block.
> ...
> 

Is there a specific error/misbehavior that you're seeing?

The patch in this thread switched only one file, lisp/org-agenda.el,
over to lexical binding.  org-babel-map-inline-src-blocks is in ob-core,
and that file has used lexical binding since 6cefae163 (ob-core: Use
lexical binding, 2016-06-20).

> but, iiuc, that relies on dynamic binding.  so, as =lexical-binding= is
> =t=, i don't have access to those appealing variables.

org-babel-map-inline-src-blocks is a macro, and these variables are
defined in its expansion.  Try:

  (pp-macroexpand-expression
   '(org-babel-map-src-blocks nil
  (message "%d %s %s" beg-block lang body)))



Re: How to jump from one spelling mistake to the next?

2021-03-19 Thread Kyle Meyer
Samuel Wales writes:

> i wonder why the generic next-error is not used.

Hmm, good question.  Ignoring any historical reasons for why flyspell
does what it does, a quick search on the Emacs lists makes me think at
least one open issue is how to prioritize/combine different next-error
sources:

 * https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00207.html
   87zi2esn7l@mail.linkov.net

 * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674#8
   87a7vkrelc@mail.linkov.net

That's getting a bit off-topic for the Org mode list though...



Re: How to jump from one spelling mistake to the next?

2021-03-19 Thread Kyle Meyer
Sharon Kimble writes:

> When I'm writing in org-mode I very often make spelling mistakes which I
> can go back to later to correct. So how can I jump from one mistake to
> the next please?

If you have Flyspell mode enabled in the buffer,
flyspell-goto-next-error (bound to `C-,' by default) will jump to the
next marked word, cycling around once you've reached the last marked
word in the buffer.

There's also `M-x ispell', which provides an interface for going through
misspelled words and presents you with suggestions.

See (info "(emacs)Spelling") for more information.



Re: [PATCH] ox-html: Add webp as an inline image format

2021-03-18 Thread Kyle Meyer
Jay Kamat writes:

> Subject: [PATCH] ox-html: Add webp as an inline image format

Thanks for the patch.  Pushed (a9f38b1c2) with a few additions (updated
the :package-version keyword, added a NEWS entry, and added a period
after the changelog entry.)



Re: [PATCH] Fix ob-smiles using old org API.

2021-03-18 Thread Kyle Meyer
Lein Matsumaru writes:

> As subject says, it does not get updated, so I did.
[...]
> Subject: [PATCH] ob-smiles.el: Update org babel API

Thanks.  Pushed (1738b455b), along with a follow-up commit that fixes
the free variable reference in molecule-jump.

Note that the plan is to move contrib/ to a separate repo [1], with the
eventual goal of each file being maintained elsewhere, in case you or
others are interested.

  [1] https://orgmode.org/list/87wnzfy60h@bzg.fr



bug#44824: [PATCH] org.el: Avoid xdg-open silent failure

2021-03-18 Thread Kyle Meyer
Maxim Nikulin writes:

> org.el: Avoid xdg-open silent failure
> 
> * lisp/org.el (org-open-file): Use 'pipe :connection-type instead of
> 'pty to prevent killing of background process on handler exit.
> 
> Problem happens only in some desktop environments where configured
> through `org-file-apps' or mailcap handlers launches actual viewer
> (as defined in .desktop files and obtained from mimeapps.list)
> in background.  E.g. xdg-open invokes "gio open" or kde-open5 for Gnome
> or KDE accordingly and these handlers launches e.g. eog or okular in
> background.  As soon as main process exits, temporary terminal session
> created by `start-process-shell-command' is terminated.  As a result
> background processes receive SIGHUP.
> 
> Previously command were executed with no buffer, so the change
> does not affect "needsterminal" and "copiousoutput" mailcap features,
> they are not supported as earlier.
> 
> If handler main process fails then show a message with exit reason.
> Output (including error messages) is ignored as before.
> Gtk application tends to report significant amount of failed asserts
> hardly informative for majority of users.

Thanks for the detailed commit message.

A few comments in addition to Eli's advice to drop the
(eq system-type 'gnu/linux) condition...

> diff --git a/lisp/org.el b/lisp/org.el
> index 7d8733448..a199a65c9 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -8645,6 +8645,15 @@ opened in Emacs."
> (when add-auto-mode
>   (mapcar (lambda (x) (cons (car x) 'emacs)) auto-mode-alist
>  
> +(defun org--error-process-sentinel (proc event)
> +  "Show a message if process failed (exited with non-zero code
> +or killed by a signal.  Pass the function as :SENTINEL argument

Please rework the first sentence so that it fits on the first line,
though I'd be in favor dropping the function and using a lambda in the
make-process call.

> +of `make-process'."
> +  (unless (string-match "finished" event)

There's no need for substring matching, right?  So it could be

  (equal event "finished\n")

Or perhaps

  (when (and (memq (process-status proc) '(exit signal))
 (/= (process-exit-status proc) 0))
...)

> +(message "Command %s: %s."
> + (mapconcat 'identity (process-command proc) " ")

s/'identity/#'identity/

> + (substring event 0 -1
> +
>  ;;;###autoload
>  (defun org-open-file (path  in-emacs line search)
>"Open the file at PATH.
> @@ -8766,7 +8775,17 @@ If the file does not exist, throw an error."
>  
>(save-window-excursion
>   (message "Running %s...done" cmd)
> - (start-process-shell-command cmd nil cmd)
> + (if (eq system-type 'gnu/linux)
> +   ;; Handlers as "gio open" and kde-open5 start viewer in background

s/as/such as/ ?

> +   ;; and exit immediately. Avoid start-process since it assumes

  ^ missing space

> +   ;; :connection-type 'pty and kills children processes with SIGHUP
> +   ;; when temporary terminal session is finished.
> +   (make-process
> + :name "org-open-file" :connection-type 'pipe :noquery 't

s/'t/t/

> + :buffer nil ; use "*Messages*" for debugging
> + :sentinel 'org--error-process-sentinel
> + :command (list shell-file-name shell-command-switch cmd))
> +   (start-process-shell-command cmd nil cmd))
>   (and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait
>   ((or (stringp cmd)
> (eq cmd 'emacs))

Thanks.





Re: [PATCH] ob-sql.el: Add support for SAP HANA

2021-03-16 Thread Kyle Meyer
Robin Campbell Joy writes:

> Subject: [PATCH] ob-sql.el: Add support for SAP HANA

Thanks for the update.  Pushed (b241c126b).

> diff --git a/testing/lisp/test-ob-sql.el b/testing/lisp/test-ob-sql.el
[...]
> +
> +(require 'org-test)
> +(require 'ob-sql)

I've dropped these two lines.

For the first one, currently only four test files load org-test
explicitly, while the majority of the tests rely on org-test being
loaded as part of the setup.

For the second, nearly all ob-LANG tests check whether the corresponding
ob- feature is available, signaling missing-test-dependency if it's not.
Which ob- libraries are loaded/tested can then controlled by the
Makefile variable BTEST_OB_LANGUAGES.  Explicitly loading the ob- file
goes against that setup, making the (featurep ...) check that follows
always return non-nil,

I'm guessing this line was adjusted from test-ob-sqlite, which appears
to be the one [*] ob-LANG test file that gets this wrong.  I've
pushed another commit to adjust it.

[*] I believe ob-emacs-lisp is an intended exception.

> +(unless (featurep 'ob-sql)
> +  (signal 'missing-test-dependency "Support for sql code blocks"))




Re: [PATCH] ob-sql.el: Add support for SAP HANA

2021-03-15 Thread Kyle Meyer
Robin Campbell Joy writes:

> Hi,
>
> could someone please let me know if something is missing/incorrect?

Thanks for the patch, and sorry for the delay.

> On Thu, 4 Feb 2021 at 08:55, Robin Campbell Joy  wrote:
>
>> * lisp/ob-sql.el (org-babel-execute:sql, org-babel-sql-dbstring-saphana):
>> Add basic support for SAP HANA to SQL blocks
>> * testing/lisp/test-ob-sql.el: Basic tests for generated db connection
>> string

Style nit: missing periods at the end of the changelog entries.

  
https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs

>> This change adds basic support for SAP HANA to SQL blocks by
>> specifying saphana as :engine.
>>
>> It also adds a new header arg `dbinstance' in order to specify the SAP
>> HANA instance to connect to.
>>
>> Signed-off-by: Robin Campbell Joy 

This trailer is fine but doesn't have any meaning in this project.

This patch is large enough that copyright should be assigned to the FSF.
Assuming you haven't already, are you willing to complete the copyright
paperwork?

  https://orgmode.org/worg/org-contribute.html#copyright-issues

>> ---
>>  lisp/ob-sql.el  |  25 ++-
>>  testing/lisp/test-ob-sql.el | 382 

Great, thanks for adding tests.

>>  2 files changed, 406 insertions(+), 1 deletion(-)
>>  create mode 100644 testing/lisp/test-ob-sql.el
>>
>> diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el

The patch doesn't apply.

  $ curl -fSs \

https://orgmode.org/list/CADzxVkEO=x6r_yai3qjkoojipvphxpcfrc2jaw7fpufs92w...@mail.gmail.com/raw
 | \
git am
  Applying: ob-sql.el: Add support for SAP HANA
  error: corrupt patch at line 40
  Patch failed at 0001 ob-sql.el: Add support for SAP HANA
  [...]

It looks like many of the lines are corrupted by additional line breaks,
so it'd take a lot of manual editing to resolve the issues on my end.

>From scanning through it, the patch looks well done.  Here are a few
quick comments.

>> index 902194ae8..5398c85aa 100644
>> --- a/lisp/ob-sql.el
>> +++ b/lisp/ob-sql.el
>> @@ -40,6 +40,7 @@
>>  ;; - dbuser
>>  ;; - dbpassword
>>  ;; - dbconnection (to reference connections in sql-connection-alist)
>> +;; - dbinstance

Hmm, so if we can't shoehorn this into an existing parameter, I guess
this should mention that dbinstance is relevant only for saphana?

>>  ;; - database
>>  ;; - colnames (default, nil, means "yes")
>>  ;; - result-params
>> @@ -58,6 +59,7 @@
>>  ;; - postgresql (postgres)
>>  ;; - oracle
>>  ;; - vertica
>> +;; - saphana
>>  ;;
>>  ;; TODO:
>>  ;;
>> @@ -85,6 +87,7 @@
>>  (dbport   . :any)
>>  (dbuser   . :any)
>>  (dbpassword   . :any)
>> +(dbinstance   . :any)
>>  (database   . :any))
>>"SQL-specific header arguments.")
>>
>> @@ -174,6 +177,18 @@ SQL Server on Windows and Linux platform."
>>(when database (format "-d %s" database
>>" "))
>>
>> +(defun org-babel-sql-dbstring-saphana (host port instance user password
>> database)
>> +  "Make SAP HANA command line args for database connection. Pass nil to
>> omit that arg."

To follow the Emacs docstring convention, "Pass" should be moved to the
second line.

>> +  (mapconcat #'identity
>> + (delq nil
>> +   (list (when (and host port) (format "-n %s:%s" host
>> port))

Please prefer `and' here and in other spots where the return value is of
interest.

  (and host port (format ...))

(Possibly breaking it up across lines if you're getting over ~80 chars.)



Re: org-export-latex-packages-alist vs org-latex-packages-alist

2021-03-15 Thread Kyle Meyer
Tyler Smith writes:

> Hello,
>
> Can someone confirm if
>
>   `org-export-latex-packages-alist` and 
>   `org-export-latex-listings-langs`
>
> are obsolete versions of
>
>   `org-latex-packages-alist` and `org-listings-langs`?
>
> I've had the former in my config for years, and today noticed that 
> they no longer appear in the org source code. I failed to find any 
> reference to this change in the documentation, so perhaps I've 
> missed something? Can I just swap out the former and replace them 
> with the latter?

org-export-latex-packages-alist was renamed to org-latex-packages-alist
in Org 8, specifically 0484c5c64 (Manage variables related to both LaTeX
export and snippets, 2013-02-02).  I believe a straight replacement is
fine.

And it looks like org-export-latex-listings-langs was the name used in
the old exporter before v8.  Simply using org-latex-listings-langs
instead should work here too, I think.



Re: [PATCH] org-compat.el (org-mode-flyspell-verify): Do not spell check code in headline

2021-03-14 Thread Kyle Meyer
Sébastien Miquel writes:

> Subject: [PATCH] org-compat.el (org-mode-flyspell-verify): Do not check code
>  in headline
>
> * lisp/org-compat.el (org-mode-flyspell-verify): Do not spell check
> code, verbatim and LaTeX fragments in headline title.

Makes sense.  Hopefully the cost of the org-element-at-point call isn't
too noticeable.

Applied to master (7c4d057cd), adding a TINYCHANGE cookie to the commit
message.  You're bumping up against the cumulative number of changes
allowed without assigning copyright, so please consider completing the
copyright paperwork (or, if you've already done so, please let me know
I'll update your status listed at
).

Thanks.



Re: org-capture gnus also extract from the cc field.

2021-03-12 Thread Kyle Meyer
Uwe Brauer writes:

> Hi
>
> This would be very useful for my workflow, actually I have 
>
> ("mu" "Stat+Num: English"
>  table-line (file+headline "/somefile.org" "Exercise Group-E")
>  "| %:fromname|%:fromaddress|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  
> %a|%:date "  :prepend t)
>
> So a %:ccname %:ccaddress would be very very useful
>
> Any idea how to achieve that?

At the minimum, it looks like you'd have to adjust two places:

  * org-gnus-store-link to extract the cc field and call
org-link-store-props with it

  * org-link-store-props to process it



Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]

2021-03-12 Thread Kyle Meyer
Ihor Radchenko writes:

> I have a https link like "https://doi.org/10.1016/0160-791x(79)90023-x".
> If I put this link into an org file (using emacs -Q or Org mode master),
> only "https://doi.org/10.1016/0160-791x(79)" part of the link is treated
> as a link. I guess, it should not happen.

This case was discussed at
.
There's mention of an improved regexp that might be worth trying.



Re: Problem with org-ref

2021-03-09 Thread Kyle Meyer
Marvin M. Doyley writes:

> Hi there,
>
> When I use crossref-add-bibtex-entry it download the BibTeX entry but cannot 
> download the associated pdf.
> I get the following error  (wrong-type-argument stringp 
> ("/Users/doyley/Dropbox/Filing_Cabinet/B/refs/pdf/“))
>
> I configured org-ref as follows
>
> (setq org-ref-bibliography-notes 
> '("/Users/doyley/Dropbox/Filing_Cabinet/B/refs/ref_notes.org") 
>   org-ref-default-bibliography 
> '("/Users/doyley/Dropbox/Filing_Cabinet/B/refs/ref.bib") 
>   org-ref-pdf-directory 
> '("/Users/doyley/Dropbox/Filing_Cabinet/B/refs/pdf/")
> org-ref-notes-citation-link '("cite")
>   )

[ Caveat: I've never used org-ref ]

org-ref's 0383cc2 (support multiple pdf directories, 2016-06-10) updated
org-ref-pdf-directory to accept a list value, so your value is valid,
but...

> Debugger entered--Lisp error: (wrong-type-argument stringp 
> ("/Users/doyley/Dropbox/Filing_Cabinet/B/refs/pdf/"))
>   file-name-as-directory(("/Users/doyley/Dropbox/Filing_Cabinet/B/refs/pdf/"))
>   doi-utils-get-bibtex-entry-pdf(nil)

... doi-utils-get-bibtex-entry-pdf wasn't updated for that (+cc the
author of that commit and John Kitchin).

It looks like org-ref-pdf-directory still supports a string, though, and
you only have one item, so you should be able to work around the issue
with

  (setq org-ref-pdf-directory 
"/Users/doyley/Dropbox/Filing_Cabinet/B/refs/pdf/")



Re: Bug: 28.0.50; `org-clocking-buffer` definition was removed, but it is still being referenced [9.4.3]

2021-03-09 Thread Kyle Meyer
Eduardo Bellani writes:

> Kyle Meyer writes:
>
>> In 16b5ee0ef, org-clocking-buffer was moved from org-clock.el to org.el,
>> and org-clock.el loads org.el.
>>
>> What's the concrete problem that you're running into?

> Backtrace:
>
> Debugger entered--Lisp error: (void-function org-clocking-buffer)
>   org-clocking-buffer()
>   org-clocking-p()
>   org-clock-in(nil)
>   funcall-interactively(org-clock-in nil)
>   call-interactively(org-clock-in nil nil)
>   command-execute(org-clock-in)

My guess is that you either have a stale org.elc file or have a mixed
installation with an old org.el shadowing the new one.  If the issue
doesn't go away after removing/regenerating the elc files,
list-load-path-shadows might reveal the problem.

https://orgmode.org/worg/org-faq.html#mixed-install



Re: Using lexical-binding

2021-03-09 Thread Kyle Meyer
Stefan Monnier writes:

> Any chance you could put this in the `Package-Requires:`?

Sure, added (5263eff5a).

> Note that all the uses I introduced of `with-suppressed-warnings` only
> wrap a very small amount of code, so you could also replace them with
> `with-no-warnings` (added back in Emacs-22).

Good point.  I've switched to using with-suppressed-warnings and applied
the patch to master (129c33ddd).

Thanks again.



Re: [PATCH] Reduce code duplication in ob-sql.el and ob-sqlite.el

2021-03-08 Thread Kyle Meyer
Nick Savage writes:

> Please see the attached updated patch with the changes requested.

Thanks.  Pushed (37749c165).

> +  (declare (obsolete "use `org-babel-sql-expand-vars' instead." "Org 9.4"))

... changing "Org 9.4" to "Org 9.5".



Re: Bug: 28.0.50; `org-clocking-buffer` definition was removed, but it is still being referenced [9.4.3]

2021-03-08 Thread Kyle Meyer
Eduardo Bellani writes:

> On 16b5ee0efb5592f78faeffa07048bfe741331a18 `org-clocking-buffer` was
> removed as a symbol. That symbol is still being referenced throughout
> the current(4d463ee4baf8a7ce8b7c633149a9452bc70ef557) `org-clock.el`
> file.

In 16b5ee0ef, org-clocking-buffer was moved from org-clock.el to org.el,
and org-clock.el loads org.el.

What's the concrete problem that you're running into?



Re: Using lexical-binding

2021-03-08 Thread Kyle Meyer
Looking at this one more time before applying, I noticed a couple of
backward compatibility issues.

Stefan Monnier writes:

> Subject: [PATCH] * lisp/org-agenda.el: Use lexical-binding
[...]
> + (pcase type
> +   ('agenda
> +(org-agenda-list current-prefix-arg))

Unfortunately Org's minimum Emacs version is still Emacs 24.3.  I'd like
to drop Emacs 24 support soon, but that hasn't been discussed or
announced.

And...

> +  (let* ((gprops (nth 1 series))
> + (gvars (mapcar #'car gprops))
> + (gvals (mapcar (lambda (binding) (eval (cadr binding) t)) gprops)))
> +(cl-progv gvars gvals (org-agenda-prepare name))
> +;; We need to reset agenda markers here, because when constructing a
> +;; block agenda, the individual blocks do not do that.
> +(org-agenda-reset-markers)
> +(with-suppressed-warnings ((lexical match))

... I believe with-suppressed-warnings isn't available until Emacs 27.1,
right?

Any objections to me squashing the below changes into your patch?

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 001ca4b1b..d08cab061 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2938,30 +2938,30 @@ (defun org-agenda ( arg keys restriction)
  (mapcar #'car lprops)
  (mapcar (lambda (binding) (eval (cadr binding) t)) lprops)
(pcase type
- ('agenda
+ (`agenda
   (org-agenda-list current-prefix-arg))
- ('agenda*
+ (`agenda*
   (org-agenda-list current-prefix-arg nil nil t))
- ('alltodo
+ (`alltodo
   (org-todo-list current-prefix-arg))
- ('search
+ (`search
   (org-search-view current-prefix-arg org-match nil))
- ('stuck
+ (`stuck
   (org-agenda-list-stuck-projects current-prefix-arg))
- ('tags
+ (`tags
   (org-tags-view current-prefix-arg org-match))
- ('tags-todo
+ (`tags-todo
   (org-tags-view '(4) org-match))
- ('todo
+ (`todo
   (org-todo-list org-match))
- ('tags-tree
+ (`tags-tree
   (org-check-for-org-mode)
   (org-match-sparse-tree current-prefix-arg org-match))
- ('todo-tree
+ (`todo-tree
   (org-check-for-org-mode)
   (org-occur (concat "^" org-outline-regexp "[ \t]*"
  (regexp-quote org-match) "\\>")))
- ('occur-tree
+ (`occur-tree
   (org-check-for-org-mode)
   (org-occur org-match))
  ((pred functionp)
@@ -3263,7 +3263,7 @@ (defun org-agenda-run-series (name series)
 ;; We need to reset agenda markers here, because when constructing a
 ;; block agenda, the individual blocks do not do that.
 (org-agenda-reset-markers)
-(with-suppressed-warnings ((lexical match))
+(org-with-suppressed-warnings ((lexical match))
   (defvar match))  ;Used via the `eval' below.
 (let* ((org-agenda-multi t)
   ;; FIXME: Redo should contain lists of (FUNS . ARGS) rather
@@ -3285,21 +3285,21 @@ (defun org-agenda-run-series (name series)
   (lvals (mapcar (lambda (binding) (eval (cadr binding) t)) 
lprops)))
   (cl-progv (append gvars lvars) (append gvals lvals)
(pcase type
- ('agenda
+ (`agenda
   (call-interactively 'org-agenda-list))
- ('agenda*
+ (`agenda*
   (funcall 'org-agenda-list nil nil t))
- ('alltodo
+ (`alltodo
   (call-interactively 'org-todo-list))
- ('search
+ (`search
   (org-search-view current-prefix-arg match nil))
- ('stuck
+ (`stuck
   (call-interactively 'org-agenda-list-stuck-projects))
- ('tags
+ (`tags
   (org-tags-view current-prefix-arg match))
- ('tags-todo
+ (`tags-todo
   (org-tags-view '(4) match))
- ('todo
+ (`todo
   (org-todo-list match))
  ((pred fboundp)
   (funcall type match))
@@ -5363,7 +5363,7 @@ (defun org-diary ( args)
 The function expects the lisp variables `entry' and `date' to be provided
 by the caller, because this is how the calendar works.  Don't use this
 function from a program - use `org-agenda-get-day-entries' instead."
-  (with-suppressed-warnings ((lexical date entry)) (defvar date) (defvar 
entry))
+  (org-with-suppressed-warnings ((lexical date entry)) (defvar date) (defvar 
entry))
   (when (> (- (float-time)
  

Re: Using lexical-binding

2021-03-06 Thread Kyle Meyer
Stefan Monnier writes:

> Should I send a rebased patch for inclusion

Yes, please.

> or do you want to give more time for people to try it out?

My guess is that we won't hear much more without bringing the changes
into master, and I'm in favor of doing so given that Marco and I have
both used it for a good amount of time without finding issues.  (Thanks,
Marco, for trying it out.)

Thank you.



Re: Using lexical-binding

2021-03-03 Thread Kyle Meyer
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?



Re: [PATCH] Reduce code duplication in ob-sql.el and ob-sqlite.el

2021-03-03 Thread Kyle Meyer
Nick Savage writes:

> Hi everyone,
>
> See the attached patch. It is a small change to reduce code duplication 
> between ob-sql.el and ob-sqlite.el by reusing org-babel-sql-expand-vars 
> as suggested by the FIXME in ob-sqlite.el.

Thank you.  Looks good, though I think it'd be nice to keep
org-babel-sqlite-expand-vars around for a bit, marked as obsolete.

> Subject: [PATCH] Reduce code duplication in ob-sqlite.el and ob-sql.el
>
> * lisp/ob-sqlite.el (org-babel-sqlite-expand-vars): removed function
> to replace with ob-sql.el version
> * lisp/ob-sql.el (org-babel-sql-expand-vars): updated to support
> expanding sqlite vars

Please capitalize the first word after ":" and end the entries with a
period.

  https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html

> -(defun org-babel-sqlite-expand-vars (body vars)
> -  "Expand the variables held in VARS in BODY."
> -  ;; FIXME: Redundancy with org-babel-sql-expand-vars!
> -  (mapc
> -   (lambda (pair)
> - (setq body
> -(replace-regexp-in-string
> - (format "$%s" (car pair))
> - (let ((val (cdr pair)))
> -  (if (listp val)
> -  (let ((data-file (org-babel-temp-file "sqlite-data-")))
> -(with-temp-file data-file
> -  (insert (orgtbl-to-csv val nil)))
> -data-file)
> -(if (stringp val) val (format "%S" val
> - body)))
> -   vars)
> -  body)
> -

How about marking this with (declare (obsolete ...)) and keeping it
around as a wrapper that calls org-babel-sql-expand-vars?  That will
give any third-party code that may have used this for whatever reason
(perhaps unlikely) a chance to update.



Re: [PATCH] Async session eval (2nd attempt)

2021-03-03 Thread Kyle Meyer
Jack Kamm writes:

> I also have an async implementation for ob-R that's ready after this is
> merged :)

It's a bit disappointing that only one babel user has tested this out
and provided feedback, but please feel free to merge this whenever you
think it's ready.

I'm very happy to leave the babel details to you, but here are minor
comments from a quick read-through looking for things that will likely
be changed/cleaned up (either in the Org repo or the Emacs repo) if left
as is.

> Subject: [PATCH] ob-comint.el, ob-python.el: Async session evaluation
[...]
> +;; Async evaluation

For a heading comment, please use at least three semicolons.

  (info "(elisp)Comment Tips")

> +
> +(defvar-local org-babel-comint-async-indicator nil
> +  "Regular expression that `org-babel-comint-async-filter' scans for.
> +It should have 2 parenthesized expressions,
> +e.g. \"org_babel_async_\\(start\\|end\\|file\\)_\\(.*\\)\". The
> +first parenthesized expression determines whether the token is
> +delimiting a result block, or whether the result is in a file. If
> +delimiting a block, the second expression gives a UUID for the
> +location to insert the result. Otherwise, the result is in a tmp
> +file, and the second expression gives the file name.")
> +
> +(defvar-local org-babel-comint-async-buffers nil
> +  "List of org-mode buffers to check for Babel async output results.")

s/org-mode/Org mode/ here and other spots, following
doc/Documentation_Standards.org and tree-wide cleanups like de24694f0
(Turn org-mode into Org or Org mode, 2016-08-23).

Also, you're missing two spaces between some sentences.

> +(defmacro org-babel-comint-async-delete-dangling-and-eval
> +(session-buffer  body)
> +  "Remove dangling text in SESSION-BUFFER and evaluate BODY.
> +This is analogous to `org-babel-comint-with-output', but meant
> +for asynchronous output, and much shorter because inserting the
> +result is delegated to `org-babel-comint-async-filter'."
> +  (declare (indent 1))
> +  `(org-babel-comint-in-buffer ,session-buffer
> + (goto-char (process-mark (get-buffer-process (current-buffer
> + (delete-region (point) (point-max))
> + ,@body))
> +(def-edebug-spec org-babel-comint-async-with-output (sexp body))

Please move this edebug spec to the `declare' form (see 7dd1cfb6c,
2021-02-12).

> diff --git a/testing/lisp/test-ob-python.el b/testing/lisp/test-ob-python.el
> index a2cc7b79c..0267678cd 100644
> --- a/testing/lisp/test-ob-python.el
> +++ b/testing/lisp/test-ob-python.el
> @@ -207,6 +207,67 @@ (ert-deftest test-ob-python/session-value-sleep ()
>  #+end_src"
>   (org-babel-execute-src-block)
>  
> +(ert-deftest test-ob-python/async-simple-session-output ()
> +  (let ((org-babel-temporary-directory "/tmp")

Prefer `temporary-file-directory' to hard coding "/tmp".

Thanks.



Re: [PATCH] Query when exiting with running clock

2021-03-03 Thread Kyle Meyer
Allen Li writes:

> Thanks for your feedback.  I have addressed your comments.  Please see
> the new patches.

Thanks.  Pushed with a few modifications and a commit on top that adds a
NEWS entry.

1:  39422ba4a ! 1:  303e7c28e org-clock: Query when exiting with running clock
@@ Commit message
 * lisp/org-clock.el (org-clock-kill-emacs-query): New function.
 (org-clock-ask-before-exiting): New user option.
 
+[km: added package-version keyword, fixed function name typo]
+
 
  ## Notes (amlog) ##
 Message-Id: 

@@ lisp/org-clock.el: (defcustom org-clock-auto-clockout-timer nil
  
 +(defcustom org-clock-ask-before-exiting t
 +  "If non-nil, ask if the user wants to clock out before exiting Emacs.
-+  This variable only has effect if set with \\[customize]."
++This variable only has effect if set with \\[customize]."
 +  :set (lambda (symbol value)
 + (if value
 + (add-hook 'kill-emacs-query-functions 
#'org-clock-kill-emacs-query)
 +   (remove-hook 'kill-emacs-query-functions 
#'org-clock-kill-emacs-query))
 + (set symbol value))
-+  :type 'boolean)
++  :type 'boolean
++  :package-version '(Org . "9.5"))
 +
  (defvar org-clock-in-prepare-hook nil
"Hook run when preparing the clock.
@@ lisp/org-clock.el: (defun org-clock-load ()
 +(defun org-clock-kill-emacs-query ()
 +  "Query user when killing Emacs.
 +This function is added to `kill-emacs-query-functions'."
-+  (let ((buf (org-clock-buffer)))
++  (let ((buf (org-clocking-buffer)))
 +(when (and buf (yes-or-no-p "Clock out and save? "))
 +  (with-current-buffer buf
 +(org-clock-out)
2:  d612adc77 = 2:  16b5ee0ef org-clock: Replace org-clocking-buffer with 
org-clock-is-active
-:  - > 3:  4d463ee4b ORG-NEWS: Add entry for 
org-clock-ask-before-exiting



Re: Org mode links: Open a PDF file at a given page and highlight a given string

2021-03-02 Thread Kyle Meyer
Rodrigo Morales writes:

[...]
> + create a Org link to specific pages of a PDF and highlight a given
>   string.
>
> #+begin_src emacs-lisp :results silent
> (setq org-file-apps
>   '(("\\.pdf::\\([0-9]+\\)::\\([^:]+\\)\\'" . "zathura -P %1 -f %2 %s")))
> #+end_src
>
> The following link must open the PDF at a given page and highlight the
> given string. However, I'm getting the following error (see the
> =#+begin_example= block below.)
>
> [[file:~/Downloads/grub.pdf::95::do]]
>
> #+begin_example
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   replace-match(nil t t "zathura -P 95 -f %2 
> /home/username/Downloads/grub")

I haven't looked at this closely or tried to trigger the error, but an
in-flight patch is touching this area
().  I've yet to
revisit it to address Maxim's helpful feedback, but I hope to soon and
will look at this error then too.

Thanks for reporting.



Re: Simple org-publish configuration example in manual does not work

2021-03-01 Thread Kyle Meyer
dalanicolai writes:

> Hello, sorry for sending this email directly, but currently sending mail
> from Emacs does not work correctly.

No worries.  There's no requirement to send it from Emacs.

[...]
> It would be great if these two small point in the manual, which is
> otherwise great, could
> get updated.
>
> 1. add the required :publishing-function keyword to the documentation (with
> the correct function value)
> 2. change the name of the default function from org-publish-org-to-html ->
> *org-html-publish-to-html*

Thanks for reporting.  Done in 8244e7ba8 and b712b9618.



Re: [tip for EXWM users] An alternative method for isolate trees

2021-03-01 Thread Kyle Meyer
Julian M. Burgos writes:

> I have not noticed that org-tree-to-indirect-buffer
> reuses the indirect buffer when you call it for a second time.
> According to the manual, "with a C-u prefix, do not remove the
> previously used indirect buffer", but that does not seem to work.
> When you do Cu-Cc-Cx-b from a buffer that already has an indirect
> buffer you get a "cannot modify an area being edited in a dedicated
> buffer".  If you try it from a different buffer, the prefix is ignored
> and the indirect buffer is assigned to the tree from the last buffer.

Hmm, could you provide a reproducer for the problem?  Here's what I
tried with the current master (afd75d05a), Emacs 27.1, and no custom
configuration.

--8<---cut here---start->8---
* a
a content
* b
b content
--8<---cut here---end--->8---

 - on "a", C-c C-x b  ;; org-tree-to-indirect-buffer
   Displays -a-1 buffer.

 - move to "b", C-u C-c C-x b
   Displays -b-1 buffer, a-1 buffer still exists.



Re: [PATCH] org-mac-link: Disable Evernote capture by default

2021-03-01 Thread Kyle Meyer
Kyle Meyer writes:

> Thanks for the patch.  Ideally someone that uses macOS would provide a
> review.  Based on the history of the file, I've cc'd two people that may
> be willing/able to do so.

Applied (afd75d05a).  Thanks again.



Re: [PATCH] ~org-font-lock-add-priority-faces~: ensure priority cookies are in a headline

2021-03-01 Thread Kyle Meyer
Sébastien Miquel writes:

> Priority cookies are always in a headline.
>
> The attached patch speeds up fontification of a 1k lines buffer by 0.1
> second.

Thank.  Pushed (a03b4656c), adding this...

> Note that the variable org-priority-regexp can't be modified since
> it is used in the agenda and in org-get-priority.

... bit to the commit message, and also adding a trailer to credit Ihor
for the initial suggestion.



Re: [PATCH] org-mac-link: Disable Evernote capture by default

2021-02-27 Thread Kyle Meyer
Aaron Jensen writes:

> On Wed, Feb 17, 2021 at 9:55 AM Aaron Jensen  wrote:
>>
>> The two `shell-command-to-string` invocations during eval are
>> extremely slow. Users of Evernote should `org-mac-grab-Evernote-app-p`
>> and `org-mac-evernote-path` explicitly.
>
> Hi all,
>
> Any chance of getting this merged in? It's a pretty nasty one for mac users.

Thanks for the patch.  Ideally someone that uses macOS would provide a
review.  Based on the history of the file, I've cc'd two people that may
be willing/able to do so.

Note that the plan is to move contrib/ to a separate repo [1], with the
eventual goal of each file being maintained elsewhere, in case you or
others are interested.

  [1] https://orgmode.org/list/87wnzfy60h@bzg.fr



Re: [PATCH] Add tests for org agenda bulk functions

2021-02-27 Thread Kyle Meyer
Thanks, pushed (63c5cacb0).



Re: org-read-date: selecting date with mouse-2 in calendar

2021-02-25 Thread Kyle Meyer
Michael Heerdegen writes:

> Hello again,
>
>> selecting a date from within `org-read-date' from the calendar works
>> with mouse-1, but not with mouse-2 (with latest Emacs master and my
>> settings loaded at least).
>>
>> The code seems to intend that it also works with mouse-2, but it fails.
>>
>> Why it doesn't work?  Oh, that's because calendar already binds
>> down-mouse-2 to pop-up a menu (see definition of `calendar-mode-map').
>> So when we would add the following line to `org-read-date' (it's obvious
>> to where and I'm too lazy to create a patch now):
>>
>> +  (org-defkey map [down-mouse-2] nil)
>
> No comments on this (hope it wasn't too confused...)?

I don't know anything about these mouse things and have to review the
manual whenever they come up.  Please provide a patch with a proper
commit message, and I'll review it this weekend if nobody else gets to
it sooner.

> Should I just commit the fix to the Emacs master branch?

No, I'd appreciate if you did not.



Re: Turning off all indentation in 9.4.4

2021-02-25 Thread Kyle Meyer
TRS-80 writes:

> On 2021-02-24 15:58, TRS-80 wrote:
>> On 2021-02-16 23:30, Kyle Meyer wrote:
[...]
>>> So, if I'm reading your preferences correctly, it sounds like you want
>>> just the first suggestion in the above snippet, leaving
>>> org-adapt-indentation at its default value:
>>> 
>>>   (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
>> 
>> OK, I just did eval-expression (M-:) with (electric-indent-local-mode
>> -1) in an Orgmode buffer.  After very brief testing, it does indeed
>> seem to return the desired behavior.  So thanks a lot for that tip!
[...]
> OK, so after that yesterday, I went ahead and added
> (electric-indent-local-mode -1) to my org-mode hook.  Then today upon
> re-starting Emacs, I am back to not working.
>
> By not working I mean:  Pressing enter goes to column 0 as it should,
> however then pressing  does nothing.  Where previously it would
> jump to same level as indented above.
>
> My settings are:
>
> - electric-indent-local-mode nil (local in each Orgmode buffer, set via
> hook)
>
> - org-adapt-indentation 'headline-data

I'm just repeating my suggestion from above, but perhaps you want to
leave org-adapt-indentation at its default value of t?



Re: Please help by becoming a maintainer for an Org Babel file

2021-02-25 Thread Kyle Meyer
Andy Klock writes:

> Hi all, am I too late?
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, October 26, 2020 4:07 AM, Bastien  wrote:
>
>> If you feel like proposing yourself for maintaining an Org Babel
>> language, that would be super helpful.
>
> Can I throw my hat in to help maintain ob-sql.el ?

While I of course can't speak for Bastien (and am not sure what this
thread involved behind the scenes here), it doesn't appear that anyone
volunteered for ob-sql.  And regardless any help would be greatly
appreciated.

Fwiw here are a couple of the recent-ish ob-sql-related messages that
haven't seen any attention:

https://orgmode.org/list/CADzxVkEO=x6r_yai3qjkoojipvphxpcfrc2jaw7fpufs92w...@mail.gmail.com
https://orgmode.org/list/97dfc87b-9748-a5e2-cf4d-1aa784516...@rwth-aachen.de



Re: Using lexical-binding

2021-02-24 Thread Kyle Meyer
Stefan Monnier writes:

>> It looks like add-to-diary-list became an obsolete alias for
>> diary-add-to-list in Emacs 23.1 and was removed in Emacs 25.1,
>> specifically 3f65970414 (Remove calendar code obsolete since at least
>> version 23.1, 2014-10-05).
>
> Ah, thanks for tracking it down, so I guess we can drop this altogether.
> And we can also drop the `condition-case` in `org-diary-default-entry`
> because that change in calling convention is even older than the change
> of name from `add-to-diary-list` to `diary-add-to-list`.

Yes, sounds good.  Done in Org's 0b117f72a.



Re: Using lexical-binding

2021-02-24 Thread Kyle Meyer
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'll also push the current changes to scratch/sm/agenda-lexical with the
hope that others will test and report back.



Re: Bug: org-clone-subtree-with-time-shift invalid interval when using hours [9.3 (release_9.3 @ /usr/local/share/emacs/27.1/lisp/org/)]

2021-02-24 Thread Kyle Meyer
Kyle Meyer writes:

> I'm guessing h was left off for this command because it didn't seem too
> useful.  But something like below should work (untested), and I don't
> see any particular reason to not support h.
>
> diff --git a/lisp/org.el b/lisp/org.el

Added tests and pushed (15c738545).



Re: Bug: org-clone-subtree-with-time-shift invalid interval when using hours [9.3 (release_9.3 @ /usr/local/share/emacs/27.1/lisp/org/)]

2021-02-23 Thread Kyle Meyer
Felipe Barros writes:

> Running org-clone-subtree-with-time-shift and entering an hourly
> interval returns an error that the shift specification is invalid.
>
> For example, entering +8h returns:
>
> user-error: Invalid shift specification +8h
[...]
> And the Info page for Repeated Tasks states that:
>
>> You can use yearly, monthly, weekly, daily and hourly repeat cookies
>> by using the ‘y’, ‘w’, ‘m’, ‘d’ and ‘h’ letters.
>
> So, as I couldn’t find a reference to this limitation anywhere, I
> believe this is a valid bug.

I'm guessing h was left off for this command because it didn't seem too
useful.  But something like below should work (untested), and I don't
see any particular reason to not support h.

diff --git a/lisp/org.el b/lisp/org.el
index 7d8733448..00596564f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7906,7 +7906,7 @@ (defun org-clone-subtree-with-time-shift (n  
shift)
"")))   ;No time shift
 (doshift
  (and (org-string-nw-p shift)
-  (or (string-match "\\`[ \t]*\\([+-]?[0-9]+\\)\\([dwmy]\\)[ 
\t]*\\'"
+  (or (string-match "\\`[ \t]*\\([+-]?[0-9]+\\)\\([hdwmy]\\)[ 
\t]*\\'"
 shift)
   (user-error "Invalid shift specification %s" shift)
 (goto-char end-of-tree)
@@ -7916,6 +7916,7 @@ (defun org-clone-subtree-with-time-shift (n  
shift)
   (shift-n (and doshift (string-to-number (match-string 1 shift
   (shift-what (pcase (and doshift (match-string 2 shift))
 (`nil nil)
+("h" 'hour)
 ("d" 'day)
 ("w" (setq shift-n (* 7 shift-n)) 'day)
 ("m" 'month)



Re: Using lexical-binding

2021-02-23 Thread Kyle Meyer
Kyle Meyer writes:

> Stefan Monnier writes:
[...]
>   ;; (org-agenda-list); fails: void-variable date
>
> There are also some `make test' failures:
>
>   7 unexpected results:
>  FAILED  test-org-agenda/diary-inclusion
>  FAILED  test-org-agenda/empty
>  FAILED  test-org-agenda/one-line
>  FAILED  test-org-agenda/scheduled-non-todo
>  FAILED  test-org-agenda/set-priority
>  FAILED  test-org-agenda/sticky-agenda-name
>  FAILED  test-org-agenda/sticky-agenda-name-after-reload
>
>> or "pretends everything is fine but doesn't do the right thing any
>> more", or (even better) actual feedback about the code itself and the
>> approach(es) I chose to use.
>
> While I'm not sure I can provide any useful feedback about approaches,
> I'll see if I can tweak your patch to resolve the org-agenda-list
> failure or any of the above test failures.

With the changes below on top of your patch, the simple org-agenda-list
call from above works and the test failures are gone.

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 16ec70c77..81409d6ac 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -5448,27 +5448,29 @@ (defun org-agenda-get-day-entries (file date  args)
  (setf args (cons :deadline* (delq :deadline* args)
;; Collect list of headlines.  Return them flattened.
(let ((case-fold-search nil) results deadlines)
- (dolist (arg args (apply #'nconc (nreverse results)))
-   (pcase arg
- ((and :todo (guard (org-agenda-today-p date)))
-  (push (org-agenda-get-todos) results))
- (:timestamp
-  (push (org-agenda-get-blocks) results)
-  (push (org-agenda-get-timestamps deadlines) results))
- (:sexp
-  (push (org-agenda-get-sexps) results))
- (:scheduled
-  (push (org-agenda-get-scheduled deadlines) results))
- (:scheduled*
-  (push (org-agenda-get-scheduled deadlines t) results))
- (:closed
-  (push (org-agenda-get-progress) results))
- (:deadline
-  (setf deadlines (org-agenda-get-deadlines))
-  (push deadlines results))
- (:deadline*
-  (setf deadlines (org-agenda-get-deadlines t))
-  (push deadlines results)))
+  (org-dlet
+  ((date date))
+   (dolist (arg args (apply #'nconc (nreverse results)))
+ (pcase arg
+   ((and :todo (guard (org-agenda-today-p date)))
+(push (org-agenda-get-todos) results))
+   (:timestamp
+(push (org-agenda-get-blocks) results)
+(push (org-agenda-get-timestamps deadlines) results))
+   (:sexp
+(push (org-agenda-get-sexps) results))
+   (:scheduled
+(push (org-agenda-get-scheduled deadlines) results))
+   (:scheduled*
+(push (org-agenda-get-scheduled deadlines t) results))
+   (:closed
+(push (org-agenda-get-progress) results))
+   (:deadline
+(setf deadlines (org-agenda-get-deadlines))
+(push deadlines results))
+   (:deadline*
+(setf deadlines (org-agenda-get-deadlines t))
+(push deadlines results
 
 (defsubst org-em (x y list)
   "Is X or Y a member of LIST?"
@@ -6710,6 +6712,7 @@ (defun org-agenda-format-item (extra txt  level 
category tags dotime
  (get-text-property 1 'effort txt)))
 (tag (if tags (nth (1- (length tags)) tags) ""))
 (time-grid-trailing-characters (nth 2 org-agenda-time-grid))
+(extra (or (and (not habitp) extra) ""))
 time
 (ts (when dotime (concat
   (if (stringp dotime) dotime "")
@@ -6793,7 +6796,6 @@ (defun org-agenda-format-item (extra txt  level 
category tags dotime
   (concat time-grid-trailing-characters " ")
 time-grid-trailing-characters)))
 (t ""))
- extra (or (and (not habitp) extra) "")
  category (if (symbolp category) (symbol-name category) category)
  level (or level ""))
(if (string-match org-link-bracket-re category)



Re: Using lexical-binding

2021-02-23 Thread Kyle Meyer
Stefan Monnier writes:

> As part of the on-going work to use lexical-binding in all the files
> bundled with Emacs, I took a stab at converting org-agenda.el to
> lexical-binding.

Thank you.

> [...]
> Anyway, here's my first cut (the patch is made against the head of
> Org's `master` rather than Emacs's `master`, since I suspect that could
> make things easier for you).  The commit message is basically empty
> because it's not intended to be installed yet.  I'm instead hoping for
> some feedback, such as "tried it, works" or "burps all over the place",

With a quick test of a few main commands, burps in one of four.
Contents /tmp/scratch.org:

--8<---cut here---start->8---
* TODO a  :t:
SCHEDULED: <2021-02-23 Tue>
foo
* DONE b
* TODO c
DEADLINE: <2021-02-23 Tue>
--8<---cut here---end--->8---

Running with emacs 27.1 and -Q:

  (require 'org-agenda)
  (setq org-agenda-files '("/tmp/scratch.org"))
  (global-set-key (kbd "C-c a") #'org-agenda)

  ;; Commands:

  ;; (org-todo-list)  ; works
  ;; (org-search-view nil "foo")  ; works
  ;; (org-tags-view nil "+t") ; works
  ;; (org-agenda-list); fails: void-variable date

There are also some `make test' failures:

  7 unexpected results:
 FAILED  test-org-agenda/diary-inclusion
 FAILED  test-org-agenda/empty
 FAILED  test-org-agenda/one-line
 FAILED  test-org-agenda/scheduled-non-todo
 FAILED  test-org-agenda/set-priority
 FAILED  test-org-agenda/sticky-agenda-name
 FAILED  test-org-agenda/sticky-agenda-name-after-reload

> or "pretends everything is fine but doesn't do the right thing any
> more", or (even better) actual feedback about the code itself and the
> approach(es) I chose to use.

While I'm not sure I can provide any useful feedback about approaches,
I'll see if I can tweak your patch to resolve the org-agenda-list
failure or any of the above test failures.

> - I believe I have quashed all the compiler warnings (some had nothing
>   to do with lexical scoping),

Hmm, I wonder why I'm not seeing the ones unrelated to the lexical
scoping change.  `make compile' and `make single' are quiet for me on
Org's current master (d21d200bc) with Emacs 27.  If I use an Emacs built
from a recent Emacs commit (6172454ff3), I see a couple of "docstring
wider than 80 characters" warnings (will fix), but nothing in
org-agenda.el.

>   except for a reference to the function `add-to-diary-list` which I
>   can't find anywhere (is it some old function that has disappeared,
>   maybe?).

It looks like add-to-diary-list became an obsolete alias for
diary-add-to-list in Emacs 23.1 and was removed in Emacs 25.1,
specifically 3f65970414 (Remove calendar code obsolete since at least
version 23.1, 2014-10-05).



Re: Org-ref-helm-insert-cite-link

2021-02-23 Thread Kyle Meyer
Marvin M. Doyley writes:

> Hi there,
>
> For some reason org-ref-helm-insert-cite-link is not working anymore
> for me. When I try to execute it, I get the following error
> helm-bibtex-candidates-formatter: Symbol’s function definition is
> void: bibtex-completion-candidates-formatter

I don't use org-ref or helm-bibtex, but, based on poking around in their
repos, helm-bibtex removed bibtex-completion-candidates-formatter way
back in 390e9c3 (move helm-specific code to helm-bibtex.el, 2016-09-27),
which in turn led to 400c4f4 (use helm-bibtex-candidates-formatter,
2016-10-01) on org-ref's side.  So...

> Does anybody know how to fix this?

... while it's not really a satisfying answer, I suspect your issue will
be fixed by uninstalling both packages, including the *.elc files, and
reinstalling.



Re: 'false' list item

2021-02-21 Thread Kyle Meyer
Juan Manuel Macías writes:

> Kyle Meyer  writes:
>
>> It seems that your approach would do a good job of helping you catch
>> cases that you don't want to be treated as lists.  I'm not aware of any
>> related functionality in Org, so I don't think you're missing something
>> there.
>>
>> Once you know that there is a particular spot that you want to prevent
>> from being interpreted as a list, you could add a zero-width space in
>> front of it:
>>
>> (info "(org)Escape Character")
>>
>> I'm not sure if that's the sort of solution you're asking for, though.
>
> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
> avoid false positives. Anyway, like Tim Cross says, that situation
> maybe should be considered as a bug. I think the ideal behavior would
> be for Org to consider a list only when there is a blank line above.

You can find some previous discussion of this longstanding and known
behavior at <https://orgmode.org/list/874ndj13u5@gmail.com/T/#u>.



Re: 'false' list item

2021-02-21 Thread Kyle Meyer
Diego Zamboni writes:

> Juan Manuel,
>
> YMMV depending on your needs and habits, but another workaround for this
> problem would be to use visual-line-mode instead of filling paragraphs.

Note that filling paragraphs in Org should already guard against
inadvertently creating a list item.  (Some related discussion is at
.)



Re: 'false' list item

2021-02-20 Thread Kyle Meyer
Juan Manuel Macías writes:

> If a line in a paragraph starts with a digit (or letter) + period +
> space, Org misinterprets that as a list item. I almost always notice
> this only when I export my document, which is a nuisance.
>
> I wonder if there is any standard solution to that, or if I'm missing
> something... All that occurred to me is this "preventive" solution,
> using `highlight-regexp':

It seems that your approach would do a good job of helping you catch
cases that you don't want to be treated as lists.  I'm not aware of any
related functionality in Org, so I don't think you're missing something
there.

Once you know that there is a particular spot that you want to prevent
from being interpreted as a list, you could add a zero-width space in
front of it:

(info "(org)Escape Character")

I'm not sure if that's the sort of solution you're asking for, though.



Re: org-agenda-list should respect org-agenda-max-entries

2021-02-20 Thread Kyle Meyer
Ag Ibragimov writes:

> While going through the source code, I've noticed that org-agenda-list
> scans all the files in org-agenda-files and processes all Org items
> those files contain.
>
> However, it seems when org-agenda-max-entries or org-agenda-max-todos
> are not nil, it still processes every entry, and only after building
> the agenda it reduces the number of items in the list. It's okay, but
> if you have lots of files and tons of entries, it seems to be waste of
> time and resources.

Hmm, it seems that org-agenda-finalize-entries sorts all the entries
before looking at org-agenda-max-entries and org-agenda-max-todos (which
makes sense), so wouldn't it generally need the entire set?



Re: org-agenda for a day different than today

2021-02-20 Thread Kyle Meyer
Alan Schmitt writes:

> On 2021-02-18 00:32, Kyle Meyer  writes:
[...]
>> Yeah, I too think it's safe.  If you have the time, I'd appreciate if
>> you could skim through the above threads and see if there are any
>> minimal examples or test cases.  If so, it be good to verify that they
>> still work with the patch.
>
> I tested the first thread (where two agendas are displayed) and it still
> works.
>
> The second thread was about the beginning of the week wrongly set in a
> custom file.

Okay, thanks for checking.  Added a basic test and applied (3a522ad53).



Re: org-agenda for a day different than today

2021-02-17 Thread Kyle Meyer
Alan Schmitt writes:

> On 2021-02-16 23:01, Kyle Meyer  writes:
>
[...]
>> Here are two threads from around that time that may be related, though I
>> haven't reviewed either of them:
>>
>>  https://orgmode.org/list/blu0-smtp912fc379760ee431d3d68ebb...@phx.gbl/T/#u
>>  https://orgmode.org/list/blu0-smtp950e9387b34fa390c4fd9cbb...@phx.gbl/T/#u
>>
>> Moving org-read-date back to the interactive form would allow lisp
>> callers to pass in the date, though perhaps it'd bring back some
>> misbehavior discussed in the above threads.
>
> I’ve tried this change here and it works great, thanks a lot.

Thanks for testing.

> Looking at the code, I don’t see how it could cause trouble elsewhere
> (but understanding agenda code is always tricky…)

Yeah, I too think it's safe.  If you have the time, I'd appreciate if
you could skim through the above threads and see if there are any
minimal examples or test cases.  If so, it be good to verify that they
still work with the patch.

> Should I file a bug regarding this?

Just this thread is fine.  I should find time to put together a proper
patch in the next couple of days.



Re: Assistance Writing Test for Org Agenda Custom Bulk Function

2021-02-17 Thread Kyle Meyer
Kevin Foley writes:

> I'm trying to mock the argument collecting function and the custom bulk
> function and then test that the arguments returned from the former are
> passed to the latter.  I'd also like to test the argument function is
> only called once while the bulk function is called multiple times.
>
> Here is an example of what I'm trying to do:
>
> (org-test-with-temp-text-in-file
> "* TODO a\n*TODO b"

Unrelated note: there's a missing a space between the second "*" and
"TODO".

[...]
> (let ((f-called-cnt 0)
>   (arg-f-call-cnt 0)
>   (f-called-args nil))
>   (cl-letf (((symbol-function 'read-char-exclusive)
>  (lambda () ?P))
> (org-agenda-bulk-custom-functions
>  '((?P (lambda ( args)
>  (message "test" args)
>  (setq f-called-cnt (1+ f-called-cnt)
>f-called-args args))
>(lambda ()
>  (setq arg-f-call-cnt (1+ arg-f-call-cnt))
>  '(1 2 3))
> (org-agenda-bulk-action)
> (org-test-agenda--kill-all-agendas)
>
> (should (= f-called-cnt 2))
> (should (= arg-f-call-cnt 1))
> (should (equal f-called-args '(1 2 3)))
>
> However, this fails with the error void-variable unless I first define
> the variables for storing the call counts/arguments.  I understand that
> defvar makes the variables dynamically bound, however I'm struggling to
> understand why that's needed here.  I've read the manual entries on
> variable binding but I seem to be missing something.
>
> Can someone help me understand what's going on here?

Perhaps you're not capturing the environment due to your quoting:

  ;; -*- lexical-binding: t; -*-

  (let ((x 0))
'(t (lambda () x)))  ;; => (y (lambda nil x))
  
  (let ((x 0))
(list t (lambda () x)))  ;; => (t (closure ((x . 0) t) nil x))

So try something like

  (org-agenda-bulk-custom-functions
   `((?P ,(lambda ( args)
(message "test" args)
(setq f-called-cnt (1+ f-called-cnt)
  f-called-args args))
 ,(lambda ()
(setq arg-f-call-cnt (1+ arg-f-call-cnt))
'(1 2 3)

or

  (org-agenda-bulk-custom-functions
   (list
(list ?P
  (lambda ( args)
(message "test" args)
(setq f-called-cnt (1+ f-called-cnt)
  f-called-args args))
  (lambda ()
(setq arg-f-call-cnt (1+ arg-f-call-cnt))
'(1 2 3)



Re: A small bugfix in org-clock-in

2021-02-16 Thread Kyle Meyer
Jean-Marie Gaillourdet writes:
> I've experienced occasionally errors while executing org-clock-in from
> the agenda. The errors seems to be that indent-line-to is called with
> a negative argument. Moving from the agenda to the todo headline in
> the underlying org file and repeating org-clock-in and org-clock-out
> usually lead to a state in which I could successfully run
> org-clock-in.
>
> The following patch fixes the issue for me and I believe it does no
> harm. I've used it daily for two month. I'd appreciate if you could
> add it to org-mode.

I agree the change is safe, though I couldn't figure out how to get into
a state where it'd be needed.  Anyway, pushed (ee4ffa567), adding
TINYCHANGE to the commit message.

Thanks.



  1   2   3   4   5   6   7   8   9   10   >