Re: [O] [PATCH] org-attach-store-link-p gets wrong value for attach when using customize-variable
Hi Henning, At Mon, 12 Mar 2012 22:17:34 +0100, Henning Weiss wrote: > I have attached a very small patch fixing the value > that org-attach-store-link-p gets through the customize > interface. The additional quote prevented org-attach-attach from > calling org-attach-store-link when org-attach-store-link-p was > configured to "Link to the attach-dir location". Thanks for spotting this. I pushed a fix to master, removing the spurios quote. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de
Re: [O] bug with org-mode-hook and text-scale-set
Hi,
At Tue, 13 Mar 2012 14:49:41 +0800,
Du Yanning wrote:
> org-mode 7.8.03
> emacs 23.3, 23.4, 24.0.94
>
> steps to recreate:
>
> emacs -q
>
> copy the following code and paste it into the *scratch* buffer:
> (add-to-list 'auto-mode-alist '("\\.txt\\'" . org-mode))
> (add-hook 'org-mode-hook '(lambda () (text-scale-set 4)))
>
> M-x eval-buffer
>
> then C-x C-f to open a .txt file, and then C-x C-f to open another .txt file.
> Every time a .txt is opened, the font size become larger and larger.
> However, the indicator in the mode line remains +4.
I can confirm this behaviour but I don't think this is an error. The
description of `text-scale-set' reads:
C-h f text-scale-set RET
,
| text-scale-set is an interactive autoloaded Lisp function in
| `face-remap.el'.
|
| (text-scale-set LEVEL)
|
| Set the scale factor of the default face in the current buffer to LEVEL.
| If LEVEL is non-zero, `text-scale-mode' is enabled, otherwise it is disabled.
|
| LEVEL is a number of steps, with 0 representing the default size.
| Each step scales the height of the default face by the variable
| ^
| `text-scale-mode-step' (a negative number decreases the height by
| the same amount).
`
The first time `org-mode-hook' is run the height of default font is
scaled by 4 levels, i.e. the height of default font is set to a new
value. The second time `org-mode-hook' is run the height is scaled
again, this time based on the new value. And so on.
If you want to set the face height you might use:
(set-face-attribute 'default nil :height 100)
Here `100' means 100% of the font size in pt (afaik).
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
pgpXlI3Ly22v6.pgp
Description: OpenPGP Digital Signature
Re: [O] Problem editing source code
Mueen Nawaz writes: > A subsequent C-c ' does nothing (i.e. I can't leave that buffer). > > Any ideas? Forgot to mention: Emacs 23.4 and Org mode 7.8.03
[O] Problem editing source code
Hi, When I try to edit source code using "C-c '", it opens the code in the appropriate mode (Python in my case), but gives this message: byte-code: Language mode `python-mode' fails with: ac-sources A subsequent C-c ' does nothing (i.e. I can't leave that buffer). Any ideas? Thanks, Mueen
Re: [O] [PATCH] Add missing word to org-contacts y-or-n-p question.
At Tue, 13 Mar 2012 08:19:39 +0100, Tassilo Horn wrote: > > From 6254305becaaa712f6f0936263a09d9ed974e51b Mon Sep 17 00:00:00 2001 > User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) > Cancel-Lock: sha1:/pUqi5NalGwuBic1R2H+VziOGlM= > > Before it was > > Do you want to this address to %s? > > now it is > > Do you want add to this address to %s? Thanks, patch applied. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpupVz6LrHyq.pgp Description: OpenPGP Digital Signature
Re: [O] Problem with choosing mode while editing blocks with C-c '
suvayu ali wrote: > >> There was a discussion of this topic recently, I had and still have my q= > uote source > >> blocks in artists (picture) mode and thought this was strange behaviour. > > > > BTW, artist-mode is *not* the same as picture-mode. > > > > Actually I keep confusing between the two and I'm not sure which I was > seeing. Well, they *are* different, but it turns out that if artist-picture-compatibility is true (which it is by default), then artist-mode turns on picture-mode, so they are difficult to tell apart just looking at the modeline. Nick
Re: [O] Problem with choosing mode while editing blocks with C-c '
suvayu ali wrote: > Actually I keep confusing between the two and I'm not sure which I was > seeing. I also forgot to mention I did not see the problem with a > minimal setup. I got frustrated (I had to get the talk done), so I > restarted Emacs and worked with LaTeX directly. Now in my new session I > cannot replicate my issue. However it still breaks in a different way. > Hitting C-c ' prompts me for a filename or a url. > > > For the OP (Suvayu): can you do C-h v org-edit-fixed-width-region-mode > > RET and post the result? If the value is picture-mode, then I can > > vaguely glimpse a (rather far-fetched) possible scenario that might get > > you into the problem you describe, but I'd rather try to rule it out > > first. > > > > This variable is set to artist-mode. > > I did a binary search through my setup and found the problem occurs when > case-fold-search is set to nil. > > You can replicate this with the following contents in an org file and > (setq case-fold-search nil). > > 8<---8< > > * Heading > #+BEGIN_SRC latex > %% this is a LaTeX comment > #+END_SRC > #+begin_src latex > %% this is a LaTeX comment > #+end_src > > 8<---8< > > C-c ' on the first block shold prompt you for a file or url and the > second block should present a temporary buffer in latex mode. > > I have actually seen both these problem (the artist-mode and prompt for > file or url) for quite a while from time to time. But I could never > replicate them consistently. I guess today is my (somewhat) lucky > day. :) > The case-fold-search problem is in org-src.el:org-edit-src-code. case-fold-search is let-bound to t, but the let form evaluates all the VARLIST forms before evaluating the body, so the very next varlist (case-fold-search t) (info (org-edit-src-find-region-and-lang)) ... fails because in its evaluation, case-fold-search is still nil. The solution is to use a let* form instead: just change the let on line 216 to a let*. I think this will cure the other problem too: org-edit-special checks for various things and if any of them succeed it skips the rest. The behavior you get is the "everything else failed, let's call ffap". But now since the org-edit-src-code call will (famous last words) succeed, then it won't fall through. Nick
Re: [O] Problem with choosing mode while editing blocks with C-c '
Hi Nick, Apologies on not responding sooner. I was preparing my slides for a presentation tomorrow. On Wed, Mar 14, 2012 at 01:34, Nick Dokos wrote: > Thorsten wrote: > >> suvayu ali writes: >> >> Hi, >> >> > I am having problems editing blocks with C-c '. If the blocks are marked >> > with upper case letters Emacs brings up the temporary buffer in >> > picture-mode. >> > >> > #+BEGIN_SRC latex >> > >> > #+END_SRC >> > >> > However the buffer mode is chosen correctly if lower case letters are >> > used. >> > >> > #+begin_src latex >> > >> > #+end_src >> > >> > Any ideas what could be wrong? >> >> There was a discussion of this topic recently, I had and still have my quote >> source >> blocks in artists (picture) mode and thought this was strange behaviour. > > BTW, artist-mode is *not* the same as picture-mode. > Actually I keep confusing between the two and I'm not sure which I was seeing. I also forgot to mention I did not see the problem with a minimal setup. I got frustrated (I had to get the talk done), so I restarted Emacs and worked with LaTeX directly. Now in my new session I cannot replicate my issue. However it still breaks in a different way. Hitting C-c ' prompts me for a filename or a url. > For the OP (Suvayu): can you do C-h v org-edit-fixed-width-region-mode > RET and post the result? If the value is picture-mode, then I can > vaguely glimpse a (rather far-fetched) possible scenario that might get > you into the problem you describe, but I'd rather try to rule it out > first. > This variable is set to artist-mode. I did a binary search through my setup and found the problem occurs when case-fold-search is set to nil. You can replicate this with the following contents in an org file and (setq case-fold-search nil). 8<---8< * Heading #+BEGIN_SRC latex %% this is a LaTeX comment #+END_SRC #+begin_src latex %% this is a LaTeX comment #+end_src 8<---8< C-c ' on the first block shold prompt you for a file or url and the second block should present a temporary buffer in latex mode. I have actually seen both these problem (the artist-mode and prompt for file or url) for quite a while from time to time. But I could never replicate them consistently. I guess today is my (somewhat) lucky day. :) > Nick > > Hope this helps paint a clearer picture. -- Suvayu Open source is the future. It sets us free.
Re: [O] Access org-tag-alist from #+FILETAGS
Nick, Thank you. I'll give it a try. Charlie Millar On 3/13/2012 2:48 PM, Nick Dokos wrote: snip Charlie Millar On 2/28/2012 2:28 PM, Charles wrote: I use a few tags and usually two or three will apply to all entries in a particular file, e.g. :work:Client:OpenFile: or :Personal:Home: All my tags are in my .emacs using the org-tag-alist and I want to use these consistently. Is there a way to access org-tag-alist from the in-buffer settings #+FILETAGS or #+TAGS? C-c C-c, of course, refreshes the local setting; C-c C-q gives an error(?) message "Before first headline at position 1 in buffer . . ." At the moment my work around is: start the file's first line with *#+FILETAGS, then C-c C-c, and after setting tags delete the *. Have you tried a setup file? tag.org: --8<---cut here---start->8--- #+TAGS: one two three --8<---cut here---end--->8--- and the "real" file is: --8<---cut here---start->8--- #+SETUPFILE: tag.org #+TAGS: foo bar baz * two * four * three :bar:baz: * one :foo: * five :foo:baz: #+BEGIN_SRC elisp org-tag-alist #+END_SRC #+RESULTS: | one | | two | | three| | :newline | | foo | | bar | | baz | everything plus :newline (whatever that is). --8<---cut here---end--->8--- Nick
Re: [O] Problem with choosing mode while editing blocks with C-c '
Thorsten wrote: > suvayu ali writes: > > Hi, > > > I am having problems editing blocks with C-c '. If the blocks are marked > > with upper case letters Emacs brings up the temporary buffer in > > picture-mode. > > > >#+BEGIN_SRC latex > > > >#+END_SRC > > > > However the buffer mode is chosen correctly if lower case letters are > > used. > > > >#+begin_src latex > > > >#+end_src > > > > Any ideas what could be wrong? > > There was a discussion of this topic recently, I had and still have my quote > source > blocks in artists (picture) mode and thought this was strange behaviour. BTW, artist-mode is *not* the same as picture-mode. For the OP (Suvayu): can you do C-h v org-edit-fixed-width-region-mode RET and post the result? If the value is picture-mode, then I can vaguely glimpse a (rather far-fetched) possible scenario that might get you into the problem you describe, but I'd rather try to rule it out first. Nick
Re: [O] Problem with choosing mode while editing blocks with C-c '
Thorsten wrote:
> suvayu ali writes:
>
> Hi,
>
> > I am having problems editing blocks with C-c '. If the blocks are marked
> > with upper case letters Emacs brings up the temporary buffer in
> > picture-mode.
> >
> >#+BEGIN_SRC latex
> >
> >#+END_SRC
> >
> > However the buffer mode is chosen correctly if lower case letters are
> > used.
> >
> >#+begin_src latex
> >
> >#+end_src
> >
> > Any ideas what could be wrong?
>
> There was a discussion of this topic recently, I had and still have my quote
> source
> blocks in artists (picture) mode and thought this was strange behaviour.
> Some stated that this is a feature, while Eric (Schulte) confirmed the
> behaviour and agreed that it appears more like a bug than a feature.
>
> I'm not sure how to link to email threads, I hope the following link
> works for you:
>
> [[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#87d3964cpp@googlemail.com][Email
> from Thorsten: {babel} Editing 'quote' source]]
>
> My system:
> "GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
> of 2012-02-07 on arch
> Org-mode version 7.8.03
> Ma Gnus v0.2"
>
Wandering aroung org-src.el, I stumbled on the following variable which you
(Thorsten) may find useful in your case:
,
| org-edit-fixed-width-region-mode is a variable defined in `org-src.el'.
| Its value is artist-mode
|
| Documentation:
| The mode that should be used to edit fixed-width regions.
| These are the regions where each line starts with a colon.
|
| You can customize this variable.
`
Nick
Re: [O] Problem with choosing mode while editing blocks with C-c '
suvayu ali writes:
Hi,
> I am having problems editing blocks with C-c '. If the blocks are marked
> with upper case letters Emacs brings up the temporary buffer in
> picture-mode.
>
>#+BEGIN_SRC latex
>
>#+END_SRC
>
> However the buffer mode is chosen correctly if lower case letters are
> used.
>
>#+begin_src latex
>
>#+end_src
>
> Any ideas what could be wrong?
There was a discussion of this topic recently, I had and still have my quote
source
blocks in artists (picture) mode and thought this was strange behaviour.
Some stated that this is a feature, while Eric (Schulte) confirmed the
behaviour and agreed that it appears more like a bug than a feature.
I'm not sure how to link to email threads, I hope the following link
works for you:
[[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#87d3964cpp@googlemail.com][Email
from Thorsten: {babel} Editing 'quote' source]]
My system:
"GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
of 2012-02-07 on arch
Org-mode version 7.8.03
Ma Gnus v0.2"
--
cheers,
Thorsten
Re: [O] Problem with choosing mode while editing blocks with C-c '
suvayu ali wrote: > Hi, > > I am having problems editing blocks with C-c '. If the blocks are marked > with upper case letters Emacs brings up the temporary buffer in > picture-mode. > >#+BEGIN_SRC latex > >#+END_SRC > > However the buffer mode is chosen correctly if lower case letters are > used. > >#+begin_src latex > >#+end_src > > Any ideas what could be wrong? > I can't reproduce it: both of them come up as latex-mode. Did you try with a new emacs instance? Perhaps your current one is curdled somehow. Nick
[O] Problem with choosing mode while editing blocks with C-c '
Hi, I am having problems editing blocks with C-c '. If the blocks are marked with upper case letters Emacs brings up the temporary buffer in picture-mode. #+BEGIN_SRC latex #+END_SRC However the buffer mode is chosen correctly if lower case letters are used. #+begin_src latex #+end_src Any ideas what could be wrong? -- Suvayu Open source is the future. It sets us free.
Re: [O] setting default pdf viewer
Nick Dokos writes: > Or maybe I've given up too easily: is there good documentation > somewhere on the web e.g. of gconftool? As they said in the old times: the documentation is in the files with the suffix .c (ducks :-). > To get back to your post: my problem with xdg-open with its switch > blades (kde-open, gnome-open, etc) is that each of those has its own > customization methods. So if I ever want to switch from kde to gnome, I > have to redo the customizations (and I have to find out how to do all > that for the new environment). Yup, one of those dislikable things they copied from Windows, it's called vendor-lock-in. Regards, 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] Sticky Agenda buffer: Announcement and request for testing
Cannot test at this time, but I have an a priori comment. Having multiple agenda buffers around increases the probability that you will change the outline buffers before you perform an operation in the agenda. You might do this either by performing agenda commands in an agenda buffer or by directly editing the outline buffer. As the agenda uses markers to get to the outline buffer, this increases the probability that you will perform an operation that will corrupt the outline buffer. I have not thought about this deeply, but perhaps every agenda command should perform a rudimentary check, if possible, to make sure the marker still points to where it did when the agenda in which it was called was created. This might entail storing header strings, or the like. It might not be ideal. However, I have noticed buffer corruption in the past and I think it would be good to keep this risk in mind in case we can come up with ways of making agenda commands safer. I avoid using the agenda because I don't always know if the marker still points where it should. Hope this helps. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] inline source blocks and minted
On 13 mars 2012, at 19:47, Eric Schulte wrote:
> Alan Schmitt writes:
>
>> Hello,
>>
>> I'm writing a presentation for a course on OCaml, and I managed to get
>> minted to work. Unfortunately I'm having issues with inline code
>> blocks. I tried to do something like:
>>
>> This value has type src_ocaml{int}
>>
>> but the exported LaTeX is simply
>>
>> This value has type
>>
>> Is it possible to have some nice syntax hilighting of source code inline?
>
> Currently there is no support for nicely syntax highlighted inline
> source blocks. I tend to use regular =verbatim= for inline code.
>
> You could always find out how this is accomplished directly in latex and
> include inline LaTeX in your Org-mode document.
Thanks, this is what I ended up doing.
Alan
Re: [O] Access org-tag-alist from #+FILETAGS
Charles wrote: > I hope my occupation is not the reason for the "no response" to my > question and comments two weeks ago. > Nope - lack of time, energy, inclination, knowledge are all possible. > Charlie Millar > > On 2/28/2012 2:28 PM, Charles wrote: > > I use a few tags and usually two or three will apply to all entries > > in a particular file, e.g. :work:Client:OpenFile: or :Personal:Home: > > > > All my tags are in my .emacs using the org-tag-alist and I want to > > use these consistently. > > > > Is there a way to access org-tag-alist from the in-buffer settings > > #+FILETAGS or #+TAGS? C-c C-c, of course, refreshes the local > > setting; C-c C-q gives an error(?) message "Before first headline at > > position 1 in buffer . . ." > > > > At the moment my work around is: start the file's first line with > > *#+FILETAGS, then C-c C-c, and after setting tags delete the > > *. > > Have you tried a setup file? tag.org: --8<---cut here---start->8--- #+TAGS: one two three --8<---cut here---end--->8--- and the "real" file is: --8<---cut here---start->8--- #+SETUPFILE: tag.org #+TAGS: foo bar baz * two * four * three :bar:baz: * one :foo: * five :foo:baz: #+BEGIN_SRC elisp org-tag-alist #+END_SRC #+RESULTS: | one | | two | | three| | :newline | | foo | | bar | | baz | everything plus :newline (whatever that is). --8<---cut here---end--->8--- Nick > > My system is Windows 7 (home Premium), emacs 24.0.93.1, org 7.8.03 > > > > If I have overlooked something obvious or easily researched, just > > say so and I'll continue looking for the answer. > > > > BTW, I'm a freelance paralegal. Amongst other uses, a few months > > ago I used org to draft a contract (from my notes kept in the org > > file), then exported to LaTeX, then to pdf to print the final draft. > > > > Charlie Millar > > > > > > > > - > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 10.0.1424 / Virus Database: 2113/4837 - Release Date: 02/28/12 > > > > > >
Re: [O] Access org-tag-alist from #+FILETAGS
I hope my occupation is not the reason for the "no response" to my question and comments two weeks ago. Charlie Millar On 2/28/2012 2:28 PM, Charles wrote: I use a few tags and usually two or three will apply to all entries in a particular file, e.g. :work:Client:OpenFile: or :Personal:Home: All my tags are in my .emacs using the org-tag-alist and I want to use these consistently. Is there a way to access org-tag-alist from the in-buffer settings #+FILETAGS or #+TAGS? C-c C-c, of course, refreshes the local setting; C-c C-q gives an error(?) message "Before first headline at position 1 in buffer . . ." At the moment my work around is: start the file's first line with *#+FILETAGS, then C-c C-c, and after setting tags delete the *. My system is Windows 7 (home Premium), emacs 24.0.93.1, org 7.8.03 If I have overlooked something obvious or easily researched, just say so and I'll continue looking for the answer. BTW, I'm a freelance paralegal. Amongst other uses, a few months ago I used org to draft a contract (from my notes kept in the org file), then exported to LaTeX, then to pdf to print the final draft. Charlie Millar - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1424 / Virus Database: 2113/4837 - Release Date: 02/28/12
Re: [O] Sticky Agenda buffer: Announcement and request for testing
Dear Max and Dominik, the new sticky agenda buffers are great! I have been using the branch for some time now and they seem to work fine. Fantastic job. I have to say at first I thought they were not working and it was because I had a preconception that they would do something else: I thought that what was sticky was the different views of a *single* agenda. For example, say you are in the week view of the agenda. I was expecting Org to remember the rendering of each week as you move from one week to another instead of recomputing each view each time (which if you have large org files is quite slow). I then realized of course that what was sticky was the different agenda views (todos, agendas, etc.). And rereading the manual it is obvious now that this is exactly what it says, so no complaints there of course. But, would it be possible to achieve the behavior I had mistakenly assumed? Going back to the week view example, Org would remember the rendering of each week as you move from one week to another, not recomputing a week that has already been visited. The different weeks would be kept in different buffers (called, e.g., *Org Agenda (*). All these buffers would be recomputed only when g is typed. It woudl work the same with, say, day view. I at least would find that *very* useful (but I do not know how much more complicated it is than the current stickiness). Cheers, Manuel --
Re: [O] Orgmode markups inside LaTeX fragments
I had a similar issue with typesetting in theorem and proof
environments; what saved me from messy LaTeX syntax was
org-special-blocks. More info is on Worg:
http://orgmode.org/worg/org-contrib/org-special-blocks.html
This is not *exactly* your situation, since this is using org syntax
within \begin{} ... \end{} blocks, but if you can adapt your commands
to be environments, this will get you what you want.
--
Albert Wang
Re: [O] inline source blocks and minted
Alan Schmitt writes:
> Hello,
>
> I'm writing a presentation for a course on OCaml, and I managed to get
> minted to work. Unfortunately I'm having issues with inline code
> blocks. I tried to do something like:
>
> This value has type src_ocaml{int}
>
> but the exported LaTeX is simply
>
> This value has type
>
> Is it possible to have some nice syntax hilighting of source code inline?
>
Currently there is no support for nicely syntax highlighted inline
source blocks. I tend to use regular =verbatim= for inline code.
You could always find out how this is accomplished directly in latex and
include inline LaTeX in your Org-mode document.
Best,
>
> Thanks,
>
> Alan
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] setting default pdf viewer
Eric Abrahamsen wrote: > ... > Sorry, that's not helpful at all! > Au contraire! It adds some validity to my prejudices :-) Thanks, Nick
Re: [O] setting default pdf viewer
On Tue, Mar 13 2012, Nick Dokos wrote: > [OT warning: no org content here, just gnome/mailcap.] > > Eric Abrahamsen wrote: > >> > Next question: since xpdf is available and /etc/mailcap prefers it, why >> > is nautilus using evince? Doesn't it use mailcap? I guess not, although >> > I don't know for sure[fn:1], but it wouldn't surprise me if it did its >> > own thing: there are way too many cooks in this kitchen. >> >> I think most linux desktop environments use something like xdg-open or >> gnome-open to determine defaults applications, all my defaults seem to >> live in /usr/local/share/applications, which can be overridden in the >> home directory. Nautilus ought to use gnome-open. I've tweaked most of >> my "open-in-external-blah" functions (in dired and gnus, for example) to >> use xdg-open, so the same defaults are used in all my applications, >> including emacs. >> > > Thanks! That was useful. > > Part of my frustration with these things (gnome things in particular) is > the sparse-to-non-existent documentation, so I really appreciate these > pointers. Or maybe I've given up too easily: is there good documentation > somewhere on the web e.g. of gconftool? Not just the syntax but an > enumeration of possibilities. My impression is that things like this are > hidden, (and in some cases, as time goes on, even if they exist, they > are taken away, so there is some motivation to keep them hidden, > although I'm not thinking conspiracy: it's just that documenting things > is hard.) I've usually fumbled in the dark with things under ~/.gconf > (or .gnome2 or .gnome) until I've found something plausible. Just to > make my problem concrete: what is the invocation of gconftool that would > change the default pdf viewer to xpdf? I don't use gnome anymore, but back when I did the gconf stuff was absolutely its most obscure aspect. I get the feeling that gnome is still trying to be the Linux Desktop for Dummies, and while gconftool is there if you need it, no one is trying to make it any easier to use. I don't think I ever once invoked gconftool, so I'm afraid I don't know… > The other way that I eventually figured out to do that is to open some > application, e.g. nautilus, select some PDF file, click on Properties > and change the default application: I find that counterintuitive, > changing the properties of a class through a single instance (and to all > applications that use the mechanism, even though I'm just using > nautilus: I can't help but find this method somewhat distasteful.) And I > like editing files rather than clicking buttons, but that's me. One of the nice things with the Mac is that it gives you two options in the contextual menu: you can open a file with a specific application, or you can tell it "use this application for all files of this type". That at least made it clearer what was going on. > To get back to your post: my problem with xdg-open with its switch > blades (kde-open, gnome-open, etc) is that each of those has its own > customization methods. So if I ever want to switch from kde to gnome, I > have to redo the customizations (and I have to find out how to do all > that for the new environment). > > I'd rather have them all use mailcap for preferred application choice. > And if mailcap does not provide all the capabilities needed by them, I'd > rather they cooperated and came up with a common mechanism that would > serve *all* their needs (plus provide thorough documentation!) But > that's a fight that's been fought and lost many times - many more times > than it's been won. Since moving from Ubuntu to a home-rolled Arch/XFCE/Stumpwm mix, I've definitely become aware that, of all the aspects of a Linux installation, the functionality that falls under the "desktop environment" category is at once the most underdocumented, and also most key to user experience. This seems to be the dark under-plumbing of the Linux GUI experience, the unlovely tangle that no one wants to expose to the user. When I went spelunking, I got the impression that mailcap predates all this XXX-open malarkey, but that most of the apps I use prefer that over mailcap. Like you, I would be very, very surprised if anyone ever put any thought into helping user customizations survive a transition from one DE to another. I still think you'll have most luck messing with files under ~/.local/share/applications, though it probably won't be as simple as that. Sorry, that's not helpful at all! > Enough venting: I've veered off-topic quite a bit here. Apologies for > the length of the (possibly uninformed) rant. If I've got things wrong, > I'd love to be corrected, but I don't want to exercise the patience of > the regulars too much. But I hope that the discussion, however > tangential, is useful. > > Thanks, > Nick > > -- GNU Emacs 24.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-03-06 on pellet Org-mode version 7.8.03 (release_7.8.03.581.g5cb80)
[O] expand view for all items in sparse tree
hello does anyone know if there is a possibility to expand all items including list items in a sparse tree for a certain tag to export only the visible to eg latex? my steps are: - C-c / :MYTAG now all headlines with the tag are shown. That's fine. But now I can only cycle the visibility of one of the sparse tree's branches and not all of them so I get something like * Item :MYTAG - [X] do this - [ ] do that * Item2 :MYTAG (hidden -[ ] do this as well) <--- but I would like to export this as well... any shortcuts I have missed so far? best regards robin
Re: [O] Orgmode markups inside LaTeX fragments
These custom commands are not analogous to sectioning commands. In fact most of them are environments. So I decided that orgmode could not achieve what I wanted to do (at least currently) and continued to use LaTeX. Too bad, I really like orgmode syntax. -- Truong Nghiem On Thu, Mar 8, 2012 at 4:05 PM, suvayu ali wrote: > On Thu, Mar 8, 2012 at 16:55, Truong Nghiem wrote: >> If there is any solution or workaround for my problem, please let me know. > > If these custom commands are analogs of commands like section and > such, you can always define your own LaTeX_CLASS. The manual has > information on how to do that. > > GL > > -- > Suvayu > > Open source is the future. It sets us free.
Re: [O] setting default pdf viewer
[OT warning: no org content here, just gnome/mailcap.] Eric Abrahamsen wrote: > > Next question: since xpdf is available and /etc/mailcap prefers it, why > > is nautilus using evince? Doesn't it use mailcap? I guess not, although > > I don't know for sure[fn:1], but it wouldn't surprise me if it did its > > own thing: there are way too many cooks in this kitchen. > > I think most linux desktop environments use something like xdg-open or > gnome-open to determine defaults applications, all my defaults seem to > live in /usr/local/share/applications, which can be overridden in the > home directory. Nautilus ought to use gnome-open. I've tweaked most of > my "open-in-external-blah" functions (in dired and gnus, for example) to > use xdg-open, so the same defaults are used in all my applications, > including emacs. > Thanks! That was useful. Part of my frustration with these things (gnome things in particular) is the sparse-to-non-existent documentation, so I really appreciate these pointers. Or maybe I've given up too easily: is there good documentation somewhere on the web e.g. of gconftool? Not just the syntax but an enumeration of possibilities. My impression is that things like this are hidden, (and in some cases, as time goes on, even if they exist, they are taken away, so there is some motivation to keep them hidden, although I'm not thinking conspiracy: it's just that documenting things is hard.) I've usually fumbled in the dark with things under ~/.gconf (or .gnome2 or .gnome) until I've found something plausible. Just to make my problem concrete: what is the invocation of gconftool that would change the default pdf viewer to xpdf? The other way that I eventually figured out to do that is to open some application, e.g. nautilus, select some PDF file, click on Properties and change the default application: I find that counterintuitive, changing the properties of a class through a single instance (and to all applications that use the mechanism, even though I'm just using nautilus: I can't help but find this method somewhat distasteful.) And I like editing files rather than clicking buttons, but that's me. To get back to your post: my problem with xdg-open with its switch blades (kde-open, gnome-open, etc) is that each of those has its own customization methods. So if I ever want to switch from kde to gnome, I have to redo the customizations (and I have to find out how to do all that for the new environment). I'd rather have them all use mailcap for preferred application choice. And if mailcap does not provide all the capabilities needed by them, I'd rather they cooperated and came up with a common mechanism that would serve *all* their needs (plus provide thorough documentation!) But that's a fight that's been fought and lost many times - many more times than it's been won. Enough venting: I've veered off-topic quite a bit here. Apologies for the length of the (possibly uninformed) rant. If I've got things wrong, I'd love to be corrected, but I don't want to exercise the patience of the regulars too much. But I hope that the discussion, however tangential, is useful. Thanks, Nick
Re: [O] Syntax highlighting of code blocks in beamer slides
Alan Schmitt wrote:
> On 13 mars 2012, at 14:41, Stefan Vollmar wrote:
>
> > Hello, we want to create slides via beamer. This works fine except
> > for source code listings (#begin_src python...#end_src) - if
> > exported as HTML they have syntax-highlighting as expected, however,
> > when exported as LaTeX the syntax-highlighting is lost. Is there a
> > way to create beamer slides with source code snippets that have
> > syntax-highlighting?
>
> I'm following this tutorial for this:
> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12-3
>
Yup, I followed the tutorial and set up minted some time ago and I have
not looked back: I just tried the following
--8<---cut here---start->8---
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+BEAMER_FRAME_LEVEL: 1
#+BEAMER_HEADER_EXTRA: \usetheme{default}\usecolortheme{default}
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_envargs(Env Args)
%4BEAMER_col(Col) %8BEAMER_extra(Extra)
#+PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 :ETC
* foo
#+BEGIN_SRC python :exports code
for x in range(100):
print "x=%d , x^2=%d" % (x, x*x)
#+END_SRC
--8<---cut here---end--->8---
and I get a caleidoscope of colors.
The TeX FAQ has some details about where to get minted and its dependencies
(it requires an external Python script, called Pygments):
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=codelist
Nick
Re: [O] Syntax highlighting of code blocks in beamer slides
On 13 mars 2012, at 14:41, Stefan Vollmar wrote: > Hello, > > we want to create slides via beamer. This works fine except for source code > listings (#begin_src python...#end_src) - if exported as HTML they have > syntax-highlighting as expected, however, when exported as LaTeX the > syntax-highlighting is lost. Is there a way to create beamer slides with > source code snippets that have syntax-highlighting? I'm following this tutorial for this: http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12-3 Alan
[O] Syntax highlighting of code blocks in beamer slides
Hello, we want to create slides via beamer. This works fine except for source code listings (#begin_src python...#end_src) - if exported as HTML they have syntax-highlighting as expected, however, when exported as LaTeX the syntax-highlighting is lost. Is there a way to create beamer slides with source code snippets that have syntax-highlighting? Many thanks in advance! Warm regards, Stefan -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleueler Str. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 E-Mail: voll...@nf.mpg.de http://www.nf.mpg.de smime.p7s Description: S/MIME cryptographic signature
[O] inline source blocks and minted
Hello,
I'm writing a presentation for a course on OCaml, and I managed to get minted
to work. Unfortunately I'm having issues with inline code blocks. I tried to do
something like:
This value has type src_ocaml{int}
but the exported LaTeX is simply
This value has type
Is it possible to have some nice syntax hilighting of source code inline?
Thanks,
Alan
[O] Bug: columnview times don't accumulate properly [7.8.03 (release_7.8.03.576.gbeb02)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
1. start with emacs -q
2. find file test-sums.org (attached)
3. adjust paths in the source block at the top of the file and evaluate
(execute?) it with C-c
4. goto the columnview block and C-c
I would expect a table like this to be inserted:
| ITEM| Sum |
|-+--|
| * Introduction | 5:40 |
|-+--|
| ** test sums| 0:30 |
|-+--|
| ** Getting warmed up| 5:10 |
|-+--|
| *** Nitty gritty| 5:10 |
| *** TODO Do something fantastic | 5:00 |
| *** END | |
|-+--|
| This is not added | 0:10 |
| *** TODO Do something else | 0:10 |
| *** END | |
Hoever, the table looks like this:
| ITEM| Sum |
|-+--|
| * Introduction | 5:30 |
|-+--|
| ** test sums| 0:30 |
|-+--|
| ** Getting warmed up| 5:00 |
|-+--|
| *** Nitty gritty| 5:00 |
| *** TODO Do something fantastic | 5:00 |
| *** END | |
|-+--|
| This is not added | 0:10 |
| *** TODO Do something else | 0:10 |
| *** END | |
i.e. the 0:10 is not being picked up in the accumulation.
#+COLUMNS: %50ITEM %5Effort(Sum){:}
#+BEGIN_SRC emacs-lisp
(setq load-path (cons "~/.emacs.d/plugins/org-mode/lisp" load-path))
(require 'org-install)
(require 'org-inlinetask)
(require 'org)
(load "~/.emacs.d/plugins/org-mode/lisp/org.el")
#+END_SRC
#+results:
: t
(emacs-version) = "GNU Emacs 23.4.1 (x86_64-unknown-linux-gnu, GTK+ Version
2.24.9)
of 2012-02-01 on shirley.hoetzel.info"
(org-version) = "Org-mode version 7.8.03 (release_7.8.03.576.gbeb02)"
* Introduction
** test sums
:PROPERTIES:
:Effort: 0:30
:END:
#+BEGIN: columnview :hlines 5 :id global
| ITEM| Sum |
|-+--|
| * Introduction | 5:30 |
|-+--|
| ** test sums| 0:30 |
|-+--|
| ** Getting warmed up| 5:00 |
|-+--|
| *** Nitty gritty| 5:00 |
| *** TODO Do something fantastic | 5:00 |
| *** END | |
|-+--|
| This is not added | 0:10 |
| *** TODO Do something else | 0:10 |
| *** END | |
#+END:
** Getting warmed up
*** Nitty gritty
*** TODO Do something fantastic
:PROPERTIES:
:Effort: 5:00
:END:
*** END
This is not added
*** TODO Do something else
:PROPERTIES:
:Effort: 0:10
:END:
*** END
Myles
Emacs : GNU Emacs 23.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.9)
of 2012-02-01 on shirley.hoetzel.info
Package: Org-mode version 7.8.03 (release_7.8.03.576.gbeb02)
current state:
==
(setq
org-export-preprocess-before-backend-specifics-hook
'(org-inlinetask-export-handler)
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-link-frame-setup '((vm . vm-visit-folder-other-frame) (gnus .
org-gnus-no-new-news)
(file . find-file-other-window) (wl . wl-other-frame))
org-structure-template-alist '(("s" "#+begin_src ?\n\n#+end_src" "\n\n")
("e" "#+begin_example\n?\n#+end_example"
"\n?\n")
("q" "#+begin_quote\n?\n#+end_quote"
"\n?\n")
("v" "#+begin_verse\n?\n#+end_verse"
"\n?\n/verse>")
("c" "#+begin_center\n?\n#+end_center"
"\n?\n/center>")
("l" "#+beg
Re: [O] ways to insert "note to self" in an org-mode file for academic paper
>> On Mon, 12 Mar 2012 16:25:42 -0400, Christopher W Ryan said: > Thanks Myles. That's pretty cool. --Chris Following on from Karl's post, this thread has some useful help on exporting inline tasks through latex: http://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00157.html Please copy any reply to the list so that people know you have received a reply. Please don't top post. Sorry for my word wrapping (below), will fix soon. Myles > Christopher W. Ryan, MD SUNY Upstate Medical University Clinical > Campus at Binghamton 425 Robinson Street, Binghamton, NY 13904 > cryanatbinghamtondotedu > "Observation is a more powerful force than you could possibly > reckon. The invisible, the overlooked, and the unobserved are the > most in danger of reaching the end of the spectrum. They lose the > last of their light. From there, anything can happen . . ." [God, > in "Joan of Arcadia," episode entitled, "The Uncertainty > Principle."] > Myles English wrote: On Mon, 12 Mar 2012 11:55:23 -0400, Christopher W Ryan said: >> >> > I'm very early in trying a transition from LaTeX to org-mode for >> > academic writing, trying to learn the Org way of doing > >> things. Running Org-mode 7.7 in Emacs 23.4.1 on Win XP. >> >> > Suppose I'm writing a draft of a research proposal and come to >> some > part that I may want to consider changing, after I think >> about it > some more, check with others, or reassess my >> resources. In LaTex, > I'd write something like this: >> >> > % need to look into this further, check with so-and-so >> >> > and keep writing on the next line. >> >> > How does one do this well in Org-mode? With a # comment >> character? > Or does this become a TODO item? >> >> Chris, >> >> I use inline tasks. e.g. >> >> *** TODO look into this further, check with >> so-and-so *** END >> >> And to see all of the todos in the file I use this quite a lot, >> just press F9 to see a list: >> >> ;; show all todos in the current buffer with one key press >> (global-set-key (kbd "") (lambda () (interactive) (org-agenda >> nil "t" 'file))) >> >> > Of course, I wouldn't want that little "note to self" to appear >> in > any final document. But I might want it to remain in the >> source > file, to document my line of reasoning. >> >> To not export todos, have this at the top of you file and press C-c >> on it before exporting: >> >> #+OPTIONS: todo:nil >> >> > Thanks. >> >> > --Chris -- Christopher W. Ryan, MD SUNY Upstate Medical >> University > Clinical Campus at Binghamton 425 Robinson Street, >> Binghamton, NY > 13904 cryanatbinghamtondotedu >> >> > "Observation is a more powerful force than you could possibly > >> reckon. The invisible, the overlooked, and the unobserved are the >> > most in danger of reaching the end of the spectrum. They lose the >> > last of their light. From there, anything can happen . . ." >> [God, > in "Joan of Arcadia," episode entitled, "The Uncertainty > >> Principle."] >> >> Myles
[O] Org-mode workshop cancelled (was: Org-mode workshop: has anyone done this already?)
* Karl Voit wrote: > > I'll probably use your material as a starting point and extend it a > bit. If you are interested in following the status of my material, > please watch my repository on GitHub[3]. > > 3. https://github.com/novoid/org-mode-workshop I was informed that the workshop was canceled because of too few attendees (6 of 12 max). So I stop my preparations for now. But in autumn, there will be the next chance of conducting this workshop. Generally, in summer term there are much fewer attendees for our internal educational programme so I hope the reason is not Org-mode being an uninteresting topic :-) But I still plan to add any workshop-related material to the github project from above. The good thing is though: this gives me more time for writing my PhD thesis this month :-) -- Karl Voit
[O] LaTeX-notes in margin space (was: ways to insert "note to self" in an org-mode file for academic paper)
* Christopher W. Ryan wrote:
>
> Suppose I'm writing a draft of a research proposal and come to some part
> that I may want to consider changing, after I think about it some more,
> check with others, or reassess my resources. In LaTex, I'd write
> something like this:
>
> % need to look into this further, check with so-and-so
>
> and keep writing on the next line.
Besides the tipp that you can make an Org-mode todo out of it
(probably the best way to write down todos :-) you might want to
have this notes in the LaTeX PDF result file as well.
For that purpose I am using a LaTeX-newcommand:
\newcommand{\fixxme}[1]{%%
\textcolor{red}{FIXXME}\marginpar{\textcolor{red}{#1}}%%
}
Writing something like this\fixxme{check source for quotation} ends
up in a «FIXXME» within the line and the text in the braces in the
margin space - set in red letters.
--
Karl Voit
[O] [PATCH] Add missing word to org-contacts y-or-n-p question.
>From 6254305becaaa712f6f0936263a09d9ed974e51b Mon Sep 17 00:00:00 2001 User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) Cancel-Lock: sha1:/pUqi5NalGwuBic1R2H+VziOGlM= Before it was Do you want to this address to %s? now it is Do you want add to this address to %s? --- contrib/lisp/org-contacts.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index f238483..bdd9996 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -388,7 +388,7 @@ This function should be called from `gnus-article-prepare-hook'." (let ((mails (org-entry-get (point) org-contacts-email-property))) (unless (member mail (split-string mails)) (when (yes-or-no-p - (format "Do you want to this address to %s?" (org-get-heading t))) + (format "Do you want to add this address to %s?" (org-get-heading t))) (org-set-property org-contacts-email-property (concat mails " " mail)) (defun org-contacts-gnus-check-mail-address () -- 1.7.8.5
