タグ付けされた質問 「org-mode」

Emacsの主要なモードであり、メモを保持したり、TODOリストを維持したり、プロジェクトを計画したり、高速かつ効果的なプレーンテキストシステムでドキュメントを作成したりできます。Orgモードは広大なサブジェクトエリアであるため、他のタグに `org-mode`タグを付ける必要があります。

1
組織からラテックスにエクスポートするときにテキストを折り返す方法は?
LaTeXにエクスポートしてからPDFドキュメントにエクスポートする組織ファイルがあります。問題は、ページの長さを超える長いテキストがあることです。次の行に入るようにそれをラップする方法は? 最初の例: #+BEGIN_SRC c++ <code goes here> // very long comment that doesn't wrap ........ #+END_SRC コメントが非常に長く、ページの長さを超えています。折り返す方法は? 2番目の例: |------+------+------------------------+------| | text | text | text | text | |------+------+------------------------+------| | text | text | very long texttt...... | text | |------+------+------------------------+------| 一部のセルには折り返されない長いテキストが含まれていますが、折り返す方法は?

2
インライン画像を表示するOrgモードCc Cc
以下の組織モードのコード例: #+BEGIN_SRC plantuml :file test.png Alice -> Bob: synchronous call Alice ->> Bob: asynchronous call #+END_SRC #+RESULTS: [[file:test.png]] Cc Ccを押すと、結果は上記のようになります。画像として表示する必要がある場合は、「Mx org-display-inline-image」コマンドを実行する必要があります。 「Cc Cc」と「Mx org-display-inline-image」を組み合わせることができますか?「Cc Cc」ショートカットを使用することをお勧めします。
9 org-mode 

2
組織モードで画像リンクを作成する
組織モードでクリック可能な画像リンクを作成したい。これは次と同等です。 <a href="path-to-file"> <img src="path-to-image"> </a> 現在、私は、うまくインライン画像のプレビューを表示することができます[[path-to-image]]が続きますorg-toggle-inline-images。私が今やりたいのは、のサポートを追加することです[[path-to-file][path-to-image]]。 何か案は?

2
24時間ではなく1日8時間をカウントする組織モードのクロック合計
私はと仕様に努力推定値を使用してい1dたり4:00、これらが正しく8H念頭に置いて一日で収集されているが、これらは1日24時間をカウントするセクションの階層をまとめています。 これは非常に混乱しますcolumnview: #+COLUMNS: %80ITEM(Tâche) %7Effort(Est){:} #+BEGIN: columnview :maxlevel 2 | Tâche | Est | |-----------+---------| | * Group 1 | 16:00 | | ** Task A | 1d | | ** Task B | 1d | | * Group 2 | 1d 0:00 | | ** Task C | 1d …
9 org-mode 

1
orgmodeエクスポートでのHTMLテーブルのクラス属性の設定
HTMLエクスポートでテーブルのクラスを設定したいと思います。例: <table class="table table-striped"> テーブルをHTMLにエクスポートするためにいくつかの属性を設定することは可能であるようです #+ATTR_HTML: :border 2 :rules all :frame borderが、クラスの設定に関するドキュメントは見つかりませんでした。これは可能ですか?

2
orgmodeを高速化するにはどうすればよいですか?
私は、1万行を超えるノート行を含むorg-modeファイルを使用しており、ツリーのトラバース(基本的な上下の動きのみ)が非常に遅い(使用できないほど)。より速く動作させるにはどうすればよいですか? 大きなファイルを多数の小さなファイルに分割できることはわかっていますが、(*。org.gpgに)暗号化して、別のファイルを開くたびにパスワードを入力したくありません。 ご協力ありがとう御座います。
9 org-mode 

