From: Nicolas Goaziou <firstname.lastname@example.org>
To: Ramesh Nedunchezian <email@example.com>
Subject: Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Date: Fri, 02 Apr 2021 16:59:44 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <TY2PR0101MB369308F8E1F04D7DC4AE570CDA7A9@TY2PR0101MB3693.apcprd01.prod.exchangelabs.com> (Ramesh Nedunchezian's message of "Fri, 2 Apr 2021 10:03:48 +0530")
Ramesh Nedunchezian <email@example.com> writes:
> While in the lint buffer, I was expecting that M-g M-n, M-g M-p would
> take me to the relevant source lines. Unfortunately, this isn't the
> case. And the linter report is derived from
> `org-lint--report-mode-map' which is derived from
> `tabulated-list-mode'. The departure from convention surprised me.
I don't know what convention you're talking about and I don't understand
why that would be unfortunate. I think RET will take you to the relevant
source lines whereas TAB and C-j will display them. See manual, or minor
mode docstring, for details.
> And .... the following snippet works fine i.e., The linter finds any
> issue with an "unknown" language but complaints if the "unknown"
> language happens to be empty.
> #+begin_src zzzzzzzzzzzzz
> make packages/<pkgname>
> I wonder why an unknown langauge would be acceptable for export and
> not a "empty" language.
> Isn't source blocks with no language equivalent to example blocks.
I don't think such assumption is written anywhere. If that was the case,
we wouldn't need example blocks, would we? A source block without
a source language is just a meaningless construct. Forcing a meaning
here would just be a sad hack, IMO.
next prev parent reply other threads:[~2021-04-02 15:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 8:17 Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)] Ramesh Nedunchezian
2021-04-01 15:16 ` Nicolas Goaziou
2021-04-02 4:09 ` Ramesh Nedunchezian
2021-04-02 14:50 ` Nicolas Goaziou
2021-04-02 4:33 ` Ramesh Nedunchezian
2021-04-02 14:59 ` Nicolas Goaziou [this message]
2021-04-03 4:44 ` Ramesh Nedunchezian
2021-04-03 9:26 ` Nicolas Goaziou
2021-04-03 11:41 ` Ramesh Nedunchezian
2021-04-03 14:40 ` Ramesh Nedunchezian
2021-04-03 14:50 ` Ramesh Nedunchezian
2021-04-03 19:50 ` Nicolas Goaziou
2021-04-04 4:26 ` Ramesh Nedunchezian
2021-04-07 17:59 ` Nicolas Goaziou
2021-04-08 14:00 ` Ramesh Nedunchezian
2021-04-19 9:30 ` Nicolas Goaziou
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).