Re: Inline src org block element with containing inside item does not get exported when it contains a newline (was: Inline src block element not parsed correctly for export when in a list item)

2022-05-15 Thread Kaushal Modi
On Sat, May 14, 2022 at 5:39 AM Ihor Radchenko  wrote:
>
> I just tried again on the latest main and I cannot reproduce anymore.
> Though I do see the problem on bugfix.
>
> Can you please check again on your side?

I confirm -- I cannot reproduce the bug in Org mode version 9.5.3
(release_9.5.3-482-gd5a52b).

For reference, I tried the same bug recipe from my earlier email:
https://lists.gnu.org/r/emacs-orgmode/2022-03/msg8.html.



Re: [BUG] C-u C-u C-u TAB regression on master

2022-05-12 Thread Kaushal Modi
> Allen Li  writes:
>
> > There appears to be a regression in the behavior of C-u C-u C-u TAB on
> > master (at aea24b3feafb9c389dc5933005928462bb20c4f8).
> >
> > C-u C-u C-u TAB is supposed to show everything including drawers, but on
> > this test file it does not show property drawers:

Thanks for reporting this! I was about to create a report for the same
issue. For me though, this issue persisted regardless of the value of
org-fold-core-style.
But it's fixed now.

On Thu, May 12, 2022 at 9:43 AM Ihor Radchenko  wrote:
> Thanks for reporting!
> Fixed on main via 7dcd15105.

Thanks! I confirm the fix.



Re: source block evaluation in #+DATE line

2022-05-10 Thread Kaushal Modi
Also check out the {{{time}}} macro if you want complete control on
the formatting of the date string.

Example Org snippet:

=
#+date: {{{time(%Y-%m-%d)}}}
#+options: toc:nil author:nil

See the ~{{{time}}}~ macro in [[info:org#Macro Replacement][org#Macro
Replacement]].

The format passed to the ~time~ macro is same as that understood by
[[help:format-time-string]].

- Note :: Remember to escape the commas. \\
  Example: ~#+date: {{{time(%b %e %Y\, %a)}}}~.


