Re: Elegant way to export org to Markdown ?
Jean-Christophe Helary writes: > I'm trying to work with SourceHut (sr.ht) and right now they only accept > Markdown syntax for their readme/wiki files. Hi Jean-Christophe, If this is just for SourceHut you can use an HTML export and upload it via the API instead of committing a Markdown based file. https://man.sr.ht/git.sr.ht/#setting-a-custom-readme Regards, Morgan
Re: Is M-j broken for you in Org on Emacs 27 and 28?
Tim Cross writes: > Based on your report of having org 9.3, my suspicion is that your org > version is too old for the current Emacs versions (since the change in > 2019 to use default-indent-new-line for C-M-j and M-j. I don't think > this is a bug in current Org or Emacs. Just for reference, I see the same problem on Emacs 27.2 using the default and latest versions of Org-mode. i.e. - using `emacs -Q` the Org version is listed as 9.4.4 and I see error - running emacs normally the Org version is listed as 9.5.1 and I see the error > The other possibility is that you have a broken "mixed" installation of > org. This can easily occur if org is upgraded when it has already been > loaded into the Emacs instance when the upgrade is performed. I upgraded the package using `emacs -Q` and I only use GNU ELPA as a package source. I think that in my case the package installation was clean. Thanks, Morgan
Re: [BUG] ox-md image captions
Ihor Radchenko writes: > Upon further investigation, I have found that our base MD reference we > follow in ox-md is defining image syntax as the following: > >  > >  > > https://daringfireball.net/projects/markdown/syntax#img > > Therefore, Org mode is doing everything right within the scope of MD > specification we follow. Pandoc does not. I don't think that Markdown has a single specification. Perhaps it is a bug that ox-md is not following a specification, and this would be fixed by using a specification and passing its test suite: https://commonmark.org/ However, if ox-md is intentionally trying to match the behaviour of the original Markdown.pl, the Pandoc format that matches this is "markdown_strict" and not "markdown". i.e. Pandoc's "markdown" format is not the same format which is described at daringfireball.net: https://pandoc.org/MANUAL.html#pandocs-markdown -- Morgan Willcock
Re: [BUG] ox-md image captions
Ihor Radchenko writes: > Please provide concrete examples where ox-md does not follow > specification. > > The title/caption issue herein does not qualify. > https://spec.commonmark.org/0.30/#images also defines >  with "title" being the title, as we currently use > it in ox-md when exporting captions. If ox-md is trying to do the same thing as Markdown.pl then it doesn't really make sense to compare it to CommonMark. The only point am I trying to make is that both ox-md and Pandoc need to deal in the same unambiguous specification in order to inter-operate. For Pandoc, the matching specification needs to be selected to ensure that the correct one is used, but nothing based on Markdown.pl can be unambiguous in this scenario because Markdown.pl has no unambiguous specification. -- Morgan Willcock
Re: ob-shell: proposal to remove "posh"
Matt writes: > AFAIKT, both PowerShell and cmd are MIT licensed: > - https://github.com/microsoft/terminal > - https://github.com/PowerShell/PowerShell > > The thought of compiling either for a GNU system is...ugh. But maybe someone > else has gotten them working? Otherwise, it looks like Microsoft distributes > a developer VM image of Windows. > > All together, this means there's no *technical* barrier preventing us from > running (and hence developing for) PowerShell or cmd. As I understand it, the code for the cmd.exe shell is not released anywhere. What is in the "terminal" repository mentioned above is the code for the console host process conhost.exe, which is the server process used to host the shell process and present it (i.e. this is the terminal and not the shell). That said, I imagine Wine does contain its own implementation of cmd.exe, although I wouldn't expect it to be 100% compatible with the real thing. -- Morgan Willcock
[BUG] Flyspell triggers "Warning (org-element-cache): org-element--cache" [9.6.18 ( @ /home/mwillcock/.emacs.d/elpa/org-9.6.18/)]
I've managed to trigger this a couple of times over the last few days, both times the backtrace began by calling flyspell functions. I'm not sure how to re-create the problem, but I thought it best to report it just in case anyone else is seeing the same thing. ⛔ Warning (org-element-cache): org-element--cache: Org parser error in filename.org::354737. Resetting. The error was: (error "Invalid search bound (wrong side of point)") Backtrace: " backtrace-to-string(nil) org-element-at-point() org-back-to-heading(t) org-back-to-heading-or-point-min(t) org-get-property-block() org--property-local-values(\"LOG_INTO_DRAWER\" t) org-entry-get-with-inheritance(\"LOG_INTO_DRAWER\" t) org-entry-get(nil \"LOG_INTO_DRAWER\" inherit t) org-log-into-drawer() org-mode-flyspell-verify() flyspell-word() flyspell-post-command-hook() " Please report this to Org mode mailing list (M-x org-submit-bug-report). Emacs : GNU Emacs 29.2 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2024-01-18 Package: Org mode version 9.6.18 ( @ /home/mwillcock/.emacs.d/elpa/org-9.6.18/)
Re: [BUG] Flyspell triggers "Warning (org-element-cache): org-element--cache" [9.6.18 ( @ /home/mwillcock/.emacs.d/elpa/org-9.6.18/)]
Ihor Radchenko writes: > Morgan Willcock writes: > >> I've managed to trigger this a couple of times over the last few days, >> both times the backtrace began by calling flyspell functions. I'm not >> sure how to re-create the problem, but I thought it best to report it >> just in case anyone else is seeing the same thing. >> >> ⛔ Warning (org-element-cache): org-element--cache: Org parser error in >> filename.org::354737. Resetting. >>The error was: (error "Invalid search bound (wrong side of point)") >> ... >> Package: Org mode version 9.6.18 ( @ >> /home/mwillcock/.emacs.d/elpa/org-9.6.18/) > > Thanks for reporting! > Would you be able to upgrade to the development version of Org mode and > test if the warning disappear? I would be willing to for diagnostic purposes (presumably I would just make sure the development version is earlier in the load-path?) but it would be tricky to know for sure whether it had made a difference unless I can get a better handle on what triggers it. Are there already changes in the development version which you think would be relevant to this problem? -- Morgan Willcock
Re: [PATCH] `org-ctags-create-tags` creates empty TAGS file [9.6.15 (release_9.6.15 @ /home/martin/Projects/emacs/lisp/org/)]
Ihor Radchenko writes: > Martin Marshall writes: > >> Hi, the docstring of `org-ctags-create-tags` says it should "(Re)create >> tags file in the directory of the active buffer," creating tags from the >> internal links found in the org files. However, it always creates an >> empty TAGS file. >> >> The cause appears to be a pair of escaped quotes used with >> `shell-command` when it calls the "ctags" executable. >> ... >> I've attached a patch against the current Emacs master branch. I hope >> that's sufficient, given the minimal nature of the change. > > Thanks! > Applied, onto main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=981402a93 Doesn't this change mean that it will now break when the expanded path has whitespace characters in it? The shell expansion should work if the asterisk is outside of the quotes. I've attached an (untested) patch to explain what I mean. -- Morgan Willcock >From b5f52034b693175df2ec057cb5e9e4de55e70078 Mon Sep 17 00:00:00 2001 From: Morgan Willcock Date: Sat, 10 Feb 2024 21:02:30 + Subject: [PATCH] org-ctags.el: Quote directory name for "ctags" shell command * lisp/org-ctags.el (org-ctags-create-tags): Expand the quoted form of the directory name in the "ctags" shell command. This allows the directory name to contain whitespace characters. --- lisp/org-ctags.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el index 693ccc87b..49c1d1228 100644 --- a/lisp/org-ctags.el +++ b/lisp/org-ctags.el @@ -484,11 +484,11 @@ defun org-ctags-create-tags (setq exitcode (shell-command (format (concat "%s --langdef=orgmode --langmap=orgmode:.org " - "--regex-orgmode=\"%s\" -f \"%s\" -e -R %s") + "--regex-orgmode=\"%s\" -f \"%s\" -e -R \"%s\"*") org-ctags-path-to-ctags org-ctags-tag-regexp (expand-file-name (concat dir-name "/TAGS")) - (expand-file-name (concat dir-name "/*") + (expand-file-name (concat dir-name "/") (cond ((eql 0 exitcode) (setq-local org-ctags-tag-list -- 2.41.0.windows.3
Re: [BUG] Flyspell triggers "Warning (org-element-cache): org-element--cache" [9.6.18 ( @ /home/mwillcock/.emacs.d/elpa/org-9.6.18/)]
Ihor Radchenko writes: > Morgan Willcock writes: > >>> Would you be able to upgrade to the development version of Org mode and >>> test if the warning disappear? >> >> I would be willing to for diagnostic purposes (presumably I would just >> make sure the development version is earlier in the load-path?) but it >> would be tricky to know for sure whether it had made a difference unless >> I can get a better handle on what triggers it. > > You may refer to https://orgmode.org/manual/Installation.html for > instructions. > >> Are there already changes in the development version which you think >> would be relevant to this problem? > > org-element.el has been changed significantly on main compared to bugfix > branch. I remained on the release version but the problem has not reappeared. Given that the development version has significant changes, and I am not able to get a handle on what causes the problem (I imagine it is a general cache problem and not something caused by flyspell), feel free to close the bug report. -- Morgan Willcock
[BUG] Trailing dash is not included in link [9.7.3 (9.7.3-2f1844 @ /home/mwillcock/.emacs.d/elpa/org-9.7.3/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. When web links are inserted into an org buffer, if the link ends in a trailing dash this seems to be omitted from the link target. i.e. Inserting "https://domain/test-"; into the buffer will create a clickable link for "https://domain/test";. These types of links will likely be encountered for sites where anchor targets are automatically generated from documentation headings which are questions. e.g. https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-faq#how-can-i-roll-over-the-kerberos-decryption-key-of-the--azureadsso--computer-account- It seems straight-forward to verify that the trailing dash of the link is not considered part of the link: (with-temp-buffer (org-mode) (insert "https://domain/test-";) (goto-char (point-min)) (let ((context (org-element-context))) (cl-assert (eq (org-element-type context) 'link)) (buffer-substring-no-properties (org-element-property :begin context) (org-element-property :end context Emacs : GNU Emacs 29.3 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2024-03-25 Package: Org mode version 9.7.3 (9.7.3-2f1844 @ /home/mwillcock/.emacs.d/elpa/org-9.7.3/)
Re: Capture from Firefox to Org-mode
Chris Keschnat writes: >> I have found 2 extensions for capturing to Org-mode from Firefox: >> >> - Org Capture (by Kosta): >> https://addons.mozilla.org/fr/firefox/addon/org-capture/ >> >> - org-protocol (by Wojciech Siewierski): >> https://addons.mozilla.org/fr/firefox/addon/org-protocol/ >> >> Which one do you suggest ? > > I'm using this one instead. > > Extension: https://github.com/Stebalien/org-capture-extension > Image of configured extension: https://0x0.st/XMHN.png > > PS: > I had also used this in the past. If you're willing to have a local > python script listening on a port instead of using org-protocol, > it might be an alternative. > > https://github.com/karlicoss/grasp Just to mention another option, I use this one: https://addons.mozilla.org/en-US/firefox/addon/linkremark/ I took the easy option and just use the default "integration" which uses the clipboard, but I think org-protocol is supported as well. -- Morgan Willcock
org-mode-flyspell-verify: Why skip checking the LOGBOOK?
With org-log-into-drawer set to t any notes that are taken with org-add-note go into a LOGBOOK drawer, but this also removes the spell-checking provided by Flyspell. It seems intentional to prevent checking the LOGBOOK (or equivalent) when the value of org-log-into-drawer is non-nil: ;; Ignore checks in LOGBOOK (or equivalent) drawer. ((let ((log (org-log-into-drawer))) (and log (let ((drawer (org-element-lineage element 'drawer))) (and drawer (org-string-equal-ignore-case log (org-element-property :drawer-name drawer)) nil) ...but why should the location of the note matter to the spell-checker? Is there any way to re-enable spell-checking of the notes without adding advice to org-mode-flyspell-verify to hijack the result? Thanks, Morgan -- Morgan Willcock
Re: org-mode-flyspell-verify: Why skip checking the LOGBOOK?
Ihor Radchenko writes: >> Is there any way to re-enable spell-checking of the notes without adding >> advice to org-mode-flyspell-verify to hijack the result? > > It looks like LOGBOOK drawers should not be ignored by flyspell. > May you comment out that check locally and see how it goes? I switch between computers fairly frequently and the Org versions may not be exactly in sync. Rather than editing the source code or redefining the entire function, would it be acceptable to you if I use the following advice for testing? (advice-add 'org-mode-flyspell-verify :around (lambda (orig-fun &rest args) (let (org-log-into-drawer) (apply orig-fun args > Ideally, please check things like CLOCK and automatic todo state change > notes. Moving over those entries with the advice added, I cannot see any obvious issues, although I imagine some people may see a difference if their todo-keywords are spelled in a way that doesn't match the dictionary being used by Flyspell, e.g. CANCELED vs. CANCELLED. -- Morgan Willcock
Re: [BUG] What about excluding .dir-locals.el from GNU ELPA tarball?
Ihor Radchenko writes: > Lin Jian writes: > >> Currently, the .dir-locals.el file is included in the GNU ELPA >> tarball[1], which causes this compilation error[2] when doing AOT native >> compilation for Emacs lisp packages in NixOS. > > I do not see why anything is wrong on Org side. > .dir-locals.el is a perfectly valid file that may be created by users as > well. The fact that they are native-compiled is probably a bug in NixOS > or a missing feature in Emacs's native compilation (maybe it should skip > compiling dir locals automatically). I believe it is up to the file to opt-out of compilation. If the file is created with add-dir-local-variable there is a boiler plate header inserted which opts out: ;;; Directory Local Variables-*- no-byte-compile: t -*- ;;; For more information see (info "(emacs) Directory Variables") >> We can workaround this by skipping native compilation for >> .dir-locals.el. However, I do not think .dir-locals.el has to be >> included in the GNU ELPA tarball. In addition, MELPA ignores[3] that >> file by default. >> >> Could you exclude .dir-locals.el from GNU ELPA tarball? FYI, >> :ignored-files[4] of GNU ELPA specification can be used to do this. > > Having dir locals file in the tarball can be useful for the users who > wish to edit Org mode's source code. We set a number of editing defaults > there that are employed across Org codebase. These defaults make our > life easier when users create patches by directly modifying Org mode code > they got via ELPA. > > Not a bug. > Canceled. > > I suggest you to report a bug or feature request to Emacs upstream about > native compiling .dir-locals.el. I don't think there is any upstream bug. The solution would be to add the missing header to the .dir-locals.el file. -- Morgan Willcock
[PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
* lisp/ox-ascii.el (org-ascii--justify-lines): Ensure that `indent-tabs-mode' is nil when applying indentation to justify lines. This prevents tab characters from appearing in the export when `indent-tabs-mode' still has its default value of t. TINYCHANGE --- Hi, I've attached a patch to fix an issue where tab characters are generated by the ASCII exporter when `indent-tabs-mode' has its default value of t. Here is a simple test case which generates tabs with 'emacs -Q': (with-temp-buffer (insert "#+TITLE: My Title\n" "#+OPTIONS: author:nil\n" "#+OPTIONS: toc:nil\n") (org-mode) (org-ascii-export-as-ascii) (with-current-buffer "*Org ASCII Export*" (buffer-string))) I haven't gone through the FSF copyright assignment process but I'm assuming this is OK based on the line count. Thanks, Morgan lisp/ox-ascii.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el index d1762d41c..176542661 100644 --- a/lisp/ox-ascii.el +++ b/lisp/ox-ascii.el @@ -480,6 +480,9 @@ HOW determines the type of justification: it can be `left', (insert s) (goto-char (point-min)) (let ((fill-column text-width) + ;; Ensure that `indent-tabs-mode' is nil so that indentation + ;; will always be achieved using spaces rather than tabs. + (indent-tabs-mode nil) ;; Disable `adaptive-fill-mode' so it doesn't prevent ;; filling lines matching `adaptive-fill-regexp'. (adaptive-fill-mode nil)) -- 2.30.2
[PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
* lisp/ox-ascii.el (org-ascii--justify-lines): Ensure that `indent-tabs-mode' is nil when applying indentation to justify lines. This prevents tab characters from appearing in the export when `indent-tabs-mode' still has its default value of t. TINYCHANGE --- Hi, I've attached a patch to fix an issue where tab characters are generated by the ASCII exporter when `indent-tabs-mode' has its default value of t. Here is a simple test case which generates tabs with 'emacs -Q': (with-temp-buffer (insert "#+TITLE: My Title\n" "#+OPTIONS: author:nil\n" "#+OPTIONS: toc:nil\n") (org-mode) (org-ascii-export-as-ascii) (with-current-buffer "*Org ASCII Export*" (buffer-string))) I haven't gone through the FSF copyright assignment process but I'm assuming this is OK based on the line count. Thanks, Morgan lisp/ox-ascii.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el index d1762d41c..176542661 100644 --- a/lisp/ox-ascii.el +++ b/lisp/ox-ascii.el @@ -480,6 +480,9 @@ HOW determines the type of justification: it can be `left', (insert s) (goto-char (point-min)) (let ((fill-column text-width) + ;; Ensure that `indent-tabs-mode' is nil so that indentation + ;; will always be achieved using spaces rather than tabs. + (indent-tabs-mode nil) ;; Disable `adaptive-fill-mode' so it doesn't prevent ;; filling lines matching `adaptive-fill-regexp'. (adaptive-fill-mode nil)) -- 2.30.2
Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
Timothy writes: > Hi Morgan, > >> I’ve attached a patch to fix an issue where tab characters are generated by >> the ASCII exporter when `indent-tabs-mode’ has its default value of t. > > Thanks for finding this bug, fixing it, and sending us it 🙂. I was able to > reproduce your test case with “emacs -Q” (thanks for that, by the way). > As you suspected, with the small number of changed lines, this would be fine > to > accept without FSF assignment. Great! Thank you for taking a look. > However, your “patch” seems to consist of a diff at the bottom of your email > and > a commit message at the top?? It would be preferable if you could provide a > “proper” patch, that way you can get attribution for your help instead of just > someone committing it on your behalf. I used `git send-email` which is listed as being OK on the website: "If you have configured git to use send-email, then you can use that." -- https://orgmode.org/contribute.html The mail can be applied with `git am` and the commit message will be correct. I'm also happy to resend as a separate patch if that is the requirement. Thanks, Morgan
Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
Timothy writes: > Hi Morgan, > > I’ve just taken a look at your patch (it `git am's just fine), since nobody > else > seems to have had the time to look at your patch as of late. There’s one thing > which I now realise completely slipped by me last time — why are tabs bad? > Maybe I’m missing something obvious, but exporting with tabs and > viewing/`cat'ing > the file everything looks fine to me in terms of alignment. Hi Timothy, It seems to default to spaces everywhere else. If you export an actual document through the ascii exporter instead of just a document header you will get a mix of tabs and spaces. This is how it was brought to my attention, I was distributing a file that was batch exported and someone pointed out that the indentation was inconsistent. If it is handled as an export preference or defaults to the global indentation preference then that would be fine but I don't believe either of those are the case. Thanks for continuing to look, Morgan
Re: [BUG] What about excluding .dir-locals.el from GNU ELPA tarball?
Ihor Radchenko writes: >> I believe it is up to the file to opt-out of compilation. > > That's true, but .dir-locals is a special file. So, I expected Emacs to > treat it specially during compilation as well. To not break old, > no-longer-maintained packages, if nothing. I guess the counter argument would be that, if this file doesn't need to compiled, and the error is that compilation of this file fails, then it isn't a critical error. >> If the file is created with add-dir-local-variable there is a boiler >> plate header inserted which opts out: >> >> ;;; Directory Local Variables-*- no-byte-compile: t -*- >> ;;; For more information see (info "(emacs) Directory Variables") >> ... >> ... The solution would be to add >> the missing header to the .dir-locals.el file. > > I do not see any downside of adding this to .dir-locals.el file. > Would you mind submitting a patch? I've attached a patch. (To be fully transparent, I have not verified that applying the patch will prevent errors during native compilation of the ELPA package, but I am pretty confident that the change is a correct one.) -- Morgan Willcock >From 18e55680191e2c803b731750643d3e854134f1a5 Mon Sep 17 00:00:00 2001 From: Morgan Willcock Date: Tue, 17 Sep 2024 18:09:08 +0100 Subject: [PATCH] .dir-locals.el: Disable compilation of .dir-locals.el * .dir-locals.el (org-mode): Add 'no-byte-compile'. --- .dir-locals.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.dir-locals.el b/.dir-locals.el index 9df10dfed..551a831f7 100644 --- a/.dir-locals.el +++ b/.dir-locals.el @@ -1,4 +1,4 @@ -;;; Directory Local Variables +;;; Directory Local Variables-*- no-byte-compile: t -*- ;;; For more information see (info "(emacs) Directory Variables") ((nil -- 2.39.5
