긴 줄이있는 표제탁 테이블

Question

테이블을 만들려면 markdown을 사용하고 있습니다. 내 설명 열은 매우 긴 텍스트를 포함하고는 인하 파일에 아주 나쁜 보이는 그 때문에 나는 라인을 포장 할 때 : 그것은 나를 위해 더 읽기 때문에

Argument   | Description | 
--------   | ----------- | 
appDir    | The top level directory that contains your app. If this 
option is used then it assumed your scripts are in |a subdirectory under this path. This option is not required. If it is not specified, then baseUrl below is the anchor point for finding things. If this option is specified, then all the files from the app directory will be copied to the dir: output area, and baseUrl will assume to be a relative path under this directory. 
baseUrl    | By default, all modules are located relative to this path. If baseUrl is not explicitly set, then all modules are loaded relative to the directory that holds the build file. If appDir is set, then baseUrl should be specified as relative to the appDir. 
dir     | The directory path to save the output. If not specified, then the path will default to be a directory called "build" as a sibling to the build file. All relative paths are relative to the build file. 
modules    | List the modules that will be optimized. All their immediate and deep dependencies will be included in the module's file when the build is done. If that module or any of its dependencies includes i18n bundles, only the root bundles will be included unless the locale: section is set above. 

나는 라인을 포장합니다.
편집기에서 테이블을 더 읽기 쉽게 만들 수있는 방법이 있습니까? 당신은 줄 바꿈을 만들기 위해 HTML을 사용해야합니다, 그는이 질문에 대해 입증되지 않은 비록 :

Answer 1

을 위해 HTML을 사용해야합니다. 그리고 표시되는 전체 테이블 코드는 반드시 필요한 것은 아닙니다. 줄 바꿈을 수행하려면 double space 또는 <br /> 태그 만 있으면됩니다. From the Markdown spec :

마크 다운은 "하드 랩」텍스트 단락을 지원합니다. 문단의 모든 줄 바꿈 문자를 <br /> 태그로 변환하는 대부분의 다른 텍스트 - HTML 형식 자 ( Movable Type의 "줄 바꿈 변환"옵션 포함)과 다른 글꼴이 다릅니다 ( ).

Markdown을 사용하여 <br /> 구분 기호를 삽입하려면 두 줄 이상의 공백이있는 줄을 끝내고 return을 입력하십시오. 소위 맛 마크 다운은 HTML 브레이크 태그 이스케이프가 필요하기 때문에 나는 텍스트 코드 래퍼를 추가했다

주 - 그래서 우리는 <br /> 일을 알고있다.

그러나, 당신은 당신과 같이 HTML로 다양한 속성을 설정할 수 없습니다 * 나는 같이 좀 더 복잡한 일을 수행하려는 경우 :

<table width="300"> 
    <tr> 
    <td> This is some text </td> 
    <td> This is some somewhat longer block of text </td> 
    <td> This is some very long block of text repeated to make it even longer. This is some very long block of text repeated to make it even longer. This is some very long block of text repeated to make it even longer. </td> 
    </tr> 
</table> 

나는 <td>들에 style="width:75%"를 추가하는 시도

에 어떤 영향을 .

* GitHub 맛의 Markdown을 사용하는 테이블에서 비슷한 문제가 발생하기 때문에이 문제가 발생합니다. 매우 고통 스럽습니다. 그러나 내가 말하는 예를 색칠해야하기 때문에이 점을 주목하고 있습니다. 내가 말하는 '작품'또는 '작동하지 않는 것'은 그 환경에서 비롯된 것입니다.

편집 : 테이블 내에 code 개의 블록이있는 경우에는 이것이 중요하지 않습니다. Markdown과 관련된 문제는 아닙니다 : HTML <code></code> 블록으로 인해 테이블이 늘어납니다.

Answer 2

슬프게도 당신은 내가 @Naor 옳다고 생각이