#+begin_src emacs-lisp
(org-export-as 'ascii)
#+end_src
=



Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

2022-05-10 Thread Kaushal Modi
On Mon, May 9, 2022 at 5:44 PM Kaushal Modi  wrote:
>
> I have now sent this to Emacs bug tracking:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342

Thanks for the debug[1] Ihor!

This issue was quickly fixed on Emacs master in
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d221c02fa1db17e1275687f0bbce4ff1499119a1.

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342#11



bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil

2022-05-10 Thread Kaushal Modi
done 55342

On Tue, May 10, 2022 at 1:06 AM Lars Ingebrigtsen  wrote:
>
> Ihor Radchenko  writes:
>
> > The code above always skips a bibtex entry starting at bob.
> > Hence, the provided example bibliography is parsed as empty, which is
> > not expected by Org.
>
> This should now be fixed on the trunk.

Thanks! I confirm the fix.





Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

2022-05-09 Thread Kaushal Modi
I have now sent this to Emacs bug tracking:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342



Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

2022-05-09 Thread Kaushal Modi
On Mon, May 9, 2022 at 10:21 AM Kaushal Modi  wrote:
> Can someone using emacs
> built from master branch confirm that they see this same error when
> `org-cite-process-bibliography` is called? It should be reproducible
> without using ox-hugo too.


Alright I was able to confirm this possibly upstream bug on Emacs 29
after building it from source.

Here's a minimal test recipe:

=
#+title: "Wrong value for ENTRY-OR-KEY: nil" error on Emacs 29

#+bibliography: test.bib

#+begin_src bib :tangle test.bib
@article{Foo,
 author={Bar},
 journal={Zoo},
 title={Foo by Bar},
 year={2021}}
#+end_src

[cite:@Foo]

#+print_bibliography:

Evaluate the below code block.

#+begin_src emacs-lisp :results none
(org-babel-tangle)
(org-export-as 'ascii)
#+end_src
=

1. Open the above file in Emacs.
2. Run C-c C-c in that emacs-lisp code block

On Emacs 28: No error
On Emacs 29: org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil



oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

2022-05-09 Thread Kaushal Modi
On Thu, Nov 25, 2021 at 6:21 AM juh  wrote:
> With cite_export: basic I get
>
> Wrong value for ENTRY-OR-KEY: nil

Hello,

I saw the ox-hugo CI fail with emacs master (29.0.50) over the past
few days with this backtrace, but this error is probably not related
to ox-hugo, and I need help confirming if that's the case.


=

  signal(error ("Wrong value for ENTRY-OR-KEY: nil"))
  error("Wrong value for ENTRY-OR-KEY: %S" nil)
  org-cite-basic--get-field(author nil (:export-options (subtree)
:back-end #s(org-export-backend :name hugo :parent blackfriday
:transcoders ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . org-hugo-export-block)
(export-snippet . org-hugo-export-snippet) (headline .
org-hugo-heading) (inner-template . org-hugo-inner-template)
(inline-src-block . org-hugo-inline-src-block) (keyword .
org-hugo-keyword) (link . org-hugo-link) (paragraph .
org-hugo-paragraph) (src-block . org-hugo-src-block) (special-block .
org-hugo-special-block)) :options ((:with-toc nil "toc"
org-hugo-export-with-toc) (:section-numbers nil "num"
org-hugo-export-with-section-numbers) (:author "AUTHOR" nil
user-full-name newline) (:creator "CREATOR" nil
org-hugo-export-creator-string) (:with-smart-quotes nil "'" nil)
(:with-special-strings nil "-" nil) (:with-sub-superscript nil "^"
...) (:hugo-with-locale "HUGO_WITH_LOCALE" nil nil)
(:hugo-front-matter-format "HUGO_FRONT_MATTER_FORMAT" nil
org-hugo-front-matter-format) (:hugo-level-offset "HUGO_LEVEL_OFFSET"
nil "1") (:hugo-preserve-filling "HUGO_PRESERVE_FILLING" nil
org-hugo-preserve-filling) (:hugo-delete-trailing-ws
"HUGO_DELETE_TRAILING_WS" nil org-hugo-delete-trailing-ws)
(:hugo-section "HUGO_SECTION" nil org-hugo-section) (:hugo-bundle
"HUGO_BUNDLE" nil nil) (:hugo-base-dir "HUGO_BASE_DIR" nil
org-hugo-base-dir) (:hugo-goldmark "HUGO_GOLDMARK" nil
org-hugo-goldmark) (:hugo-code-fence "HUGO_CODE_FENCE" nil t)
(:hugo-use-code-for-kbd "HUGO_USE_CODE_FOR_KBD" nil
org-hugo-use-code-for-kbd) (:hugo-prefer-hyphen-in-tags
"HUGO_PREFER_HYPHEN_IN_TAGS" nil org-hugo-prefer-hyphen-in-tags)
(:hugo-allow-spaces-in-tags "HUGO_ALLOW_SPACES_IN_TAGS" nil
org-hugo-allow-spaces-in-tags) (:hugo-auto-set-lastmod
"HUGO_AUTO_SET_LASTMOD" nil org-hugo-auto-set-lastmod)
(:hugo-custom-front-matter "HUGO_CUSTOM_FRONT_MATTER" nil nil space)
(:hugo-blackfriday "HUGO_BLACKFRIDAY" nil nil space)
(:hugo-front-matter-key-replace "HUGO_FRONT_MATTER_KEY_REPLACE" nil
nil space) (:hugo-date-format "HUGO_DATE_FORMAT" nil
org-hugo-date-format) (:hugo-paired-shortcodes
"HUGO_PAIRED_SHORTCODES" nil org-hugo-paired-shortcodes space)
(:hugo-pandoc-citations "HUGO_PANDOC_CITATIONS" nil nil)
(:bibliography "BIBLIOGRAPHY" nil nil newline) (:html-container
"HTML_CONTAINER" nil org-hugo-container-element)
(:html-container-class "HTML_CONTAINER_CLASS" nil "") (:hugo-aliases
"HUGO_ALIASES" nil nil space) (:hugo-audio "HUGO_AUDIO" nil nil) ...)
:filters ((:filter-body . org-hugo-body-filter)) :blocks nil :menu (72
"Export to Hugo-compatible Markdo..." (... ... ... ... ... ...)))
:translate-alist ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . org-hugo-export-block)
(export-snippet . org-hugo-export-snippet) (headline .
org-hugo-heading) (inner-template . org-hugo-inner-template)
(inline-src-block . org-hugo-inline-src-block) (keyword .
org-hugo-keyword) (link . org-hugo-link) (paragraph .
org-hugo-paragraph) (src-block . org-hugo-src-block) (special-block .
org-hugo-special-block) (center-block . org-blackfriday-center-block)
(example-block . org-blackfriday-example-block) (fixed-width .
org-blackfriday-fixed-width) (footnote-reference .
org-blackfriday-footnote-reference) (inner-template .
org-blackfriday-inner-template) (italic . org-blackfriday-italic)
(item . org-blackfriday-item) (latex-environment .
org-blackfriday-latex-environment) (latex-fragment .
org-blackfriday-latex-fragment) (line-break . org-html-line-break)
(plain-list . org-blackfriday-plain-list) (plain-text .
org-blackfriday-plain-text) (quote-block .
org-blackfriday-quote-block) (radio-target .
org-blackfriday-radio-target) (special-block .
org-blackfriday-special-block) (src-block . org-blackfriday-src-block)
(strike-through . org-blackfriday-strike-through) (table-cell .
org-blackfriday-table-cell) (table-row . org-blackfriday-table-row)
(table . org-blackfriday-table) ...) :exported-data # :input-buffer "*Ox-hugo Pre-processed all-posts..."
:input-file "/home/runner/work/ox-hugo/ox-hug..." :with-toc nil
:section-numbers nil :author "" :creator "Emacs + Org mode + ox-hugo"
:with-smart-quotes nil :with-special-strings nil :with-sub-superscript
{} :hugo-with-locale nil :hugo-front-matter-format "toml"
:hugo-level-offset "1" ...))
  org-cite-basic--print-entry(nil nil (:export-options (subtree)
:back-end #s(org-export-backend :name hugo :parent blackfriday
:transcoders ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . 

Re: [BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too

2022-04-28 Thread Kaushal Modi
On Thu, Apr 28, 2022 at 10:44 AM Ihor Radchenko  wrote:

> I am not going to fix this just yet unless it is critical. It does not
> look like this bug is common.

It's not time-critical, but it would be good to fix this bug. It's not
just the Org link syntax.. any Org markup is fontified inside the src
blocks. Here's a screenshot (attached) that shows the bold
fortification happen in the src block as well.

> This and other fontification issues will be solved by new parser-based
> fontification engine I am working on now.

If it is planned to be fixed before the next major release of Org,
it's OK. Thanks for working on this!


[BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too

2022-04-27 Thread Kaushal Modi
Hello,

With the default value of the new org-fold-core-style, if I have a
snippet like below:

#+begin_src toml
[[asdf]]
#+end_src

The brackets around asdf get hidden. ([[asdf]] is TOML syntax for maps
or array of tables: https://toml.io/en/v1.0.0#array-of-tables)

If I change org-fold-core-style to overlays, and refresh that Org
buffer, I see the square brackets around asdf in the src block (as
expected).

Org mode version 9.5.3 (release_9.5.3-458-g1ed9e4)

--
Kaushal Modi



Difference seen in org-version strings when built from git

2022-04-23 Thread Kaushal Modi
On Fri, Dec 17, 2021 at 11:34 PM Ihor Radchenko  wrote:
>
> Kaushal Modi  writes:
>
> > I actually run a wrapper script to update Org and that has all that:
> > ...
> > I verified that at least the git hash was latest as of then:
> > release_9.5-364-g*de022e*
>
> Odd. Though the commit number is indeed correct.

I figured out this mystery ..

>From the org-fixup function in mk/org-fixup.el, I saw that the "git
describe .." command is used to derive the Org version with git hash.
That bakes in the last tag + number of commits seen since that tag in
the org-version returned string.

Turns out that I was simply doing a pull of the main branch and
building Org all this time. I wasn't fetching all the tags!

I saw the version as "release_9.5-364-gde022e". That meant that
"release_9.5" happened to be the last fetched tag in my local repo
back then.

Fix was simple.. I had to do "git fetch --all" before building Org.



[PATCH] Fix inf-loop due to org-eldoc when point is in an org src block

2022-04-23 Thread Kaushal Modi
Hello all,

The patches attached in this email fix the issue reported in
https://lists.gnu.org/r/emacs-orgmode/2022-04/msg00373.html. They are
based off the master branch of https://git.sr.ht/~bzg/org-contrib.

patch 1: Minor cleanup in the function that I am touching for the fix
in patch 2: re-indent, untabify
patch 2: Fix for the inf-loop

Can someone please review and apply these patches to the org-contrib repo?
[I am unable to commit using ssh/git: protocol (only https is allowed)
based on the network restrictions at work.]

Thanks!

--
Kaushal Modi


0001-lisp-org-eldoc.el-Whitespace-change.patch
Description: Binary data


0002-lisp-org-eldoc.el-Fix-inf-loop-when-point-in-org-src.patch
Description: Binary data


[BUG] org-eldoc inf-loops when point is in an org src block

2022-04-23 Thread Kaushal Modi
c-print-current-symbol-info ((string= lang "css")
(if (require 'css-eldoc nil t) (progn (css-eldoc-function
((string= lang "php") (if (require 'php-eldoc nil t) (progn
(php-eldoc-function ((or (string= lang "go") (string= lang
"golang")) (if (require 'go-eldoc nil t) (progn
(go-eldoc--documentation-function (t (let ((doc-fun
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car
args))) (if (functionp doc-fun) (progn (if (functionp callback)
(funcall doc-fun callback) (funcall doc-fun)))
  (let ((lang (org-eldoc-get-src-lang))) (cond ((or (string= lang
"emacs-lisp") (string= lang "elisp")) (cond ((and (boundp
'eldoc-documentation-functions) (fboundp 'elisp-eldoc-var-docstring)
(fboundp 'elisp-eldoc-funcall)) (let ((eldoc-documentation-functions
...)) (eldoc-print-current-symbol-info))) ((fboundp
'elisp-eldoc-documentation-function)
(elisp-eldoc-documentation-function)) (t (let
(eldoc-documentation-function) (eldoc-print-current-symbol-info)
((or (string= lang "c") (string= lang "C")) (if (require 'c-eldoc nil
t) (progn (c-eldoc-print-current-symbol-info ((string= lang "css")
(if (require 'css-eldoc nil t) (progn (css-eldoc-function
((string= lang "php") (if (require 'php-eldoc nil t) (progn
(php-eldoc-function ((or (string= lang "go") (string= lang
"golang")) (if (require 'go-eldoc nil t) (progn
(go-eldoc--documentation-function (t (let ((doc-fun
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car
args))) (if (functionp doc-fun) (progn (if (functionp callback)
(funcall doc-fun callback) (funcall doc-fun
  (or (org-eldoc-get-breadcrumb) (org-eldoc-get-src-header) (let
((lang (org-eldoc-get-src-lang))) (cond ((or (string= lang
"emacs-lisp") (string= lang "elisp")) (cond ((and (boundp ...)
(fboundp ...) (fboundp ...)) (let (...)
(eldoc-print-current-symbol-info))) ((fboundp
'elisp-eldoc-documentation-function)
(elisp-eldoc-documentation-function)) (t (let
(eldoc-documentation-function) (eldoc-print-current-symbol-info)
((or (string= lang "c") (string= lang "C")) (if (require 'c-eldoc nil
t) (progn (c-eldoc-print-current-symbol-info ((string= lang "css")
(if (require 'css-eldoc nil t) (progn (css-eldoc-function
((string= lang "php") (if (require 'php-eldoc nil t) (progn
(php-eldoc-function ((or (string= lang "go") (string= lang
"golang")) (if (require 'go-eldoc nil t) (progn
(go-eldoc--documentation-function (t (let ((doc-fun
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car
args))) (if (functionp doc-fun) (progn (if ... ... ...
  org-eldoc-documentation-function(#f(compiled-function (string 
plist) #))
=


Recipe to create this error:
1. Create a file test.org with these contents:

#+begin_src org
,#+html: foo
#+end_src

2. emacs -Q
3. Load/evaluate org-eldoc.el from
https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/org-eldoc.el
4. Open the test.org file and place the point *inside* the org src block
5. eldoc error: (error Lisp nesting exceeds ‘max-lisp-eval-depth’)

-

Upon inspecting the `org-eldoc-documentation-function` function, I
don't see a reason why the control should enter the default of `t'
case if the src lang is "org". Just returning with nil works for me if
the lang is "org". I will send a patch for this in a follow-up email.

--
Kaushal Modi



Re: What's the flow for adding info: links in Org documents?

2022-04-15 Thread Kaushal Modi
On Wed, Apr 13, 2022 at 7:38 AM Max Nikulin  wrote:
>
> On 13/04/2022 01:26, Kaushal Modi wrote:
> > On Mon, Apr 11, 2022 at 10:57 AM Max Nikulin wrote:
> >
> >> There are a some problems with info links outside of Emacs:
> >> - Export to PDF
> >
> > Yeah, I recently realized that I will need to add custom support for
> > exporting info: links using ox-hugo. I made a small blog post out of
> > this learning: https://scripter.co/linking-and-exporting-org-info-links/.
>
> I would prefer
>  info "(org) Top"
> to
>  Org Info: Top
> since the former may be pasted to M-x : or to shell command prompt. And
> the link target ideally should be https://orgmode.org/manual/index.html
> Unfortunately there is no way to customize mapping of documents.
>
> >> - Links to single page manuals as the result of export to HTML. E.g.
> >> Emacs manual is really huge
> >
> > I did not understand this. The HTML exports convert an Info node to a
> > hyperlink of the same manual page online.
>
> For  export to html produces the following link:
> https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Browse_002dURL
> I think, a better variant is
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Browse_002dURL.html
> even though for the Org manual I often prefer single-page HTML version.

Thanks for your feedback! I absorbed almost all of it into ox-hugo and
wrote about it in a followup blog post:
https://scripter.co/improving-ox-hugo-exported-org-info-links/.

You'll see the update info: link examples on that post.



Re: What's the flow for adding info: links in Org documents?

2022-04-12 Thread Kaushal Modi
On Mon, Apr 11, 2022 at 10:57 AM Max Nikulin  wrote:

> There are a some problems with info links outside of Emacs:
> - Export to PDF

Yeah, I recently realized that I will need to add custom support for
exporting info: links using ox-hugo. I made a small blog post out of
this learning: https://scripter.co/linking-and-exporting-org-info-links/.

> - Links to single page manuals as the result of export to HTML. E.g.
> Emacs manual is really huge

I did not understand this. The HTML exports convert an Info node to a
hyperlink of the same manual page online.

> - info: is a registered scheme, but not for texinfo.
>https://www.rfc-editor.org/rfc/rfc4452.html
>RFC 4452 - The "info" URI Scheme for Information Assets



Re: #+latex_header blocks, or, managing lots of LaTeX headers

2022-04-12 Thread Kaushal Modi
On Mon, Apr 11, 2022 at 10:53 PM Vikas Rawal  wrote:
>
> For a major project like this, I would just put these in a separate file, and 
> include it using #+INCLUDE:

Org has a special keyword for the purpose of including *just the setup
stuff*: #+setupfile

See (org) Export Settings.

#+include is useful when you want to include setup stuff mixed with Org content.

#+setupfile will include only the setup stuff. I think that would mean
only the Org keywords (lines beginning with #+) will be imported.
Additionally, #+setupfile keyword can accept either a file path or a
web URL.

So I have this at the top of many of my Org files:

#+setupfile: 
https://cdn.rawgit.com/kaushalmodi/.emacs.d/master/misc/org-setupfile.org

That file has my common setup stuff like LaTeX headers, Org macros, etc.



Re: What's the flow for adding info: links in Org documents?

2022-04-11 Thread Kaushal Modi
On Mon, Apr 11, 2022 at 8:35 AM Kaushal Modi  wrote:

> I believe I am missing out something basic with inserting info: links
> in Org documents.

Yes, I was missing out on something :)

To my future self:

1. When in Info buffer, do M-x org-store-link (typically a user binds
this to C-c l: https://orgmode.org/manual/Activation.html ). The link
gets copied in the [[info:MANUAL#NODE]] format.
2. In Org buffer, do C-c C-l to insert that last stored link.



What's the flow for adding info: links in Org documents?

2022-04-11 Thread Kaushal Modi
Hello all,

I believe I am missing out something basic with inserting info: links
in Org documents.

The info links look like:

[[info:org#External links]]

But if I am on that Info node and I hit `w' to copy the node
reference, this gets copied: "(org) External Links"

So when I insert a link in Org, it goes like this:

1. Type "[[info:"
2. Paste the Info node ref, so that I get "[[info:(org) External Links"
3. Refactor that to make it parseable by ol-info: "[[info:org#External Links]]"

I can locally advice the `org-info-export' so that "[[info:(org)
External Links]]" would work as well. But I think I am missing out on
some flow that would make the above manually editing in step 3
unnecessary.

How do you insert info: links efficiently?

--
Kaushal Modi



Re: How to handle strings with commas in macros?

2022-04-07 Thread Kaushal Modi
On Thu, Apr 7, 2022 at 12:30 PM William Denton  wrote:

> I'm using macros to format names in a LaTeX export, like so:
>
> on export and LaTeX will format it.  That works fine.  But in an index of
> names,
> if I want
>
> {{{m(Denton, William)}}}
>
> then Org takes that as two arguments to the macro, and outputs
>
> \m{Denton}
>
> Is there a way to get around this?
>

The comma needs to be backslash escaped.

{{{m(Denton\, William)}}}

Ref: (org) Macro Replacement

> (1) Since commas separate the arguments, commas within arguments have
to be escaped with the backslash character.  So only those backslash
characters before a comma need escaping with another backslash
character.


Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?

2022-04-04 Thread Kaushal Modi
On Mon, Apr 4, 2022 at 10:34 AM  wrote:

>
> I would like to know why does a list need 2 blank lines instead of 1?
> For what reason exists this rule?
>

- 1 blank line in a list item with create a paragraph break as I showed in
my example earlier. It will not end the list item or list.
- So we need 2 blank lines if we mean to end the list.


Example:

- list 1 item 1

  second paragraph in list 1 item 1
- list 1 item 2


- list 2 item 1 because there are 2 blank lines before this item.


Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?

2022-04-03 Thread Kaushal Modi
On Mon, Apr 4, 2022, 12:06 AM Ihor Radchenko  wrote:

>
> I think your examples are a bit misleading.


I have the indentations correct in my three examples.

A list item continues until
> there are _2_ blank lines or until the subsequent line is not indented >=
> current list item indentation:
>

The whole list ends after 2 blank lines. But I didn't demonstrate this rule
in my examples. I was just focusing on plain single new line char vs a
blank line (2 consecutive newlines) in my examples.

1. list item 1
> not a list item because it not indented
> 2. completely new list
>
> Also,
>
> 1. list item 1
>
>Still a list item - new paragraph inside the list
>
>
>Indented, but not a list item because there are two blank lines above
>
> Everything is described in the manual. See
> https://orgmode.org/manual/Plain-Lists.html#Plain-Lists


+1

>
>


Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?

2022-04-03 Thread Kaushal Modi
On Sun, Apr 3, 2022, 4:29 PM  wrote:

> Hello togehter,
>
> is it usual to have auto-fill-mode (automatic new-line after n
> characters) turned on in org or org-roam (including fill-column set e.g.
> to 80)?
>

I cannot comment on that. Enabling auto-fill-mode is user preference.

Or let me ask from another point of view: Is it usual to have multiline
> list entries?
>

Yes, if auto-fill-mode is enabled in org-mode.

I know that org is not markdown but I tried some markdown editors to
> test it. They still recognize the linebreak in my first example and
> rendered it "correct" as a 3 item list.
> I checked the syntax docu [1] about it but I couldn't find a hint or
> didn't understand.
>
> Do I understand it correct that the end of a list is marked by an empty
> line?
>

Yes. I think that the list items follow the same rules as Paragraphs [1]
i.e. A list item continues until it sees a blank line. This is identical to
Markdown.

Below, you have 2 list items:

- item 1
- item 2

Below is also 2 list items:

- item 1
  item 1 continued
- item 2

Below is also 2 list items, but the first item has 2 paragraphs:

- item 1

  second paragraph in item 1
- item 2

I hope that helps.

[1]: https://orgmode.org/manual/Paragraphs.html#Paragraphs


Re: Inline src block element not parsed correctly for export when in a list item

2022-03-16 Thread Kaushal Modi
Hello,

Just pinging here again. Can someone confirm this bug?

--
Kaushal Modi

On Tue, Mar 1, 2022, 10:10 PM Kaushal Modi  wrote:

> Hello,
>
> I believe I have come across a corner case issue where the inline src
> block element doesn't get parsed as one, if:
>
> 1. That src block is in a list item (plain list, definition list, etc.),
> AND
> 2. That src block wraps around when auto-filling.
>
> This issue can be reproduced on the main branch:
>
> Org mode version 9.5 (release_9.5-505-gef666)
>
> MWE:
>
> =
> #+author:
> #+options: toc:nil
>
> Run ~C-c C-e t A~.
>
> * Doesn't export correctly if inline src block is in a wrapped list
> - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
>   def][bar]]}.
> * Exports correctly
> ** .. if the inline src block wraps in a paragraph
> abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
> def][bar]]}.
> ** .. if the inline src block is in a list but doesn't wrap
> - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc def][bar]]}.
> =
>
> Upon pasting the above snippet in an Org buffer and running `C-c C-e t
> A`, I get:
>
> =
> Run `C-c C-e t A'.
>
>
> 1 Doesn't export correctly if inline src block is in a wrapped list
> ===
>
>   - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
>   def][bar]]}.
>
>
> 2 Exports correctly
> 
>
> 2.1 .. if the inline src block wraps in a paragraph
> ~~~
>
>   abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.
>
>
> 2.2 .. if the inline src block is in a list but doesn't wrap
> 
>
>   - abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.
> =
>
>
> Note that incorrect export of the inline src block in section 1 above.
> The remaining sections exports correctly because either the inline src
> block is not in a list item, or it doesn't wrap to the next line.
>
> --
> Kaushal Modi
>


Possible bug in `org-subtree--get-subtree-options`?

2022-03-14 Thread Kaushal Modi
Hello Nicolas,

Today I was debugging something where a subtree export wasn't recognizing
the EXPORT_OPTIONS property set in that subtree.

MWE:

=
* Top level
** Allow broken links, but mark them
:PROPERTIES:
:EXPORT_FILE_NAME: allow-broken-links-but-mark-them
:EXPORT_OPTIONS: broken-links:mark
:END:
=

1. Move cursor to BOL of "** Allow broken links, but mark them" line.
2. M-: (org-export--get-subtree-options)

Output:

(:title (#("Top level" 0 9 (:parent #1

Issue: Point is already on a heading, but it is jumping to the parent
heading and returning that heading's properties.

Debugging through how the export options got parsed in subtree exports, I
reached the `org-export--get-subtree-options' function and this line in
there:

;;
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox.el#n1425
(if (org-at-heading-p) (org-up-heading-safe) (org-back-to-heading t))

It looks like the if condition actions are swapped here.

Should it be:

(if (org-at-heading-p) (org-back-to-heading t) (org-up-heading-safe))
;; If point is in a heading, just go to the BOL  (org-back-to-heading t)
;; Otherwise, jump up to a parent-heading if available.

If I evaluate that function after updating that if condition as above and
redo the steps I mentioned above, the output is now what I expect:

(:with-broken-links mark :title (#("Allow broken links, but mark them" 0 33
(:parent #1

I am only surprised that this line has been there at least since 2015.

Thanks!

--
Kaushal Modi


Re: Code blocks and quotes export style

2022-03-13 Thread Kaushal Modi
On Sun, Mar 13, 2022, 6:55 AM Sébastien Gendre  wrote:

> Hello everyone. _o/
>
> When I export an Org file to LaTeX and finally PDF, the code blocks and
> quotes often exceed the width of the page.
>

Hello _o/

I fixed[1] that problem by using the LaTeX minted package that allows
wrapping around the lines using its "breaklines" option.

Well, that will at least help the code blocks going out of bounds. It won't
help the quotes.

Note that I added that to my Org mode config more than 6 years back or
something. So there might be a better way to do the same but that setup
still works! :)

[1]:
https://github.com/kaushalmodi/.emacs.d/blob/c643684ad675753c69df602d7298241d05173255/setup-files/setup-org.el#L941-L972

>


Re: Unable to resolve link; aborting: "roam:git"

2022-03-13 Thread Kaushal Modi
On Sun, Mar 13, 2022, 8:23 AM  wrote:

> In real I (try to) use ox-hug to export my org-files (org-roam-v2) to
> markdown (and later to HTML).
>
> After analyzing the my debug output [1] the ox-hugo people pointed me to
> org-roam community because the error is "thrown" (correct term in
> emas-lisp=?) by "org-export-resolve-fuzzy-link".
>

After revisiting this, I believe, this is something that needs to be fixed
in ox-hugo as it is calling org-export-resolve-fuzzy-link directly without
handling the broken link error.

I'll try to fix it in the next week.

>


Re: org-roam to HTML: My needs are unusual?

2022-03-11 Thread Kaushal Modi
Hello Christian,

tl;dr: If you decide to learn how to use Hugo (read its docs, ask questions
on its forum, etc.), this[1] should solve the issues you have faced so far.

---

Details:

On Fri, Mar 11, 2022 at 7:04 AM  wrote:

>
> ox-hugo with hugo is often mentioned in the context. But ox-hugo is not
> able to export everything out-of-the-box [2].
> [2] -- 


Correct, because it is not the job of `ox-hugo` to figure out how the user
needs to export all the Org files. I see users coming with various
use-cases; it is out of scope of my free time to attempt to support all of
that in the ox-hugo package:

- How to export only the Org files that already have the Markdown exported?
- How to export Org files written for  package?
- This didn't work on Windows.
- etc.

So I encourage the users to attempt to learn a bit of elisp or Makefile or
bash to do this batch exporting for them. I have posted one solution to
this here[4], but I won't be surprised if this solution is not exactly what
someone wants (for example, that solution does not update the org-id
locations from everywhere a user has their Org files).


And the HTML files
> generated by hugo are not usable via the file:// protocol without some
> hacks [3].
> [3] -- 
>

Those are not hacks; those are Hugo switches a user can use to generate the
kind of HTML they need (with or without ugly URLs, with or without relative
URLs, with or without RSS, so on and so forth).

[1]:
https://github.com/kaushalmodi/ox-hugo/discussions/585#discussioncomment-2339756
[4]:
https://github.com/kaushalmodi/ox-hugo/discussions/585#discussioncomment-2335203


Inline src block element not parsed correctly for export when in a list item

2022-03-01 Thread Kaushal Modi
Hello,

I believe I have come across a corner case issue where the inline src
block element doesn't get parsed as one, if:

1. That src block is in a list item (plain list, definition list, etc.), AND
2. That src block wraps around when auto-filling.

This issue can be reproduced on the main branch:

Org mode version 9.5 (release_9.5-505-gef666)

MWE:

=
#+author:
#+options: toc:nil

Run ~C-c C-e t A~.

* Doesn't export correctly if inline src block is in a wrapped list
- abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
  def][bar]]}.
* Exports correctly
** .. if the inline src block wraps in a paragraph
abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
def][bar]]}.
** .. if the inline src block is in a list but doesn't wrap
- abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc def][bar]]}.
=

Upon pasting the above snippet in an Org buffer and running `C-c C-e t
A`, I get:

=
Run `C-c C-e t A'.


1 Doesn't export correctly if inline src block is in a wrapped list
===

  - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
  def][bar]]}.


2 Exports correctly


2.1 .. if the inline src block wraps in a paragraph
~~~

  abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.


2.2 .. if the inline src block is in a list but doesn't wrap


  - abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.
=


Note that incorrect export of the inline src block in section 1 above.
The remaining sections exports correctly because either the inline src
block is not in a list item, or it doesn't wrap to the next line.

--
Kaushal Modi



Re: Inconsistent handling of multi-line properties

2022-02-28 Thread Kaushal Modi
On Mon, Feb 28, 2022 at 3:34 PM Kaushal Modi  wrote:
>
> On Sat, Oct 2, 2021 at 11:03 AM Hanno Perrey  wrote:
> >
> > Hej,
> >
> > I have noticed that properties that stretch over multiple lines using
> > the :value+: syntax are ignored by org-element-property and therefore
> > also by e.g. org-export-get-node-property when exporting to ics via
> > ox-icalendar.el (see example below). I was wondering now whether this is
> > intentional and to be expected or a bug?
>
> I use the :value+: syntax for the subtree properties regularly. For
> exports, though, you need to prefix the properties with EXPORT_.
>
> See the (org) Export Settings node in Org manual.
>
> > When exporting sub-trees, special node properties can override the
> above keywords.  These properties have an ‘EXPORT_’ prefix.  For
> example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific
> sub-tree.  Except for ‘SETUPFILE’, all other keywords listed above have
> an ‘EXPORT_’ equivalent.

Sorry, ignore my email noise. I had never tried ox-icalendar before.
But I just tried it with your test snippet and it doesn't work as
expected even with the EXPORT_ prefix.

Also, I don't see any location info get exported to the .ics file
(with or without the EXPORT_ prefix). So I don't know what I should
expect to see in the .ics file.



Re: Inconsistent handling of multi-line properties

2022-02-28 Thread Kaushal Modi
On Sat, Oct 2, 2021 at 11:03 AM Hanno Perrey  wrote:
>
> Hej,
>
> I have noticed that properties that stretch over multiple lines using
> the :value+: syntax are ignored by org-element-property and therefore
> also by e.g. org-export-get-node-property when exporting to ics via
> ox-icalendar.el (see example below). I was wondering now whether this is
> intentional and to be expected or a bug?

I use the :value+: syntax for the subtree properties regularly. For
exports, though, you need to prefix the properties with EXPORT_.

See the (org) Export Settings node in Org manual.

> When exporting sub-trees, special node properties can override the
above keywords.  These properties have an ‘EXPORT_’ prefix.  For
example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific
sub-tree.  Except for ‘SETUPFILE’, all other keywords listed above have
an ‘EXPORT_’ equivalent.

Here's one of the pathogenic test cases of ox-hugo:

=
** Custom front matter in multiple lines
:PROPERTIES:
:EXPORT_FILE_NAME: custom-front-matter-multiple-lines
:EXPORT_DATE: 2017-07-24
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :foo bar
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :baz zoo
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :alpha 1
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :beta "two words"
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :gamma 10
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :empty_string ""
:END:
=

All the HUGO_CUSTOM_FRONT_MATTER properties get collected as expected.

Here's another example:

=
#+author:
#+options: toc:nil
* Heading
:PROPERTIES:
:EXPORT_AUTHOR: abc def
:EXPORT_AUTHOR+: ghi jkl
:EXPORT_AUTHOR+: kmo pqr
:END:
=

C-c C-e C-s t A exports to:

=
   _

HEADING

abc def ghi jkl kmo pqr
   _


=



Re: Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature))

2022-02-23 Thread Kaushal Modi
On Wed, Feb 23, 2022 at 7:37 AM Ihor Radchenko  wrote:
>
> Dear all,
>
> Since there is at least a couple of people who might be interested, lets
> try to meet online on jitsi and debug performance issues you experience
> because of Org mode. Probably some time this Saturday (Feb 26). I am
> thinking about 9pm SG time (4pm Moscow; 8am New York; 1pm London). WDYT?

That time will work for me. Thanks!



Re: profiling latency in large org-mode buffers (under both main & org-fold feature)

2022-02-21 Thread Kaushal Modi
On Tue, Feb 22, 2022, 12:34 AM Ihor Radchenko  wrote:

>
> I am wondering if many people in the list experience latency issues.
> Maybe we can organise an online meeting (jitsi or BBB) and collect the
> common causes/ do online interactive debugging?
>

+1

I have seen few people see this issue on the ox-hugo issue tracker:
https://github.com/kaushalmodi/ox-hugo/discussions/551#discussioncomment-2104352


Re: [PATCH] c-csl : accept relative CSL filenames

2022-02-18 Thread Kaushal Modi
> It is already in the main branch, AFAIU. I assume you mean it should be
> back-ported to bugfix branch. If that's the case, I don't know. This is
> a new feature, and not a critical one: there are workarounds, as you
> found out.

Yes, sorry, I meant the bugfix branch.

> This should be available when Org 9.6 is released. I don't know when
> that will happen.

OK. It's not urgent. I can wait.

> I don't think Glenn Morris suggests using #'string-or-null-p, which
> would contradict his statement. He is pointing out that ":safe
> #'string-or-null-p" is better than ":safe t", even though but allowing
> arbitrary locations (strings in this case) is not safe anyway.

OK, I thought he referred to ":safe t" equivalent to any arbitrary
location. I don't understand how ":safe
#'string-or-null-p" can be potentially unsafe. So I will go by your judgment.

So, no action needed. Thanks! :)



Re: [PATCH] c-csl : accept relative CSL filenames

2022-02-18 Thread Kaushal Modi
Hello Nicolas,

> Since you are probably busy, I implemented this on your behalf. The new
> behaviour is in main branch. Thank you.
>

Can this commit[1] be merged into the main branch. Locally on my
machine, I use org built from main and something like this was working
fine:

#+cite_export: csl cite/csl/ieee.csl

Here, "csl cite/csl/ieee.csl" is the csl path relative to the Org file.

But when the same ran on a CI where the stable Org version is used, it
failed with this error:

> Debugger entered--Lisp error: (user-error "Cannot handle relative style file 
> name: "cite/csl/...")
> signal(user-error ("Cannot handle relative style file name: "cite/csl/..."))
> user-error("Cannot handle relative style file name: %S" "cite/csl/ieee.csl")

I believe the behavior I see with this commit on main branch is kind
of obvious and it should prevent this surprise failure for other users
too.

This is my current workaround for the Org stable version:

#+cite_export: csl ieee.csl

# Local Variables:
# org-cite-csl-styles-dir: "./cite/csl/"
# End:

This works for both main and bugfix, but while doing this, I realized
that even string values are not considered safe for this variable.

Looking through git revisions, I found
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=41e67cff0d3bf27ffb57f9a230598b0385341517.

Earlier `:safe t' was added for `org-cite-csl-styles-dir'. Instead can
we have `:safe #'string-or-null-p' as suggested by Glenn Morris in
that commit?

Thanks!




[1]: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c6186be3fd6c09a6deaa4edc1fbabbad0cb986d3



Re: Bug with exporting list with link item containing "::" to markdown

2022-02-13 Thread Kaushal Modi
On Sun, Feb 13, 2022, 4:18 AM Jeremie Juste  wrote:

> Hello Cash,
>
> Many thanks for reporting but I cannot reproduce the error with my current
> version of emacs and org-mode. Could you specify the version of org-mode
> and emacs you are currently using?
>
> * test
> :PROPERTIES:
> :ID:   cbce567a-861c-4d9b-8b2f-5933afadb864
> :END:
>
> [[id:cbce567a-861c-4d9b-8b2f-5933afadb864][ryans01 :: No Zero Days]]
>

I haven't tried this yet (away from computer), but I think you would need a
hyphen before that line with :: to make it a list item. The :: in the link
description then probably gets perceived as the :: marker for descriptive
lists.

So try:

- [[id:cbce567a-861c-4d9b-8b2f-5933afadb864][ryans01 :: No Zero Days]]

>


org-element persist logic hangs when quitting emacs

2022-01-26 Thread Kaushal Modi
Hello,

Lately (at least as of last 3 days), I have seen that when I try to
quit emacs, it gets stuck on one of my Org files; it's a personal
journal.org that I frequently update using org-capture. So that file
is usually open in one of the buffers.

Today I did M-x toggle-debug-on-quit and tried to quit emacs. When it
got stuck, I hit C-g and I saw this backtrace:

=
Debugger entered--Lisp error: (quit)
  org-get-limited-outline-regexp()
  org-element--current-element(567757 element nil nil)
  org-element--parse-to(567811)
  org-element-at-point(567811)
  org-element--cache-persist-before-write(org-element--cache #)
  run-hook-with-args-until-success(org-element--cache-persist-before-write
org-element--cache #)
  #f(compiled-function (v) #)(org-element--cache)
  #f(compiled-function (elt) #)(org-element--cache)
  mapc(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-do(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-find(#f(compiled-function (v) #)
(org-element--headline-cache org-element--cache))
  org-persist-write((org-element--headline-cache org-element--cache)
#)
  org-persist-write-all()
  #f(compiled-function (fun) #)(org-persist-write-all)
  run-hook-wrapped(#f(compiled-function (fun) #) org-persist-write-all)
  run-hook-query-error-with-timeout(kill-emacs-hook)
  kill-emacs()
  save-buffers-kill-emacs()
  (if (daemonp) (save-buffers-kill-emacs) (save-buffers-kill-terminal))
  modi/quit-emacs(nil)
  funcall-interactively(modi/quit-emacs nil)
  call-interactively(modi/quit-emacs nil nil)
  command-execute(modi/quit-emacs)
=


I had also enabled the profiler. The profiler report showed this:

=
   14247  92% - command-execute
   14247  92%  - call-interactively
   14247  92%   - funcall-interactively
   13973  91%- modi/quit-emacs
   13973  91% - if
   13939  90%  - save-buffers-kill-emacs
   13834  90%   - kill-emacs
   13834  90%- run-hook-query-error-with-timeout
   13834  90% - run-hook-wrapped
   13834  90%  - #
   13724  89%   - org-persist-write-all
   13715  89%- org-persist-write
   13698  89% - seq-find
   13698  89%  - seq-do
   13698  89%   - mapc
   13698  89%- #
   13698  89% - #
   13698  89%  - run-hook-with-args-until-success
   13698  89%   - org-element--cache-persist-before-write
   13698  89%- org-element-at-point
   13244  86% - org-element--parse-to
6568  42%  + org-element--current-element
2649  17%  + org-element--cache-put
=


I was able to quit emacs once I disabled the cache feature by setting
org-element-use-cache to nil.

---

- Org mode version 9.5 (release_9.5-428-g26dece)
- Emacs version: GNU Emacs 28.0.91 (build 7, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12) of 2022-01-25, built using
commit 7eca80b20444f7bd7bcb6a66a9054e029f0e7013.


--
Kaushal Modi



Re: Question Regarding CSS Stylesheets For Art Gallery Webpage Made With Org Mode

2022-01-21 Thread Kaushal Modi
Hi Samuel,

On Sun, Jan 16, 2022 at 12:06 PM Samuel Banya  wrote:
>
> I am planning to use Emacs to create Org Mode files for the few main sections 
> of my site that aren't the Art Gallery page itself.
>
> I'm trying to figure out how to get a modern Wordpress looking Org generated 
> HTML page that rivals pages like this:
>
> https://karlkopinski.com/
> https://wyliebeckert.com/
> http://www.brucepennington.co.uk/
> https://turnislefthome.com/
> https://davidmattingly.com/sketches/
> https://www.mathewborrett.com/
> https://www.stephenfabian.com/gallery

Here's my personal opinion: Org mode is great at concisely formatting
content, so I format my blog content in Org. But then I leave it up to
static site generator giants like Hugo to make the site look good. The
kind of look you want on your website could be achieved by one of the
themes: https://themes.gohugo.io/
Static site generators have tons of other benefits like putting the
right meta data, easily creating RSS, ATOM feeds, integrating
pre-generated search index, post-processing images, etc. before
uploading to the server, minifying CSS, JS, HTML, etc.

[ I am giving examples of using Hugo because that's what I use. You
can pick any static site generator and a compatible theme. ]

> Would be curious to know everyone's thoughts on this if there's a cool way to 
> do this via Org Mode :)

I would focus on:

1. Content writing in Org mode
2. Rendering/prettifying the website using CSS, templating, etc in a
static site generator.

Of course you can do everything in Org mode and many people do it, but
then you need to design CSS, JS, etc yourself.
( I am not a web designer, so I took the static site generator
approach and started learning more about CSS and templating from
available themes. )



Kaushal



org-element-cache: org-set-tags (C-c C-q) makes Emacs unresponsive at times

2022-01-21 Thread Kaushal Modi
Hello Ihor,

> The issue here had nothing to do with hanging. You are probably seeing
> yet another bug.

ok.

> By hang, do you mean that even C-g does not restore responsiveness?

Typically, within a second of doing C-c C-q, I would know that the
buffer is going to freeze, and if I do C-g soon enough, Emacs would
recover in a second or two.

But if I wait 5-6 seconds and then do C-g, it could take minutes to
recover, and I often do pkill SIGUSR2 from the terminal to get back.

Sorry, but since then I set org-element-use-cache to nil once that
issue comes back. It's usually that I am between something and I don't
think of getting a backtrace on C-g (Now I have made a note to self to
provide a backtrace in this thread when that issue repeats).

---

Right now, I set org-element-use-cache back to t, did M-x
toggle-debug-on-quit and did a couple of C-c C-q in a 10k line Org
buffer .. this time, it's responsive and snappy :|

I'll keep you posted. Thanks!!

---

Org mode version 9.5 (release_9.5-415-g9b58ea)
Emacs version: GNU Emacs 28.0.91 (build 5, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12) of 2022-01-18, built using
commit f393d0d441c3746f98007ae54341870a296bf809.



Re: [BUG] org-element-cache: The inherited property is set wrong

2022-01-20 Thread Kaushal Modi
Hi Anders,

I have also been seeing some issues when adding/modidying heading tags
(C-c C-q), and I was able to narrow it down to the element caching
mechanism.

Issue: Org mode/Emacs hangs kind of indefinitely when I do C-c C-q,
but that doesn't happen each time.

Once I set org-element-use-cache to nil, Emacs stopped hanging.

Looking at your bug report, I believe that the issue I am seeing with
cache and Org tags could be very much related. So thanks for
submitting this.

--
Kaushal Modi



Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

2022-01-10 Thread Kaushal Modi
On Mon, Jan 10, 2022 at 8:35 AM Timothy  wrote:
>
> FWIW, I think it would be good to be internally consistent. #+RESULTS is
> currently one of the few keywords inserted in upper case. Unless there’s a 
> good
> reason to distinguish it from other keywords (perhaps an argument could be 
> made
> that it should be treated differently because it is usually generated, not
> inserted by the user?), I’d be in favour of changing the default to be
> consistent.

+1 for consistency. The Org parser does not care if the keywords are
upper or lower case.

So inserting the #+results keyword in lower-case would be a good
change towards improving the consistency.



Re: Way to mark contents of an Org special block as verbatim?

2022-01-09 Thread Kaushal Modi
On Sun, Jan 9, 2022 at 3:01 PM Nicolas Goaziou  wrote:
>
> I suggest to use
>
>   (org-element-interpret-data (org-element-contents special-block))


That does it!! Thank you!

Also thanks to Juan and Charles who helped lead me to the final solution.



Re: Way to mark contents of an Org special block as verbatim?

2022-01-09 Thread Kaushal Modi
> On Sat, Jan 8, 2022 at 10:01 PM Berry, Charles  
> wrote:

Hi Charles,

I used your minimal example to show the issue I am seeing when using
ox-md as the base exporter.

=
#+property: header-args :results none :exports none :eval never-export
#+options: toc:nil

* Define newmd :noexport:
Eval below to define a minimal "newmd" exporter:
#+begin_src emacs-lisp
;; minimal backend with md parent
(org-export-define-derived-backend 'newmd 'md
  :translate-alist
  '((special-block . org-newmd-special-block)))

;; special block transcoder
(defun org-newmd-special-block (special-block contents info)
  "Newmd special block transcoder."
  (let
   ((type (org-element-property :type special-block)))
(if (equal type "katex")
(format "{{<%s>}}\n%s{{}}\n" type contents type)
  ;; not `katex' so default to md transcoder
  (org-export-with-backend 'md special-block contents info
#+end_src
* Test block for exporting
#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex
* Do export:noexport:
Eval below to export this buffer using the ~newmd~ exporter:
#+begin_src emacs-lisp
(org-export-to-buffer 'newmd "*Org NEW LATEX Export*" nil nil nil :body-only)
#+end_src
=

1. Eval the block in first heading
2. Eval the block in second heading to export

Exporter buffer content:

=
# Test block for exporting

{{}}
E = -J i=1^N s\_i si+1
{{}}
=


How do we disable Org from transforming this:

E = -J \sum_{i=1}^N s_i s_{i+1}

to this:


E = -J i=1^N s\_i si+1



Re: Way to mark contents of an Org special block as verbatim?

2022-01-08 Thread Kaushal Modi
On Sat, Jan 8, 2022 at 10:01 PM Berry, Charles  wrote:
>
>
> A simple one here:
>
> #+begin_src emacs-lisp
>   ;; minimal backend with latex parent
>   (org-export-define-derived-backend 'newlatex 'latex
> :translate-alist
> '((special-block . org-newlatex-special-block)))
>
>   ;; special block transcoder
>   (defun org-newlatex-special-block (special-block contents info)
> "Newlatex special block transcoder."
> (let
>  ((type (org-element-property :type special-block)))
>   (if (equal type "newlatex")
>   (format "{{}}\n%s{{}}\n" contents)

I am already doing something like this, but at this point in the code,
the `contents' already is the modified content i.e. Org entities
replaced and _{..} converted to , etc.

Note that ox-hugo exporter is extended from ox-md, which is extended
from ox-html.

My problem statement is that the contents I am receiving is already
modified and I don't get to access the original/raw/verbatim content.
Thanking the original example in this thread:

#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex

- \sum will have converted to 
- _{i=1} will have converted to i=1 by the time I receive
the contents in ox-hugo's org-hugo-special-block.

[ May be I am doing something wrong in my exporter? ]

Or may be it's due to the fact that my eventual base exporter is ox-html?

> ;; not `newlatex` so default to latex transcoder
> (org-export-with-backend 'latex special-block contents info
> #+end_src
>
> Eval the above, then use this as an example by copying the following
> src block to an org buffer and entering
>
> M-; (org-export-to-buffer 'newlatex "*Org NEW LATEX Export*" nil nil nil t) 
> RET
>
> #+begin_src org
>
>   ,#+begin_newlatex
>   This is the new content
>   ,#+end_newlatex
>
>
>   ,#+attr_latex: :caption \MyCaption{HeadingA}
>   ,#+BEGIN_proof
>  dot-dot-dot
>   ,#+END_proof
>
> #+end_src
>
> I get an *Org NEW LATEX Export* buffer like this:
>
> #+begin_example
> {{}}
> This is the new content
> {{}}
>
>
> \begin{proof}
> dot-dot-dot
> \MyCaption{HeadingA}
> \end{proof}
>
> #+end_example



Re: Way to mark contents of an Org special block as verbatim?

2022-01-08 Thread Kaushal Modi
> What am I missing?
>
> It seems like you want your derived backend to transcode special blocks 
> somewhat differently than the parent backend. And adding a special block 
> export filter doesn't quite do the job.

I tried out the example Juan posted and it works perfectly well. But
it would require to user to do something similar for each arbitrary
new special block they need. E.g. #+being_katex, #+begin_tikz,
#+begin_tikzjax (could be anything!) where the content needs to be
kept unmodified.

> For that purpose, you should write a special block transcoder - perhaps 
> falling back to the parent backend for block types you do not wish to handle 
> as described above.

Can you please point me to an example?

> Block specific customizations could rely on a backend specific attribute.

Yes, I am doing block-specific customization (like support
#+attr_shortcode above special blocks here[1]). But I don't know how
to get back the original content of the special block because the
`contents` arg received by the exporter's org-hugo-special-block
already has the Org entities, and sub/super replacements done.

[1]: 
https://github.com/kaushalmodi/ox-hugo/blob/458142675bb5a0e7ee26ecea07d75c10aa52184b/ox-hugo.el#L2872



Re: Way to mark contents of an Org special block as verbatim?

2022-01-06 Thread Kaushal Modi
On Thu, Jan 6, 2022 at 2:33 PM Juan Manuel Macías
 wrote:
> I just realized that there is a much simpler solution for your katex
> environment :-)
>
> You can use an example block, and define your custom environment using
> the attribute :environment

Sorry, but this exporter is derived from md, and before exporting the
verbatim body of the special block needs to be surrounded with some
special syntax, with some optional stuff that the user specifies. Also
it could any special block name:
- katex
- tikz
- tikzjax

In any case, if user has this in Org:

#+begin_FOO

#+end_FOO

I need to export:

{{< FOO custom stuff >}}

{{< /FOO >}}



Re: Way to mark contents of an Org special block as verbatim?

2022-01-06 Thread Kaushal Modi
On Thu, Jan 6, 2022 at 1:27 PM Juan Manuel Macías
 wrote:
> I think one possibility would be using a parse tree export filter:
>
> #+BIND: org-export-filter-parse-tree-functions (katex-verbatim)
> #+begin_src emacs-lisp :exports results :results none
>   (defun katex-verbatim (tree backend info)
> (when (org-export-derived-backend-p backend 'latex)
>   (org-element-map tree 'special-block
> (lambda (block)
>   (when (equal "katex" (org-element-property :type block))
> (let ((cont (org-element-interpret-data (org-element-contents 
> block)))
>   (create-export-snippet ;; idea from Nicolas Goaziou
>(lambda (v)
>  (org-element-create 'export-snippet (list :back-end 
> "latex" :value v)
>   (apply #'org-element-set-contents
>  block
>  (list (funcall create-export-snippet cont))
> info)
>   tree))
> #+end_src
>
> #+begin_katex
> E = -J \sum_{i=1}^N s_i s_{i+1}
> #+end_katex
>
> ==>
>
> \begin{katex}
> E = -J \sum_{i=1}^N s_i s_{i+1}
> \end{katex}

Wow, thanks for that complete code. I didn't know about the parse tree
functions.

I was thinking if below is possible as any user running my exporter
would need to use this feature easily.

#+begin_katex :verbatim t
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex

Is it possible to do anything inside the org-hugo-special-block
function that's defined in the exporter?



Way to mark contents of an Org special block as verbatim?

2022-01-06 Thread Kaushal Modi
Hello,

Is there a way to mark contents of an Org special block as verbatim?

In my custom exporter, when I do the below,

#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex

it gets exported to:

{{< katex display >}}
E = -J i=1^N s\_i si+1
{{< /katex >}}

I would like to treat that block /like/ how Org treats the latex
environment blocks, but it needs to be a special block as
begin_katex/end_katex here is special and it could be a different
equation rendering backend for another user.

So is that a header switch or arg that can be passed on to this
special block that enables the verbatim mode (prevent Org from
replacing the Org entities, do the sub/superscript expansion, etc.)?

--
Kaushal Modi



Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

2021-12-18 Thread Kaushal Modi
On Fri, Dec 17, 2021 at 11:34 PM Ihor Radchenko  wrote:

> > There's a setup included in there; I forgot about that. If you don't mind
> > trying it again, this would download everything needed:
>
> Thanks! I was able to follow your steps this time.
>

I really appreciate making this extra effort to help me out. Thanks!


> > Sorry, but I am getting similar backtrace in another function now:
>
> Sigh... Should be fixed now. I did not expect that arguments to cache
> functions could ever be markers.
>
> After the fix, I was able to see the warning you were talking about in
> the earlier email. Your test case revealed an important omission in the
> cache logic when a huge number of edits are stacked together into
> asynchronous cache queue. Thanks you for providing the excellent
> reproducer!
>

No problem! The ox-hugo tests end up indirectly testing a lot of Org
features :D


> On latest main, your example file is exported without any warnings.
>

I just verified that. Also, I did not even need to add
`(org-element-cache-reset)' in `org-hugo--get-pre-processed-buffer' after
the `(insert ..)' in the temp buffer.

Is that expected?

Also, I noticed that now the exports are much more snappier than before!

Also, I noticed that the large number of edits makes the cache use a lot
> of memory adding load onto the Emacs garbage collector. May I know what
> exactly ox-hugo does that triggers that many edits? Exporting your
> example files took approximately 30sec on my system (both with and
> without cache). I believe that the speed can be improved if cache is
> used more optimally.
>

That command exports 81 subtrees (as of now) from ox-hugo-manual.org to
independent Markdown files.

That said, I think that `org-hugo--get-pre-processed-buffer' [1] is the
performance bottleneck. It was added so that Org subtree exports can work
even if one subtree has an internal link to a different subtree in the same
file.

The pre processing logic slurps up the AST of the whole Org buffer, does
org-element-copy on all the link org-elements to point to a place outside
the exported subtree, fixes that link so that the export works, and copies
the modified link element back on the original element. And then the whole
Org temp buffer is overwritten with the modified AST.
And then.. the subtree export happens from there.

This is the only way possible as far as I know to support cross-subtree
links. Credit for this implementation goes to Folkert van der Beek[2].

Let me know if you have any suggestions to improve the performance. I think
that the org-element-copy and writing the huge AST to temp Org buffer is
keeping the GC busy (the ox-hugo-manual.org is about 3700 lines right now).

[1]:
https://github.com/kaushalmodi/ox-hugo/blob/1ea466d33f76eaf2567593fa612b82c22ef86d3d/ox-hugo.el#L4033-L4151

[2]: https://github.com/kaushalmodi/ox-hugo/pull/280


Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

2021-12-16 Thread Kaushal Modi
On Thu, Dec 16, 2021 at 10:16 AM Ihor Radchenko  wrote:

>
> FYI, it is suspicious. You should be at 9.5.1. Maybe you forgot to make
> clean; make autoloads.
>

I actually run a wrapper script to update Org and that has all that:

=
# cmds to update to latest commit on git main branch
# Ensure that the prefix path is correct in local.mk for
# emacs/home/$1 version.
sed -i 's|^prefix.*=.*|prefix =
/home/kmodi/usr_local/apps/7/emacs/'"$1"'/share|' local.mk
# Update the infodir if needed.
sed -i 's|^infodir.*=.*|infodir = $(prefix)/org/info|' local.mk
echo -e "\\nBuilding for emacs version: $(emacs --version | grep -E
'Emacs [0-9]+\.[0-9]+')\\n"
make cleanall
make autoloads
make compile
make doc
make install
=

I verified that at least the git hash was latest as of then:
release_9.5-364-g*de022e*



> > Steps to reproduce this issue (after setting those variables as suggested
> > above):
> >
> > 1. Install ox-hugo from MELPA and require it
> > 2. Download the ox-hugo-manual.org[1]
> > 3. Take point to anywhere inside a subtree with :EXPROT_FILE_NAME:
> property
> > (e.g. under the * Org Special Blocks subtree around line 3038)
> > 4. C-c C-e H A (this will export all the valid subtrees in that file
> using
> > ox-hugo)
>
> I tried on my side and I am getting "Undefined Org macro: issue;
> aborting" Does not look like Org's fault unless I miss something.
>

There's a setup included in there; I forgot about that. If you don't mind
trying it again, this would download everything needed:

=
git clone https://github.com/kaushalmodi/ox-hugo
cd ox-hugo/doc/
# open ox-hugo-manual.org from this dir
=

and then:

=
1. Eval /ox-hugo/ox-hugo.el
2. Take point to anywhere inside a subtree with :EXPROT_FILE_NAME: property
(e.g. under the * Org Special Blocks subtree around line 3038)
3. C-c C-e H A (this will export all the valid subtrees in that file using
ox-hugo)
=

I am unable to reproduce but I know why it happened (and it is indeed
> different from previous one). I just pushed a fix upstream.
>

Thanks. I see this version after the update:

Org mode version 9.5 (release_9.5-366-g092e92 @
/home/kmodi/usr_local/apps/7/emacs/emacs-28/share/emacs/site-lisp/org/)
The git hash is correct (
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=092e921423f02d48778a0c5d298a211388af8090).
So not sure, why it's still saying version 9.5.

Sorry, but I am getting similar backtrace in another function now:

=
Debugger entered--Lisp error: (error "Format specifier doesn’t match
argument type")
  format("org-element-cache diagnostics( *temp*-378635): Int..." 28172
#)
  org-element--cache-process-request([28170 28171 22333 1 (headline
(:raw-value "Usage" :begin 17933 :end 22334 :pre-blank 0 :contents-begin
17942 :contents-end 22334 :robust-begin 17978 :robust-end 22332 :level 2
:priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated
17933 :CUSTOM_ID "usage" :title "Usage" :mode nil :granularity element
:cached t :parent (headline (:raw-value "Reused Sections" :begin 17054 :end
28172 :pre-blank 0 :contents-begin 17072 :contents-end 28172 :robust-begin
17074 :robust-end 28170 :level 1 :priority nil :tags nil :todo-keyword nil
:todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil
:commentedp nil :post-affiliated 17054 :title "Reused Sections" :mode nil
:granularity element :cached t :parent (org-data (:begin 1 :contents-begin
1 :contents-end 145098 :end 145098 :robust-begin 3 :robust-end 145096
:post-blank 0 :post-affiliated 1 :path nil :mode org-data :CATEGORY nil
:cached t)) :org-element--cache-sync-key (69 . 17054)))
:org-element--cache-sync-key (67 . 17933))) 1] 145000 # nil nil)
  org-element--cache-sync(# #)
  org-element-at-point(#)
  org-element-cache-map(#f(compiled-function (el) #) :next-re "^\\*+ " :fail-re "^\\*+ " :narrow t)
  org-scan-tags(#f(compiled-function () #) t
nil nil)
  org-map-entries(#f(compiled-function () #))
=

*Another observation: *

I see this warning when building from the latest main:

In org-element--cache-sync:
org-element.el:5935:19: Warning: assignment to free variable
‘org-element--cache-change-warning’


Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

2021-12-16 Thread Kaushal Modi
> Can you:
> 1. Update Org to latest version
> 2. set org-element--cache-self-verify to 'backtrace
> 3. set org-element--cache-self-verify-frequency to 1.0
> 4. Try to reproduce the warning you are seeing
> 5. If you still see it, post the full warning text including the
>backtrace (below the warning).
>

Hi Ihor,

I updated Org to

Org mode version 9.5 (release_9.5-364-gde022e @
/home/kmodi/usr_local/apps/7/emacs/emacs-28/share/emacs/site-lisp/org/)

I am using the latest build of emacs-28 branch:

=
Emacs version: GNU Emacs 28.0.90 (build 2, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12)
 of 2021-12-16, built using commit 1e578267fb19208504d28253e0c892ceb9a34fb4.

./configure options:
  --prefix=/home/kmodi/usr_local/apps/7/emacs/emacs-28
'--program-transform-name=s/^ctags$/ctags_emacs/' --with-modules
--with-harfbuzz --with-native-compilation --enable-checking=yes,glyphs
--enable-check-lisp-object-type CPPFLAGS=-I/home/kmodi/stowed/7/include
'CFLAGS=-ggdb3 -Og' 'CXXFLAGS=-ggdb3 -Og'
'LDFLAGS=-L/home/kmodi/stowed/7/lib -L/home/kmodi/stowed/7/lib64 -ggdb3'

Features:
  ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3
ZLIB
=

I also set those 2 variables and then exported the ox-hugo-manual.org[1]
using ox-hugo and get those warnings[2].

Steps to reproduce this issue (after setting those variables as suggested
above):

1. Install ox-hugo from MELPA and require it
2. Download the ox-hugo-manual.org[1]
3. Take point to anywhere inside a subtree with :EXPROT_FILE_NAME: property
(e.g. under the * Org Special Blocks subtree around line 3038)
4. C-c C-e H A (this will export all the valid subtrees in that file using
ox-hugo)
5. The exports abruptly stop around half way due to this error (this error
doesn't always get thrown at the same point):

=
org-babel-exp process org at position 59086...
org-babel-exp process org at position 59385...
org-babel-exp process org at position 60069...
org-babel-exp process org at position 60740...
org-babel-exp process org at position 63055...
Saving file
/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/ox-hugo/doc/content/doc/image-links.md...
Wrote
/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/ox-hugo/doc/content/doc/image-links.md
[ox-hugo] 21/ Exporting ‘Source blocks’ ..
org-element--cache-process-request: Format specifier doesn’t match argument
type

(I have an advice applied in between:
modi/advice-org-tangle-and-export-boost. But it's unrelated to this error.)

Debugger entered--Lisp error: (error "Format specifier doesn’t match
argument type")
  format("org-element-cache diagnostics( *temp*-467986): Rea..." # "(headline (:raw-value \"Menus\" :begin 28167
:end 14...")
  org-element--cache-process-request([26673 26673 25896 1 (paragraph
(:begin 26634 :end 26674 :contents-begin 26634 :contents-end 26674
:post-blank 0 :post-affiliated 26634 :mode nil :granularity element
:org-element--cache-sync-key (76 26672 1152921504606846975) :cached t
:parent (item (:bullet "8. " :begin 26631 :end 26674 :contents-begin 26634
:contents-end 26674 :checkbox nil :counter nil :structure ((26009 0 "1. "
nil nil nil 26029) (26029 0 "2. " nil nil nil 26145) (26145 0 "3. " nil nil
nil 26167) (26167 0 "4. " nil nil nil 26346) (26226 3 "- " nil nil nil
26346) (26346 0 "5. " nil nil nil 26462) (26389 3 "- " nil nil nil 26462)
(26462 0 "6. " nil nil nil 26564) (26564 0 "7. " nil nil nil 26631) (26631
0 "8. " nil nil nil 26674)) :pre-blank 0 :post-blank 0 :post-affiliated
26631 :tag nil :mode item :granularity element :org-element--cache-sync-key
(76 26672 -1) :cached t :parent (plain-list (:type ordered :begin 26009
:end 26674 :contents-begin 26009 :contents-end 26674 :structure ...
:post-blank 0 :post-affiliated 26009 :mode nil :granularity element
:org-element--cache-sync-key ... :cached t :parent ...)) 2] nil
# nil nil)
  org-element--cache-sync(# #)
  org-element-at-point(#)
  org-element-cache-map(#f(compiled-function (el) #) :next-re "^\\*+ " :fail-re "^\\*+ " :narrow t)
  org-scan-tags(#f(compiled-function () #) t
nil nil)
  org-map-entries(#f(compiled-function () #))

org-export--prepare-file-contents("/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/el..."
"548-589" 0 4 1 #
"/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/el...")
  org-export-expand-include-keyword()
  org-export-as(hugo :subtreep nil nil (:output-file
"/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/el..."))
  #f(compiled-function (backend file  async subtreep visible-only
body-only ext-plist post-process) "Call `org-export-as' with output to a
specified file.\n\nBACKEND is either an export back-end, as returned by,
e.g.,\n`org-export-create-backend', or a symbol referring to\na registered
back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil
optional argument ASYNC means the 

Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

2021-12-15 Thread Kaushal Modi
On Wed, Dec 15, 2021 at 9:29 PM Kaushal Modi  wrote:

>
> Can you help fix this?
>

Also looking closely, I am seeing a different warning:

Warning (org-element-cache): org-element--cache:
(org-hugo-export-wim-to-md) Cached element is incorrect in *Ox-hugo
Pre-processed ox-hugo-manual.org *<2>. (Cache tic up to date: "yes")
Resetting.
If this warning appears regularly, please report it to Org mode mailing
list (M-x org-submit-bug-report).
The element is:   "(headline (:raw-value \"Homepage\" :begin 16675 :end
25840 :pre-blank 0 :contents-begin 16686 :contents-end 25840 :robust-begin
16891 :robust-end 25838 :level 1 :priority nil :tags nil :todo-keyword nil
:todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil
:commentedp nil :post-affiliated 16675 :EXPORT_TITLE \"Org to Markdown for
Hugo\" :EXPORT_FILE_NAME \"_index\" :EXPORT_HUGO_TYPE \"homepage\"
:EXPORT_HUGO_SECTION \"/\" :EXPORT_HUGO_MENU \":menu \\\"1.main\\\" :title
\\\"Homepage\\\"\" :CUSTOM_ID \"main\" :title \"Homepage\" ...))"
 The real element is: "(headline (:raw-value \"Homepage\" :begin 16675 :end
25888 :pre-blank 0 :contents-begin 16686 :contents-end 25888 :robust-begin
16891 :robust-end 25886 :level 1 :priority nil :tags nil :todo-keyword nil
:todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil
:commentedp nil :post-affiliated 16675 :EXPORT_TITLE \"Org to Markdown for
Hugo\" :EXPORT_FILE_NAME \"_index\" :EXPORT_HUGO_TYPE \"homepage\"
:EXPORT_HUGO_SECTION \"/\" :EXPORT_HUGO_MENU \":menu \\\"1.main\\\" :title
\\\"Homepage\\\"\" :CUSTOM_ID \"main\" :title \"Homepage\" ...))"

I see the :end and :content-end changing.


Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

2021-12-15 Thread Kaushal Modi
On Mon, Nov 8, 2021 at 1:05 AM Ihor Radchenko  wrote:

>
> I was able to reproduce the issue. This is a bug on ox-hugo side.
> `org-hugo--get-pre-processed-buffer' inserts text with
> inhibit-modification-hooks bound to non-nil, which breaks
> org-element-cache. The cache is enabled by default in latest Org, which
> is why the issue revealed itself.
>
> The fix on ox-hugo side can be made similarly to the new implementation
> of `org-export--generate-copy-script' - ox-hugo needs to manually reset
> the cache after silent changes in temporary Org buffer.
>

Hi Ihor,

I followed your change to `org-export--generate-copy-script'  in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fe6cefdaaf020c315031a139a7b9bc443cbefc5c
and added a `(org-element-cache-reset)' call in
`org-hugo--get-pre-processed-buffer' after the `(insert ..)' in the temp
buffer.

But I am still seeing that warning.

Ref commit to a branch:
https://github.com/kaushalmodi/ox-hugo/commit/2bdbf51922ec2e01be65397b237d0b716edb5cb4

Can you help fix this?

Thanks!


Re: [BUG] make test is extremely slow since b3cc2f793 [9.5.1 (9.5.1-g984367 @ /home/yantar92/.emacs.d/straight/build/org/)]

2021-12-06 Thread Kaushal Modi
On Sun, Dec 5, 2021 at 4:12 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Ihor Radchenko  writes:
>
> > Sorry, but tests are still slow for me after the update.
> > If I run the test from inside Emacs with ert, things got better, but
> > make BTEST_RE="^test-org-cite/adjust-note" test
> > still takes 12sec.
>
> I cannot reproduce it. The test went down from 4.5s to 1.5s. I am using
> Emacs 27.2.
>

Ihor,

FWIW, the tests runs in about the same time for me.

Running 1 tests (2021-12-06 08:59:31-0500, selector
‘"^test-org-cite/adjust-note"’)
   passed  1/1  test-org-cite/adjust-note (1.333928 sec)

I just rebuild Org from main branch and I am on emacs-28 branch built last
Friday:

Emacs version: GNU Emacs 28.0.90 (build 1, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12)
 of 2021-12-03, built using commit 7282e492d5c3ed8c856d92a121d143f6a70db244.

Maybe strace would help identify a disk IO issue if any?


Re: [PATCH] Fix org-comment-line-break-function

2021-12-06 Thread Kaushal Modi
Hi Nicolas,

I have added few tests in the updated patch pasted in this email.
I have made the tests for (call-interactive #'default-indent-new-line)
because that the interactive function M-j is bound to by default.

Can you please review and commit it? The machine I am on right now does not
allow external ssh access.



>From de607dff518eaa91149ff1aa8c255f67fb6ee887 Mon Sep 17 00:00:00 2001
From: Kaushal Modi 
Date: Tue, 30 Nov 2021 20:37:10 -0500
Subject: [PATCH] org: Remove `org-comment-line-break-function'

* lisp/org.el: Remove `org-comment-line-break-function' and let
`comment-line-break-function' be the default value.
* testing/lisp/test-org.el (test-org/default-indent-new-line): Add
tests for M-j behavior when point is inside or outside an Org comment.

This fixes the `M-j' binding issue reported by Richard Lawrence in
<https://lists.gnu.org/r/emacs-orgmode/2021-11/msg00639.html>.
---
 lisp/org.el  | 17 ++---
 testing/lisp/test-org.el | 19 +++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..ee8ca1f03 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19624,8 +19624,7 @@ assumed to be significant there."

 ;; `org-auto-fill-function' takes care of auto-filling.  It calls
 ;; `do-auto-fill' only on valid areas with `fill-prefix' shadowed with
-;; `org-adaptive-fill-function' value.  Internally,
-;; `org-comment-line-break-function' breaks the line.
+;; `org-adaptive-fill-function' value.

 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
@@ -19647,8 +19646,7 @@ assumed to be significant there."
   (setq-local fill-paragraph-function 'org-fill-paragraph)
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
-  (setq-local normal-auto-fill-function 'org-auto-fill-function)
-  (setq-local comment-line-break-function
'org-comment-line-break-function))
+  (setq-local normal-auto-fill-function 'org-auto-fill-function))

 (defun org-fill-line-break-nobreak-p ()
   "Non-nil when a new line at point would create an Org line break."
@@ -19903,17 +19901,6 @@ filling the current element."
  (adaptive-fill-mode (not (equal fill-prefix ""
  (when fill-prefix (do-auto-fill))

-(defun org-comment-line-break-function ( soft)
-  "Break line at point and indent, continuing comment if within one.
-The inserted newline is marked hard if variable
-`use-hard-newlines' is true, unless optional argument SOFT is
-non-nil."
-  (if soft (insert-and-inherit ?\n) (newline 1))
-  (save-excursion (forward-char -1) (delete-horizontal-space))
-  (delete-horizontal-space)
-  (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
-

 ;;; Fixed Width Areas

diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 056ea7d87..de4ac7ea9 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -1200,6 +1200,25 @@
 (org-indent-region (point-min) (point-max))
 (buffer-string)

+(ert-deftest test-org/default-indent-new-line ()
+  "Test behavior of default binding `M-j'."
+  ;; Calling `M-j' when point is not in an Org comment:
+  (should
+   (equal "* Some heading\n"
+  (org-test-with-temp-text "* Some heading"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string
+  ;; Calling `M-j' when point is in an Org comment:
+  (should
+   (equal "# Some Org comment\n# "
+  (org-test-with-temp-text "# Some Org comment"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string
+  (should
+   (equal "# Some Org\n# comment"
+  (org-test-with-temp-text "# Some Org comment"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string)


 ;;; Editing
-- 
2.34.0





--
Kaushal Modi


On Mon, Dec 6, 2021 at 8:17 AM Richard Lawrence <
richard.lawre...@uni-tuebingen.de> wrote:

> Kaushal Modi  writes:
>
> > On Sat, Dec 4, 2021, 5:25 PM Tim Cross  wrote:
> >
> >> Given that Nicholas cannot remember the reason for the original function
> >> and suspects it was meant to be an internal only function, I think this
> >> patch is probably the best way forward and should be applied.
> >
> > Thanks. Nicolas asked me to add tests for this patch. But I need to look
> > into how to add tests for behavior of bindings. Need to add tests for M-j
> > binding behavior when cursor is within a comment or outside.
>
> FWIW I have been running the equivalent of Kaushal's patch (I just
> removed the local binding of comment-line-break-function to
> 'org-comment-line-break-function without deleting 

Re: [PATCH] Fix org-comment-line-break-function

2021-12-04 Thread Kaushal Modi
On Sat, Dec 4, 2021, 5:25 PM Tim Cross  wrote:

>
> Given that Nicholas cannot remember the reason for the original function
> and suspects it was meant to be an internal only function, I think this
> patch is probably the best way forward and should be applied.
>

Thanks. Nicolas asked me to add tests for this patch. But I need to look
into how to add tests for behavior of bindings. Need to add tests for M-j
binding behavior when cursor is within a comment or outside.

>


Re: examples for org-manual

2021-12-02 Thread Kaushal Modi
On Thu, Dec 2, 2021, 8:08 AM Vincent Breton 
wrote:

> Hi,
>
>
> Emacs and Emacs Org documentation, and lot of others GNU products use
> Texinfo to generate their own  documentation to different formats.


The Org mode documentation switched to Org format few years back:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-manual.org

Yes, originally, it was in Texinfo.


Re: [PATCH] Fix org-comment-line-break-function

2021-11-30 Thread Kaushal Modi
On Tue, Nov 30, 2021 at 6:29 PM Tim Cross  wrote:

>
> It would be good to get Nicholas' input here as I think he wrote the
> original function back in 2012.
>

Just to see what happens, I tried this:

M-: (setq-local comment-line-break-function #'comment-indent-new-line)

.. and then M-j started working perfectly! It worked fine both: in Org
comment lines and out of comment lines.

I see that comment-indent-new-line was added to emacs in newcomment.el back
in 2000. So I don't know why org-comment-line-break-function was added. May
be Nicolas can comment more on that.

So would this patch work?

=

>From 1a9187b82ed8d4e8d54ddd369a44d34295281fc3 Mon Sep 17 00:00:00 2001
From: Kaushal Modi 
Date: Tue, 30 Nov 2021 20:37:10 -0500
Subject: [PATCH] org: Remove `org-comment-line-break-function'

* lisp/org.el: Remove `org-comment-line-break-function' and let
`comment-line-break-function' be the default value.

This fixes the `M-j' binding issue reported by Richard Lawrence in
<https://lists.gnu.org/r/emacs-orgmode/2021-11/msg00639.html>.
---
 lisp/org.el | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..ee8ca1f03 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19624,8 +19624,7 @@ assumed to be significant there."

 ;; `org-auto-fill-function' takes care of auto-filling.  It calls
 ;; `do-auto-fill' only on valid areas with `fill-prefix' shadowed with
-;; `org-adaptive-fill-function' value.  Internally,
-;; `org-comment-line-break-function' breaks the line.
+;; `org-adaptive-fill-function' value.

 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
@@ -19647,8 +19646,7 @@ assumed to be significant there."
   (setq-local fill-paragraph-function 'org-fill-paragraph)
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
-  (setq-local normal-auto-fill-function 'org-auto-fill-function)
-  (setq-local comment-line-break-function
'org-comment-line-break-function))
+  (setq-local normal-auto-fill-function 'org-auto-fill-function))

 (defun org-fill-line-break-nobreak-p ()
   "Non-nil when a new line at point would create an Org line break."
@@ -19903,17 +19901,6 @@ filling the current element."
  (adaptive-fill-mode (not (equal fill-prefix ""
  (when fill-prefix (do-auto-fill))

-(defun org-comment-line-break-function ( soft)
-  "Break line at point and indent, continuing comment if within one.
-The inserted newline is marked hard if variable
-`use-hard-newlines' is true, unless optional argument SOFT is
-non-nil."
-  (if soft (insert-and-inherit ?\n) (newline 1))
-  (save-excursion (forward-char -1) (delete-horizontal-space))
-  (delete-horizontal-space)
-  (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
-

 ;;; Fixed Width Areas

-- 
2.34.0

=


Re: [PATCH] Fix org-comment-line-break-function

2021-11-30 Thread Kaushal Modi
On Tue, Nov 30, 2021, 6:29 PM Tim Cross  wrote:

>
> Regardless, I think that unless we understand the purpose of
> insert-before-markers-and-inherit, we should make the patch such that it
> still calls that function. Even if fill-prefix is nil there is
> probably a good reason why the markers and properties need to be
> modified for some situations.
>

Oops! You're right; I did not verify that binding within a comment. I just
checked that it prevented the error.

It would be good to understand the purpose of that function call and have a
proper fix.

>


Re: [PATCH] Fix org-comment-line-break-function

2021-11-30 Thread Kaushal Modi
On Tue, Nov 30, 2021 at 3:20 PM Marco Wahl  wrote:

>
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 1a1375461..fdeec0d67 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -19695,7 +19695,8 @@ non-nil."
>(save-excursion (forward-char -1) (delete-horizontal-space))
>(delete-horizontal-space)
>(indent-to-left-margin)
> -  (insert-before-markers-and-inherit fill-prefix))
> +  (when fill-prefix
> +(insert-before-markers-and-inherit fill-prefix)))
>
> I don't have anything better.  I think this is a good patch.  It makes
> M-j work again.
>
> Possible refinements and improvements can follow.
>
> +1 for applying of your patch.
>

I am able to reproduce that M-j issue (using Emacs version: GNU Emacs
28.0.60 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version
1.15.12)
 of 2021-11-29, built using commit
c4daff9cf844ec85930bdcd2064787c92c260861, and Org mode version 9.5
(release_9.5-292-g5e35de)).

And this patch fixes that for me as well.

+1 for applying this patch.

=

Before this patch, M-j gave this backtrace with debug enabled:

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
  insert-before-markers-and-inherit(nil)
  org-comment-line-break-function(nil)
  default-indent-new-line(nil t)
  funcall-interactively(default-indent-new-line nil t)
  call-interactively(default-indent-new-line nil nil)
  command-execute(default-indent-new-line)


Output of C-h k M-j:

M-j runs the command default-indent-new-line (found in global-map),
which is an interactive compiled Lisp function in ‘simple.el’.

It is bound to C-M-j, M-j.

(default-indent-new-line  SOFT FORCE)

Break line at point and indent.
If a comment syntax is defined, call ‘comment-line-break-function’.

The inserted newline is marked hard if variable ‘use-hard-newlines’ is true,
unless optional argument SOFT is non-nil.


Re: babel output seems to drop anything before % (in session)

2021-11-09 Thread Kaushal Modi
Hello all,

I am following up on this issue with ob-shell and sessions.

I had posted the recipe to reproduce the issue few months back, and it
still applies; ref:
https://list.orgmode.org/CAFyQvY2AeToQc2G=e+de4votetfbkvisenipypw1y-feu1o...@mail.gmail.com/

Thanks!

--
Kaushal Modi


Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

2021-11-05 Thread Kaushal Modi
On Fri, Nov 5, 2021, 9:48 AM Ihor Radchenko  wrote:

>
> I am not sure if we are dropping Emacs 25 just yet. However, there is
> currently more than one place in Org that does not work on Emacs 25.
> See https://list.orgmode.org/87zgqu6081.fsf@localhost/T/#t
>
> If compilation is critical for you, I can make a patch to make things
> compile in Emacs 25. Though compatibility layer for xdg is more tricky.
> I do not want to do it unless necessary.
>

I haven't switched back to emacs 25 in a while. It's just that the script I
had for building Org started failing. All's good after removing the build
step for emacs 25.

I am anyways on emacs/master and then emacs-28 for a while now. So I
personally don't need emacs 25 compatibility. But in any case, this
breakage on emacs 25 should be fixed or the min req bumped to emacs 26.

>


Re: wrong-type-argument avl-tree- (org-persist-write-all-buffers) [org main + emacs emacs-28]

2021-11-05 Thread Kaushal Modi
On Fri, Nov 5, 2021 at 10:25 AM Ihor Radchenko  wrote:

> Fixed on main. Thanks for reporting!
>

Thanks! I confirm the fix.


wrong-type-argument avl-tree- (org-persist-write-all-buffers) [org main + emacs emacs-28]

2021-11-05 Thread Kaushal Modi
Hello all,

For few days now, I have been seeing the "wrong-type-argument avl-tree-"
error when I try to kill a buffer where org-persist has run.

I am seeing this with the latest build of emacs-28 branch plus org main
branch as of today.

Here's the backtrace:

Debugger entered--Lisp error: (wrong-type-argument avl-tree- nil)
  avl-tree-mapc(# nil)
  org-element--cache-persist-before-write(org-element--cache #)
  run-hook-with-args-until-success(org-element--cache-persist-before-write
org-element--cache #)
  #f(compiled-function (v) #)(org-element--cache)
  #f(compiled-function (elt) #)(org-element--cache)
  mapc(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-do(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-find(#f(compiled-function (v) #)
(org-element--headline-cache org-element--cache))
  org-persist-write((org-element--headline-cache org-element--cache)
#)
  org-persist-write-all(#)
  org-persist-write-all-buffer()
  kill-buffer("NEWS")

Are there any pointers on how to fix this?

Thanks!

--
Kaushal Modi


Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

2021-11-05 Thread Kaushal Modi
On Fri, Nov 5, 2021 at 9:27 AM Kaushal Modi  wrote:

> Hello,
>
> On the topic of xdg, I pulled Org from main branch today and tried to
> build it but it's failing with:
>
> org-persist.el:32:1:Error: Cannot open load file: No such file or
> directory, xdg
>
> Anybody else seeing this?
>

Figured out the problem.. looks like Org main branch doesn't support emacs
25.

My build script was building Org for all emacs versions starting from
version 25. It builds fine if remove the build  for emacs 25. I think I
missed it somewhere that Org main branch is dropping emacs 25 support.


Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

2021-11-05 Thread Kaushal Modi
On Fri, Nov 5, 2021 at 9:27 AM Kaushal Modi  wrote:

> Hello,
>
> On the topic of xdg, I pulled Org from main branch today and tried to
> build it but it's failing with:
>
> org-persist.el:32:1:Error: Cannot open load file: No such file or
> directory, xdg
>
> Anybody else seeing this?
>

To add more context, I am on emacs-28 branch right now.


Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

2021-11-05 Thread Kaushal Modi
Hello,

On the topic of xdg, I pulled Org from main branch today and tried to build
it but it's failing with:

org-persist.el:32:1:Error: Cannot open load file: No such file or
directory, xdg

Anybody else seeing this?


Re: Headings and Headlines

2021-07-23 Thread Kaushal Modi
On Fri, Jul 23, 2021 at 10:07 AM Marco Wahl  wrote:

> André A. Gomes  writes:
>
> > The project's documentation refers to headings and headlines as
> > synonyms.  Relying on a single definition would be beneficial.
>
> Agreed.  E.g. no more thinking waste about the question if it is
> headline or heading?
>

+1

> If I had to choose between the two, I'd go with heading.
>
> +1
>

+1

> If the community finds this valuable, I could prepare a patch.
>
> +1
>

+1

@André

> There's a problem though.  Function names would have to be changed,
> which would have to wait for version 10 otherwise we'd ruin backwards
> compatibility.

It doesn't have to break things drastically. When such changes are made,
you would define function aliases using `define-obsolete-function-alias'.
And then that obsoletion warning is removed after a few years.


Re: Comments break up a paragraph when writing one-setence-per-line

2021-07-16 Thread Kaushal Modi
Hello,


On Fri, Jul 16, 2021 at 12:35 PM Bruce D'Arcus  wrote:

> On Fri, Jul 16, 2021 at 12:07 PM William Denton  wrote:
>
> > However, I was a bit surprised when I found that a commented line starts
> a new
> > paragraph.
>
> I hadn't yet discovered that, but I think it should be considered a
> bug.


Comments causing paragraph breaks has been a long known behavior. I learned
about it few years back, probably from one of the threads here or by
reading the code.


> The output of your example should remove the commented line
> entirely, and so be:
>
> In this paragraph I introduce an idea.
> But I am sure about this. And here is my conclusion.
>
> Perhaps it can be easily fixed?
>

I don't think it would be a very easy fix as the behavior stems from an
intentional low level implementation in org-element.el. Changing this
behavior will cause a regression in all Org exporters out there.


Re: babel output seems to drop anything before % (in session)

2021-06-08 Thread Kaushal Modi
Hi Nick,

On Tue, Jun 8, 2021 at 11:54 PM Kaushal Modi  wrote:

>
> Thanks! I tried out your patch and it does fix the truncation of results
> output. Though, it retains the shell prompt in the first eval block and
> removes it only from the second eval block onwards.
>

I have one more feedback about the patch. I see that now indentation is
stripped away from ob-shell results.

I am documenting git commands in ob-shell.

In the terminal, `git log' outputs:

=
commit ba72672c499af8b713437d8c05eb5979969954dd (HEAD -> main)
Author: Foo Bar 
Date:   Tue Jun 8 23:56:48 2021 -0400

first commit
=

But in shell src block results, I see that that indentation is gone:

=
#+begin_src shell
git log
#+end_src

#+RESULTS:
:
: commit 34924761f042eab59567ec150a73c730ab2c929c (HEAD -> main)
: Author: Foo Bar 
: Date:   Tue Jun 8 23:56:48 2021 -0400
:
: first commit
=



Kaushal Modi


Re: babel output seems to drop anything before % (in session)

2021-06-08 Thread Kaushal Modi
On Thu, May 6, 2021 at 7:45 PM Nick Savage  wrote:

> So I have a patch written that doesn't completely fix the problem, but
> maybe makes enough progress that someone else can figure it out.
>
> The issue is that comint-prompt-regexp is reading the "% " as a prompt,
> and taking everyone off before it. I've added another parameter to
> org-babel-comint-with-output in the "meta" to pass our own regexp to
> replace comint-prompt-regexp, which works except when it doesn't. The
> regexp I've added is just "\n" now, so the newline characters are removed.
>
> The tests that Daniele added as a patch don't quite pass though with
> this. The issue is that something in the way the output is posted in the
> output buffer includes the prompt occasionally is included in a line and
> occasionally not. It seems the first time the block of code is executed,
> it is included (and therefore needs to be removed) and each other time
> it is not, so it is only the first time that it is run is not working
> properly.
>
> This is obviously way too fragile to actually merge, but I was hoping
> the work I've done so far is enough to help someone else make progress.
> I'll probably take another stab at this tomorrow (since it's bugging
> me), but thought I'd share what I have for now.
>
> Cheers,
> Nick
>

Thanks! I tried out your patch and it does fix the truncation of results
output. Though, it retains the shell prompt in the first eval block and
removes it only from the second eval block onwards.

Here's a MWE:

=
#+property: header-args:shell :exports both :results output :session
*ob-shell-session-issue*

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: sh-4.2$ 1 > 0

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 1 > 0

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 1 > 0

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 1 > 0
=


Re: babel output seems to drop anything before % (in session)

2021-06-08 Thread Kaushal Modi
Today I ended up on possibly a related issue with ob-shell results.

Observations:
1. Issue triggered when using :session
2. Output text is OK for the the first shell src block's output. But for
the second block, the output before '>' gets truncated.

Here's a minimal reproducible example:

=
#+property: header-args:shell :exports both :results output :session
*ob-shell-session-issue*

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 1 > 0

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 0
=

The root cause seems to be similar, with detection of shell prompt: '>',
'%', etc. when session is enabled.


--
Kaushal Modi


On Sat, May 15, 2021 at 4:48 PM Bastien  wrote:

> Hi Nick,
>
> Nick Savage  writes:
>
> > So I have a patch written that doesn't completely fix the problem, but
> > maybe makes enough progress that someone else can figure it out.
>
> I hope you can continue to make progress on this (annoying) one.
>
> Let us know!
>
> --
>  Bastien
>
>


Re: [ORG] Moving the org-mode.git repo to savannah.gnu.org

2021-06-01 Thread Kaushal Modi
Hello,

On Sun, May 16, 2021 at 3:53 AM Bastien  wrote:

> Dear all,
>
> with the help of the Savannah folks, I sat up a new org-mode.git repo:
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git
>
> The current master branch of Org is pushed to the main branch on Savannah
> and the current maint branch of Org is pushed to the bugfix branch there.
>

I am seeing that the master branch on
https://code.orgmode.org/bzg/org-mode/commits/master has newer commits than
the main branch on https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/
.

I am assuming that the complete switch to Savannah is still pending?

--
Kaushal Modi


Re: Regression in table.el detection? [maint]

2021-01-05 Thread Kaushal Modi
On Tue, Jan 5, 2021 at 12:09 PM Nicolas Goaziou 
wrote:

> Oops. Fixed. Thank you.
>

Thank you! for fixing this so quick :)

I confirm that fix you made in
https://code.orgmode.org/bzg/org-mode/commit/332da69b3c3ca222943728c20287e4ace6d40e61
.

Can you also please add a test for that? [My ox-hugo test suite will
anyways keep on serving via its weekly crons :) ]


Re: Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
Hi Kyle,

I was able to reproduce with issue with ox-html as well.

Please copy paste this in a new temp.org file and run `C-c C-e h H':

* Subtree 1
+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a| b| c|
+--+--+--+
| d| e| f|
+--+--+--+
* Subtree 2


The issue is when the "* Subtree 2" begins in the very next line after that
last line of table.el table ending in "--+".

When I export that, I see that ox-html fails to detect that table.el table
because I see this in the exported buffer:

=












Header 1
Header 2
Header 3




--


=

But if I introduce a newline before "* Subtree 2", the table.el table
detection works fine.



--
Kaushal Modi


Re: Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
On Tue, Jan 5, 2021 at 1:36 AM Kaushal Modi  wrote:

>
> I'll keep looking..
>

OK, when I added the same debug messages to ox-html.el, I see:

=
(table (:begin 1860 :end 2104 :type table\.el :tblfm nil :contents-begin
nil :contents-end nil :value "+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a| b| c|
+--+--+--+
| d| e| f|
+--+--+--+" :post-blank 1 :post-affiliated 1860
:parent (section (:begin 1703 :end 2104 :contents-begin 1703 :contents-end
2104 :post-blank 1 :post-affiliated 1703 :parent (org-data nil #2))
(special-block (:type "description" :begin 1703 :end 1783 :contents-begin
1723 :contents-end 1765 :post-blank 1 :post-affiliated 1703 :parent #2)
(paragraph (:begin 1723 :end 1765 :contents-begin 1723 :contents-end 1765
:post-blank 1 :post-affiliated 1723 :parent #3) #("Support tables written
in table.el format
" 0 42 (:parent #4 (paragraph (:begin 1783 :end 1860 :contents-begin
1783 :contents-end 1859 :post-blank 1 :post-affiliated 1783 :parent #2)
(verbatim (:value "ox-hugo" :begin 1783 :end 1793 :post-blank 1 :parent
#3)) #("Issue #" 0 7 (:parent #3)) (link (:type "https" :path "//
github.com/kaushalmodi/ox-hugo/issues/374" :format bracket :raw-link "
https://github.com/kaushalmodi/ox-hugo/issues/374; :application nil
:search-option nil :begin 1800 :end 1858 :contents-begin 1853 :contents-end
1856 :post-blank 0 :parent #3) #("374" 0 3 (:parent #4))) #("
" 0 1 (:parent #3))) #0)))
"
=

ox-hugo is stripping the leading/trailing spaces from the table cells,
while ox-html is not. Somehow that doesn't play with the recent change to
table.el detection.

I'll try fixing that in ox-hugo.


Re: Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
On Tue, Jan 5, 2021 at 1:15 AM Kyle Meyer  wrote:

>
>
> Exporting that table to html, I see "Before" on release_9.4.4, maint
> (273391c97), and master (00b4de329).
>
> You're able to trigger the issue with a vanilla configuration on maint?
>

Hi Kyle,

Thanks for checking. Indeed ox-html export does not show that issue.

But the weekly cron (and even local) ox-hugo exports started showing this
issue after the update to table.el table detection change that happened a
few weeks ago.

I'll investigate why only ox-hugo is showing this issue.. I am simply
calling the table.el related function from ox-html:

=
(defun org-blackfriday-table (table contents info)
  "Transcode TABLE element into Blackfriday Markdown format.

CONTENTS is contents of the table.  INFO is a plist holding
contextual information."
  ;; (message "[ox-bf-table DBG] In contents: %s" contents)
  (if (eq (org-element-property :type table) 'table.el)
  ;; "table.el" table.  Convert it using appropriate tools.
  (let ((tbl (org-html-table--table.el-table table info)))
(message "%S" table) ; just added this for debug
(message "%S" tbl) ; just added this for debug
=

and I am getting only partial table in the "tbl" variable

=
(table (:begin 1860 :end 2062 :type table\.el :tblfm nil :contents-begin
nil :contents-end nil :value "+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a | b | c |
+--+--+--+
| d | e | f |
+--+--+--+" :post-blank 1 :post-affiliated 1860
:parent (section (:begin 1703 :end 2062 :contents-begin 1703 :contents-end
2062 :post-blank 1 :post-affiliated 1703 :parent (org-data nil #2))
(special-block (:type "description" :begin 1703 :end 1783 :contents-begin
1723 :contents-end 1765 :post-blank 1 :post-affiliated 1703 :parent #2)
(paragraph (:begin 1723 :end 1765 :contents-begin 1723 :contents-end 1765
:post-blank 1 :post-affiliated 1723 :parent #3) #("Support tables written
in table.el format
" 0 42 (:parent #4 (paragraph (:begin 1783 :end 1860 :contents-begin
1783 :contents-end 1859 :post-blank 1 :post-affiliated 1783 :parent #2)
(verbatim (:value "ox-hugo" :begin 1783 :end 1793 :post-blank 1 :parent
#3)) #("Issue #" 0 7 (:parent #3)) (link (:type "https" :path "//
github.com/kaushalmodi/ox-hugo/issues/374" :format bracket :raw-link "
https://github.com/kaushalmodi/ox-hugo/issues/374; :application nil
:search-option nil :begin 1800 :end 1858 :contents-begin 1853 :contents-end
1856 :post-blank 0 :parent #3) #("374" 0 3 (:parent #4))) #("
" 0 1 (:parent #3))) #0)))
"

  

  Header1


  Header2


  Header3

  
"
=

I'll keep looking..


Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
Hello,

There has been a recent regression in table.el detection.

Earlier, this used to be detected as a table.el table, but now it's not
(entirely):


+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a| b| c|
+--+--+--+
| d| e| f|
+--+--+--+


Before:


  

  Header1


  Header2


  Header3

  
  

  a


  b


  c

  
  

  d


  e


  f

  



After:


  

  Header1


  Header2


  Header3

  


I stumbled across this regression as I was looking into why my weekly cron
for ox-hugo tests failed:
https://travis-ci.org/github/kaushalmodi/ox-hugo/jobs/752831865


--
Kaushal Modi


Re: pcase failure with Emacs 24 (was Emacs version for Org 9.4?)

2020-09-17 Thread Kaushal Modi
> On 2020-09-15, Kyle Meyer wrote:

> >
> >> It is pretty tricky to debug, but the failure starts with 4a27b67fd
> >> (org-element: Fix property drawers parsing, 2020-04-22).  As far as I
> >> can see, the pattern introduced there is perfectly valid and should be
> >> compatible with Emacs 24.  I'd _guess_ this is a pcase bug in Emacs 24,
> >> particularly the one fixed by 528872c5f8 (bug#18554, 2014-09-27), but I
> >> didn't make an effort to try to understand that commit.
> >>
> >> Interestingly, the error goes away if I just swap the elements in the
> >> pcase (and ...) pattern added by that commit.  Dunno, but if that clears
> >> up the failure on your end as well, I don't see any reason to not make
> >> that change.
> >>
> >>
> >> diff --git a/lisp/org-element.el b/lisp/org-element.el
> >> [...]
> >
> > Yes, that fixes the problem over here.
>
> Thanks for confirming.  Pushed (73c929e3b).
>
>
I just stumbled on this as I was looking into why ox-hugo tests failed on
emacs 24.x (
https://travis-ci.org/github/kaushalmodi/ox-hugo/builds/728059027 ). This
should pass next week now. Thanks for your fix.


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-09-07 Thread Kaushal Modi
On Sun, Sep 6, 2020, 5:37 PM Bastien  wrote:

> Hi Kaushal,
>
> sorry for the late reply, and thanks for the detailed report.
>
> Kaushal Modi  writes:
>
> > *The regression is that earlier (org-babel--string-to-number "1,3-5")
> > used to return nil, but now it returns 1.*
>
> This should be fixed now in master, as of 15a6836e4, it will be
> in Org 9.4.


Thank you very much! For now, I have just overridden that Org Babel
function in ox-hugo with a package-local fix. Once the maint is fixed, I'll
remove that workaround.


Re: ox-* vs org-* naming convention?

2020-06-10 Thread Kaushal Modi
Hello Diego,

That's great! Thanks for your PR.

On Wed, Jun 10, 2020 at 12:57 PM Diego Zamboni  wrote:

> Hi everyone,
>
> Just a quick update: issue
> https://github.com/purcell/package-lint/issues/89 submitted by Kaushal
> has been closed through the PR I submitted, so now package-lint
> officially accepts "org-" symbols in "ox-" and "ob-" packages :)
>
> --Diego
>


Re: ox-* vs org-* naming convention?

2020-06-07 Thread Kaushal Modi
Hello,

This came up when I submitted ox-hugo to Melpa as well[1].

I stayed with the norm.. naming the package ox-hugo, but naming all the
functions and variables with org-hugo-* prefix.

[1] https://github.com/purcell/package-lint/issues/89


Re: `#+author:' stopped setting the author to empty string

2020-05-20 Thread Kaushal Modi
On Tue, May 19, 2020 at 8:38 PM Kyle Meyer  wrote:

> Nicolas Goaziou writes:
>
> > At first glance, it looks harmless. If the test suite passes, we can
> > apply it.
>
> The test suite does pass with the change.  Pushed, along with a
> regression test (962b8e765).
>

Thank you for the debug and quick fix! I confirm the fix.


Re: `#+author:' stopped setting the author to empty string

2020-05-19 Thread Kaushal Modi
On Mon, May 18, 2020 at 7:30 PM Kyle Meyer  wrote:

>
> It bisects to b4e91b7e9 (New function: org-collect-keywords,
> 2020-04-26).  I haven't done much digging, but I was able to restore the
> behavior with the change below, which may be a bad idea for other
> reasons.
>

Thanks for that bisect!

If the current tests (and the new test with blank author "#+author:") pass,
then we should be good :)


`#+author:' stopped setting the author to empty string

2020-05-18 Thread Kaushal Modi
Hello,

At some point in the past month or so, I have noticed that on Org master,
#+author: does not set the author to empty in the exports.

Simply example to reproduce:

=
#+author:
Test
=

Run C-c C-e t A

Expected output:

=
Table of Contents
_




Test
=

Observed output:


=


Table of Contents
_




Test
=

I looked through the commits on master in the past month, but I don't see
any author-specific change that would affect *all* the exporter backends.

Can anyone else reproduce this issue?

--
Kaushal Modi


Re: Why not org-tempo insert upcased strings?

2020-04-27 Thread Kaushal Modi
On Mon, Apr 27, 2020, 4:35 AM tsuucat  wrote:

>
> > tsuucat  writes:
> >
> >>> Yes, the convention is now to have downcased keywords.
> >> Thanks. Is the convention documented?
> >>
> >> https://orgmode.org/manual/Structure-Templates.html#Structure-Templates
> 
> >> It doesn’t seems that The Org Manual uses such a convention.
> >
> > While the manual doesn't recommend which you should prefer (I don't
> > think), it does provide a rationale for its use of uppercase:
> >
> >(info "(org)Conventions")
> >
>
> Hmm…
> According to etc/ORG-NEWS, org-tempo.el was introduced in Org 9.2.
> Unfortunately the section doesn’t refer the change of convention.
>
> Why the convention is changed in org-tempo?
>

I'm a bit hazy about this, but I believe that org-tempo got introduced
after this commit:
https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0

This was a few years ago. There was even a discussion thread on this list
that showed preference to make that change.

https://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00449.html


Re: Why not org-tempo insert upcased strings?

2020-04-24 Thread Kaushal Modi
On Fri, Apr 24, 2020, 2:52 AM tsuucat  wrote:

> Hi,
> I tried Emacs 27 and found org mode shortcuts such as  then I found org-tempo.el.
>
> However, org-tempo.el’s shortcuts insert downcased blocks (e.g.
> #+begin_src).
> Is this intended?
>

Yes, the convention is now to have downcased keywords.

>


Re: Adding Romanian translation for ox.el

2020-04-21 Thread Kaushal Modi
On Tue, Apr 21, 2020 at 12:43 PM Claudiu Tănăselia 
wrote:

> Yay! My first contribution to org-mode and Emacs!
>
> Thank you cleaning it up and making it part of the official branch!
>
> Regards,
> Claudiu.
>

Congrats! Really glad you followed through the whole submission procession.
:)


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-03-05 Thread Kaushal Modi
On Thu, Mar 5, 2020 at 9:04 AM Bastien  wrote:

> Hi Kaushal,
>
> Kaushal Modi  writes:
>
> > I'm just pinging again on this thread to bring it to attention.
>
> I'm reading the list but I didn't find the time to reply to the
> threads yet, I'll get back to this.
>
> Thanks,
>

Thanks, no hurry. I just wanted to make sure that these issues are read
before Org 9.4 drops, and also that regression in Org maint is noted.


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-03-05 Thread Kaushal Modi
Hello,

I'm just pinging again on this thread to bring it to attention.

Thanks.

Kaushal


Re: Bug or not a bug? dot expansion in ob-shell

2020-02-27 Thread Kaushal Modi
Hello all,


On Wed, Feb 19, 2020 at 7:11 AM Bastien  wrote:

> Hi Eric,
>
> note that the previous behavior only _seemed_ right by chance: there
> is no notion of getting the exit code of the shell command in
> ob-shell.el, and returning "0" is just a hazard here, just because
> (org-babel--string-to-number ".") returns "0", while it should return
> nil.
>

Seems like I missed this long thread. After this change to
org-babel--string-to-number, now (org-babel--string-to-number "1,3-5") is
now returning 1 (instead of returning nil as before).

Related thread that I just started:
https://lists.gnu.org/r/emacs-orgmode/2020-02/msg00932.html


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Kaushal Modi
On Thu, Feb 27, 2020 at 9:13 AM Kaushal Modi  wrote:

> The regression is caused by
> https://code.orgmode.org/bzg/org-mode/commit/6b2a7cb20b357e730de151522fe4204c96615f98
> or the later commit that changes `org-babel--string-to-number'.
>
> Using this function redefinition with additional debug messages:
>
> (defun org-babel--string-to-number (string)
>   "If STRING represents a number return its value.
> Otherwise return nil."
>   (message "DBG: string: %S" string)
>   (unless (string-match-p "\\s-" (org-trim string))
> (let ((interned-string (ignore-errors (read string
>   (when (numberp interned-string)
> (message "DBG: interned string: %S" interned-string)
> interned-string
>
> I get:
>
> DBG: string: "1,3-5"
> DBG: interned string: 1
>
> So that ",3-5" piece of information is lost.
>

To be more specific, here is the call order:

org-babel-parse-header-arguments -> org-babel-read ->
org-babel--string-to-number

org-babel-read returns the string as-is if org-babel--string-to-number
returns nil.

*The regression is that earlier (org-babel--string-to-number "1,3-5") used
to return nil, but now it returns 1.*

I think that it should return a number only if 100% of the input string
represents a number. In the case of "1,3-5", it makes sense for it to still
return nil, so that org-babel-read does not throw away the ",3-5" piece of
information.


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Kaushal Modi
On Thu, Feb 27, 2020 at 9:00 AM Kaushal Modi  wrote:

> Failure 2: Change in parsing of org babel header arguments.
>
> The relevant snippet where I parse the header arguments in ox-hugo.el is
> at
> https://github.com/kaushalmodi/ox-hugo/blob/f8ec4aa5ad7d92f94bd8dbb814d85f980be67aea/ox-hugo.el#L2563
>
> This behavior change in org-babel-parse-header-arguments is also not
> documented in ORG-NEWS. I will now investigate what cause this regression.
>

The regression is caused by
https://code.orgmode.org/bzg/org-mode/commit/6b2a7cb20b357e730de151522fe4204c96615f98
or the later commit that changes `org-babel--string-to-number'.

Using this function redefinition with additional debug messages:

(defun org-babel--string-to-number (string)
  "If STRING represents a number return its value.
Otherwise return nil."
  (message "DBG: string: %S" string)
  (unless (string-match-p "\\s-" (org-trim string))
(let ((interned-string (ignore-errors (read string
  (when (numberp interned-string)
(message "DBG: interned string: %S" interned-string)
interned-string

I get:

DBG: string: "1,3-5"
DBG: interned string: 1

So that ",3-5" piece of information is lost.


Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Kaushal Modi
Hello,

I recently updated to the latest org-mode master and it is failing
ox-hugo[1] build and tests at 2 places.

Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS

Compiling ox-hugo.el now gives:

ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not
known to be defined.

I see that defun has now moved to org-refile.el. I see that
org-get-outline-path has nothing to do specific to refiling. Can that be
moved back to org.el, or may be a separate library? Otherwise, ox-hugo.el
will have to load org-refile.el too (yes, I don't use org-refile (yet), and
that's how I discovered this :))

Failure 2: Change in parsing of org babel header arguments.

This was caught by my weekly Travis CI cron jobs for ox-hugo:
https://travis-ci.org/kaushalmodi/ox-hugo/jobs/655410731#L2426

26c26
< {{< highlight emacs-lisp "hl_lines=1" >}}
---
> {{< highlight emacs-lisp "hl_lines=1 3-5" >}}

Earlier this kind of src block header:

#+begin_src emacs-lisp :hl_lines 1,3-5
...
#+end_src

got exported as

{{< highlight emacs-lisp "hl_lines=1 3-5" >}}

The regression is that now it is getting exported as

{{< highlight emacs-lisp "hl_lines=1" >}}

The values that I have after the comma in ":hl_lines 1,3-5" are getting
lost.

The relevant snippet where I parse the header arguments in ox-hugo.el is at
https://github.com/kaushalmodi/ox-hugo/blob/f8ec4aa5ad7d92f94bd8dbb814d85f980be67aea/ox-hugo.el#L2563

This behavior change in org-babel-parse-header-arguments is also not
documented in ORG-NEWS. I will now investigate what cause this regression.

...

--
Kaushal Modi

[1]: https://github.com/kaushalmodi/ox-hugo


Re: Survey: changing a few default settings for Org 9.4

2020-02-20 Thread Kaushal Modi
>
> > However, hiding emphasis and macro markers can make editing text at
> > the boundaries of emphasized text non-intuitive, which I can imagine
> > might frustrate some new users, so that should probably be carefully
> > considered.
>

+1e6


> Interestingly, hiding emphasis and macro markers are the two changes
> that get the *less* votes, so we probably won't change these.
>

Thank you! Hiding those will somehow take away the "Org-ness" in my humble
opinion :)


Re: A few changes to test in master

2020-01-31 Thread Kaushal Modi
On Fri, Jan 31, 2020, 9:45 PM Samuel Wales  wrote:

> org-table-header-line-mode?
>

+1

>


Re: A few changes to test in master

2020-01-31 Thread Kaushal Modi
On Fri, Jan 31, 2020, 6:28 AM Bastien  wrote:

> Dear all,
>
> I would like to highlight three changes from master that need to be
> carefully tested before Org 9.4 can be released:
>
> - M-x org-table-electric-header-mode RET will display the first row
>   of the table at point in the header line when the first row is not
>   visible anymore.
>

Hello Bastien,

Thanks for that mode!

Minor nitpick coming up..

May I suggest naming the mode org-table-sticky-header-mode instead? Somehow
the "electric" in the name wasn't intuitive to me.. or maybe that's just
me.


Re: documenting python module examples in orgmode

2019-12-09 Thread Kaushal Modi
On Mon, Dec 9, 2019, 5:49 AM Divan Santana  wrote:

> Hi All,
>
> I'm trying to document python module examples in orgmode.
>
> I'm sure this is possible, but not quite sure how to do it.
>
> I'd like to define the python module in one block, and then import it in
> another.
>

Have you looked at the Noweb syntax?

It might so what you want (inject code from one Org src block into multiple
other src blocks).

Here's an example from my notes where I use Noweb syntax with both Python
and Nim src blocks:
https://gitlab.com/kaushalmodi/kaushalmodi.gitlab.io/raw/master/content-org/notes/string-fns-nim-vs-python.org

>


Re: ox-latex: missing :LATEX_HEADER:

2019-12-04 Thread Kaushal Modi
On Wed, Dec 4, 2019 at 1:32 PM Karl Voit  wrote:

> Hi,
>
> For LaTeX export, I'd love to use ::LATEX_HEADER: instead of
> file-based settings with #+LATEX_HEADER.
>

Typically all Org export keywords work in properties too, but with an
"EXPORT_" prefix.

See if the ":EXPORT_LATEX_HEADER:" property works ..


Re: Gnus org-mode link problems in org 9.3

2019-12-04 Thread Kaushal Modi
On Wed, Dec 4, 2019 at 11:31 AM Kaushal Modi  wrote:

>
> Not sure if the issue you are seeing is because of the same cause.
>

It's very much likely that's the case:

>From https://orgmode.org/Changes.html :

> The old org-link-escape and org-link-unescape functions have been renamed
into org-link-encode and org-link-decode.


Re: Gnus org-mode link problems in org 9.3

2019-12-04 Thread Kaushal Modi
On Wed, Dec 4, 2019 at 11:27 AM Bob Newell  wrote:

> Aloha,
>
> Posting to both org-mode and gnus groups.
>
> Just updated to latest org (9.3 of 3 December) on Emacs 26.3.1
> and my gnus link functions seem to have quit.
>
> Now, whenever I do C-c C-o on an email link I get something like this:
>
> org-link-search: No match for fuzzy expression: gnus:nnimap+imap.gmail.com:
> %5BGmail%5D/All%20Mail#
> can9lugf6qkkyxt9ewjjs+hoyc6ywjasft4k4hv5zr2d10vy...@mail.gmail.com
>

Very strange! Just an hour back, my test suite failed because earlier
org-link-unescape used to unhex but now it doesn't. I haven't yet traced
back to the commit where this change happened.

Then replacing org-link-unescape with url-unhex-string fixed my use case[1].

Not sure if the issue you are seeing is because of the same cause.

[1]:
https://github.com/kaushalmodi/ox-hugo/commit/4badf135967c03c402ef8fc636ac4968ac98e57c


  1   2   3   4   5   6   7   8   >