Re: About exporting
Eric S Fraga writes: > On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote: >> And there is a final thing which (for me) seem to work better in >> latex-mode compared to org. That's jumping to the ``next error'' with >> some key stroke. That's important, LaTeX's own error output it quite >> poor, but jumping to error locations is vital. > > Yes, this is an issue I have as well. And the fact that the error > messages are for the LaTeX lines, not the org lines, so you end up > sometimes having to look at the LaTeX code and then go back to the org > file. This definitely adds friction! > >> I would not be surprised if some of that is somehow supported by org as >> well (for TeX), only I have not figured it out, or perhaps I was too >> lazy to figure it out how. > > No, I don't think there's anything (at the moment) to help with this. I > would love to be proven wrong, mind you! Org always has more > capabilities than I know... the only small bit of help I've found is org-lint, which has helped me find issues in the past. Doesn't help track down errors from *.tex -> pdf etc, but often an error in the org file causes the errors in the *.tex export. Having said that, I find the most common cause of errors in the *.tex export is due to in-line Latex in my org file. I rarely run into errors due to export of 'normal' org content. When I do run into problems, I just open the *.tex file in Auctex mode and track it down that way. Usually, it isn't too hard to work out where that relates back to the source org file. Being able to do that semi-automatically would be nice, but I think something that would be very difficult to implement. You would need something to parse the tex error output, extract text which could be then searched for in the org file. As mentioned, the problem is tex errors don't always contain that information, so you would probably also have to parse the tex file and then try to map that back to the corresponding part of the org file (which assumes of course that it is the org data which has caused the issue and not something relating to latex package or package configuration). -- Tim Cross
Re: About exporting
On Thursday, 1 Apr 2021 at 18:00, Tim Cross wrote: > the only small bit of help I've found is org-lint, which has helped me org-lint is very helpful indeed. > Having said that, I find the most common cause of errors in the *.tex > export is due to in-line Latex in my org file. I rarely run into errors > due to export of 'normal' org content. yes, true for me as well. the root cause of most of my errors are tikz pictures... one missing semicolon or a $ in the wrong place... The problem is that I often have these in beamer presentations and the errors are always at the end of the frame, not in the tikz picture. But this is now starting to be almost OT so enough. :-) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
Re: "Org" source blocks and minted
Yes, this looks very promising. I'm looking forward to playing with it when I have more time. On 27/03/21 12:55 am, Juan Manuel Macías wrote: > Hi Timothy, > > I really like your approach. And it is org/emacscentric! Minted has > never quite convinced me, and gives me some trouble with certain > packages in LuaLaTeX that I have not been able to solve. Thank you for > this promising alternative. > > Best regards, > > Juan Manuel > > Timothy writes: > >> Juan mentioned an Org lexer exists, but another approach that may be of >> interest is using Emacs' own font-lock. I wrote a package that's like >> HTMLize but works with LaTeX and currently have it sitting in my config. >> >> I plan on submitting a patch to Org at some point on this, but for now: >> - https://github.com/tecosaur/engrave-faces >> - https://tecosaur.github.io/emacs-config/config.html#pretty-code-blocks >> >> Sample output: all the code blocks in >> https://tecosaur.github.io/emacs-config/config.pdf >> >> Since this uses Emacs' font-lock, this means that you can use any >> language that you have a syntax-highlighting-mode for :) >
header-args property
I'm confused about the use of the header-args property. It works as expected when I export a file, but not when I evaluate a code block manually. For example, consider this file: #+PROPERTY: header-args :var x="Hello" :exports both #+begin_src shell echo X is $x #+end_src When I export, the result of the code block is "X is Hello", but when I use C-c C-c to evaluate the block in emacs, I get "X is"--the variable isn't defined. In practice, this means I generally define things like :session for each block, rather than using a file-level property. Is this behaviour expected? Kind regards, Mike
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/)]
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.
Re: About exporting
Eric S Fraga writes: > On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote: >> And there is a final thing which (for me) seem to work better in >> latex-mode compared to org. That's jumping to the ``next error'' with >> some key stroke. That's important, LaTeX's own error output it quite >> poor, but jumping to error locations is vital. > > Yes, this is an issue I have as well. And the fact that the error > messages are for the LaTeX lines, not the org lines, so you end up > sometimes having to look at the LaTeX code and then go back to the org > file. This definitely adds friction! This may sound facetious, but my current approach is just to not write LaTeX in Org files, and have only robust LaTeX I've already worked out the kinks for loaded. I think in part this works for me because of a particular system I have in place (that IMHO works *wonderfully* with Org) which I plan on submitting patches to upstream (to Org) in the not-to-distant future. -- Timothy
Re: Using backticks for the inline code delimeter?
I vote against backticks, since I think we can learn to live with some diversity. Running with the crowd, the latest fashion, would, in the end, leave us with something like Word and Windows, that is, something which is seductively easy to use the first two days, but a pain in the neck the rest of your life. Unfortunately, I have seen these tendencies in Linux, in Emacs -- yes, live-move-visual is now default, which makes Emacs less consistent, but more like Word -- and even in my favourite window manager. Please evaluate the design of Org Mode (and other things) without putting a value on how similar it is to other things. A bicycle would appear more familiar to a car driver if we replaced the handlebar with a steering wheel, but it wouldn't make the bike any better. If someones fingers cannot adjust, let him/her customise a bit. Just my two cents. Rasmus
Re: header-args property
Michael, i see "Hello" when i C-c C-c. i see this with "emacs -Q". cheers, Greg
Re: header-args property
On Thu, Apr 1, 2021 at 4:23 AM Michael Gauland wrote: > When I export, the result of the code block is "X is Hello", but when I > use C-c > C-c to evaluate the block in emacs, I get "X is"--the variable isn't > defined. > This works for me on org 9.4. I had trouble getting a file-level property to work across source blocks before, but it worked in a property drawer. I thought this was going to be that case, but I guess not. This seemed to work.
Re: About exporting
On Thursday, 1 Apr 2021 at 16:50, Timothy wrote: > I think in part this works for me because of a particular system I > have in place (that IMHO works *wonderfully* with Org) which I plan on > submitting patches to upstream (to Org) in the not-to-distant future. Interesting. Look forward to seeing this! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
Re: header-args property
On Thursday, 1 Apr 2021 at 21:23, Michael Gauland wrote: > When I export, the result of the code block is "X is Hello", but when > I use C-c C-c to evaluate the block in emacs, I get "X is"--the > variable isn't defined. Did you hit C-c C-c on the property line to update org's view of the properties set? I think on export it will read these anew for the export but executing C-cC-c on the src block will not pick up the value unless you have re-initialized. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
"#+STARTUP: hideblocks" has no effect?
Hi, I recently read about the #+STARTUP parameter "hideblocks", but it doesn't seem to have any effect in my set-up. All the blocks kept laughing straight in my face. :-( Any ideas about what could have gone wrong? I use Org Mode 9.4.5 with Emacs 26.3, and I also tried closing the file and Emacs before I tried. Cheers Rasmus p.s. Setting org-hide-block-startup with local variables is a solution, but not as nice as doing it with #+STARTUP, I'd say.
Re: About exporting
Eric S Fraga writes:
> On Thursday, 1 Apr 2021 at 16:50, Timothy wrote:
>> I think in part this works for me because of a particular system I
>> have in place (that IMHO works *wonderfully* with Org) which I plan on
>> submitting patches to upstream (to Org) in the not-to-distant future.
>
> Interesting. Look forward to seeing this!
If you want to get an "sneak peek" you may be interested in taking a
quick look at:
https://tecosaur.github.io/emacs-config/config.html#content-feature-preamble
In essence this system is the combination of LaTeX snippet / generated
content with feature detection.
For example, this is what I have for working with Julia code:
#+begin_src emacs-lisp
(add-to-list 'org-latex-conditional-features '((and org-export-has-code-p "^[
\t]*#\\+begin_src julia\\|^[ \t]*#\\+BEGIN_SRC julia\\|src_julia") .
julia-code) t)
(add-to-list 'org-latex-feature-implementations '(julia-code :snippet
org-latex-julia-mono-fontspec :order 0) t)
(add-to-list 'org-latex-feature-implementations '(.microtype-lualatex :eager t
:when (microtype julia-code) :prevents microtype :order 0.1 :snippet
"\\usepackage[activate={true,nocompatibility},final,tracking=true,factor=2000]{microtype}\n"))
(add-to-list 'org-latex-feature-implementations '(.custom-font-no-mono :eager t
:prevents custom-font :order 0 :snippet (org-latex-fontset :serif :sans)) t)
#+end_src
It's been evolving for a several weeks now, and I feel like it should
soon settle down enough that I will be happy preparing a patch based on
it.
--
Timothy
Re: About exporting
Eric S Fraga writes:
> On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
>> And there is a final thing which (for me) seem to work better in
>> latex-mode compared to org. That's jumping to the ``next error'' with
>> some key stroke. That's important, LaTeX's own error output it quite
>> poor, but jumping to error locations is vital.
>
> Yes, this is an issue I have as well. And the fact that the error
> messages are for the LaTeX lines, not the org lines, so you end up
> sometimes having to look at the LaTeX code and then go back to the org
> file. This definitely adds friction!
These days I'm working on a book (a dictionary) of over 1000 pages. The
preamble contains 1813 lines of code (+/-), and is written separately in
a Org document, through literary programming. Contains: a) A lot of
(La)TeX code written (or perpetrated) by me, b) some Lua functions to
control certain parts of the process, c) all the configuration for Xindy
(the indexes) in Common Lisp (inside a filecontents* environment).
Everything, of course, ordered by sections. With this cocktail it seems
that something can go wrong at some point :-) However I find it very
easy to debug having things well separated. And I can always tangle
different versions of the preamble...
As I have already mentioned, I use Org Publish intensively. Some parts
of my Org Publish setup for this project are:
[...]
:base-directory "~/Git/DHTC/libro/org/"
:base-extension "org"
; *.tex files and output
:publishing-directory "~/Git/DHTC/libro/tex/"
:publishing-function org-latex-publish-to-latex
:body-only t
:exclude "DHTC-master\\.org\\|bibli-dhtc\\.org"
Each part of the book is an *org document that I export to *tex using
Org-Publish (:body-only t). And each document only includes at the
beginning:
#+SETUPFILE: diccionario.setup
#+INCLUDE: "elisp"
(that is, a setup file and a file that I have named `elisp' where I include
functions and filters).
And then I have a master document, as simple as possible, where the
preamble and the subdocuments are added through '\input{...}'. I have
defined this macro:
#+MACRO: input (eval (if (org-export-derived-backend-p
org-export-current-backend 'latex) (concat "@@latex:\\input{@@" $1 ".tex"
"@@latex:}@@") $1))
And, with a simple Elisp function, I compile the final document (or
parts of it) using latexmk (with `start-process-shell-command'). I add
an argument so that a dedicated buffer is generated with the output of
latexmk. As latexmk runs in interactive mode, every time I do a change
in a subdocument and call Org-Publish again, latexmk rebuilds everything
automatically. The latexmk output is very neat and warns of possible
errors. Also I always have an alternative branch in the repository to do
tests when I put 'experimental' code.
By all this I mean that using LaTeX from Org (but without stopping using
LaTeX) gives me a pretty productive and organized workflow. I recommend
try it out for large books.
Best regards,
Juan Manuel
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/)]
Hello, Ramesh Nedunchezian 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
Re: bug with macro expansion after underscore (subscript)
Hello,
"Dauer, Michael" writes:
> I cannot expand a macro after underscore, as the following sample shows in
> detail:
>
> #+macro: xxx A
> * macro bug
> a _{{{xxx}}}
> a_{{{xxx}}}
The first pair of braces belongs to the sup/superscript syntax, as in
a_{foo}. IOW, you need a fourth pair of braces in this case.
Regards,
--
Nicolas Goaziou
Re: Bug: inconsistent escaping of coderef regexp
Hello, Tom Gillespie writes: > It is not possible to strip coderefs when tangling and also search for > those coderefs using org-link-search. This is because org-link-search > uses org-src-coderef-regexp which calls regexp-quote on the regexp > string while org-babel-tangle-single-block does not and uses the > regexp string directly without quoting it. I'm not sure about the best > way to fix this. It seems to me that the call to regexp-quote should > be removed but I'm not entirely sure of the consequences of doing > that. Thoughts? This would be wrong. A format string is not a regexp, and therefore needs to be quoted. E.g., one might want to use "/* %s */". `org-babel-tangle-single-block' should make use of `org-src-coderef-regexp' and, possibly, `org-src-coderef-format'. > PS While on the topic of coderefs, let me drop a note that is a > preview of some of the issues I have encountered while working on a > full formal grammar for org. Having the -l switch control this is an > awful design that induces more complexity into the org-mode grammar > than nearly any other feature. Source block switches are completely > inconsistent with the rest of org and completely undiscoverable. I had > no idea they even existed until I was trying to figure out which > header argument could be used to set the coderef regexp. The -l option > and switches in general need to have their behavior implemented as > part of the standard header arguments like everything else so that > users can migrate away from switches with an eye toward removing them > entirely. Switches predate Babel and its header arguments. Also, they are orthogonal to Babel. I don't know what a sound design would be here, tho. Regards, -- Nicolas Goaziou
Re: Bug: inconsistent escaping of coderef regexp
Nicolas Goaziou writes: > Switches predate Babel and its header arguments. Also, they are > orthogonal to Babel. I don't know what a sound design would be here, > tho. Breaking backwards comparability is a tough call, but somehow I feel that it would be appropriate here. A number of reasons why they should go come to mind: - Rarely used. Searching github I found 146k results for "#+begin_src" but as soon as I added a switch (I tried -n and +n) that dropped to 0 results - Easily replaced by a more consistent syntax, which has multiple benefits IMO + Simplify parsing a bit + Less forms for a new user to learn + Better consistency Perhaps a less sudden approach would to be mark them as depreciated, implement equivalents with the standard syntax, update manual to use the new/standard syntax, then remove at some point in the future? In that case I think it would also be acceptable for new things built for Org (e.g. a grammar) to ignore them. Thoughts? -- Timothy
Re: Using backticks for the inline code delimeter?
On 01/04/2021 02:24, Sébastien Miquel wrote: George Mauer writes: is there a straightforward way to extend the org parser to do this? For the cosmetic part, there's this piece of code from https://archive.casouri.cat/note/2020/better-looking-verbatim-markup-in-org-mode/index.html Personally, I consider marker appearance as a minor issue. The real pain is that, besides thinking on content, it is necessary to concentrate which type of plain text markup must be used at every moment. Switching between chat with markdown and bug tracker with a flavor of wiki markup, it requires additional efforts to avoid incorrect formatting. I do not mind to have backticks for code snippets in org but unfortunately the choice was done many years ago, so such change is unrealistic. Remapping "`" is rather intrusive. Would not be better to define a command and key binding that fix markers on the current line or in the current paragraph? A strange idea. If logic were perfectly decoupled from formatting it would be possible to have org actions with various formats (markdown, reStructured text, etc.) with some extensions to markup and limitations in respect to org functionality. I know that is unfeasible.
Re: Using backticks for the inline code delimeter?
Maxim Nikulin writes: > On 01/04/2021 02:24, Sébastien Miquel wrote: >> George Mauer writes: >>> is there a straightforward way to extend the org parser to do this? >> For the cosmetic part, there's this piece of code from >> https://archive.casouri.cat/note/2020/better-looking-verbatim-markup-in-org-mode/index.html > > Personally, I consider marker appearance as a minor issue. The real pain is > that, besides thinking on content, it is necessary to concentrate which type > of > plain text markup must be used at every moment. Switching between chat with > markdown and bug tracker with a flavor of wiki markup, it requires additional > efforts to avoid incorrect formatting. I do not mind to have backticks for > code > snippets in org but unfortunately the choice was done many years ago, so such > change is unrealistic. > > Remapping "`" is rather intrusive. Would not be better to define a command and > key binding that fix markers on the current line or in the current paragraph? > > A strange idea. If logic were perfectly decoupled from formatting it would be > possible to have org actions with various formats (markdown, reStructured > text, > etc.) with some extensions to markup and limitations in respect to org > functionality. I know that is unfeasible. This whole issue is why I made https://github.com/tecosaur/emacs-everywhere and https://github.com/tecosaur/org-pandoc-import :P -- Timothy
Re: Using backticks for the inline code delimeter?
n.b. everybody knows better in this thread, but the docstring of org-emphasis-alist seemed to me like `test` + reload would fontify.
Bug: org-link-descriptive needs to be buffer-local [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. I stumbled upon weird behavior when using `org-toggle-link-display', and I finally checked what that is about. Observation: - use `org-toggle-link-display' in org buffer A, and (coming from the defaults) links are now shown in full (not just the description), but only in buffer A - switch to org buffer B, still only showing the description part, and again use `o-t-l-d' --- nothing changes - the state for new org buffers is as before, onle link descriptions are shown. This behavior is very confusing, IMO. The reason is simple. The display hiding comes from changing the `buffer-invisibility-spec', which is automatically buffer-local. But the state of the org toggle is kept in `org-link-descriptive', which is global! I suggest a simple fix that I just tested: make `org-link-descriptive' automatically buffer-local, by adding ":local t" to the defcustom. NB: This also fixes a related bug that eval: (org-toggle-link-display) in the file-local works properly --- it did not work for me before. Thanks. Emacs : GNU Emacs 28.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-03-27 Package: Org mode version 9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)
Bug in formula updates when sorting table (and inserting hlines)
Hi! I have noticed a few times that sorting tables with C-c ^ does not update the formulas it contains. This has bitten me quite a bit, so it's good i have backups :) Here is a minimal example: | A | B | |+---| || 5 | || 4 | | 8 | 3 | | 6 | 2 | || 1 | |+---| | 14 | | #+TBLFM: @4$1=@2$2+@4$2::@5$1=@3$2+@5$2::@7$1=vsum(@I..@II) Sorting in column B (between the hlines) with C-c ^ n, moves the lines around as you would expect, but notice that there are no changes in the TBLFM line. A C-u C-u C-c * after a sort should not change the values, but of course it does in this example. The TBLMF line should have been changed to:#+TBLFM: @4$1=@6$2+@4$2::@3$1=@5$2+@3$2::@7$1=vsum(@I..@II) One could also try adding a hline between the 8 and the 6 in the original table by typing C-c -, assuming no values in the table should change from it, the formula line should update @I..@II to @I..@III. I would really appreciate it if someone with more knowledge of the org-mode guts could have a look at this and come up with a solution :) -- Peder Stray
Re: Using backticks for the inline code delimeter?
Samuel Wales writes: > n.b. everybody knows better in this thread, but the docstring of > org-emphasis-alist seemed to me like `test` + reload would fontify. Getting backticks to font-lock correctly is relatively easy. Getting the exporters to understand the new syntax is more of a challenge as is how to deal with backwards compatibility so that all your existing org files don't need to be modified. -- Tim Cross
Re: Using backticks for the inline code delimeter?
On Fri, Apr 02 2021, Tim Cross wrote: > Getting backticks to font-lock correctly is relatively easy. Getting the > exporters to understand the new syntax is more of a challenge Don't the exporters work off of some intermediate representation, like Pandoc does? I kinda thought that was what `org-element.el` was all about... And of course I meant to type ~org-element.el~ there... :D -- Joost Kremers Life has its moments
Re: Using backticks for the inline code delimeter?
Joost Kremers writes: > On Fri, Apr 02 2021, Tim Cross wrote: >> Getting backticks to font-lock correctly is relatively easy. Getting the >> exporters to understand the new syntax is more of a challenge > > Don't the exporters work off of some intermediate representation, like Pandoc > does? I kinda thought that was what `org-element.el` was all about... > > And of course I meant to type ~org-element.el~ there... :D Yes, at least most of the core ones should. However, I would still expect some surprises and of course there are no guarantees regarding the contrib and other external ones. Despite attempts to abstract the syntax to make it 'flexible', I would be surprised if there is not functionality in some of the exporters which has implicit assumptions regarding the syntax being used and is not isolated from such changes. Note that I'm not saying this cannot be done or even that is should not be done. I just want to highlight that just making changes to how org deals with it at the 'presentation' layer may not be sufficient and that you would have to verify there are no unexpected side effects in any of the exporters. If you wanted to keep backwards compatibility or make using ` and alternative to ~, you would also need to decide/verify things like `word~ (i.e. mixed delimiters) are handled correctly (i.e. simple regex with alternatives would not be sufficient - would need to be a match which allowed both but ensured matching values). Of course, there is a big difference between making a change to org and making a change to an individual's own org instance. So if we are talking about how someone can hack their own org instance to use ` instead of ~, it can be much simpler as they don't have to worry about the bits they don't use or backwards compatibility. The downside then becomes just the hassle of maintaining your hacks over subsequent org releases. One reason why I would probbly go with a method which just changes how I input data. For example, I would define a function which inserts ~ or if a region is marked, surrounds it in ~ and then just bind that to a key, never using ~ or ` directly to mark text. -- Tim Cross
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/)]
On 01/04/21 8:46 pm, Nicolas Goaziou wrote:
> Hello,
>
> Ramesh Nedunchezian 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
Re: Font lock in org+elisp confused with ?\[
I'm forwarding this to the emacs-orgmode list as this is something org maintainers probably need to see. On Thu, 1 Apr 2021 at 15:43, Arthur Miller wrote: > > Is it me or is it a bug? > > When in org mode in an elisp block, this seems to confuse syntax > checker: > > #+begin_src emacs-lisp > (progn > (if (= (following-char) ?\]) > (forward-char -1)) > ) > #+end_src > > Identation seems to think it is one level extra, and it also shows as > error. Same of course when testing for ?\[. > > It does evaluate correctly. Ordinary elisp buffer does not have problem > with this, only when in code blocks in org-mode or elisp mode.I can send > in some screenshot with errors if needed. > > > -- regards, Tim -- Tim Cross
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/)]
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/ #+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 z make packages/ #+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.
