Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

2022-04-04 Thread Kyle Meyer
Max Nikulin writes:

> Confirmed
>
> Emacs copy of Org changed the way of calling `encode-time' as a result 
> interpretation of last nils returned by `org-parse-string' altered from 
> ignored to "no DST".
>
> Kyle, be aware of the conflict with `org-time-string-to-time' when you 
> will port emacs commit dd0727e1ec1f535b9b06be88173b4d3ccd55abcb
> Paul Eggert  Thu Dec 16 09:40:21 2021 -0800
> encode-time simplifications

Thank you, Max, for looping me into the discussion (and thanks, Ignacio,
for the initial report and debugging).

> New calling convention for `encode-time' exists since emacs-27.1, so it 
> is incompatible with yet supported emacs-26. [...]

>> So I guess this is an Emacs 29 bug? I didn't know the two repositories
>> could diverge like that. Should I report it to Emacs 29 maintainers?
>> Or can org-mode maintainers fix it in the Emacs repository?
>
> The problem is a consequence of grep-refactoring of Emacs code, but 
> likely it should be fixed at the Org side.

The long tail of 9e1b9fe62 (Port more time-related changes, 2019-08-18)

My suggestion:

  1. Send a report to bug-gnu-em...@gnu.org describing the issue.  Ask
 that Paul revert those changes.

 I can do this at some point this week.

  2. Audit and update the call sites on our side, along with some
 compatibility layer.

