When I use the gitbook editor's preview server, the numbering for the TOC is what I expect:
First Chapter
1.1 Sub-section
1.1.1. Sub-sub section
1.1.2. Second sub section
Second Chapter
2.1 Sub-section
When using command line gitbook to generate html, the result is different, and clearly incorrect:
First Chapter
1.2 Sub-section
1.2.3 Sub-sub section
1.2.4 Second sub section
Second Chapter
2.3 Sub-section
Any suggestions for what I'm doing wrong or how to correct it? Thank you!
From the documentation I think you need to prefix the subchapter lines with two dots:
..* Subchapter
Related
Is there any way by which I can add a useful message to a line in VS Code Editor which is not written in code but is like a note (Similar to like comments on a line in a Pull Request in Git) which can be deleted later on.
Here are the two extensions that I came across, hope this helps:
1). Line Note: https://marketplace.visualstudio.com/items?itemName=tkrkt.linenote
2). Code Annotation: https://marketplace.visualstudio.com/items?itemName=tkcandrade.code-annotation
I preferred Code Annotation for it's seemingly active org admin and the team of contributors and for marking notes as DONE or PENDING feature.
The "Line note" extension https://marketplace.visualstudio.com/items?itemName=tkrkt.linenote is probably what you are looking for…
Many languages allow you to append a comment to the end of a line. In python for example, you could have the following:
import numpy as np
a = 13.6 # a is the density of material
anser = a * b # where b is the volume in meters/cubic centimeters
...
Do not know what your language is but maybe this could work.
Comments can be added to code based on what language you are using. They are not specfic to the editor for the most part.
For example, in C++ you can comment by putting double slashes before the line such as // Random Comment.
Look up the commenting syntax for whatever code language you are using.
In org-mode, normal hierarchy goes like :
* Section 1
Content of section 1
** Section 1-1
Content of section 1-1
** Section 1-2
Content of section 1-2
As I understand it, everything after a header belongs to that section until it meets another (higher or lower) header.
But is it possible to break the current section without using another header, and to continue the content of the previous section? Something like :
* Section 1
Content of section 1
** Section 1-1
Content of section 1-1
** Section 1-1 end
Content of section 1 continues ...
** Section 1-2
Content of section 1-2
** Section 1-2 ends
Content of section 1 continues ...
There has been a long discussion in org-mode mailing list on this same issue.
Several proposals, but at the end, the need for simplicity and compatibility with LaTeX, DocBook and traditional book/article structures seem more important than allowing for content continuation after subheadings.
Also, content continuation after subheading sections end is in general not obvious to the reader.
One of the workarounds proposed is using lists as the sub-content. This is quite clear in the markup, and also for the reader.
This question already has answers here:
What does the number in parentheses shown after Unix command names in manpages mean?
(7 answers)
Closed 4 years ago.
I have a simple question I made my self but didn't find any answer and hints.
When I type for the man entries of a command, e.g. "man git", I get the following:
...
DESCRIPTION
...
See gittutorial(7) to get started, then see Everyday Git[1] ...
The Git User's Manual[2] has a more in-depth
introduction.
After you mastered the basic concepts, you can come back to this page to learn what commands Git offers. You can learn more about individual Git
commands with "git help command". gitcli(7) manual page gives you an overview of the command line command syntax.
Formatted and hyperlinked version of the latest Git documentation can be viewed at http://git-htmldocs.googlecode.com/git/git.html.
Could someone explain what are those "See gittutorial(7)...Everyday Git[1]...gitcli(7)" etc.? I mean, I know that they are telling "look at this resource if you want to know the basic concepts, for more info, etc.", but actually how should one interpret it?
What is the meaning of the numbers (like 7, 1, 2, etc..) inside the parenthesis or brackets? And where I can find the resources the manual is telling me to see, do I have to type something in the man prompt, or search on the Internet?
I just would like to ask for an elucidation.
Thank you for your attention!
Man pages are splitted into sections
to access a manual page inside a specific section you prepend the section number before the manpage name, for example try:
man 3 fork
or
man 2 fork
Usually the square braketed numbers are links to additional material in the NOTES section of the manpage (scroll to the bottom)
The parenthesized numbers indicate in which section of the manual the referenced entry appears. Section (1) is commands (programs), section (2) is system call functions, section (3) is general library functions, etc. Some terms have distinct entries in multiple sections. For example, this ...
man 1 printf
... gives a different manual page (from section 1, describing the printf program) than does this ...
man 3 printf
... which gives a page from section 3, describing the printf() function from the C standard library.
It means type man 7 gittutorial for more info. Man page are divided in numbered categories, sometimes overlapping. Use apropos git for instance to see the various possibilities.
The numbers in parentheses, manpage(N), are the manual section, each of the 8 sections covers a different topic.
See man-mages(7) ;) for a list of sections:
man man-pages
And you can open a manpage from a given section by including the number in the command:
man 7 man-pages
The numbers give you a hint of what the manpage will cover, e.g. time(1) is about a command, whereas time(2) is about a system call, and let you specify which section of the manual you're interested in when there's an entry with the same name on different sections.
The numbers between brackets, something[N] are footnotes, usually pointing to places where you can get more information.
I've searched around the web, and haven't found any procedure or tool that can distinguish those .docx files that are encoded as Strict ECMA-376 and those that are not. (same drill for .xlsx files) Most discussions center on which formats are supported by a given app, e.g. LibreOffice, but not how to distinguish files.
Dovetail question: 2. Does anyone know of any documentation that lays out the differences in the four editions of ECMA-376? http://www.ecma-international.org/publications/standards/Ecma-376.htm
On that page, you'll see first edition, second edition, third edition, fourth edition. First edition was 2006, and fourth edition is Dec 2012. None of the documentation appears to describe the revisions from one edition to the next, no "What's New in this edition" or anything like that. (In some cases they note structural changes, like a topic that was housed in Part 1 last time is now in Part 2, etc.)
Wikipedia describes the structural contents of the first two editions...: https://en.wikipedia.org/wiki/Office_Open_XML#Versions
...but has nothing to say about third or fourth editions, or substantive changes between the first two. Can anyone point me to documentation that lays out the iterative changes?
(ECMA-376 is normally mirrored by ISO 29500. ISO might document revisions, but their pubs are paywalled, and not just any paywall, but a 352 Swiss Franc paywall, which at today's exchange rates comes to $394.20...)
There are a couple of things to your questions:
Difference between Strict and Transitional
The main difference between Strict documents and Transitional documents is namespaces. The namespaces in Strict all contain #purl.org", as far as I remember, whereas namespaces in Transitional contain the word "microsoft". See the exact strings in Part 1 of OpenXml Standard for Strict and Part 4 for Transitional.
I do not think there is such a document available - and neither for the ISO-version.
And finally - you say that ECMA is mirrored by ISO. It is actually the other way around. Whenever ISO publishes a new version of the standard, an (almost) exact copy is published by ECMA (with their letter-head etc) afterwards.
And finally, finally, ISO OpenXml standard is free of charge. You can find the latest edition at http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html (search for "29500" on the page).
Should you wish to look a bit into what we do in the ISO working group, this is a good start: http://jtc1sc34.org/wg4 .
Jesper Lund Stocholm
Appointed Expert to ISO SC34 committee working with OpenXml.
According to section 17.2.3 of Ecma Office Open XML Part 1, the document element of the main document story will have an attribute "conformance" that specifies the conformance class. This can either be strict, or transitional. If the attribute is omitted, the default value is transitional.
Annex M of Ecma Office Open XML Part 1 (page 5028) documents the differences between ECMA-376:2012 and ECMA-376:2006.
Could anybody tell me if there are any tools could help to draw Effect Sketches described in Michael Feathers' book "Working Effectively with Legacy Code"??
The purpose of Effect Sketches is to show the interactions between the fields and methods in a group of coupling classes while browsing through the code.
For more information about Effect Sketches, please refer to the following blogs:
http://www.markhneedham.com/blog/2009/11/04/reading-code-unity/
http://www.markhneedham.com/blog/2010/02/23/coding-effect-sketches-and-the-mikado-method/
Thanks!
Ben Wu
The second article actually demonstrates such a tool: graphviz. Just look at the example given and write up a dot file. Then run it through the dot command line program form graphviz and you'll end up with the graph that looks like the one in the article.
A dot file is simply a description of relationships. For more on dot file syntax read up the documentation from the graphviz site or this wikipedia entry: http://en.wikipedia.org/wiki/DOT_(graph_description_language)