[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
[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 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: 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
[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: [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: > >> 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: 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
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