The first isn't necessary, but it avoids the problem living in the Emacs
master branch until the updated Org code base (main branch) is synced
with it (which hasn't started yet).



Re: bug-tracker: How to response/subscribe to a bug-thread

2022-03-09 Thread Kyle Meyer
c.bu...@posteo.jp writes:

> Side question: I can I monitor that thread/bug without being subscribed 
> to the list? The "dashboard" seems not to have any subscribe, monitor or 
> feed mechanism. The "Atom" feed (https://list.orgmode.org/new.atom) is 
> only for complete list not for one thread.

You can get an atom feed for a single thread using the /t.atom endpoint
(documented in ).

Example:

  https://list.orgmode.org/orgmode/12368452.sVpYeFqCzH@pluto/t.atom



Re: org-refile, org-capture byte-compiling failure with recent emacs-git

2022-03-02 Thread Kyle Meyer
Kyle Meyer writes:

> Kyle Meyer writes:
>
>> However, it seems unintended that with-demoted-errors would actually
>> error here now rather than give a warning; again, will need to take a
>> closer look.
>
> The patch at <https://debbugs.gnu.org/54225> demotes the error to the
> intended warning.

And Emacs's d52c929e3 has been ported to Org's bugfix branch to avoid
these failures regardless of whether the patch there is applied.



Re: org-refile, org-capture byte-compiling failure with recent emacs-git

2022-03-02 Thread Kyle Meyer
Kyle Meyer writes:

> However, it seems unintended that with-demoted-errors would actually
> error here now rather than give a warning; again, will need to take a
> closer look.

The patch at <https://debbugs.gnu.org/54225> demotes the error to the
intended warning.



Re: org-refile, org-capture byte-compiling failure with recent emacs-git

2022-03-02 Thread Kyle Meyer
Vladimir Lomov writes:

> Hello,
>
> org-refile and org-capture failed to byte-compile by emacs from git (commit:
> 8c8093aa6f20a7a4f3799cbdb9270cac013ef71d) with following messages:
>
> ...
>
> Compiling 
> /home/vladimir/pkgs/emacs-org-mode/src/emacs-org-mode/lisp/org-capture.el...
>
> In toplevel form:
> org-capture.el:1455:12: Error: Wrong number of arguments: (1 . 2), 4
>
> ...
>
> Compiling 
> /home/vladimir/pkgs/emacs-org-mode/src/emacs-org-mode/lisp/org-refile.el...
>
> In toplevel form:
> org-refile.el:566:17: Error: Wrong number of arguments: (1 . 2), 4

Thanks for reporting.

I'll need to look more closely, but this is very likely triggered by
d52c929e31f ((with-demoted-errors): Warn on missing `format` arg,
2022-02-04) on Emacs's side.  That commit is slated to be ported to the
Org repo but has been held for the time being with the rest of the
Org-touching commits that are in Emacs's master branch but not the
emacs-28 branch.

In d52c929e31f, the with-demoted-errors calls in org-refile and
org-capture were changed to use the format argument, which has been
available since Emacs 24.4.  So, the likely fix will just be porting
that commit.  However, it seems unintended that with-demoted-errors
would actually error here now rather than give a warning; again, will
need to take a closer look.



bug#49967: 27.2; org-copy-visible copies invisible text when there is a link

2022-02-27 Thread Kyle Meyer
close 49967 28.1
quit

Максим Бабушкин writes:

> The function org-copy-visible should copy visible text only, but it
> copies invisible text when there is a link in a header. For example, let
> an org buffer contains:
> [...]

Thanks for the detailed report, and sorry for the delayed response.
This should be fixed by f2833ff25 on Org's bugfix branch.

Note that Org's mailing list is the main place for development and
discussion of Org mode; you're more likely to get feedback by sending
bug reports to .





Re: How to enforce sub-scripts with {} only for HTML export?

2022-02-20 Thread Kyle Meyer
ed...@openmail.cc writes:

> What am I doing wrong? Thanks!
>
> * Emacs and Org configuration
>
> I am using this with ~emacs -q~:
>
> #+begin_src emacs-lisp
>  (setq
> ;; Use {} for super and subscripts
> org-export-with-sub-superscripts "{}")
> #+end_src

{} should be a symbol.  Try

  (setq org-export-with-sub-superscripts '{})



Re: ox-taskjuggler missing

2022-02-19 Thread Kyle Meyer
Greg Sullivan writes:

> Trying to export to taskjuggler (tj3) to get a gantt chart as in this
> description
> .
> But I can't find the taskjuggler exporter.
>
> emacs-version
> => GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
> Version 10.14.6 (Build 18G95)) of 2021-11-18
>
> org-version
> => Org mode version 9.4.4 (release_9.4.4 @
> /Applications/Emacs.app/Contents/Resources/lisp/org/)

Hmm, based on the version and location, that's presumably the builtin
Org that shipped with Emacs 27.2.  ox-taskjuggler.el has never shipped
with Emacs, so you must have been pulling it in from somewhere else.

Anyway, ox-taskjuggler.el along with the rest of contrib/ was removed
from the main Org repo in 0555665bb (Remove the contrib/ directory,
2021-05-03), part of the 9.5 release.

It's hosted at  for the time being
and is available from .



org-persist uses Emacs 28+ buffer-local-boundp

2022-02-13 Thread Kyle Meyer
Hi Ihor,

27215ac5b (org-persist: Handle undefined variables in elisp containers,
2022-02-13) added a call to buffer-local-boundp, which was introduced in
(what will be) Emacs 28.1.

Could you update org-persist-write:elisp to be compatible with older
Emacs versions (e.g., by inlining the short definition and adding a
comment about why buffer-local-boundp isn't used)?

Thanks.



bug#53393: 29.0.50; org mode timestamp C-c C-c not updating day of week

2022-01-20 Thread Kyle Meyer
[ I've reassigned this bug report so that new messages will be directed
  to the Org mailing list, where it's more likely to get a reply.  In
  the future, please consider using org-submit-bug-report or sending a
  message to emacs-orgmode@gnu.org directly. ]

Bruce E. Robertson writes:

> emacs -Q test.org
> cursor to "CLOCK:" line, C-c C-c
> total time updates but day of week does not change
> contents of test.org
> --
> * heading
> :LOGBOOK:
> CLOCK: [2022-01-17 Tue 10:29]--[2022-01-19 Tue 10:29] => 48:00
> :END:
> --
> typing C-c C-c does update total log time for line and recently did
> update the day of the week but no long does

I'm having trouble finding an Org version where it will update a
timestamp _within_ a clock line.  I tried it out with v9.1 and the day
of the week still isn't updated.  Outside of that context it will, as
org-ctrl-c-ctrl-c-hook gets through to its timestamp condition rather
than taking the clock branch.

If you can provide more details about a version where it did work,
showing it's a regression, I think you'll have a higher chance of
getting this fixed.

Anyway, at least for now, perhaps you could try something like this to
get the behavior you want:

  (defun my/update-clock-and-days ()
(when (eq (org-element-type (org-element-context)) 'clock)
  (let ((re (org-re-timestamp 'inactive)))
(save-excursion
  (goto-char (line-beginning-position))
  (while (re-search-forward re (line-end-position) t)
(backward-char)
(org-timestamp-change 0 'day))
  
  (add-hook 'org-ctrl-c-ctrl-c-hook #'my/update-clock-and-days)

With that, hitting `C-c C-c` on the clock line at

--8<---cut here---start->8---
* heading
:LOGBOOK:
CLOCK: [2022-01-17 Thu 10:29]--[2022-01-19 Sun 10:29] => 40:00
:END:
--8<---cut here---end--->8---

produces

--8<---cut here---start->8---
* heading
:LOGBOOK:
CLOCK: [2022-01-17 Mon 10:29]--[2022-01-19 Wed 10:29] => 48:00
:END:
--8<---cut here---end--->8---





Re: org-store-link does not work in gnus article mode (messages)

2022-01-02 Thread Kyle Meyer
Uwe Brauer writes:

> Hi  
>
> I thought this worked a while ago, but in a gnus article buffer I tried to 
> use org-store-link and received
>
> (Running Emacs Master and org-mode master (some weeks old))
>
> Debugger entered--Lisp error: (void-function org-fixup-message-id-for-http)
>   
> org-fixup-message-id-for-http("8ad92378cff625ebc8020dc45afdaadef484a3a3.ca...@web.de")

org-fixup-message-id-for-http was removed from Org before the 9.3
release (more specifically a486d9c, 2019-03-10) so your assumption that
a recent Org is at the front of your load-path is invalid.



Re: Export org to just body HTML

2021-12-28 Thread Kyle Meyer
Thomas Ingram writes:

> Hello,
>
> I was wondering if there is an easy to export an org file to HTML that
> is just the body of the HTML document.  Or to put it differently, just
> the HTML formatting that is actually displayed on the page and no extra
> metadata (no DOCTYPE, html, head tags etc).
>
> I often need this for inserting HTML into existing documents or for text
> boxes that support HTML formatting.

Have you tried selecting "Body only" when exporting to an HTML buffer?
With the default bindings, that'd be 'C-c C-e C-b h H'.



bug#52778: 29.0.50; refill-mode issues in org-mode

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

> Eli Zaretskii  writes:
>
>>> You are right. I do not actively watch Emacs bug tracker and I had no
>>> information about Rudolf's previous reports today.
>>
>> Did you look at them now?  I meant bugs 52771 and 52772.
>
> Yes. One is fixed already.

Thanks for fixing 52772.  I've marked it as done.  (One way to do that
is appending -done to the bug number in the debbugs address:
<52772-d...@debbugs.gnu.org>.)

> The other one should probably be forwarded to
> Org ML. However, I am not sure what is the right way to redirect
> messages from Emacs bug tracker to Org ML. Usually, Kyle takes care
> about this part.

Before replying to a message, you can reassign it the "org-mode" package
by sending a message to cont...@debbugs.gnu.org.  Here's an example:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38592;msg=10

However, looking at , it's already been
assigned to the org-mode package, so the reply I've sent should go to
Org's mailing list.






bug#52771: 29.0.50; org-fill-paragraph does not work for several plain lists

2021-12-26 Thread Kyle Meyer
Rudolf Adamkovič writes:

> Reproduction steps:
>
> 1. start "emacs -Q"
> 2. type "C-x C-f" and "test.org" and RET
> 3. type the following:
>
> - one
>  two
>
> - three
>  four
>
> 4. mark all with "C-x h"
> 5. type "M-q" to fill
>
> Actual:
>
> - one
>  two
>
> - three four
>
> Expected:
>
> - one two
>
> - three four

I can trigger the same behavior on my end.  I haven't stepped through
any code or searched the mailing list for related discussion, but it
looks like a bug to me.

(Unlike the initial post, this message should be forwarded to Org's
mailing list, and I've marked it as a confirmed bug for Org's
.)





bug#44833: 27.1; Org org-docview-open (wrong-number-of-arguments (2 . 2) 1)

2021-12-18 Thread Kyle Meyer
close 44833
quit

Kyle Meyer writes:

> I'm sorry you didn't get a response at the time, but it seems unlikely
> that you still have this issue because, as of Org's afd3b04ec (ol:
> Extend open tooling in link parameters, 2020-02-19), org-link-open
> handles the above error:
>
> ;; 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)))
>
> And that change made its way into the Emacs repo with f22856a5c54
> (Update to Org 9.4.1, 2020-12-13), which was a part of the 27.2 release.
>
> Can you confirm that the issue is resolved for you?

It's been close to two weeks, so I'll close this, but, if you are still
having this issue, please let us know.





bug#50218: 28.0.50; org-babel-tangle-file tangles code blocks starting with #+begin_src :tangle no

2021-12-18 Thread Kyle Meyer
Tassilo Neubauer writes:

> Hello,
>
> Here are the steps that led to code blocks being tangled I did not 
> expect to:
>
> emacs -Q
> C-x C-h: ~/org-roam/example.org
> content of example.org (excluding "):
> "
> #+begin_src emacs-lisp
> (setq some-emacs-lisp-variable t)
> #+end_src
>
> #+begin_src :tangle no
> ;;This line should not be in the elisp code
> #+end_src
> "

(Sorry for the delayed reply.  This message, unlike the initial post,
will be redirected to the Org list, where you're more likely to get a
response.)

Org sees the last block above as a source block of language ":tangle".
Here's what org-element-at-point reports:

  (src-block (:language ":tangle" :switches nil :parameters "yes"...)

org-lint will complain about this block:

 2 nil   Missing colon in header argument "yes"

And, were you to use a bare source block (i.e. drop ":tangle no"), it
would complain about a missing language:

 2 nil   Missing language in source block

So, I think the source block is mis-specified, and I'm not sure there's
much that Org should do here, but perhaps others will chime in with
their thoughts.





bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-16 Thread Kyle Meyer
Rudolf Adamkovič:

> I have a .org file with two kinds of src blocks:
>
> 1. sqlite blocks
> 2. bibtex blocks
>
> I want to execute all sqlite blocks with org-babel-execute-buffer.
>
> When I try to do so, org-mode complains:
>
> org-babel-execute-src-block: No org-babel-execute function for bibtex!
>
> I know I can work around the problem (as one does in org-mode) with:
>
> #+property: header-args:bibtex+ :eval no
>
> Then, why not skip the irrelevant blocks, the ones with no execute functions, 
> by default?

I don't know, but I've reassigned this bug in order to redirect this to
the Org list, which serves as the primary place for Org development and
discussion.





bug#52547: 29.0.50; Confusing behavior of org-timer-set

2021-12-16 Thread Kyle Meyer
Rudolf Adamkovič:

> Reproduction steps:
>
> 1. run 'emacs -Q'
> 2. type M-; and then "(require 'org)"
> 3. type M-x and then 'org-timer-set'

This must be org-timer-set-timer; there's no org-timer-set in Org's
tree.

> 4. see 'How much time left? (minutes or h:mm:ss)'
> 5. type '10m'
>
> Expected: The timer runs for 10 minutes.
> Actual: The timer runs for 10 seconds.
>
> From the perspective of the user, this makes no sense.

Yes, it seems better to at least signal a user-error if the input
doesn't match the expected format.

Anyway, I'm redirecting this to the Org list.  Perhaps someone there
will be interested in improving this behavior or reviewing a patch that
does so.

> P.S. I would also expect auto-load on "org-timer-set".

org-timer-set-timer has been autoloaded since 4e2795413 (Add autoload
cookie to org-timer-set-timer, 2009-07-27).






bug#51365: 29.0.50; org-mode: modification-time error with git controled file

2021-12-11 Thread Kyle Meyer
close 51365 28.1
quit

TAKAHASHI Yoshio writes:

> Hi,
>
> With git controled file,
> {{{modification-time(%Y-%02m-%02dT%02H:%02M:%02S+09:00, 1)}}}
> causes "Wrong type argument: stringp, " error.
>
> `org-macro--vc-modified-time' in org-macro.el should pass list of FILE
> to `vc-call', because `vc-git-print-log' expects list of file as its 1st
> argument.

Thanks for the report and fix.  This failure is new with Emacs 28,
specifically 3572613550f (Fix vc-git-state for filenames with wildcards,
2021-08-15).  Before that, passing a string instead of a list worked
okay because vc-git-print-log just passed its FILES argument untouched
to vc-git-command's FILE-OR-LIST.

> diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el
> index b8d3373418..9e70844963 100644
> --- a/lisp/org/org-macro.el
> +++ b/lisp/org/org-macro.el
> @@ -368,7 +368,7 @@ org-macro--vc-modified-time
>   date)
>   (unwind-protect
>   (progn
> -   (vc-call print-log file buf nil nil 1)
> +   (vc-call print-log (list file) buf nil nil 1)
> (with-current-buffer buf
>   (vc-exec-after
>(lambda ()

Looks good to me.  I confirmed the bug and fix only with vc-git,
although the change looks appropriate for the other backends too:

  $ git grep -E '\(defun vc-.+-print-log'
  lisp/vc/vc-bzr.el:(defun vc-bzr-print-log (files buffer  shortlog 
start-revision limit)
  lisp/vc/vc-cvs.el:(defun vc-cvs-print-log (files buffer  _shortlog 
_start-revision limit)
  lisp/vc/vc-dav.el:(defun vc-dav-print-log (_url)
  lisp/vc/vc-git.el:(defun vc-git-print-log (files buffer  shortlog 
start-revision limit)
  lisp/vc/vc-hg.el:(defun vc-hg-print-log (files buffer  shortlog 
start-revision limit)
  lisp/vc/vc-mtn.el:(defun vc-mtn-print-log (files buffer  _shortlog 
start-revision limit)
  lisp/vc/vc-rcs.el:(defun vc-rcs-print-log-cleanup ()
  lisp/vc/vc-rcs.el:(defun vc-rcs-print-log (files buffer  _shortlog
  lisp/vc/vc-sccs.el:(defun vc-sccs-print-log (files buffer  _shortlog 
_start-revision-ignored limit)
  lisp/vc/vc-src.el:(defun vc-src-print-log (files buffer  shortlog 
_start-revision limit)
  lisp/vc/vc-svn.el:(defun vc-svn-print-log (files buffer  _shortlog 
start-revision limit)

So, I've added a commit message to above patch and applied it in your
name on Org's bugfix branch (888689f2b).






bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

2021-12-09 Thread Kyle Meyer
close 52341
quit

Kyle Meyer writes:

> I suppose one solution would be to check for " " and translate that to
> the ?\s so that the remove is triggered.  I'll plan to apply the change
> below to Org's bugfix branch in a day or two unless the author of the
> above commit (+cc) or someone else has another suggestion.

Applied to the Org repo (4aca51fcb).





bug#52399: 28.0.60; easier access to ORG-NEWS

2021-12-09 Thread Kyle Meyer
Mike Kupfer writes:

> Finding ORG-NEWS seems harder than it should be.
>
> 1. The "Browse Org News" menu item (Org > Documentation > Browse Org
> News) isn't adequate, because it takes you to orgmode.org.  The package
> description (C-h P org RET) has the same problem.  If you're working
> offline, orgmode.org is not going to be available.  Also, it shows the
> news for the latest release, which might not be what you have installed.
> (The news for older releases is available at the bottom of the page, but
> it could be confusing if you don't notice that the news that is first
> presented is for a different release.)
>
> 2. I don't see a reference to ORG-NEWS in the Org mode section of the
> Info pages, much less an easy way to get to it.

These two look like something that would be dealt with on Org's side.
This report has been reassigned there, so perhaps someone on the Org
list will have thoughts or decide to work on a patch.

> 3. The entry in NEWS for the Org mode update mentions ORG-NEWS, but it
> doesn't say how to get to it.  (Yes, I know how to get to ORG-NEWS from
> NEWS.  Do we expect random users to understand the layout of an
> installed Emacs at that level of detail?)

And I guess this one is for Emacs's side at the time of the sync.

I was looking through the NEWS* files in the Emacs repo for guidance
from other packages, but I see mostly the same thing ("GNUS-NEWS",
"MH-E-NEWS", "ERC-NEWS", ...).  I guess there is one that's a little
different, though I'm not sure how helpful tacking on "./" is: "See the
file ./MH-E-NEWS for details".

Do you have any suggestions for what would be more helpful to put there?





bug#52392: 29.0.50; org-priority 'SPC to remove' doesn't work

2021-12-09 Thread Kyle Meyer
forcemerge 52341 52392
quit

Bruce E. Robertson writes:

> 1. in init.el:
> (custom-set-variables
>  '(org-priority-default 32)
>  '(org-priority-highest 0)
>  '(org-priority-lowest 31)
> )
> 2. position to line in .org file:
[...]

This looks like a duplicate of https://debbugs.gnu.org/52341 (which has
already received comments), so I'm merging the reports.





bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

2021-12-07 Thread Kyle Meyer
Robert Pluim writes:

>>>>>> On Mon, 06 Dec 2021 20:48:46 -0500, Kyle Meyer  said:
> Kyle> Right, this stems from org-priority feeding " " to string-to-number 
> and
> Kyle> ending up with 0 instead of the ?\s (32) that's used downstream to
> Kyle> signal "remove".  The problem goes back to when support for numeric
> Kyle> priorities was added in Org v9.4's 4f98694bf (Allow numeric values 
> for
> Kyle> priorities, 2020-01-30).
>
> Kyle> I suppose one solution would be to check for " " and translate that 
> to
> Kyle> the ?\s so that the remove is triggered.  I'll plan to apply the 
> change
> Kyle> below to Org's bugfix branch in a day or two unless the author of 
> the
> Kyle> above commit (+cc) or someone else has another suggestion.
>
> That fixes part of the issue, but still when using numeric priorities,
> removal will be 'SPC RET' rather than 'SPC'.

If someone 1) uses numeric priorities and 2) has org-priority-lowest
above 9, read-string is used to prompt with "Priority M-N, SPC to
remove: ".  They need to use 'SPC RET' just as they need to use, say, '3
RET'.  That is, it's consistent with the prompt behavior for entering
the actual priorities.

Perhaps that should change in some way (though I'm not planning on
working on it myself), but in my view that behavior shouldn't be
conflated with SPC not being translated to "remove the priority".





bug#44687: 26.3; Link broken in inline comment

2021-12-06 Thread Kyle Meyer
tags 44687 wontfix
close 44687
quit

YH Tan writes:

> In org-mode,
>
> ```
> [[link]]@@comment:[[link]]@@
> # [[link]]
>
> * link
> ```
>
> I get the message "No Link Found" when clicking on the [[link]] within
> the inline @@comment:[[link]]@@.
>
> The link works fine with emacs -Q, but breaks after evaluating some
> init.el code.
>
> Problem is, I cannot pinpoint to the exact code that broke the link.

I'm sorry you didn't get a response at the time.

Your recipe starts complaining "No Link Found" as of Org's d3774fba7,
which was a part of the 9.2 release:

  Limit `org-open-at-point'
  
  * lisp/org.el (org-open-at-point): Do not open everything that looks
like a link, in particular in verbatim or code objects.  However,
still conveniently open links in comments, node properties and
keywords.

The Org bundled with Emacs 26.3 was 9.1.9, so the difference you
reported between your regular environment and 'emacs -Q' is very likely
explained by the above commit being included in the Org available from
ELPA but not yet included in the Org that shipped with Emacs 26.3.

My understanding is that no longer being able to open a link (or rather
text that resembles a link) in an export snippet is an intentional
consequence of that commit, so I'm closing this as wontfix.  (But fwiw
calling org-open-at-point-global rather than org-open-at-point should
give the behavior you're after.)





bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

2021-12-06 Thread Kyle Meyer
bruce robertson writes:

> 1. in init.el:
> (custom-set-variables
>  '(org-priority-default 32)
>  '(org-priority-highest 0)
>  '(org-priority-lowest 31)
> )
> 2. position to line in .org file:
> ** TODO [#0] test line
>
> 3. from M-x view-lossage:
>  C-c , ;; org-priority
>
> 4. mini-buffer displays:
> "Priority 0-31, SPC to remove: "
>
> 5. further in view-lossage:
> SPC   ;; self-insert-command
>;; exit-minibuffer
>
> 4. from *Messages* (and mini-buffer):
> Priority of current item set to 0
>
> 5. PROBLEM:
> I wanted to remove priority.
>
> 6. WORK-AROUND:
> set priority to 32. Then priority disappears. Perhaps this is because 32
> is space code or because I've set org-priority-default to 32.
> ( I spent a medium amount of time to find this behavior. )
>
> 7. SUGGESTION:
> rewrite org-priority to have a clear distinction between numbers and
> characters and whatever will be used to remove the priority.
> ( I gave a look at this but my emacs-fu is too weak. Or my time-fu is
> too small. )

Right, this stems from org-priority feeding " " to string-to-number and
ending up with 0 instead of the ?\s (32) that's used downstream to
signal "remove".  The problem goes back to when support for numeric
priorities was added in Org v9.4's 4f98694bf (Allow numeric values for
priorities, 2020-01-30).

I suppose one solution would be to check for " " and translate that to
the ?\s so that the remove is triggered.  I'll plan to apply the change
below to Org's bugfix branch in a day or two unless the author of the
above commit (+cc) or someone else has another suggestion.

diff --git a/lisp/org.el b/lisp/org.el
index 1a1375461..998da0656 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11323,13 +11323,14 @@ (defun org-priority ( action show)
(setq
 new
 (if nump
- (let ((msg (format "Priority %s-%s, SPC to remove: "
-   (number-to-string org-priority-highest)
-   (number-to-string org-priority-lowest
-   (if (< 9 org-priority-lowest)
-  (string-to-number (read-string msg))
- (message msg)
- (string-to-number (char-to-string 
(read-char-exclusive)
+ (let* ((msg (format "Priority %s-%s, SPC to remove: "
+ (number-to-string org-priority-highest)
+ (number-to-string org-priority-lowest)))
+(s (if (< 9 org-priority-lowest)
+   (read-string msg)
+ (message msg)
+ (char-to-string (read-char-exclusive)
+   (if (equal s " ") ?\s (string-to-number s)))
   (progn (message "Priority %c-%c, SPC to remove: "
   org-priority-highest org-priority-lowest)
  (save-match-data





bug#44833: 27.1; Org org-docview-open (wrong-number-of-arguments (2 . 2) 1)

2021-12-04 Thread Kyle Meyer
Michael 1 writes:

> Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
>   org-docview-open("file.odt::1")
>   org-link-open((link (:type "docview" :path "file.odt::1" :format bracket 
> :raw-link "docview:file.odt::1" :application nil :search-option nil :begin 
> 364 :end 453 :contents-begin 415 :contents-end 451 :post-blank 0 :parent 
> (paragraph (:begin 364 :end 454 :contents-begin 364 :contents-end 454 
> :post-blank 0 :post-affiliated 364 :parent nil nil)
>   org-open-at-point(nil)
>   funcall-interactively(org-open-at-point nil)
>   call-interactively(org-open-at-point nil nil)
[...]
> Can you reproduce the error?
> Is there any way to fix this behavior?

I'm sorry you didn't get a response at the time, but it seems unlikely
that you still have this issue because, as of Org's afd3b04ec (ol:
Extend open tooling in link parameters, 2020-02-19), org-link-open
handles the above error:

;; 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)))

And that change made its way into the Emacs repo with f22856a5c54
(Update to Org 9.4.1, 2020-12-13), which was a part of the 27.2 release.

Can you confirm that the issue is resolved for you?





Re: org-sort random

2021-11-22 Thread Kyle Meyer
(Please don't drop the list.)

Vikas Rawal writes:

> That is, just press RET?

I think that depends on the completion framework.  With the default
completion, yes, I think RET should do it.  With ivy, it's instead
ivy-immediate-done (C-M-j).  I'm not sure offhand about other
frameworks.

> If I do that, it just reverses the existing order. No randomisation
> happens.

Dunno.  Seems to work on my end (release_9.5.1-188-g27f26f782).

* h
** a
** b
** c
** d
** e
** f
** g
** h
** i
** j
** k
** l

With point on h and vanilla Emacs:

- C-c ^ f
- random
- RET

* h
** f
** e
** h
** i
** g
** j
** k
** b
** c
** d
** a
** l



Re: [PATCH] Fix regex for determining image width from attribute

2021-11-22 Thread Kyle Meyer
Matt Huszagh writes:

> Timothy  writes:
>
>> I’ve just pushed the change I described in 4514a32. This improves the
>> interpretation of :width attributes and makes a value of “t” work as 
>> discussed.
>> I have not prioritised #+attr_org for now, but that sounds like a change we
>> could make in the future.
>
> Thanks Timothy. However, I think this change may have some issues. It
> seems that it unbalances parentheses. This also no longer sets width
> (so, e.g., (floatp width) won't work). Maybe attr-width was intended to
> be renamed to width? Are you seeing the same?

I'm not sure either, but this syntax error brings down the whole tree,
so I've pushed 27f26f782 to resolve it.  Timothy, please check my guess
at what the intended code was.



Re: Invalid read syntax errors compiling orgmode from git repository

2021-11-22 Thread Kyle Meyer
JG writes:

> commit 4514a324c86a408951a0553a390a01981d61c367 (HEAD -> main, origin/main, 
> origin/HEAD)
[...]
> In toplevel form:
> org-agenda.el:50:1: Error: Invalid read syntax: ")", 50, 14
> Compiling /home/etest/org-mode/lisp/org-archive.el...
[...]

Thanks for reporting.  The syntax error was introduced by the commit you
referenced and is fixed with 27f26f782.

Timothy, please look over my change to confirm that it matches the
change you intended to make in 4514a324c.



Re: org-sort random

2021-11-21 Thread Kyle Meyer
On 11/22/21 07:40:35 +0530, Vikas Rawal wrote:
> I am trying to sort a sub-tree of headings randomly. But `C-c ^ f
> random RET` asks for a "function for comparing keys". What am I
> supposed to do?

Here's the prompt:

  Function for comparing keys (empty for default `sort-subr' predicate):

And here's what sort-subr's docstring says about the behavior of the
default predicate:

  If PREDICATE is nil, comparison is done with ‘<’ if
  the keys are numbers, with ‘compare-buffer-substrings’ if the
  keys are cons cells (the car and cdr of each cons cell are taken
  as start and end positions), and with ‘string<’ otherwise.

That sounds like that should handle random's return value fine, so try
entering an empty string at that prompt.



Re: test-org-cite/main-affixes failure

2021-11-06 Thread Kyle Meyer
Nicolas Goaziou writes:

> Kyle Meyer  writes:
[...]
>> Does the current version of the test (no space) pass on your end?
>
> No idea. I haven't been able to run any test during the past week, at
> least (due to a silly error about missing ob-vala).

Hmm, after ob-vala.el was removed from the repo, I believe I saw a
similar failure and needed to remove "vala" from the BTEST_OB_LANGUAGES
value in local.mk.

> Anyway, you're certainly right about the fix. You can push it.

Okay, thanks for the confirmation.  Pushed.



test-org-cite/main-affixes failure

2021-11-06 Thread Kyle Meyer
Hi Nicolas,

test-org-cite/main-affixes, added in ad4028286 (oc: Refactor affixes
extraction, 2021-11-03), is failing on my end:

  $ BTEST_RE=main-affixes make test-dirty
  [...]
  Test test-org-cite/main-affixes condition:
  (ert-test-failed
   ((should
 (equal '...
(org-test-with-temp-text "[cite:@key1 post1;@key2 post2; global post]" 
...)))
:form
(equal
 (nil "global post")
 (nil
#(" global post" 0 12 ...)))
:value nil :explanation
(list-elt 1
(arrays-of-different-length 11 12 "global post"
#(" global post" 0 12 ...)
first-mismatch-at 0
 FAILED  1/1  test-org-cite/main-affixes (0.009342 sec)
  [...]

Adding a space to the expected SUFFIX (as in the diff below) makes the
test pass for me and looks to be consistent with some of the other cases
in that test.

Does the current version of the test (no space) pass on your end?


diff --git a/testing/lisp/test-oc.el b/testing/lisp/test-oc.el
index c700780fe..896870303 100644
--- a/testing/lisp/test-oc.el
+++ b/testing/lisp/test-oc.el
@@ -286,7 +286,7 @@ (ert-deftest test-org-cite/main-affixes ()
   (org-test-with-temp-text "[cite:global pre;pre1 @key1;pre2 @key2]"
 (org-cite-main-affixes (org-element-context)
   (should
-   (equal '(nil . ("global post"))
+   (equal '(nil . (" global post"))
   (org-test-with-temp-text "[cite:@key1 post1;@key2 post2; global 
post]"
 (org-cite-main-affixes (org-element-context))
 



Re: Problems generating the org-mode documentation

2021-10-22 Thread Kyle Meyer
Hoffmann, Jobst writes:

> But I think I found the culprit:
>
> Line 17568 of org.texi reads:
>
> @kindex C-c C-x @
>
> and @ starts a command, which leads to the stack overflow.
>
> Line 17568 of org.texi should read
>
> @kindex C-c C-x @@
>  
> witha doubled @ at the end of the line and after applying this change
> org.texi the documentation org.pdf can be generated without any error.

Marco Wahl fixed this entry a few days ago on the bugfix branch:
37791bb4f (org-manual: Fix one kindex entry, 2021-10-18).



Re: org-table-blank-field key binding removal

2021-10-16 Thread Kyle Meyer
Bastien Guerry writes:

> I suggest we add a news entry in etc/ORG-NEWS in the bugfix branch for
> the change to be advertized for 9.5.x users.
>
> Can anyone do that?

Done in 9bc3a2b98.



Re: org-table-blank-field key binding removal

2021-10-13 Thread Kyle Meyer
Michael Brand writes:

> The change is not announced in ORG-NEWS. I think it should be in Version 9.4.

Right, I agree this change should have come with a NEWS entry, though
0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
is from the 9.5 release not 9.4.

However, 9.5 is out, and my understanding is that released NEWS sections
should not be substantially modified in most cases
().  I'll leave it to
the author of the original change and Bastien to decide if they want to
make an exception in this case.



test-org-cite/list-citations failure (was: Citation not inserted as 1st item in footnote ...)

2021-10-09 Thread Kyle Meyer
Hi Nicolas,

Nicolas Goaziou writes:

> Nicolas Goaziou  writes:
>
>> This allows one to insert a citation in the middle of the citation
>> number, which is not desirable either. IOW, an additional check is
>> required.
>
> I think this is now fixed. Thank you.

It looks like this commit introduced a test failure.  Starting with
7d22dca54 (oc: Fix citations in footnotes when using biblatex back-end,
2021-10-06), test-org-cite/list-citations fails on my end (Emacs 27.2):

--8<---cut here---start->8---
Test test-org-cite/list-citations condition:
(ert-test-failed
 ((should
   (equal '...
(org-test-with-parsed-data "Text[fn:1]
[fn:1] [fn:2][cite:@a]

[fn:2] [cite:@b]" ...)))
  :form
  (equal
   ("b" "a")
   ("a"))
  :value nil :explanation
  (proper-lists-of-different-length 2 1
("b" "a")
("a")
first-mismatch-at 0)))
   FAILED  1/1  test-org-cite/list-citations (0.015186 sec)
--8<---cut here---end--->8---



Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

2021-10-09 Thread Kyle Meyer
No Wayman writes:

> Subject: [PATCH] lisp/org.el: (org-save-all-org-buffers): Prevent `org-mode'
>  reload
>
> * lisp/org.el: (org-save-all-org-buffers): Ensure `save-some-buffers' PRED 
> returns boolean.
>
> As of this upstream commit:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9ad3d477441feefa3bf6107d58281cb64e0e78a
>
> `save-some-buffers' will call its PRED argument if it returns a function.
> Since (derived-mode-p 'org-mode) returns the symbol org-mode,
> and org-mode is a function, org-mode is reloaded in modified Org
> buffers when calling `org-save-all-org-buffers'. Among other
> undesirable behavior, this will cause the buffer's visibility to be
> reset to its initial visibility.

Thanks for the analysis and fix.

  To git.savannah.gnu.org:/srv/git/emacs/org-mode.git
 11f450da8..b71474ff7  bugfix -> bugfix



Re: org-table-blank-field key binding removal

2021-10-05 Thread Kyle Meyer
On 10/05/21 21:49:22 -0500, Alan Wehmann wrote:
> On 2/5/21 in this email list Carsten Dominik suggested removing the
> key binding C-c  for "org-table-blank-field".  That got
> implemented for Org-9.5, but the Info file didn't get changed, so it
> still says:
>
> ‘C-c ’ (‘org-table-blank-field’)
>  Blank the field at point.
>
> in node (org) Built-in Table Editor

Thank you for catching that.  I've updated the manual in 6874af872.

> In my own usage of tables I use this key binding a lot, so I am going
> to figure how to restore it.

Sorry about that.  You can restore it on your end by putting something
like this in your config:

  (define-key org-mode-map (kbd "C-c SPC") #'org-table-blank-field)



Re: [org-cite] Testing on macOS, XML file missing

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

> Rudolf Adamkovič writes:
>
>> When I try to export HTML with APA/CSL citations (C-c C-e h o), 
>> Emacs says:
>>
>>> The default CSL locale file 
>>> /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/etc/csl/locales-en-US.xml
>>>  
>>> doesn’t exist or is unreadable

This is hopefully resolved with bb209cd5ab (Update to Org
9.5-30-g10dc9d, 2021-10-02) in the Emacs repo.



Re: Grabbing the link to a message on the archive

2021-10-02 Thread Kyle Meyer
Max Nikulin writes:

> On 02/10/2021 21:26, Ihor Radchenko wrote:
[...]
>> It can be parsed from the html.  Something like below (it is my
>> home-made parser, but I think the idea should be clear):
>> 
>> (org-capture-ref-set-bibtex-field :key (org-capture-ref-query-dom :tag 'form 
>> :tag 'input :attr '(name . "d") :attr 'value))
>
> Thank you, Ihor. I did not expect such funny form of obfuscation. Since 
> even author names are hidden in search results, I believed that 
> message-id should be considered even more confidential to put it into 
> page code.

Any obfuscation presented by https://lists.gnu.org is misleading.  Bots
don't have any issue getting addresses from that domain:

  curl -fSsL https://lists.gnu.org/archive/mbox/emacs-orgmode/2021-09



Re: [org-cite] Testing on macOS, XML file missing

2021-10-02 Thread Kyle Meyer
Bruce D'Arcus writes:

> Sorry; I wasn't clear.
>
> What I meant is that etc/styles was also not synced.

Right, some of the non-lisp files get moved around directory-wise
between the Org and Emacs repos.  Just in case it didn't stick out in
the snippets from my message upstream, the same files are there on both
sides:

  $ git -C org-mode ls-tree -r release_9.5:etc/styles
  100644 blob d0c98a3e51c079e74780d54289b09ba8ba52ac64  
OrgOdtContentTemplate.xml
  100644 blob 1a8edee99b4ccbbb18321091a7530afee660906a  OrgOdtStyles.xml
  100644 blob 07126fc31ba60103032e075e7cfdf81569e324c9  README

  $ git -C emacs show --no-patch --format="%s (%ch)" bf9ec3d91a
  Update to Org 9.5 (Wed Sep 29 23:21)

  $ git -C emacs ls-tree bf9ec3d91a:etc/org
  100644 blob d0c98a3e51c079e74780d54289b09ba8ba52ac64  
OrgOdtContentTemplate.xml
  100644 blob 1a8edee99b4ccbbb18321091a7530afee660906a  OrgOdtStyles.xml
  100644 blob 07126fc31ba60103032e075e7cfdf81569e324c9  README



Re: [org-cite] Testing on macOS, XML file missing

2021-10-02 Thread Kyle Meyer
Bruce D'Arcus writes:

> On Sat, Oct 2, 2021 at 1:24 AM Kyle Meyer  wrote:
>
>> Is there a reason to avoid updating to the latest version?
>
> No; updating them makes sense.

All right, thanks.  I've updated these files to latest versions in
06ab36eb0.



Re: [org-cite] Testing on macOS, XML file missing

2021-10-01 Thread Kyle Meyer
Rudolf Adamkovič writes:

> I compiled Emacs from "master" (2e92f90a5d) to try the new 
> citations.
>
[...]
>
> When I try to export HTML with APA/CSL citations (C-c C-e h o), 
> Emacs says:
>
>> The default CSL locale file 
>> /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/etc/csl/locales-en-US.xml
>>  
>> doesn’t exist or is unreadable
>
> (I checked, and no 'etc' directory exists in 'lisp/org'.)

Thanks for the report.  Indeed I didn't check for new files outside of
lisp/, and etc/csl/ wasn't synced to Emacs.  Though even if those files
were present, you would have seen the same failure due to the way things
are written on our end.

I've pushed a set of commits to the Org repo (60b178e59, 0f11a44e0, and
9cc7f8bd1) that should prepare things on our end.  And I've done a local
sync to Emacs and verified that org-cite-csl--etc-dir looks to point to
the right place when running from Emacs and when installed to the
system.

Before we sync these etc/csl/ files to the Emacs repo (which hopefully
won't be a point of contention), I have a question about these files.
After a bit of digging, I traced their origin.  As I say in 9cc7f8bd1
(etc/csl: Add a README in preparation for Emacs sync):

  I did not add these files, but I have verified that
  
   - etc/csl/chicago-author-date.csl is identical to
 9821a884d2cbf919a064426999b05aa78e98da8d:chicago-author-date.csl
 from https://github.com/citation-style-language/styles
  
   - etc/csl/locales-en-US.xml is identical to
 a2b76b20ee120979ec66cfdcfa798b36fc5a7f0b:locales-en-US.xml from
 https://github.com/citation-style-language/locales

However, both of those files have newer versions.

  $ git log --oneline --format="%ch | %h %s" 9821a88.. -- 
chicago-author-date.csl
  Sun Sep 19 03:19 | ccb71844f Update chicago-author-date.csl (#5605)
  Apr 26 2020 | a78997329 Chicago: Uppercase "Presentated at" if no `genre` 
(#4729)
  Aug 13 2019 | d9852a293 Update chicago-author-date.csl and other author date 
variants (#4250)
  Jan 3 2019 | 246ce5fdf Chicago: Correct dictionary/encyclopedia entries
  May 21 2018 | 9296c8c15 Fix redundant terms (#3517)
  May 13 2018 | e4db3699d update chicago-author-date.csl; close issue #3386 
(#3455)
  Jan 25 2018 | f601d1af5 Fix missing space before locators. (#3288)
  Dec 6 2017 | 04cbd1787 Reindent/reorder

  ---

  $ git log --oneline --format="%ch | %h %s" a2b76b2.. -- locales-en-US.xml 
  Dec 29 2017 | 9a4eb48 Replace some usernames by real names
  Dec 29 2017 | f01d92a Drop email addresses from translator tags
  Dec 29 2017 | f6fa898 Add translators from git log to the locale files.

Is there a reason to avoid updating to the latest version?



Re: org-element.el change in emacs.git

2021-09-30 Thread Kyle Meyer
Adam Porter writes:

> I noticed this recent commit on emacs.git making a change to
> org-element.el:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58102466e32d4dd9c7d816cdc3f4595a2145f332

Thanks for the heads up.

I monitor Org-related changes to the Emacs repo and port them to Org's.
Entering into Emacs release periods, I tend to look at least once a day
so that porting doesn't hold up cutting a bugfix release and syncing.
Other times, it's not as frequent, but usually not less than once a
week.

None of that is to say that flagging an important commit isn't
appreciated.  Just setting expectations about what the normal intake
looks like.

(Fwiw a log of the considered commits is available at
.)

> I don't see that change in org-mode.git, and it seems like it could be
> an important one, so I wanted to make sure it doesn't go unnoticed.

It came in with c763b9ae6 (Backport commit 58102466e from Emacs,
2021-09-30), and it looks like it was merged into the bugfix branch
about ten minutes before your message landed, but I probably _pushed_ a
bit after you hit send :)



Re: Switching to new Git repositories

2021-09-23 Thread Kyle Meyer
No Wayman writes:

> Out of curiosity I ran this against the repo to see if the 
> "Version" metadata had always followed its current convention:
>
> git grep "Version:" $(git rev-list --all) -- lisp/org.el
>
> Looks like the "-dev" suffix goes back to "9.4-dev" and before 
> that we have "8.4-git" and "6.08-pre01".
> I'm not sure what Org's convention is here, but the patsubst could 
> be adjusted to be more flexible if necessary.

Thanks for checking.  I think just handling -dev is probably good
enough.

> Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos

Pushed:

  To git.savannah.gnu.org:/srv/git/emacs/org-mode.git
 c9dc6603a..9a4a24a94  main -> main

(It's not needed on the bugfix branch given -dev isn't used in the
header there.  Plus I think the 9.5 release is expected before another
release from maint/bugfix.)

Thank you for fixing my mistake.



Re: Switching to new Git repositories

2021-09-23 Thread Kyle Meyer
On 09/23/21 17:17:48 -0400, No Wayman wrote:
>> Sounds like a weird issue.  I don't think this 9.5-dev tag is 
>> something from the Org repo.
>
> There is a bug in mk/targets.mk introduced by 61336f80dc.

Quoting that commit message for context:

  mk/targets.mk: Add version fallback for tag-less repos
  
  * mk/targets.mk (ORGVERSION, GITVERSION): Get version from lisp/org.el
  header if it can't be retrieved from git-describe.
  
  As of elpa.git's ee03829f90 (Finalize the new master branch,
  2020-12-14), org-release and org-git-version are empty strings in
  https://elpa.gnu.org/packages/org-*.tar files.  This is because the
  new setup executes `make autoloads info' in an elpa.git worktree with
  an Org branch checked out, but elpa.git of course doesn't have Org's
  release tags.
  
  Maintaining the org.el version header has been a point of contention
  in the past [1], but the header has been there for a while now.  Use
  it to avoid the above elpa.git issue.  In the case of the master
  branch, the org-release value generated in a tag-less repo will have a
  different version than the one from a regular repo because org.el's
  version header has a "-dev" suffix, but that's still better than an
  empty version.
  [...]

> As others have pointed out, the new repository does not have tags.
> As a fallback, org.el's version is read in it's header.
> However, it looks like Kyle forgot to trim that string so we get 
> ORGVERSION set to "9.5-dev" instead of "9.5".

I of course can't say for sure, but based on my commit message (in
particular the last paragraph), it sounds like I was aware of the
discrepancy but didn't realize it'd cause the downstream "Invalid
version syntax" issue mentioned by Bill in
.

> This causes `org-version' to return an incorrect version string.
>
> The attached patch addresses the issue in the makefile.

Thanks.

> Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos
>
> * mk/targets.mk (ORGVERSION, GITVERSION): properly generate ORGVERSION.

I think it'd be better to say something more specific about the change
rather than say "properly" and assume the reader knows what the writer
has in mind.

> Fix bug introduced 61336f80 which caused ORGVERSION to be generated as
> "Major.Minor-dev" instead of "Major.Minor" in tag-less repos.

Please say what the bug is.  Can you give a sparse outline of the call
chain for the error mentioned in Bill's message?

> -ORGVERSION := $(shell $(BATCH) --eval "(require 'lisp-mnt)" \
> -  --visit lisp/org.el --eval '(princ (lm-header "version"))')
> -GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
> +ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
> 'lisp-mnt)" \
> +  --visit lisp/org.el --eval '(princ (lm-header "version"))'))
> +GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD))

It looks like you've unintentionally added a ')' to the end of the
GITVERSION line.

Another approach would be to update org.el's version to contain
something that still signals "-dev" but won't trigger the "Invalid
version syntax" (which, based on grepping the Emacs repo, is signaled by
version-to-list).  But given that in the current setup a clone with tags
wouldn't use the header version, stripping -dev for consistency sounds
like the way to go.



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

2021-08-08 Thread Kyle Meyer
Hi Marco,

In 61e083732 (org-attach: Possibly delete empty attach directory,
2021-07-09), you added a call to directory-empty-p.  This function was
introduced in Emacs's 0806075520 (Add directory-empty-p and new argument
COUNT for directory-files-*, 2020-11-02) and hasn't yet made it into a
release.

Could you update org-attach-sync to avoid using directory-empty-p (e.g.,
by inlining it or by adding a compatibility alias)?

Thanks.



[RFH] thoughts on porting an Emacs etc/schema/ change

2021-05-23 Thread Kyle Meyer
I'm trying to figure out how to port changes to etc/schema/ files in the
Emacs repo back to the Org repo.  I'd appreciate feedback from anyone
who knows anything about the etc/schema/ files in Org's tree and/or
ox-odt.


Background
==

Org has a few files in etc/schema:

  org$ git ls-files --stage etc/schema
  100644 87f84d1ea87e1e0eef759fac1bd7db74ce0a704e 0 
etc/schema/od-manifest-schema-v1.2-os.rnc
  100644 8d679d62e4ef1a21707250cf4cabcd5b657d7683 0 
etc/schema/od-schema-v1.2-os.rnc
  100644 f1e0ed7856f24c58488bbeac1df922a7d5100776 0 etc/schema/schemas.xml

Two of those are in Emacs's tree as is:

  emacs$ git ls-tree -r origin/emacs-27 -- etc/schema/ | grep od
  100644 blob 87f84d1ea87e1e0eef759fac1bd7db74ce0a704e  
etc/schema/od-manifest-schema-v1.2-os.rnc
  100644 blob 8d679d62e4ef1a21707250cf4cabcd5b657d7683  
etc/schema/od-schema-v1.2-os.rnc

The contents of Org's etc/schema/schemas.xml, on the other hand, are
_added_ within Emacs's etc/schema/schemas.xml.

  org$ git show f1e0ed7856f24c58488bbeac1df922a7d5100776
  
  http://thaiopensource.com/ns/locating-rules/1.0;>




  

  emacs$ git show origin/emacs-27:etc/schema/schemas.xml | wc -l
  65

  emacs$ git show origin/emacs-27:etc/schema/schemas.xml | grep -i 
'opendoc\|od-'






Changes on the Emacs master branch
==

A commit on Emacs's master branch (author cc'd) makes changes to these
files.

  emacs $ git ls-tree -r master -- etc/schema/ | grep od
  100644 blob 87f84d1ea87e1e0eef759fac1bd7db74ce0a704e  
etc/schema/od-manifest-schema-v1.2-os.rnc

  emacs$ git show --numstat --format=%B f1f351def3d84813d2c4b2174dfef07b01bec058
  Update rnc to use Open Document's Relax-NG schema to version 1.3
  
  * Use the LibreOffice Relax-NG files since they include a hack to
 support 1.2.
  * rng source:
 https://raw.githubusercontent.com/freedesktop/libreoffice-core/master/
 schema/libreoffice/OpenDocument-schema-v1.3%2Blibreoffice.rng
  * translation to rnc with trang:
 trang -I rng -O rnc OpenDocument-schema-v1.3+libreoffice.rng \
 OpenDocument-schema-v1.3+libreoffice.rnc
  
  
  892 0   etc/schema/OpenDocument-schema-v1.3+libreoffice.rnc
  59145780etc/schema/{od-schema-v1.2-os.rnc => 
OpenDocument-schema-v1.3.rnc}
  5   1   etc/schema/schemas.xml

Here are the changes to schemas.xml:

  emacs$ git diff f1f351def3d84813d2c4b2174dfef07b01bec058^- 
etc/schema/schemas.xml
  diff --git a/etc/schema/schemas.xml b/etc/schema/schemas.xml
  index 7fd91b8c72..f8acb0d40c 100644
  --- a/etc/schema/schemas.xml
  +++ b/etc/schema/schemas.xml
  @@ -31,6 +31,10 @@
 http://relaxng.org/ns/structure/1.0; typeId="RELAX NG"/>
 http://thaiopensource.com/ns/locating-rules/1.0;
   uri="locate.rnc"/>
  +  
  +  
  +  
  +  
   
 
 
  @@ -59,7 +63,7 @@
   
 
 
  -  
  +  
 
   
   


Porting to Org's tree
=

So, coming back to the Org repo, I guess that'd be

  * delete the od-schema-v1.2-os.rnc file and add
OpenDocument-schema-v1.3.rnc

  * update the typeID line for od-schema-v1.2-os.rnc in Org's
etc/schema/schemas.xml to match the
OpenDocument-schema-v1.3+libreoffice.rnc line in the diff above

  * add the namespace lines to Org's etc/schema/schemas.xml (?)

But I know nothing about those files or ox-odt, so testing it on my end
would mostly be fumbling around to see if I spot any breakage when
exporting with ox-odt.

Does the above approach look reasonable?  Will it break ox-odt or be
problematic for some other reason?



Re: Org mode manual export

2021-05-22 Thread Kyle Meyer
Thomas S. Dye writes:

> Aloha all,
>
> The Org mode FAQ on Worg correctly reports that the Org mode 
> manual is written in Org mode, but it implies that it is exported 
> to texinfo using pandoc--"You can export .org files to texinfo 
> using Pandoc".
>
> I thought the manual was exported to texinfo with ox-texinfo, but 
> I don't know for certain.
>
> Can someone confirm how the Org mode manual is exported to 
> texinfo, please?

Yes, you're right that ox-texinfo is used.

In doc/Makefile there's

  org.texi orgguide.texi:   org-manual.org org-guide.org
$(BATCH)  \
  --eval '(add-to-list `load-path "../lisp")' \
  --eval '(load "../mk/org-fixup.el")'\
  --eval '(org-make-manuals)'

where org-make-manuals is defined in mk/org-fixup.el as

  (defun org-make-manuals ()
"Generate the Texinfo files out of Org manuals."
(require 'ox-texinfo)
(dolist (manual '("../doc/org-manual.org" "../doc/org-guide.org"))
  (find-file manual)
  (org-texinfo-export-to-texinfo)))



Re: tags-todo agenda shoud not ignore DONE items

2021-05-16 Thread Kyle Meyer
Bastien writes:

> Bastien  writes:
>
>> Confirming this as an issue, if someone wants to fix it.
>
> This should be fixed now with 823f9744e in maint, tags-todo should now
> include DONE headings.

823f9744e looks like a regression because it removes the distinction
between `tags' and `tags-todo'.  Consider the following file

--8<---cut here---start->8---
* h1   :atag:
* TODO h2  :atag:
* DONE h3  :atag:
* h4
* TODO h5
* DONE h6
--8<---cut here---end--->8---

and the following configuration

  (setq org-agenda-custom-commands
'(("1" tags "atag")
  ("2" tags-todo "atag")))

Before the above commit, 1 should show

  scratch:h1
  :atag:
  scratch:TODO h2   
  :atag:
  scratch:DONE h3   
  :atag:

and 2

  scratch:TODO h2   
  :atag:

That matches my expectations, though the request in this thread is that
2 includes "DONE h3" as well.

With 823f9744e, both 1 and 2 show

  scratch:h1
  :atag:
  scratch:TODO h2   
  :atag:
  scratch:DONE h3   
  :atag:

Note the inclusion of a non-TODO entry for 2 (tags-todo).

---

James Cash sent a followup patch to this in a detached thread:

  https://orgmode.org/list/87tuvyaopv@gmail.com

As I mentioned in that thread (<87361d7p3q@kyleam.com>) and
suggested in this thread (<87d061auiw@kyleam.com>), I think tags and
tags-todo should stay aligned with agenda's m/M, with tags-todo
excluding DONE items just as M does.



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



  1   2   3   4   5   6   7   8   9   10   >