таблица markdown с длинными линиями

Я использую markdown для создания таблицы. Мой столбец Description содержит очень длинные тексты, и поэтому он выглядит очень плохо в файле 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.

Я хочу обернуть строки, так как это более читаемо для меня.
Есть ли способ сделать таблицу более читаемой для редактора?

12
markdown octopress

4 ответов

Я считаю, что @Naor прав: вы должны использовать HTML для создания разрывов строк, хотя это не показано в ответе. И полный отображаемый код таблицы не является строго необходимым: для достижения разрыва строки вам нужно только двойное пространство или <br /> тег. из спецификации Markdown:

Markdown поддерживает" жесткие " текстовые абзацы. Это отличается значительно от большинства других форматеров text-to-HTML (включая Подвижный тип " конвертировать разрывы строк" вариант) которые переводят каждый символ разрыва строки в абзаце на <br /> тег.

когда вы хотите вставить <br /> тег break с помощью Markdown, вы заканчиваете в соответствии с двумя или более пробелами, затем тип возврата.

обратите внимание, что мне пришлось добавить обертки кода в текст, потому что так ароматизированная уценка требует 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>

Я пробовал добавлять style="width:75%" до <td>s, не влияет.

*Я должен отметить, что я столкнулся с этим, потому что у меня возникли аналогичные проблемы с написанием кода в таблицах с использованием GitHub-ароматизированной Markdown, что очень больно. Но я отмечаю это, потому что это должно окрашивать примеры, которые я даю: все, что я говорю "работает" или "не работает", происходит из этой среды.

EDIT: это может быть еще стоит отметив, что это не имеет значения, если у вас есть code блоки в вашей таблице. Это не проблема с Markdown, хотя: HTML <code></code> блоки заставляют таблицу растягиваться.

5

есть еще один вариант. Поскольку философия заключается в том, что 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.                                                    |
|-------------|---------------------------------------------------------------|

... и готово.

3

к сожалению вы должны использовать HTML для этого

<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>
2

Привет мне было интересно то же самое. Мне нужно это для файла документации, и вот как я с этим справляюсь:

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

Я согласен с Сэмом, о котором идет речь выше, что уценка должна быть "жестким" языком, и для этого это обман (я думаю, что это не действительная уценка). Но, например, в нескольких проектах 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-парсера или тестовой таблицы Cucumber.

но я могу ошибаться

1