Re: [O] [PATCH] org.el: Preserve indentation of manually indented lines in example blocks.
Hello, Valentin Wüstholz writes: > Sure. At least four use cases come to my mind for this: (a) literal > console output, (b) blocks of pseudo code (can't really use SRC blocks > since there is no actual language for this), (c) blocks of source code > in experimental or little known programming languages (ditto), and (d) > sketches of mathematical proofs or computations where you don't want > to mess with LaTeX typesetting (yet). I see (even though #d sounds strange). >>> What potential hassle were you thinking of? >> >> Being left with no more literal markup automatically indented. It's not >> that your idea is bad, but there could be users appreciating the current >> feature. > > I certainly thought about existing users, which is why by default > lines are is still indented like before. If you care about automatic > indentation, your example blocks are already indented like the > delimiters and the new behaviour keeps it just like that. If you > previously chose to indent you blocks differently, the new behaviour > will respect that decision by not messing with your indentation. Both situations are different from an user perspective. With the current behaviour, the only annoyance you encounter is that you cannot indent the whole buffer (or a region containing the block) automatically. But nothing prevents you from writing (and exporting) arbitrarily indented code. Sure, you won't get any indenting help in the process but it's the same as in your proposal. So all you have to do is basically refraining from using a global indentation tool. In your proposal, you still can write text with no indenting help. You can now indent the whole buffer, too. But there's one major problem. Suppose that you paste some badly indented text (from an external source) into an example block. You want to indent it properly... but it's now impossible. You have to fix indentation manually, line by line. To sum it up, in the first case, you only loose the ability to indent the whole buffer in one go (which isn't as bad as it sounds, since you can achieve that differently). In the second case, you get limited in your actions as you completely loose the ability to indent examples. I still think that's not fair. >> Perhaps this could be applied to verse blocks instead. > > As far as I recall verse blocks are treated somewhat differently from > example blocks by the exporter (e.g. verse vs verbatim in LaTeX). Indeed, but I think verses are closer to free text than examples and, as such, may not be subject to automatic indentation. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org.el: Preserve indentation of manually indented lines in example blocks.
Valentin Wüstholz writes:
> At least that's my understanding of what /literal/ examples should
> give you. Besides, you don't need to fix each line separately: simply
> removing the indentation and auto-indenting the block will get you the
> desired results.
Ah, true. I hadn't thought about that. I guess it's not that bad then.
> I would love to hear how other people feel about this.
Same here. I don't use such blocks very often after all.
Meanwhile, could you please reformat a bit your patch (no more than 80
columns, no parents on their own line), add a commit message followed
by TINYCHANGE (unless you have signed FSF papers already) and use git
format-patch for the output?
>> To sum it up, in the first case, you only loose the ability to indent
>> the whole buffer in one go (which isn't as bad as it sounds, since you
>> can achieve that differently).
>
> How else would you be able to achieve that?
You may still indent regions without examples blocks, you can also
indent automatically each line you're writing.
I rarely indent globally buffers I wrote.
> I might be wrong, but I believe that at least in LaTeX indentation in
> verse blocks is not taken into account. This seems reasonable since
> they are not typeset in a monospaced font.
Actually indentation is partially taken into account. Some \hspace*{1cm}
are added. On the other hand, HTML enforces indentation with the help of
.
Regards,
--
Nicolas Goaziou
[O] Bug: emacs crashes when scrolling column view [7.7]
I am reposting an earlier bug report with a slightly different subject
because this appears to be a serious problem not confined to aquamacs
on macos. I have triggered the crash on both windows and mac emacs and
provided a minimal, complete example to reproduce the problem. It
seems likely to be a more general problem with handling overlays in
Emacs 24. I am happy to provide any more details required to debug.
Originally posted with subject:
Bug: aquamacs hangs when scrolling column view [7.7 (release_7.7.104.g8425)]
http://thread.gmane.org/gmane.emacs.orgmode/45327
On Sat, Aug 6, 2011 at 5:50 PM, Skip Collins wrote:
> On Fri, Aug 5, 2011 at 11:09 PM, Skip Collins wrote:
>> When I move the scroll bar down in column view, Aquamacs typically
>> hangs. This is repeatable with the following minimal.emacs file:
>
> I tested emacs 24.0.50.1 and stock org 7.7 on windows xp the with the
> same minimal.emacs and minimal orgbug.org files. This crashes emacs.
> To trigger the crash, I open the file and ensure that the cursor is at
> the top. Then I go into column view with C-c C-x C-c. Then I use the
> scroll wheel on my mouse to scroll down. Immediately, the emacs abort
> dialog appears. I have not generated a backtrace.
On Fri, Aug 5, 2011 at 11:09 PM, Skip Collins wrote:
> When I move the scroll bar down in column view, Aquamacs typically
> hangs. This is repeatable with the following minimal.emacs file:
>
> --8<---cut here---start->8---
> (add-to-list 'load-path (expand-file-name "~/Documents/elisp/org-mode/lisp"))
> (add-to-list 'auto-mode-alist '("\\.\\(org\\ |org_archive\\|txt\\)$"
> . org-mode))
> (setq org-agenda-files '("/tmp/test.org"))
> (require 'org-install)
> (require 'org-habit)
>
> (global-set-key "\C-cl" 'org-store-link)
> (global-set-key "\C-ca" 'org-agenda)
> (global-set-key "\C-cb" 'org-iswitchb)
> --8<---cut here---end--->8---
>
> orgbug.org:
>
> --8<---cut here---start->8---
> #
> * foo
> * bar
> * baz
> * qux
> * foo
> * bar
> * baz
> * qux
> * foo
> * bar
> * baz
> * qux
> * foo
> * bar
> * baz
> * qux
> --8<---cut here---end--->8---
>
> /Applications/Aquamacs.app/Contents/MacOS/Aquamacs -Q -l
> ~/minimal.emacs ~/orgbug.org
>
> Emacs : GNU Emacs 24.0.50.3 (i386-apple-darwin10.8.0, NS
> apple-appkit-1038.36)
> of 2011-08-02 on colli
> Package: Org-mode version 7.7 (release_7.7.104.g8425)
>
> current state:
> ==
> (setq
> org-export-preprocess-before-selecting-backend-code-hook
> '(org-beamer-select-beamer-code)
> org-tab-first-hook '(org-hide-block-toggle-maybe
> org-src-native-tab-command-maybe
> org-babel-hide-result-toggle-maybe)
> org-speed-command-hook '(org-speed-command-default-hook
> org-babel-speed-command-hook)
> org-occur-hook '(org-first-headline-recenter)
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-export-preprocess-before-normalizing-links-hook
> '(org-remove-file-link-modifiers)
> org-confirm-shell-link-function 'yes-or-no-p
> org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc
> org-beamer-auto-fragile-frames
> org-beamer-place-default-actions-for-lists)
> org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
> org-support-shift-select t
> org-after-todo-state-change-hook '(org-clock-out-if-current)
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-babel-pre-tangle-hook '(save-buffer)
> org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
> org-mode-hook '(#[nil "\300\301\302\303\304$\207"
> [org-add-hook change-major-mode-hook org-show-block-all
> append local]
> 5]
> #[nil "\300\301\302\303\304$\207"
> [org-add-hook change-major-mode-hook
> org-babel-show-result-all append local]
> 5]
> org-babel-result-hide-spec org-babel-hide-all-hashes)
> org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
> org-babel-execute-safely-maybe)
> org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
> org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
> org-export-latex-format-toc-function 'org-export-latex-format-toc-default
> org-export-blocks '((src org-babel-exp-src-block nil)
> (comment org-export-blocks-format-comment t)
> (ditaa org-export-blocks-format-ditaa nil)
> (dot org-export-blocks-format-dot nil))
> org-export-first-hook '(org-beamer-initialize-open-trackers)
> org-export-interb
[O] block quotes or indented blocks?
Hi org folks; is there any way in org-mode's markup language to get an
HTML blockquote or LaTeX {quote} (or presumably similar for odt) when
exported? Looking through the manual I don't see one, though it's
quite possible I missed something.
--
-- Gary
[O] [yasnippet] Symbol's function definition is void: yas/next-field-group
Hi! I tried to set up yasnippet for me and it seems to me that I do have problems using yasnippet. yasnippet v0.6.1 Org-mode current git version I already found [1] and my .emacs contains: , | ;; ## | ;;; yasnippet | ;; http://yasnippet.googlecode.com/svn/trunk/doc/index.html | (require 'yasnippet) | (setq yas/root-directory "~/.emacs.d/snippets") | (yas/load-directory yas/root-directory) | | ;; ## | ;; yasnippet and Org-mode | ;; from: http://orgmode.org/manual/Conflicts.html | (add-hook 'org-mode-hook | (lambda () | (org-set-local 'yas/trigger-key [tab]) | (define-key yas/keymap [tab] 'yas/next-field-group))) | (defun yas/org-very-safe-expand () | (let ((yas/fallback-behavior 'return-nil)) (yas/expand))) | (add-hook 'org-mode-hook | (lambda () | (make-variable-buffer-local 'yas/trigger-key) | (setq yas/trigger-key [tab]) | (add-to-list 'org-tab-first-hook 'yas/org-very-safe-expand) | (define-key yas/keymap [tab] 'yas/next-field))) ` Whenever I try to expand a snippet containing $1, $2, ... I just get to $1 and then there I get «Symbol's function definition is void: yas/next-field-group» in the *Messages* buffer. Pressing «Tab» does not jump to $2 or $0. Does anybody have a clue, what is going on? Probably this is not even related to Org-mode since I changed to *scratch* and invoked latex-mode/begin+«Tab» and it does not work either ... 1. http://orgmode.org/manual/Conflicts.html -- Karl Voit
Re: [O] [babel] set post tangle hook on per file basis - evalu
Rainer M Krug writes: > Hi > > for different files, I put different things in the post-tangle hook. At tha > moment, I have an emacs-lisp code block, which I evaluate before I tangle, > but I forget this sometimes - so y question: is it possible (and think to > remember that it is, but I can't find how) to evaluate a source code block > upon opening of the file, or set the org-babel-post-tangle-hook in a > different way upon opening of the org file? > > The code block I am using at the moment is: > > ** Evaluate to run post tangle script > #+begin_src emacs-lisp :results silent :tangle no :exports none > (add-hook 'org-babel-post-tangle-hook > ( > lambda () > (call-process-shell-command "./postTangleScript.sh" nil > 0 nil) > ) > ) > #+end_src > Hi Rainer, I like to use file local variables [1] to do per-file Org-mode configuration and customization this is an easy way to set the local value of a variable every time the file is opened. I think you could use file local variables to evaluate arbitrary elisp when a file is opened in which case you could evaluate a named code block with something like `(sbe code-block-name)'. Best -- Eric Footnotes: [1] [[info:emacs#Specifying%20File%20Variables][info:emacs#Specifying File Variables]] -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] block quotes or indented blocks?
Gary Oberbrunner writes:
> Hi org folks; is there any way in org-mode's markup language to get an
> HTML blockquote or LaTeX {quote} (or presumably similar for odt) when
> exported? Looking through the manual I don't see one, though it's
> quite possible I missed something.
#+BEGIN_QUOTE
This generates blockquote tag on HTML export.
#+END_QUOTE
--
Re: [O] [PATCH] org.el: Preserve indentation of manually indented lines in example blocks.
Hi Nicolas. On Tue, Aug 9, 2011 at 11:18 AM, Nicolas Goaziou wrote: > Hello, > > Valentin Wüstholz writes: > >> Sure. At least four use cases come to my mind for this: (a) literal >> console output, (b) blocks of pseudo code (can't really use SRC blocks >> since there is no actual language for this), (c) blocks of source code >> in experimental or little known programming languages (ditto), and (d) >> sketches of mathematical proofs or computations where you don't want >> to mess with LaTeX typesetting (yet). > > I see (even though #d sounds strange). > What potential hassle were you thinking of? >>> >>> Being left with no more literal markup automatically indented. It's not >>> that your idea is bad, but there could be users appreciating the current >>> feature. >> >> I certainly thought about existing users, which is why by default >> lines are is still indented like before. If you care about automatic >> indentation, your example blocks are already indented like the >> delimiters and the new behaviour keeps it just like that. If you >> previously chose to indent you blocks differently, the new behaviour >> will respect that decision by not messing with your indentation. > > Both situations are different from an user perspective. > > With the current behaviour, the only annoyance you encounter is that you > cannot indent the whole buffer (or a region containing the block) > automatically. But nothing prevents you from writing (and exporting) > arbitrarily indented code. Sure, you won't get any indenting help in the > process but it's the same as in your proposal. So all you have to do is > basically refraining from using a global indentation tool. > > In your proposal, you still can write text with no indenting help. You > can now indent the whole buffer, too. But there's one major problem. > Suppose that you paste some badly indented text (from an external > source) into an example block. You want to indent it properly... but > it's now impossible. You have to fix indentation manually, line by line. I would argue, that most of the time when you copy something from an external source into an example block, you want to preserve the indentation and formatting. At least that's my understanding of what /literal/ examples should give you. Besides, you don't need to fix each line separately: simply removing the indentation and auto-indenting the block will get you the desired results. I fully agree that that's a slight change in behaviour. However, there are simple ways of fixing the issue you pointed out /once/ (when you past the text), whereas at the moment the default indentation is forced on you /every time/ you want to indent a line, region or buffer. Obviously, this is mainly my personal view as someone that relies on auto-indentation quite heavily. I would love to hear how other people feel about this. If too many people don't like the new behaviour, one could still consider adding an optional switch (like -n in SRC blocks). > To sum it up, in the first case, you only loose the ability to indent > the whole buffer in one go (which isn't as bad as it sounds, since you > can achieve that differently). How else would you be able to achieve that? > In the second case, you get limited in your actions as you completely loose > the ability to indent examples. I don't see why you would lose the ability to indent examples. When you write inside the block, each line will be auto-indented just like before. Only the lines that were manually indented further to the right, will not be reset to the default indentation. In that sense, you become more flexible in how your example blocks can be indented. >>> Perhaps this could be applied to verse blocks instead. >> >> As far as I recall verse blocks are treated somewhat differently from >> example blocks by the exporter (e.g. verse vs verbatim in LaTeX). > > Indeed, but I think verses are closer to free text than examples and, as > such, may not be subject to automatic indentation. I might be wrong, but I believe that at least in LaTeX indentation in verse blocks is not taken into account. This seems reasonable since they are not typeset in a monospaced font. Best regards, Valentin
Re: [O] [babel] set post tangle hook on per file basis - evalu
On Tue, Aug 9, 2011 at 2:33 PM, Eric Schulte wrote: > Rainer M Krug writes: > > > Hi > > > > for different files, I put different things in the post-tangle hook. At > tha > > moment, I have an emacs-lisp code block, which I evaluate before I > tangle, > > but I forget this sometimes - so y question: is it possible (and think to > > remember that it is, but I can't find how) to evaluate a source code > block > > upon opening of the file, or set the org-babel-post-tangle-hook in a > > different way upon opening of the org file? > > > > The code block I am using at the moment is: > > > > ** Evaluate to run post tangle script > > #+begin_src emacs-lisp :results silent :tangle no :exports none > > (add-hook 'org-babel-post-tangle-hook > > ( > > lambda () > > (call-process-shell-command "./postTangleScript.sh" > nil > > 0 nil) > > ) > > ) > > #+end_src > > > > Hi Rainer, > > I like to use file local variables [1] to do per-file Org-mode > configuration and customization this is an easy way to set the local > value of a variable every time the file is opened. > > I think you could use file local variables to evaluate arbitrary elisp > when a file is opened in which case you could evaluate a named code > block with something like `(sbe code-block-name)'. > Sounds interesting. So to set the post-tangle-hook, I tried the following: # -*- eval: (add-hook 'org-babel-post-tangle-hook( lambda () (call-process-shell-command "./postTangleScript.sh" nil 0 nil); -*- But it did not work - I have no idea, what I'm missing - eval should evaluate the following expression, which should set the post-tangle-hook. Your suggestion, to evaluate a code block after opening, sounds very interesting - could you give me a very short example? Thanks, and sorry for my lack of elisp understanding - it has not improved much... Rainer > Best -- Eric > > Footnotes: > [1] [[info:emacs#Specifying%20File%20Variables][info:emacs#Specifying File > Variables]] > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/ > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] Merge org-7.7 into emacs
Hi, suvayu ali writes: > Hi, > > On Sun, Aug 7, 2011 at 7:54 PM, Memnon Anon > wrote: >> Hi, >> >> Just a heads up: >> >> http://permalink.gmane.org/gmane.emacs.devel/142944 >> >> I don't know anything about this, but maybe something can be said/done >> about it while Bastien enjoys his vacation? >> > > I see my name in there. I only submitted a small (touching less than 20 > lines) documentation patch[1]. Would I still need to sign the copyright > assignment? If so, how do I initiate the process? > I believe 10 lines is the cutoff for whether a patch may be considered "tiny" and thus whether it requires copyright attribution to the FSF. I'm not sure if the same rules apply to documentation patches as to code patches. If you are willing to complete the FSF attribution process that would be ideal and would cover you for any future contributions. The steps are described at. > >> Memnon >> > > Footnotes: > > [1] commit 71d871f96e3e916a9542daeb6d3b102a77d9b068 > Author: Suvayu Ali > Date: Mon Jul 4 15:03:06 2011 +0200 > > Improve "Images in LaTeX export" documentation > > * Mention use of keywords like multicolumn and float > * Remove previous mention of hack with placement option > as per comments on the mailing list. The hack is > better suited for Worg. > > doc/org.texi | 34 -- > 1 files changed, 16 insertions(+), 18 deletions(-) -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [bug] removing last column with a column formula
Hello, Let's consider the following table: #+begin_src org | 1 | 2 | 3 | | 1 | 2 | 3 | #+TBLFM: @2$1..@2$3=@1 #+end_src If I remove the second column (M-S-Left), the formula is correctly updated. But when I remove the last column, the formula gets partly deleted and becomes: #+TBLFM: @2$1.. Also, if this times, the first column is removed, that line becomes: #+TBLFM: @2$INVALID..@2$2=@1 This is with latest Org and no user configuration. Regards, -- Nicolas Goaziou
Re: [O] block quotes or indented blocks?
duh. OK, just after posting, I found #+BEGIN_QUOTE. Sorry for the noise.
On Tue, Aug 9, 2011 at 8:55 AM, Gary Oberbrunner wrote:
> Hi org folks; is there any way in org-mode's markup language to get an
> HTML blockquote or LaTeX {quote} (or presumably similar for odt) when
> exported? Looking through the manual I don't see one, though it's
> quite possible I missed something.
>
> --
> -- Gary
>
--
-- Gary
Re: [O] [bug] org-inlinetask produces invalid xhtml
Hello, Jambunathan K writes: > The problem persists. You can put the exported html file in nxml-mode > and do a C-c C-n to find the validation errors. The problem is different now. > I am attaching the two examples and the problematic html segment (marked > with VALIDATION ERROR) here. Note that one of the examples has a list in > the inline task. > > > > #+begin_src nxml > Detector effects > > How is the Gaussian used for smearing of proper time resolution > derived? http://www.google.com";>Google this. > > Why is the proper time error PDF needed? Why is > smearing of time resolution not enough? > > > #+end_src > > #+begin_src nxml > > 1 B oscillations > > > This is Suvayu's example but simplified. Also see the annotation > within the inline task itself. > > > Questions: > > > > Detector effects > > Suvayu's example uses lists within inline task. Can the html export > engine produce valid html when the inline task has lists. But honestly > why does a preformatted text looks like a well-formatted html > list. Isn't that strange. Just uncomment the below list and see for > yourself. > > > > > #+end_src I see. Contents of inline tasks are meant to be interpreted during export. Thus, paragraphs will be marked as , lists as or whatever... This isn't compatible with the default tag provided. I can see two possibilities. Come up with a better default value, or provide a way to tell to template that contents will be verbatim (or both). I prefer the first solution, but I can't think of something simple, yet elegant enough, for that value. Do you have any suggestion? Regards, -- Nicolas Goaziou
[O] [bug] killing and yanking _sometimes_ doesn`t indent correctly
Hi! Using the following files I can reproduced a bug I encountered. inbox.org --- * Inbox ** TODO first ** TODO second --- fileto.org --- * What todo ** Subheading 1 ** Subheading 2 --- Now, if I place the cursor in inbox.org on ** TODO first hit C-c C-x C-w move to fileto.org and hit C-c C-x C-y whlie the cursor is in the empty line after ** Subheading 1 I get --- ** Subheading 1 * TODO first ** Subheading 2 --- Should be --- ** Subheading 1 *** TODO first ** Subheading 2 --- In larger files it somestimes works, sometimes behaves this way. While experimenting I found, when yanking while the cursor is _at the end_ of the line ** Subheading 1 I get -- * What todo ** TODO first ** Subheading 2 -- so the lovely subheading 1 gets eaten by my yank. Shouldn`t I guess. Orgmode: release_7.7-38-g1b379 Org-mode version 7.7 (release_7.7.38.g1b379) Emacs: GNU Emacs 23.2.1 (x86_64-suse-linux-gnu, GTK+ Version 2.22.1) of 2011-02-22 on build34 Regards Detlef
Re: [O] [bug] removing last column with a column formula
Hi Nicolas Columns and rows are better referenced with "<" and ">" in many cases to avoid such oddities: #+begin_src org | 1 | 2 | 3 | | 1 | 2 | 3 | #+TBLFM: @2$<..@2$>=@1 #+end_src http://orgmode.org/manual/References.html#References Michael On Tue, Aug 9, 2011 at 14:50, Nicolas Goaziou wrote: > Hello, > > Let's consider the following table: > > #+begin_src org > | 1 | 2 | 3 | > | 1 | 2 | 3 | > #+TBLFM: @2$1..@2$3=@1 > #+end_src > > If I remove the second column (M-S-Left), the formula is correctly > updated. But when I remove the last column, the formula gets partly > deleted and becomes: > > #+TBLFM: @2$1.. > > Also, if this times, the first column is removed, that line becomes: > > #+TBLFM: @2$INVALID..@2$2=@1 > > This is with latest Org and no user configuration.
Re: [O] [yasnippet] can not creating links with description
Hi Karl,
I do not know how to accomplish this with a single field but the
following workaround might be sufficient:
,[ ~/snippets/org-mode/vkcomp ]
| # name : expand link to company
| # --
| [[file:~/share/all/org-mode/contacts.org::*$1][${2:$$(unless yas/modified-p
| (let ((field (nth 0 (yas/snippet-fields (first (yas/snippets-at-point))
|(concat "companie: "
|(and field (buffer-substring
| (yas/field-start field)
| (yas/field-end field))]] $0
`
As long as the first field is active the second one is empty, thus, no
troublesome link hiding will occur. As I said, this isn't exactly what
you were asking for, since you have to press TAB a second time to
actually exit the snippet.
Best regards,
Bianca.
On Mon, Aug 8, 2011 at 10:46 PM, Karl Voit wrote:
> Hi!
>
> I'd like to create a link like
>
> [[file:~/share/all/org-mode/contacts.org::*foo][company:foo]]
>
> ... and therefore I created:
>
> ,[ ~/snippets/org-mode/vkcomp ]
> | # name : expand link to company
> | # --
> | [[file:~/share/all/org-mode/contacts.org::*$1][company:$1]] $0
> `
>
> But: unfortunately my Org-mode behaves strangely when applying the
> snippet: "company:" with blinking cursor in the «c» which does not
> let me enter the string which replaces «$1».
>
> I guess this is related to «hiding the actual link when a
> description is set».
>
> Can I define a snippet which behaves like following? After entering
> the snippet command and pressing TAB, I get the chance to type «foo»
> part and after another TAB, the link as stated above is finished and
> the cursor is at the end.
>
> Thanks!
>
> --
> Karl Voit
>
>
>
Re: [O] [yasnippet] can not creating links with description
I just realized that the test for field being non-nil is superfluous
in the example below -- the usual copy and paste mess got me. Thus,
you may omit it, i.e. use
(concat "companie: " (buffer-substring ...))
instead of
(concat "companie: " (and field (buffer-substring ...)))
Bianca.
On Tue, Aug 9, 2011 at 5:05 PM, Bianca Lutz wrote:
> Hi Karl,
>
> I do not know how to accomplish this with a single field but the
> following workaround might be sufficient:
>
> ,[ ~/snippets/org-mode/vkcomp ]
> | # name : expand link to company
> | # --
> | [[file:~/share/all/org-mode/contacts.org::*$1][${2:$$(unless yas/modified-p
> | (let ((field (nth 0 (yas/snippet-fields (first (yas/snippets-at-point))
> | (concat "companie: "
> | (and field (buffer-substring
> | (yas/field-start field)
> | (yas/field-end field))]] $0
> `
>
> As long as the first field is active the second one is empty, thus, no
> troublesome link hiding will occur. As I said, this isn't exactly what
> you were asking for, since you have to press TAB a second time to
> actually exit the snippet.
>
> Best regards,
> Bianca.
[O] Markup in BEGIN_EXAMPLE and alike block
Hi. I want to emphasize (using bold monospace font when exporting to HTML) some parts of text in example block. Consider the following example: *** Determining adapter chipset and used driver #+BEGIN_EXAMPLE zbox$ lspci -v ... 04:00.0 Network controller: *RaLink RT2860* Subsystem: Device 1a3b:1059 Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at febf (32-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Kernel driver in use: *rt2800pci* Kernel modules: rt2800pci #+END_EXAMPLE But in exported html file the '*'s are remain. Is it possible to use markup in BEGIN_EXAMPLE? Or I have to use another type of block? --- TIA, Vladimir Lomov
[O] [babel] [bug] inline src_R breaks downstream src block
,
|
| * inline code block example
|
|
| AAA
| blah blah src_R[:results output]{cat(rnorm(2))}
| CC
| #+begin_src R :eval never :exports none
| 1+2
| a <- b + c
| xyz
| #+end_src
|
`
When I run C-c C-e A y, I get a buffer that misses the 'DDD...' line.
When I run C-c C-e L y, I get a buffer that ends like this:
| AAA
| blah blah \texttt{-1.172165 -0.5324113}
| CC
| \begin{src}R DDD
|
| \end{document}
`
More complicated examples exhibit other problems, I speculate that
parsing the inline src_R and setting up to find the next
#+begin_src...#+end_src instance is what has gone wrong.
FWIW, changing the :exports header to 'code' seems to give correct
results
Also, placing a dummy example like this:
,
| #+begin_example
| #+end_example
`
after the src_R line produces correct results.
Chuck
Charles C. BerryDept of Family/Preventive Medicine
cbe...@tajo.ucsd.eduUC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
[O] org-sudoku.el
Hi, my daughter got stuck with a couple of SUDOKU puzzles during the vacation (where wh had no internet connection), so I hacked a small SUDOKU solver that reads a 9x9 Org table and solves it as a sudoku puzzle. A little silly, but maybe fun for someone - I have pushed it into the contrib/lisp directory. Cheers - Carsten
Re: [O] Merge org-7.7 into emacs
Eric Schulte writes: > I believe 10 lines is the cutoff for whether a patch may be considered > "tiny" and thus whether it requires copyright attribution to the FSF. ,[ http://orgmode.org/worg/org-contribute.html ] | If your patch is against a file that is part of Emacs, then your total | contribution (all patches you submit) should change less than 20 lines. | If you contribute more, you have to assign the copyright of your | contribution to the Free Software Foundation (see below). ` Memnon
Re: [O] org-sudoku.el
Carsten Dominik writes: > my daughter got stuck with a couple of SUDOKU puzzles during > the vacation (where wh had no internet connection), so I > hacked a small SUDOKU solver that reads > a 9x9 Org table and solves it as a sudoku puzzle. > A little silly, but maybe fun for someone - I have pushed it > into the contrib/lisp directory. Now, plug it into sudoku.el and let Emacs play against itself. :-D Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] org-sudoku.el
On 9.8.2011, at 18:54, Achim Gratz wrote: > Carsten Dominik writes: >> my daughter got stuck with a couple of SUDOKU puzzles during >> the vacation (where wh had no internet connection), so I >> hacked a small SUDOKU solver that reads >> a 9x9 Org table and solves it as a sudoku puzzle. >> A little silly, but maybe fun for someone - I have pushed it >> into the contrib/lisp directory. > > Now, plug it into sudoku.el and let Emacs play against itself. > :-D Yep, I found out, in the mean time, that there is sudoku.el as well. Nice interface. - Carsten > > > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > SD adaptation for Waldorf rackAttack V1.04R1: > http://Synth.Stromeko.net/Downloads.html#WaldorfSDada > >
Re: [O] [yasnippet] Symbol's function definition is void: yas/next-field-group
Hi Karl, On Tue, Aug 9, 2011 at 1:34 PM, Karl Voit wrote: > Whenever I try to expand a snippet containing $1, $2, ... I just get > to $1 and then there I get «Symbol's function definition is void: > yas/next-field-group» in the *Messages* buffer. > > Pressing «Tab» does not jump to $2 or $0. > > Does anybody have a clue, what is going on? The org info seems to be outdated: yas/next-field-group is called yas/next-field nowadays. A simple rename should solve the issue. BTW: Are you sure you need both calls to add-hook? The way I understand the org manual is that you need either of them (not both at the same time). Bianca.
Re: [O] [babel] set post tangle hook on per file basis - evalu
>> >> Hi Rainer, >> >> I like to use file local variables [1] to do per-file Org-mode >> configuration and customization this is an easy way to set the local >> value of a variable every time the file is opened. >> >> I think you could use file local variables to evaluate arbitrary elisp >> when a file is opened in which case you could evaluate a named code >> block with something like `(sbe code-block-name)'. >> > > Sounds interesting. > > So to set the post-tangle-hook, I tried the following: > > # -*- eval: (add-hook 'org-babel-post-tangle-hook; -*- > > But it did not work - I have no idea, what I'm missing - eval should > evaluate the following expression, which should set the post-tangle-hook. > maybe try something like the following # -*- org-babel-post-tangle-hook: '(my-tangle-hook-function) -*- where `my-tangle-hook-function' is defined in your .emacs config. > > Your suggestion, to evaluate a code block after opening, sounds very > interesting - could you give me a very short example? > The info link I posted should explain how to evaluate a snippet of elisp, once you have that working (you could test with simple calls to the `message' function) you can use the `sbe' function (see it's documentation) to evaluate named code blocks. Best -- Eric > > Thanks, and sorry for my lack of elisp understanding - it has not improved > much... > > Rainer > > >> Best -- Eric >> >> Footnotes: >> [1] [[info:emacs#Specifying%20File%20Variables][info:emacs#Specifying File >> Variables]] >> >> -- >> Eric Schulte >> http://cs.unm.edu/~eschulte/ >> -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [PATCH] org.el: Preserve indentation of manually indented lines in example blocks.
Hi Nicolas.
On Tue, Aug 9, 2011 at 3:21 PM, Nicolas Goaziou wrote:
>> I would love to hear how other people feel about this.
>
> Same here. I don't use such blocks very often after all.
>
> Meanwhile, could you please reformat a bit your patch (no more than 80
> columns, no parents on their own line), add a commit message followed
> by TINYCHANGE (unless you have signed FSF papers already) and use git
> format-patch for the output?
Sure. I have attached the output.
>>> To sum it up, in the first case, you only loose the ability to indent
>>> the whole buffer in one go (which isn't as bad as it sounds, since you
>>> can achieve that differently).
>>
>> How else would you be able to achieve that?
>
> You may still indent regions without examples blocks, you can also
> indent automatically each line you're writing.
True, but that gets quite tedious once you have more than two or three
blocks in your file.
>> I might be wrong, but I believe that at least in LaTeX indentation in
>> verse blocks is not taken into account. This seems reasonable since
>> they are not typeset in a monospaced font.
>
> Actually indentation is partially taken into account. Some \hspace*{1cm}
> are added. On the other hand, HTML enforces indentation with the help of
> .
Your right, it seems that org-mode somehow deals with it, even though
LaTeX doesn't quite support it natively.
Best regards,
Valentin
From c64f1b607d937c6484dfc18110125b1287175ac4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Valentin=20W=FCstholz?=
Date: Tue, 9 Aug 2011 21:28:56 +0200
Subject: [PATCH] Preserve indentation of explicitly indented lines in example
blocks
* lisp/org.el (org-indent-line-function): Made the way in which example blocks
are
indented more flexible.
Before: Lines in example blocks were indented like the surrounding begin and end
delimiters.
After: By default, lines in example blocks are indented like the surrounding
begin and end
delimiters, unless the user explicitly indents them differently.
TINYCHANGE
---
lisp/org.el | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index ba7f049..d8f1d2a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19460,10 +19460,14 @@ If point is in an inline task, mark that task
instead."
(save-excursion
(re-search-backward "^[ \t]*#\\+begin_\\([a-z]+\\)" nil t))
(setq column
- (if (equal (downcase (match-string 1)) "src")
- ;; src blocks: let `org-edit-src-exit' handle them
- (org-get-indentation)
- (org-get-indentation (match-string 0)
+(cond ((equal (downcase (match-string 1)) "src")
+ ;; src blocks: let `org-edit-src-exit' handle them
+ (org-get-indentation))
+ ((equal (downcase (match-string 1)) "example")
+ (max (org-get-indentation)
+ (org-get-indentation (match-string 0
+ (t
+ (org-get-indentation (match-string 0))
;; This line has nothing special, look at the previous relevant
;; line to compute indentation
(t
--
1.7.4.msysgit.0
Re: [O] Bug: Column view in the agenda does not clean up ITEM [7.7]
Hi Sebastien, Sebastien wrote: Hi Christian, I (would have) thought that, when having a column dedicated for tags, the tag would as well be removed from the "headline" column (3^rd one, in your example). Is there a good reason it's not working like that for the tag as well? Talking about version 7.5, you can get rid of the tags in the agenda view by setting org-agenda-remove-tags to t. But I think that variable is depricated in version 7.7 as well. Anyway my original issue is concerning the column view called upon an agenda view in version 7.7: Unfortunately column view is not cleaning up the column "ITEM" at all when called upon an agenda view (not only the tag). But according to the documentation it should clean up the column "ITEM". But it does not. :-( Does org-mode clean up the column "ITEM" in the column view when called upon agenda view in your installation? Best, Christian -- Christian Schmidt mailto: c...@canau.de
Re: [O] Bug: Column view in the agenda does not clean up ITEM [7.7]
Hi Christian, Christian Schmidt wrote: > Sebastien wrote: >> I (would have) thought that, when having a column dedicated for >> tags, the tag would as well be removed from the "headline" column >> (3^rd one, in your example). >> >> Is there a good reason it's not working like that for the tag as >> well? > > Talking about version 7.5, you can get rid of the tags in the agenda > view by setting org-agenda-remove-tags to t. But I think that > variable is depricated in version 7.7 as well. It still is in my Org, git pulled this morning. > Anyway my original issue is concerning the column view called upon an > agenda view in version 7.7: Unfortunately column view is not cleaning > up the column "ITEM" at all when called upon an agenda view (not only > the tag). But according to the documentation it should clean up the > column "ITEM". But it does not. :-( > > Does org-mode clean up the column "ITEM" in the column view when > called upon agenda view in your installation? Everything seems fine, before and after the timeline (C-c a L). My ECM: #+begin_src org * TODO [#B] Test :Tag: SCHEDULED: <2011-08-07 So> #+end_src My config: #+begin_src emacs-lisp (setq org-columns-default-format "%65ITEM(Task) %TODO %3PRIORITY %TAGS") #+end_src The result: http://imgur.com/TAYH5 Best regards, Seb -- Sebastien Vauban
Re: [O] Org-Babel Mode : a suggestion and a contribution article [Babel]
Feiming Chen wrote:
> I wonder if it is possible to use the macro option (#+MACRO:) to save
> the typing of header options (of code blocks). For example, currently
> it does NOT work if I try to use
>
>
>
>
If you read the appropriate section of the manual
(info "(org)Macro replacement")
you will find that
"...
Macro expansion takes place during export, and some people use it to
construct complex HTML code.
"
so no: you cannot use it for the purpose you describe. Look into various
abbreviation expanders (a lot of people here like yasnippets) or into
the simple abbrev expansion mechanism that org itself provides:
(info "(org)Easy templates")
Nick
> #+MACRO: p :file $1.png :width 1000 :height 800
>
>
>
>
>
>
>
> to shorten the header of a code block to
>
>
>
>
>
>
>
> #+begin_src R {{{p(plot)}}}
>
>
>
>
>
>
>
> Anyway, I found Org-Babel Mode to be a great tool since Sweave for writing R
> literate program document. I wrote a how-to article on its use (see
> attached file "how-to-use-*.html", other files are raw and support files).
> Hopefully it can be useful to some users.
>
>
>
>
> Sincerely,
>
>
>
> Feiming Chen
>
>
>
>
>
>
> Alternatives:
>
>
Re: [O] [bug] org-inlinetask produces invalid xhtml
> I see. Contents of inline tasks are meant to be interpreted during > export. Thus, paragraphs will be marked as , lists as or > whatever... > > This isn't compatible with the default tag provided. I can see two > possibilities. Come up with a better default value, or provide a way to > tell to template that contents will be verbatim (or both). > > I prefer the first solution, but I can't think of something simple, yet > elegant enough, for that value. Do you have any suggestion? (I am speaking here from purely html/odt perspective) 1. When org-inlinetask is NOT LOADED, inline tasks are treated as regular headlines and are listified. (The "END" of inlinetask appears as listified headline though) 2. If inlinetask is LOADED, the exporter could check the headline level against org-inlinetask-min-level and take the following actions: - Continue to generate listified entries for inline tasks but surround them with ... entries. - Strip the "END" list item from being generated I think org-inlinetask-export-handler could be reduced to 1. removing the inlinetask when org-inlinetask-export is nil 2. stripping the inlinetask of drawers etc etc. (Queestions: Does the org-inlinetask-export-handler treat nested inline tasks well? Btw, Is nesting of inline tasks "legitimate" to begin with? ) I am sure html and odt exporters can take care of inlinetask purely during post-processing and do away with templates altogether. I am not sure about LaTeX exporter though. What do you & others think? Let me work on a patch from odt/html side of things. Misc: 1. May be someone with css/html expertise can devise a nice css for formatting of inlinetasks as part of addressig this bug. 2. I am undecided about how odt export be formatted - comments, text boxes, what else. In case of odt export, there is an option of always exporting the inline task but turn on/off their display conditionally based on user setting. > Regards, --
[O] tag searches with regular expressions
Hi Orgers,
I was trying to do a tags search for all tags with people's names. I
use people's names like this "Suvayu". So I tried something like this
"{[A-Z][a-z]+}", but that returns me almost every tag I have.
Is this possible? If not, are there other ways of achieving something like this?
PS: I checked the advanced search tutorial on Worg, it only talks
about grouping tags.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [bug] org-inlinetask produces invalid xhtml
Hello Nicolas and Jambu,
On Tue, Aug 9, 2011 at 11:51 PM, Jambunathan K wrote:
>> I see. Contents of inline tasks are meant to be interpreted during
>> export. Thus, paragraphs will be marked as , lists as or
>> whatever...
>>
>> This isn't compatible with the default tag provided. I can see two
>> possibilities. Come up with a better default value, or provide a way to
>> tell to template that contents will be verbatim (or both).
>>
>> I prefer the first solution, but I can't think of something simple, yet
>> elegant enough, for that value. Do you have any suggestion?
>
> (I am speaking here from purely html/odt perspective)
>
> 1. When org-inlinetask is NOT LOADED, inline tasks are treated as
> regular headlines and are listified. (The "END" of inlinetask appears
> as listified headline though)
>
> 2. If inlinetask is LOADED, the exporter could check the headline level
> against org-inlinetask-min-level and take the following actions:
>
> - Continue to generate listified entries for inline tasks but
> surround them with ... entries.
>
> - Strip the "END" list item from being generated
I don't know much html/css but lately I have been fooling around with
export of inlinetasks. I found that for html export having them as a
section with highlighting seemed to serve my purpose well. It seems to
me inline tasks are either used as task reminders in the context of a
larger document or as contextual notes. For either case, it serves the
purpose better if its highlighted or quoted in some coloured box or
something similar.
To achieve this, I modified the default templates for html and latex
export like this:
(html "%s%s%s"
'("inlinetask"
(unless
(eq todo "")
(format "%s%s " class todo todo
priority))
heading content))
;; this requires the todonotes package
(latex "\\todo[inline]{\\textbf{%s %s}\\linebreak{} %s}"
'((unless
(eq todo "")
(format "\\textsc{%s%s}" todo priority))
heading content))
For html export with the above template one could control the styling by
defining the div.inlinetask class in their custom.css.
To have more control over the styling using multiple css classes, I
tried using HTML_CONTAINER_CLASS with an inline task and altering the
html template to something like this:
(html "%s%s%s"
'((org-entry-get nil "HTML_CONTAINER_CLASS")
(unless
(eq todo "")
(format "%s%s " class todo todo
priority))
heading content))
But that doesn't seem to work at all! I get no errors, just the
inlinetask gets exported with an empty class like this:
...
Strangely, if I replace the (org-entry-get ..) with (message "bla"), the
exported markup looks something like this:
...
I hope this gives you ideas or scope for improvement for export of
inlinetasks.
--
Suvayu
Open source is the future. It sets us free.
