From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-orgmode@gnu.org
Subject: Re: setting local variables
Date: Wed, 06 Sep 2017 10:44:32 -0700 [thread overview]
Message-ID: <87k21b7mdb.fsf@ericabrahamsen.net> (raw)
In-Reply-To: 874lsfaho3.fsf@nicolasgoaziou.fr
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I think I ran into trouble just doing a simple `org-store-link' from an
>> Info file, then `org-insert-link' in the Org mode manual.
>>
>> That produced:
>>
>> [[info:org#Installation][info:org#Installation]] -->
>> @ref{Installation,@ref{Installation,,,org,},,org,} -->
>> *note *note (org)Installation::: (org)Installation.
>
> This bug was fixed months ago, when we removed support for nested links.
Bah, sorry. I'm on org-plus-contrib.
>> Why not just change the behavior of `org-export-headline-levels' for
>> texinfo output? We can already make plain lists, it doesn't seem useful
>> to me to also turn minor headings into lists. Since texinfo has the
>> concept of pages, why not just inline headings below H: level?
>
> We can certainly do that, but that doesn't solve the real problem. Such
> headings could be generated at any level. Conversely, you may want to
> have a deeper level in some section, so H:4 would be mandatory.
>
> Maybe UNNUMBERED property could imply a "not in TOC" clause in every
> back-end (I assume this is difficult to implement for LaTeX, though). In
> that case, UNNUMBERED would be a generic answer the problem.
>
> Or UNNUMBERED could imply "not in TOC" in "ox-texinfo.el", but that's
> less good, IMO.
Right, the headline-levels approach is not very graceful. I like
using UNNUMBERED, that seems conceptually correct.
>>> IMO, advanced marking is not needed, at least out of the box. For
>>> example, @kbd{M-@key{TAB}} in Texinfo is morally equivalent to
>>> ~M-<TAB>~ in Org, as long as the document targets info.
>>
>> Morally equivalent in that they're typeset the same, right?
>
> Correct.
>
>> I decided to embrace texinfo pedantry and make a kbd macro :)
>
> I think it really matters if you're going to use the Texinfo file to
> produce other formats than "info" (e.g., you're writing a GNU manual).
> If that's only for the "info" part, ~M-<TAB>~ is infinitely more
> readable.
I don't think anything needs to be done here, it's just a matter of what
authors want.
>> I'd be happy to provide a patch, and I think we should mention
>> `org-texinfo-text-markup-alist', as well. Then we can say "here's how
>> Org's basic markup elements are translated, here's a defcustom you can
>> play with, and failing that you can also make a macro".
>
> Sounds good.
>
>> To be honest I don't know how the markup alist is supposed to work,
>> though. If I mark up a phrase /like so/, shouldn't that count as
>> "italic", and get transformed into @emph{like so}?
>
> It should, and it does.
>
>> Right now it goes through unchanged into the Info file, which doesn't
>> seem right, since the Texinfo manual seems to indicate that _this_ is
>> the proper way to do emphasis.
>
> I cannot reproduce the problem.
I'll assume it's something version related, or local.
>> The other thing I'd like to expand is the "Plain lists in Texinfo
>> export" section. First of all, it's about definition lists, not plain
>> lists, which I found confusing. Also, I think it just needs to have more
>> basic information in it, unless you already know texinfo well, it's hard
>> to know what it's telling you.
>
> Agreed.
Great, I'll do this in the next couple of days.
Thanks,
Eric
next prev parent reply other threads:[~2017-09-06 17:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 21:53 setting local variables Eric Abrahamsen
2017-08-02 22:10 ` Kaushal Modi
2017-08-02 22:15 ` Eric Abrahamsen
2017-08-03 10:52 ` Nicolas Goaziou
2017-08-03 16:11 ` Eric Abrahamsen
2017-08-03 22:02 ` Nicolas Goaziou
2017-08-03 22:49 ` Eric Abrahamsen
2017-08-04 0:42 ` Eric Abrahamsen
2017-08-04 15:37 ` Nicolas Goaziou
2017-08-05 1:06 ` Eric Abrahamsen
2017-08-05 8:50 ` Nicolas Goaziou
2017-08-05 19:14 ` Eric Abrahamsen
2017-09-05 11:48 ` Rasmus
2017-09-05 16:57 ` Eric Abrahamsen
2017-09-06 8:56 ` Rasmus
2017-09-06 10:38 ` Nicolas Goaziou
2017-09-06 12:42 ` Rasmus
2017-09-06 13:08 ` Nicolas Goaziou
2017-09-06 16:33 ` Eric Abrahamsen
2017-09-06 16:57 ` Nicolas Goaziou
2017-09-06 17:44 ` Eric Abrahamsen [this message]
2017-09-07 8:56 ` Rasmus
2017-09-07 12:48 ` Nicolas Goaziou
2017-09-07 15:01 ` Eric Abrahamsen
2017-09-10 13:55 ` Nicolas Goaziou
2017-09-20 16:17 ` Carsten Dominik
2017-09-20 18:42 ` Scott Randby
2017-09-20 23:16 ` Kaushal Modi
2017-09-21 8:38 ` Carsten Dominik
2017-09-21 9:39 ` Rasmus
2017-09-21 9:58 ` Carsten Dominik
2017-09-21 19:21 ` Nicolas Goaziou
2017-09-21 21:25 ` Kaushal Modi
2017-09-22 7:22 ` Carsten Dominik
2017-09-22 9:09 ` Rasmus
2017-09-21 13:00 ` Scott Randby
2017-09-21 7:45 ` Eric S Fraga
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k21b7mdb.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).