1
プロパティで照合する場合のorg-map-entriesの高速化
質問:org-map-entriesプロパティマッチングが非常に遅いのはなぜですか、それを高速化するにはどうすればよいですか? 背景:私は比較的単純な用途がありorg-map-entriesます:タグgoalと特定の優先順位(例:)を持つすべての組織アジェンダエントリから(整数分で)作業を取得しますB。 (org-map-entries #'hw-org-get-effort-in-minutes "goal+PRIORITY=\"B\"" 'agenda) これはひどく遅く、私の〜12,000行の議題ファイルに1分以上かかります。 ただし、PRIORITYフィルターからを削除してgoalsタグ付きアイテムを選択すると、ほぼ即座に完了します。 のようにフィルターを設定することもできますが、フィルターはgoal/DONE非常に迅速に完了しますが、私がそのようなgoals+EFFORT>0ことをすると、1分以上かかるようになります。一般に、プロパティのマッチングは非常に遅いようです。 私はチートの回避策を見つけました:を使用して、マップされた関数内のプロパティを非常にすばやく一致させることができますorg-entry-get。これを実行すると、実行は1秒未満です。これはばかげているようですが、うまくいけばもっと良い方法があると思いますが、少なくともそれはうまくいきます! すでに試してみました:(benchmark 1000 (hw-org-effort-to-minutes "1:20"))戻るので"Elapsed time: 0.000019s"、私の機能はあまり貢献していないと思います。 によるとprofiler、CPU時間の最大40%がによって使用されcond、最大29%が要素の解析に起因しています(org-element--current-element)。次の2つの最大の寄与は14%と13%であるため、40%がcond問題の大部分を占めているようです。ヘッダー(タグ、TODO)とヘッダー+ボディ(プロパティ)の解析のみが異なる場合を除き、プロパティマッチャーを使用して要素の解析がより頻繁に行われる理由がわかりません。

1
org-modeキャプションは、EXAMPLEブロックではサポートされていませんか?
次の自己完結型.orgファイルMVEを検討してください。 #+OPTIONS: toc:nil Figure [[captions-work-for-src-blocks]] shows that captions are correctly exported for SRC blocks. The second figure, in an EXAMPLE block, does not receive an exported caption. Furthermore, cross references to figure [[captions-dont-work-for-example-blocks]] incorrectly resolve to figure [[captions-work-for-src-blocks]]. ----- #+NAME: captions-work-for-src-blocks #+CAPTION: Captions work for SRC blocks #+BEGIN_SRC foo(bar) == …


1
組織モードテーブル内の他のテーブルの参照セル
10テーブルの長いドキュメントがあり、ドキュメントの最後に要約テーブルを配置したいと考えています。そんな感じ: タブ1 | Nº | Description | Value | +----+-------------+-------+ |... | +----+-------------+-------+ | | TOTAL | XXX | ... タブ10 | Nº | Description | Value | +----+-------------+-------+ |... | +----+-------------+-------+ | | TOTAL | XXX | タブの要約 | Description | Value | +------------------+-------| | Total of Table 1 …


2
OrgmodeからのHTMLエクスポートにBase64として画像を埋め込む
目標は、orgmodeからエクスポートするときに自己完結型のhtmlファイルを作成して、画像がファイルに固有であり、単一のhtmlファイルを配布できるようにすることです(私が教えており、学生に提供したいクラスに対してこれを試みています)ブラウザで開くことができる単一のhtml)。 私が欲しいもののアイデアを与えるコードのスニペットをオンラインで見つけました: #+BEGIN_SRC python :results output html :exports results with open('/home/britt/Pictures/Britt0001.jpg', 'rb') as image: data = image.read() print '<img src="data:image/jpg;base64,%s">' % data.encode("base64") #+END_SRC そして、私はそれをelispに入れて、Pythonへの依存を取り除こうとしています。そして、より詳細な独自のelisp関数を作成するためのステップとして。 これが私が得たものです。アドバイスありがとうございます。 #+BEGIN_src elisp :results output html :exports results (setq myim (concat "<img src=\\"data:image/jpg;base64," (tob64 "/home/britt/Pictures/Britt0001.jpg") ">")) (print myim) #+END_SRC そしてどこtob64に (defun tob64 (filename) (base64-encode-string (with-temp-buffer (insert-file-contents …
8 org-mode  images  html 


3
組織の議題のセクションを折りたたむ/折りたたむ?
カスタムの複数セクションの議題ビューはかなり長くなる可能性があります。読みやすくするために組織ファイルの標準的なアウトラインビューのようにセクションを折りたたんだり折りたたんだりする組み込みのメカニズムはありますか? 私は、複数セクションの議題の個々のセクションを最小限に折りたたむことができることに興味があります。

2
組織テキストでソースブロックを参照する方法
(LaTeXを含む任意の言語で)ソースブロックを作成し、次に内部リンクを使用してテキストでこれらを参照します。この同様の投稿は私のために働いていません。 私がしている簡単に、たとえば、共通の構造を使用して作成された多くのソースブロックすることができました: #+BEGIN_SRC python for i in 1:10: print i #+END_SRC 次に、内部リンクでそれらについて話したいので、ブロックに名前を追加しました。Idはを追加し#+NAME:てこれを行ったので、次のようにします。 #+NAME: some-source-code #+BEGIN_SRC python for i in 1:10: print i #+END_SRC したがって、テキストブロックはorgファイル内のどこかにあり(私の場合は同じ)、上記を使用して上記のコードブロックへのリンクを挿入したいと思いC-c C-lます。私はこれを説明ありとなしで試してみたので、両方で終わりました: [[some-source-code][my description]] そして [[some-source-code]] ただし、エクスポートされたPDFファイルではどちらも認識されません。PDFファイルに一対の疑問符が表示される*Org PDF LaTeX output buffer*だけで、次のメッセージが表示されます。 6ページのハイパーソースsome-source-codeが入力行182で未定義です。 org-file自体にリンクが表示され、リンクをクリックすると、予想どおりコードブロックに移動します。 そのようなソースブロックのバベルのドキュメントには、(ソースブロックに提供した名前を意味すると想定している)に関する未完成の文があり、次のように述べています。 名前は20文字で、…XXXを含めることができます に関するルールは実際にあります#+NAME: <label>か? 特定の#+ LaTeX_HEADERをorg-fileに含める必要がありますか? 私は午前使用してWebサイトへのリンクを作成することができC-c C-l説明では、 -およびPDFへの期待通り、これはエクスポートされます。 私はorgバージョン8.2.10、emacsバージョン24.5を持っています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.