<table> 
<tr> 
<th>Argument</th> 
<th>Description</th> 
</tr> 
<tr> 
<td>appDir</td> 
<td>The top level directory that contains your app. If this option is used then 
it assumed your scripts are in</td> 
</tr> 
<tr> 
<td>baseUrl</td> 
<td>By default, all modules are located relative to this path. If baseUrl is not 
explicitly set, then all modules are loaded relative to the directory that holds 
the build file. If appDir is set, then baseUrl should be specified as relative 
to the appDir.</td> 
</tr> 
<tr> 
<td>dir</td> 
<td>The directory path to save the output. If not specified, then the path will 
default to be a directory called "build" as a sibling to the build file. All 
relative paths are relative to the build file.</td> 
</tr> 
<tr> 
<td>modules</td> 
<td>List the modules that will be optimized. All their immediate and deep 
dependencies will be included in the module's file when the build is done. If 
that module or any of its dependencies includes i18n bundles, only the root 
bundles will be included unless the locale: section is set above.</td> 
</tr> 
</table> 

Answer 3

안녕하세요. 저는 똑같은 것을 궁금해하고있었습니다. 나는 문서 파일이 필요하고 이는 내가이 다루고있어 어떻게 방법 :이가 거기에 "-하드 랩」언어로 생각하는 마크 다운 위의 질문에 샘에 동의하고

| key | description      | 
| --- | ---        | 
| foo | bla bla blabla bla blabla bla bla | 
|  | bla bla blabla bla bla bla bla bla | 
| bar | something else bla     | 

부정 행위 (나는 그것이 유효한 Markdown이 아닌 것으로 짐작한다).그러나 몇 가지 Github에서, 예를 들어 나는 사람들이이 같은 목록 항목을 포장했다 README.md 파일 프로젝트 : 또한

* foo 
* bla bla bla bla bla bla bla bla bla bla 
    bla bla bla bla bla bla bla bla bla 

을 내 대학 http://www.tablesgenerator.com/markdown_tables이 테이블과 유사한 방식 (덕분에 톰)

그래서 내가 무슨 생각을 감싸는 것을 지적 (Github 문서와 같은) 구문 분석되지 않는 무언가를 수행하는 경우 내 예제를 사용하는 것이 좋지만 HTML 파서 또는 오이 테스트 테이블에 대한 Markdown을 수행하는 경우 랩핑해서는 안됩니다.

하지만 내가 틀릴 수도 있습니다.

Answer 4

다른 옵션이 있습니다. Markdown은 마크 업 언어가 아닌 가볍고 자연스러운 인간 소비를 목표로한다는 철학이 있기 때문에 SGML/HTML 스타일 형식과는 달리 특수한 경우 ASCII 아트로 돌아갈 수 있다고 생각합니다. .

이 작업을 수행하려면 캐릭터 아트가 자연 스럽습니다. 따라서 네 칸을 사용하여 테이블을 들여 쓰고 가독성을 위해 멋지게 형식을 지정하면 Markdown은이 텍스트를 미리 형식이 지정된 텍스트로 취급하고 양측이 서로 싸우지 않게 할 수 있습니다. 예를 들어

:

| Sequence | Result              | 
|-------------|---------------------------------------------------------------| 
| `a?c`  | Matches `abc`, `axc`, and `aac`. Does not match `ac`, `abbc`, | 
|    | or `a/c`.              | 
|-------------|---------------------------------------------------------------| 
| `a*c`  | Matches "ac", "abc" and "azzzzzzzc". Does not match "a/c". | 
|-------------|---------------------------------------------------------------| 
| `foo...bar` | Matches "foobar", "fooxbar", and "fooz/blaz/rebar". Does not | 
|    | match "fo/obar", "fobar" or "food/bark".      | 
|-------------|---------------------------------------------------------------| 
| `....obj` | Matches all files anywhere in the current hierarchy that end | 
|    | in ".obj". Note that the first three periods are interpreted | 
|    | as "...", and the fourth one is interpreted as a literal "." | 
|    | character.             | 
|-------------|---------------------------------------------------------------| 

... 그리고 다.