[-- Attachment #1: Type: text/plain, Size: 3340 bytes --] Hello I am using a Emacs with no custom config. Here is the version info Emacs : GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-03-20 Package: Org mode version 9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/) When I export the following snippet to TexInfo format the export fails. ** To add a package: (submission, submit) Adding a basic package is very simple. There are thorough instructions below, but the gist of it is that you: (FWIW, the above snippet is from the README file of Emacs's official ELPA repo. cf. https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/README#n80) The error report in *Messages* buffer is Processing Texinfo file test.texi... test.texi:4: warning: @settitle missing argument test.texi:11: warning: @title missing argument test.texi:23: @menu reference to nonexistent node `(submission' test.texi:26: warning: node `Top' is up for `To add a package (submission submit)' in sectioning but not in menu test.texi:18: node `Top' lacks menu item for `To add a package (submission submit)' despite being its Up target org-compile-file: File "/home/rameshnedunchezian/test.info" wasn’t produced. See "*Org INFO Texinfo Output*" for details The error reported in *Org INFO Texinfo Output* is test.texi:4: warning: @settitle missing argument test.texi:11: warning: @title missing argument test.texi:23: @menu reference to nonexistent node `(submission' test.texi:26: warning: node `Top' is up for `To add a package (submission submit)' in sectioning but not in menu test.texi:18: node `Top' lacks menu item for `To add a package (submission submit)' despite being its Up target This is how test.texi looks like \input texinfo @c -*- texinfo -*- @c %**start of header @setfilename test.info @settitle @documentencoding UTF-8 @documentlanguage en @c %**end of header @finalout @titlepage @title @author Ramesh Nedunchezian @end titlepage @contents @ifnottex @node Top @top @end ifnottex @menu * To add a package: (submission, submit): To add a package (submission submit). @end menu @node To add a package (submission submit) @chapter To add a package: (submission, submit) Adding a basic package is very simple. There are thorough instructions below, but the gist of it is that you: @bye When in texi buffer I do Menu -> TexInfo->Makeinfo buffer, I get the same error. This is not surprising. Next, I removed the menu entry by hand and did Menu->TexInfo->Make Menu. I get the following input \input texinfo @c -*- texinfo -*- @c %**start of header @setfilename test.info @settitle @documentencoding UTF-8 @documentlanguage en @c %**end of header @finalout @titlepage @title @author Ramesh Nedunchezian @end titlepage @contents @ifnottex @node Top @top @end ifnottex @menu * To add a package (submission submit):: @end menu @node To add a package (submission submit) @chapter To add a package: (submission, submit) Adding a basic package is very simple. There are thorough instructions below, but the gist of it is that you: @bye The above texi output compiles well to info, and the resulting info file is browsable. Looks like the TexInfo exporter may have to take some extra steps when there is a 'colon' in the headline text. [-- Attachment #2: Type: text/html, Size: 4815 bytes --]
Hello,
Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes:
> When I export the following snippet to TexInfo format the export fails.
>
>
> ** To add a package: (submission, submit)
>
> Adding a basic package is very simple. There are thorough
This should now be fixed. Thank you.
Regards,
--
Nicolas Goaziou
On 01/04/21 8:46 pm, Nicolas Goaziou wrote: > Hello, > > Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes: > >> When I export the following snippet to TexInfo format the export fails. >> >> >> ** To add a package: (submission, submit) >> >> Adding a basic package is very simple. There are thorough > > This should now be fixed. Thank you. This fixes the issue I reported. Thanks. FWIW, TexInfo manual has a bunch of gotchas here: (info "(texinfo) Node Line Requirements") https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Node-Line-Requirements.html The following are the lines that seem relevant to the problem at hand. * Unfortunately, you cannot reliably use periods, commas, or colons within a node name; these can confuse the Info reader. Also, if you insist on using these characters in node names (accepting the resulting substandard Info output), in order not to confuse the Texinfo processors you must still escape those characters, by using either special insertions (*note Inserting a Comma::) or '@asis' (*note @asis::). For example: @node foo@asis{::}bar As an example of avoiding the special characters, the following is a section title in this manual: @section @code{@@unnumbered}, @code{@@appendix}: ... But the corresponding node name lacks the commas and the subtitle: @node @unnumbered @appendix
On 01/04/21 1:47 pm, Ramesh Nedunchezian wrote:
> (FWIW, the above snippet is from the README file of Emacs's official ELPA repo. cf. https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/README#n80)
While I was trying to convert the above `org' file to `info' I
observed the following:
1. org linter report being /unlike/ compilation buffer.
2. source blocks with do /not/ specify a language failing to export.
The file has two source blocks like with "empty" language. (Note that
there are other src blocks in that file, which /do/ specify language
as shell.)
#+begin_src
make packages/<pkgname>
#+end_src
and doing C-c C-e i o results in a failure.
M-x org-lint produces the following result
44 high Missing language in source block
51 high Missing language in source block
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.
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>
#+end_src
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.
Hello,
Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes:
> FWIW, TexInfo manual has a bunch of gotchas here:
>
> (info "(texinfo) Node Line Requirements")
>
> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Node-Line-Requirements.html
>
> The following are the lines that seem relevant to the problem at hand.
No, this is a different issue. We're talking about the first part of
a menu entry, which doesn't have the same limitations as a node name.
Those limitations are not explicit in the Texinfo manual, AFAICT.
Regards,
--
Nicolas Goaziou
Ramesh Nedunchezian <rameshnedunchezian@outlook.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> > #+end_src > > 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. Regards,
On 02/04/21 8:29 pm, Nicolas Goaziou wrote:
> Ramesh Nedunchezian <rameshnedunchezian@outlook.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.
I was expecting that the linter report will be in
`compilation-minor-mode`.
(info "(emacs) Compilation Mode")
If the linter buffer were in compilation mode, I can do M-g M-n, M-g
to move to next or previous errors. And these key-presses will work
when I am in _either_ of the source org buffer or linter report.
With things as it is now, is there a way I can quickly move between
next or previous errors, when I am in _either_ of the source buffer or
the linter report?
Hello, Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes: > I was expecting that the linter report will be in > `compilation-minor-mode`. Well, it isn't, obviously. > With things as it is now, is there a way I can quickly move between > next or previous errors, when I am in _either_ of the source buffer or > the linter report? You move back to the linter report and proceed from there. I cannot think of any other way. Regards, -- Nicolas Goaziou
On 03/04/21 2:56 pm, Nicolas Goaziou wrote: > Hello, > > Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes: > >> I was expecting that the linter report will be in >> `compilation-minor-mode`. > > Well, it isn't, obviously. > >> With things as it is now, is there a way I can quickly move between >> next or previous errors, when I am in _either_ of the source buffer or >> the linter report? > > You move back to the linter report and proceed from there. I cannot > think of any other way. Some one has integrated flycheck with `org-lint'. I am copying their code verbatim here https://github.com/flycheck/flycheck/issues/1757#issuecomment-759546940. Full credit goes to https://github.com/czikus. The author of the snippet is massaging (org-lint)'s output--note that this is a elisp list--in to something that one wold expect from a compiler i.e., a set of error messages in stdout. Flycheck is invoking emacs on command line. This suggests that making (org-lint) throwout errors on stdout would be of immediate use to flycheck-like apps. That said, it would be useful to add file name (optionally) to the tabulated list output. (What if one wants to run `org-lint' on all files that they want to publish?) (defconst flycheck-org-lint-form (flycheck-prepare-emacs-lisp-form (require 'org) (require 'org-attach) (let ((source (car command-line-args-left)) (process-default-directory default-directory)) (with-temp-buffer (insert-file-contents source 'visit) (setq buffer-file-name source) (setq default-directory process-default-directory) (delay-mode-hooks (org-mode)) (setq delayed-mode-hooks nil) (dolist (err (org-lint)) (let ((inf (cl-second err))) (princ (elt inf 0)) (princ ": ") (princ (elt inf 2)) (terpri))))))) (defconst flycheck-org-lint-variables '(org-directory org-id-locations org-id-locations-file org-attach-id-dir org-attach-use-inheritance org-attach-id-to-path-function-list) "Variables inherited by the org-lint subprocess.") (defun flycheck-org-lint-variables-form () (require 'org-attach) ; Needed to make variables available `(progn ,@(seq-map (lambda (opt) `(setq-default ,opt ',(symbol-value opt))) (seq-filter #'boundp flycheck-org-lint-variables)))) (flycheck-define-checker org-lint "Org buffer checker using `org-lint'." :command ("emacs" (eval flycheck-emacs-args) "--eval" (eval (concat "(add-to-list 'load-path \"" (file-name-directory (locate-library "org")) "\")")) "--eval" (eval (flycheck-sexp-to-string (flycheck-org-lint-variables-form))) "--eval" (eval flycheck-org-lint-form) "--" source) :error-patterns ((error line-start line ": " (message) line-end)) :modes (org-mode))
On 03/04/21 2:56 pm, Nicolas Goaziou wrote: > Hello, > > Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes: > >> I was expecting that the linter report will be in >> `compilation-minor-mode`. > > Well, it isn't, obviously. > >> With things as it is now, is there a way I can quickly move between >> next or previous errors, when I am in _either_ of the source buffer or >> the linter report? > > You move back to the linter report and proceed from there. I cannot > think of any other way. Here is an attempt. (defun my-org-lint () (interactive) (let* ((file (buffer-file-name)) (file (file-relative-name (buffer-file-name) default-directory)) (lint-alist (org-lint)) (inhibit-read-only t) ;; Choose a format that matches any of error regexps in ;; `compilation-error-regexp-alist-alist' (msg-fmt "%f: line %l: %m")) (with-current-buffer (or (get-buffer-create "*My Org Lint*")) (pop-to-buffer (current-buffer)) (erase-buffer) (let ((filename (buffer-file-name))) (save-excursion (insert (mapconcat #'identity (cl-loop for (_ inf) in lint-alist collect (pcase-let ((`[,line ,trust ,msg ,rest] inf)) (format-spec msg-fmt (list (cons ?f file) (cons ?l line) (cons ?t trust) (cons ?m msg))))) "\n")))) (compilation-mode 1)))) Let myfile.org be a file with following content * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone <membername>@git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. then 1. C-x C-f myfile.org 2. M-x my-org-lint 3. M-g M-n to move between the errors. M-g M-n would work both in linter output buffer and the org source buffer The advantage is you move to an error, fix it, then M-g M-n, fix it and so on and so forth.
On 03/04/21 8:10 pm, Ramesh Nedunchezian wrote: > > > On 03/04/21 2:56 pm, Nicolas Goaziou wrote: >> Hello, >> >> Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes: >> >>> I was expecting that the linter report will be in >>> `compilation-minor-mode`. >> >> Well, it isn't, obviously. >> >>> With things as it is now, is there a way I can quickly move between >>> next or previous errors, when I am in _either_ of the source buffer or >>> the linter report? >> >> You move back to the linter report and proceed from there. I cannot >> think of any other way. > > Here is an attempt. > (defun my-org-lint () > (interactive) When I am re-using "*My Org Lint*" for some other file, I may have to change the `default-directory' as well. As a proof-of-concept the code I shared should hold good.
Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes:
> The advantage is you move to an error, fix it, then M-g M-n, fix it
> and so on and so forth.
But all reports are not errors. You may not want to fix them all either.
OTOH, you lose the ability to hide or ignore unwanted reports, or sort
them by trust level.
I don't think this is a net win. Maybe other users of Org Lint may want
to chime in.
Regards,
On 04/04/21 1:20 am, Nicolas Goaziou wrote: > Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes: > >> The advantage is you move to an error, fix it, then M-g M-n, fix it >> and so on and so forth. > > But all reports are not errors. You may not want to fix them all either. > OTOH, you lose the ability to hide or ignore unwanted reports, or sort > them by trust level. If you are using `compilation-minor-mode'--yes, the minor mode and not the major mode--you can have goodness of /both/ tabulated list mode and compilation mode. Here is an attempt. (require 'compile) (add-to-list 'compilation-error-regexp-alist 'org-lint) (add-to-list 'compilation-error-regexp-alist-alist (list 'org-lint "^[[:blank:]]+\\([[:digit:]]+\\)[[:blank:]]+\\(high\\|low\\)[[:blank:]]+\\(.+\\)$" (lambda nil (buffer-file-name org-lint--source-buffer)) 1 nil nil 1)) (add-hook 'org-lint--report-mode-hook (defun turn-on-compilation-minor-mode () (compilation-minor-mode 1))) If you mix `compilation-minor-mode' and `tabulated-list-mode', then you may have to revise the key bindings so that they don't run in to each other. 1. C-x C-f myfile.org. (See below) 2. M-x org-lint 3. Goto `Warnings' column and press 'S'. Satisfy yourself that tabulated list commands are still available. Note that the line numbers are in "arbitrary" order. 4. Go to a random line. Press RET. Press M-g M-n (or M-g M-p) couple of times. Satisfy yourself that the order of traversal is controlled by the cursor's position in the report buffer. Seek a random position in org buffer. Say, bob or eob. Press M-g M-n (or M-g M-p) couple of times. Satisfy yourself that the order of traversal is controlled by the cursor's position in the report buffer. Contents of myfile.org: (Note that I have replicated the first tree many more times to get a large number of errors) * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone <membername>@git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone <membername>@git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone <membername>@git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone <membername>@git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone <membername>@git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want.
Hello,
Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes:
> If you are using `compilation-minor-mode'--yes, the minor mode and not
> the major mode--you can have goodness of /both/ tabulated list mode
> and compilation mode.
>
> Here is an attempt.
At this point, I may suggest to write a proper patch so Org users can
test it.
WDYT?
Regards,
--
Nicolas Goaziou
On 07/04/21 11:29 pm, Nicolas Goaziou wrote:
> Hello,
>
> Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes:
>
>> If you are using `compilation-minor-mode'--yes, the minor mode and not
>> the major mode--you can have goodness of /both/ tabulated list mode
>> and compilation mode.
>>
>> Here is an attempt.
>
> At this point, I may suggest to write a proper patch so Org users can
> test it.
>
> WDYT?
Thanks for the feedback. I would be most happy if you could borrow
ideas from my patch. (The changes are really small.)
Additional notes:
1. I didn't have information on how the trust levels map to the error
levels. I also had some difficulty getting the error, info, warning
highlighter to work.
2. My patch assumes that the org buffer is associated with a file.
This may not be true.
Hello, Ramesh Nedunchezian <rameshnedunchezian@outlook.com> writes: > Thanks for the feedback. I would be most happy if you could borrow > ideas from my patch. (The changes are really small.) Sorry, my plate is full already. Maybe someone else will want to give it a try. > Additional notes: > > 1. I didn't have information on how the trust levels map to the error > levels. I also had some difficulty getting the error, info, warning > highlighter to work. > > 2. My patch assumes that the org buffer is associated with a file. > This may not be true. This is a big drawback. Is it possible to circumvent this limitation? Regards, -- Nicolas Goaziou