Re: [Orgmode] text color + highlight
On 08/11/2010 01:14 AM, Samuel Wales wrote: i suggest begin-end pairs, not putting text in the syntax itself. though you could, if you want, using quotes. $[class begin :title animals]Some text about animals$[class end :title animals] Why not allow both? If I want to highlight one or two words, maybe I could use: $[class :title animals African swallow] Compare this to: $[class begin :title animals]African swallow$[class end :title animals] For a few sentences and to get support for nested formatting, I would definitely want begin-end pairs, too, but if you want to highlight a few words, being able to put text into the syntax itself makes things a lot shorter. As far as I understand it, once a framework for this extensible syntax is in place, it would not be too hard to support both variants. BTW, I really like the idea of having extensible syntax in general; this could also make inline todos a lot less painful. I do not know enough about elisp and Org to help with the implementation, but if someone wants to implement this and needs help with testing, I'd be glad to help. (I wrote my last exam today, so I will have a lot more time to spare until October.) Jan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: text color + highlight
Carsten Dominik carsten.domi...@gmail.com writes:
Hi,
Can we please first read Samuels post about extensible syntax? Before
we invent 20 other new syntaxes?
http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10204
May I add this thread to the discussion as an example of another feature
that was suggested as a possible use case for extensible syntax:
http://thread.gmane.org/gmane.emacs.orgmode/24431
This is the feature I currently want most in org-mode: org mode blocks
that behave exactly like org-mode blocks, except that their content in
reality lies in a different file. This would allow org-mode to improve
on its claim of inobtrusiveness: one could collaborate on a code project
without the other people knowing you were using org-mode to manage your
access points into the shared files. Also, I like the corollary, that a
version control system will track the code content in separate files
from the org content.
A related idea is having links with both a start and an end point:
following them would end up in a buffer to the specified region (window
links if window wasn't already used for a different meaning).
Any ideas welcome! (there are also ideas in that thread)
Dan
Thanks!
On Aug 10, 2010, at 8:14 AM, Christian Moe wrote:
Hi,
- this would be extensible, e.g.
[background[yellow] highlighted text]
could export to the following html
span style=background:yellow;highlighted text/span
- this would avoid {}s
- this would look more org-like than the pure latex solution
the only issue with the above is that it may conflate a new /
markup/
syntax with org-mode's existing /link/ syntax.
Thoughts? -- Eric
I'd like an extensible inline markup construct (not primarily for
coloring).
Would it make sense to hijack custom links for this purpose, and use
existing bracketed link syntax rather than add a new syntax?
For semantic tagging (my chief interest), one might e.g. define a
class' link type and an HTML export handler to wrap the contents in
span class=kewyord tags.
: [[class:animals][some text about animals]]
As for color: If one is satisfied with getting colors on export,
defining a `color' link type and appropriate export handlers will
do.
: [[color:red][some colored text]]
If one also wants the text to appear in the right color within Org-
mode, and does not want the pseudo-link markup to be underlined and
look like links, it would require additional Org functionality (I
think): User-defined custom faces for different link types.
What syntax to use...
I've thought briefly about the following syntax
[color[red] text to be colored red]
Nope, I am against this syntax. If we introduce a more general
syntax,
then it should be done in the way Samuel proposed. WHich means
we firs get a keyword indtroducing the piece, and then properties.
Like
$[style :color red the red text]
or
$[face :color :italic t red the red text]
Something like the $ before [ also would seem critical to
disambiguate
from other uses of [.
However, I am not too excited about extra syntax to get this kind
of thing.
Would not oppose it, but probably never use it.
- Carsten
Those examples are not very readable IMO -- without a separator it's
hard to see where the property values end and the marked up text
begins.
Yours,
Christian
- Carsten
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Does new version 7.01 break mail-archive-file-name?
Dear list, first of all, many thanks for this wonderful piece of software and for this wonderful list. I use to send my emails with emacs (gnus) and use the variable: (setq mail-archive-file-name ~/sent-items) After upgrading to orgmode 7.01 sent mails are not being archived in this file. They are not archived at all. With version 6.36c there was not this issue. Thnaks in advance. I. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] why not auto-renumbering list ?
On 10/8/10 14:32 , Nicolas Goaziou n.goaz...@gmail.com wrote: Andrew Swann writes: Many thanks for this suggestion. It is certainly useful. Is there a local solution that could be used just around this line? It would be nice if one could escape the period. Enforce numbering to 2 with [...@start:2]. It will still be treated as a list, but it won't be renumbered. Otherwise, if this isn't at column 0, you can insert a non-breaking space (C-q 240) somewhere in front of your item. Org will not recognize a list, and it will be invisible when exporting. Aha! The C-q 240 non-breaking space is the key. With the 2. at column 0, I can put this immediately after the period and the text is treated as text rather than list item. Excellent. Many thanks Andrew -- Andrew Swann sw...@imada.sdu.dk http://www.imada.sdu.dk/~swann Department of Mathematics and Computer Science, Tel +45 6550 2354 and CP3-Origins, University of Southern Denmark,Dept +45 6550 2387 Campusvej 55, DK-5230 Odense M, Denmark Fax +45 6550 2325 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: %i indentation in capture templates
On Aug 6, 2010, at 12:11 PM, Thomas Jack wrote: 2010/8/6 Sébastien Vauban wxhgmqzgw...@spammotel.com: But just wanted to confirm you this seems, then, a bug to me (regarding what the doc promises). Thanks for the confirmation. The following patch seems to fix the problem: diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 111f7f7..1e407f1 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1045,6 +1045,7 @@ Lisp programs can force the template by setting KEYS to a string. Fill a template and return the filled template as a string. The template may still contain \%?\ for cursor positioning. (setq template (or template (org-capture-get :template))) + (setq initial (or initial (org-capture-get :initial))) (when (stringp initial) (setq initial (org-no-properties initial)) (remove-text-properties 0 (length initial) '(read-only t) initial)) Applied, at a slightly different place in that function. Thanks! - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: keys and command name info
On Aug 9, 2010, at 9:28 PM, Dan Davison wrote:
Dan Davison davi...@stats.ox.ac.uk writes:
Gregor Zattler telegr...@gmx.net writes:
Hi Andreas, org-mode developers,
* Andreas Burtzlaff and...@gmx.net [09. Aug. 2010]:
Carsten Dominik carsten.domi...@gmail.com writes:
I have put a version of the manual as modified by Andreas here:
http://orgmode.org/org-manual-with-command-names.pdf
Not all the command names are in there, but quite a few are.
I'd like to hear from more people
- if they would like to have the names there (i.e. if it would
help them finding a command)
I would like the command names in the manual.
- Emacs-lisp has a lovely tradition of naming functions *very*
descriptively and not being afraid to use long names in the
interests
of accuracy. It's a shame to lose all that by displaying only key
sequences. It's a linguistic world of its own and I like being
exposed
to it.
- While one can do C-h k, that's not the same as the way one learns
the
function names by skimming the manual
Also, it does not add length to the HTML version of the manual,
because
the key sequences are already on a line of their own. And the same is
true for a certain proportion of the pdf entries (when the key
sequence
is long, then it seems to go on its own line).
- if the position (first thing in the command description)
is right, or if it would be better to have it
- last thing in the description
- or after the first sentence, this is how the GNUS manual
does it.
I definitely would want them out on a line of their own with the key
sequence. I liked the right-aligned model.
Or if not right-aligned, is it possible not to have the comma?
Maybe a
different font?
I also like the position on the key line best. So if there is a more-
or-less
general agreement that we should get the names in, this would be my
preferred
location as well. I knot that this is different from what the emacs
and gnus manuals do - but I still think that a solution like this would
be better.
Andreas, can you be bothered to rework the patch?
Unfortunately I have no idea if/how the right-aligned model could be
made to
work. So I think the safest way to do this would be to introduce the
macro,
and we can then work on the macro to get the formatting right, and
also to do the
key and function index stuff fully automatically.
Here is my proposal for now:
@macro orgcmd{key,command}
@kindex \key\
@findex \command\
@item \key\ @ @ @ @ @ @ @ @ @ @ @r{(}\comma...@r{)}
@end macro
And then define keys/commands like this:
@table @kbd
.
@orgc...@key{tab}, org-cycle}
Here follows the description of the command
@end table
- Carsten
Dan
Having the function names in the manual at all makes it look a bit
overloaded and might lose us a couple of newbies, I think.
Personally, I
would not have use for it.
If the names are included in the manual I strongly object to them
being
at the beginning of the first sentence. The fixed starting column
of the
sentences becomes variable and that makes it hard to skim through
for
those who don't want to read the function names.
+1 for the same reasons.
This is especially true for paragraphs like those:
C-c C-n (outline-next-visible-heading) Next heading.
C-c C-p (outline-previous-visible-heading) Previous heading.
C-c C-f (org-forward-same-level) Next heading same level.
C-c C-b (org-backward-same-level) Previous heading same level.
C-c C-u (outline-up-heading) Backward to higher level heading.
C-c C-j (org-goto) Jump to a different place without changing the
current outline
visibility. Shows the document structure in a temporary
buffer, where you can
use the following keys to find your destination:
What about having them in the same line as the keybinding but
aligned to
the right?
`C-c [' org-agenda-file-
to-front
Add current file to the list of agenda files. The file is
added to
the front of the list. If it was already in the list, it is
moved
to the front. With prefix arg, file is added/moved to the end.
It would make the manual longer, but at least it looks clean.
It is easy to neglect the function names if one wants, and just
as easy
to skim through them.
+1 for the same reasons.
But Andreas Röhlers original variant is IMHO even better:
| [ ... ]
| `C-c [', org-agenda-file-to-front
| Add current file to the list of agenda files. The file is
added to
| the front of the list. If it was already in the list, it
is moved
| to the front. With prefix Argument, file is added/moved to
the end.
Yes, but let's lose the extra comma.
`C-c [' org-agenda-file-to-front
Here the command name serves as a kind of a heading, it's easy
to search these locations while at the same time it's easy to
skim over the pages and not bother with the command names.
My preference:
1. as in Andreas Röhlers original ASCII
Re: [Orgmode] Re: keys and command name info
Am 11.08.2010 12:05, schrieb Carsten Dominik:
On Aug 9, 2010, at 9:28 PM, Dan Davison wrote:
Dan Davison davi...@stats.ox.ac.uk writes:
Gregor Zattler telegr...@gmx.net writes:
Hi Andreas, org-mode developers,
* Andreas Burtzlaff and...@gmx.net [09. Aug. 2010]:
Carsten Dominik carsten.domi...@gmail.com writes:
I have put a version of the manual as modified by Andreas here:
http://orgmode.org/org-manual-with-command-names.pdf
Not all the command names are in there, but quite a few are.
I'd like to hear from more people
- if they would like to have the names there (i.e. if it would
help them finding a command)
I would like the command names in the manual.
- Emacs-lisp has a lovely tradition of naming functions *very*
descriptively and not being afraid to use long names in the interests
of accuracy. It's a shame to lose all that by displaying only key
sequences. It's a linguistic world of its own and I like being exposed
to it.
- While one can do C-h k, that's not the same as the way one learns the
function names by skimming the manual
Also, it does not add length to the HTML version of the manual, because
the key sequences are already on a line of their own. And the same is
true for a certain proportion of the pdf entries (when the key sequence
is long, then it seems to go on its own line).
- if the position (first thing in the command description)
is right, or if it would be better to have it
- last thing in the description
- or after the first sentence, this is how the GNUS manual
does it.
I definitely would want them out on a line of their own with the key
sequence. I liked the right-aligned model.
Or if not right-aligned, is it possible not to have the comma? Maybe a
different font?
I also like the position on the key line best. So if there is a
more-or-less
general agreement that we should get the names in, this would be my
preferred
location as well. I knot that this is different from what the emacs
and gnus manuals do - but I still think that a solution like this would
be better.
Andreas, can you be bothered to rework the patch?
Unfortunately I have no idea if/how the right-aligned model could be
made to
work. So I think the safest way to do this would be to introduce the macro,
and we can then work on the macro to get the formatting right, and also
to do the
key and function index stuff fully automatically.
Here is my proposal for now:
@macro orgcmd{key,command}
@kindex \key\
@findex \command\
@item \key\ @ @ @ @ @ @ @ @ @ @ @r{(}\comma...@r{)}
@end macro
And then define keys/commands like this:
@table @kbd
.
@orgc...@key{tab}, org-cycle}
Here follows the description of the command
@end table
- Carsten
OK, I'm on it next days.
Cheers
Andreas
Dan
Having the function names in the manual at all makes it look a bit
overloaded and might lose us a couple of newbies, I think.
Personally, I
would not have use for it.
If the names are included in the manual I strongly object to them
being
at the beginning of the first sentence. The fixed starting column
of the
sentences becomes variable and that makes it hard to skim through for
those who don't want to read the function names.
+1 for the same reasons.
This is especially true for paragraphs like those:
C-c C-n (outline-next-visible-heading) Next heading.
C-c C-p (outline-previous-visible-heading) Previous heading.
C-c C-f (org-forward-same-level) Next heading same level.
C-c C-b (org-backward-same-level) Previous heading same level.
C-c C-u (outline-up-heading) Backward to higher level heading.
C-c C-j (org-goto) Jump to a different place without changing the
current outline
visibility. Shows the document structure in a temporary buffer,
where you can
use the following keys to find your destination:
What about having them in the same line as the keybinding but
aligned to
the right?
`C-c [' org-agenda-file-to-front
Add current file to the list of agenda files. The file is added to
the front of the list. If it was already in the list, it is moved
to the front. With prefix arg, file is added/moved to the end.
It would make the manual longer, but at least it looks clean.
It is easy to neglect the function names if one wants, and just as
easy
to skim through them.
+1 for the same reasons.
But Andreas Röhlers original variant is IMHO even better:
| [ ... ]
| `C-c [', org-agenda-file-to-front
| Add current file to the list of agenda files. The file is added to
| the front of the list. If it was already in the list, it is moved
| to the front. With prefix Argument, file is added/moved to the end.
Yes, but let's lose the extra comma.
`C-c [' org-agenda-file-to-front
Here the command name serves as a kind of a heading, it's easy
to search these locations while at the same time it's easy to
skim over the pages and not bother with the command names.
My preference:
1. as in Andreas Röhlers original ASCII rendering
2. as in Andreas Burtzlaffs ASCII rendering
3. not at all
4. as in
Re: [Orgmode] Re: keys and command name info
On Aug 11, 2010, at 12:23 PM, Andreas Röhler wrote:
Am 11.08.2010 12:05, schrieb Carsten Dominik:
On Aug 9, 2010, at 9:28 PM, Dan Davison wrote:
Dan Davison davi...@stats.ox.ac.uk writes:
Gregor Zattler telegr...@gmx.net writes:
Hi Andreas, org-mode developers,
* Andreas Burtzlaff and...@gmx.net [09. Aug. 2010]:
Carsten Dominik carsten.domi...@gmail.com writes:
I have put a version of the manual as modified by Andreas here:
http://orgmode.org/org-manual-with-command-names.pdf
Not all the command names are in there, but quite a few are.
I'd like to hear from more people
- if they would like to have the names there (i.e. if it would
help them finding a command)
I would like the command names in the manual.
- Emacs-lisp has a lovely tradition of naming functions *very*
descriptively and not being afraid to use long names in the
interests
of accuracy. It's a shame to lose all that by displaying only key
sequences. It's a linguistic world of its own and I like being
exposed
to it.
- While one can do C-h k, that's not the same as the way one
learns the
function names by skimming the manual
Also, it does not add length to the HTML version of the manual,
because
the key sequences are already on a line of their own. And the same
is
true for a certain proportion of the pdf entries (when the key
sequence
is long, then it seems to go on its own line).
- if the position (first thing in the command description)
is right, or if it would be better to have it
- last thing in the description
- or after the first sentence, this is how the GNUS manual
does it.
I definitely would want them out on a line of their own with the
key
sequence. I liked the right-aligned model.
Or if not right-aligned, is it possible not to have the comma?
Maybe a
different font?
I also like the position on the key line best. So if there is a
more-or-less
general agreement that we should get the names in, this would be my
preferred
location as well. I knot that this is different from what the emacs
and gnus manuals do - but I still think that a solution like this
would
be better.
Andreas, can you be bothered to rework the patch?
Unfortunately I have no idea if/how the right-aligned model could be
made to
work. So I think the safest way to do this would be to introduce
the macro,
and we can then work on the macro to get the formatting right, and
also
to do the
key and function index stuff fully automatically.
Here is my proposal for now:
@macro orgcmd{key,command}
@kindex \key\
@findex \command\
@item \key\ @ @ @ @ @ @ @ @ @ @ @r{(}\comma...@r{)}
@end macro
And then define keys/commands like this:
@table @kbd
.
@orgc...@key{tab}, org-cycle}
Here follows the description of the command
@end table
- Carsten
OK, I'm on it next days.
Great.
I am not yet sure how to handle @itemx, so maybe just leave alone
entries which have an @itemx
Cheers
- Carsten
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Proposed command: org-agenda-clock-goto
Carsten Dominik carsten.domi...@gmail.com writes: I have not looked up which way it is now, but thinking again it seems to me that this would be the right way: C-c C-x C-j jumps to the entry in the org buffer, both from the agenda and from normal buffers. This is how it works now. I updated the doc accordingly and I also added a line for the `J' command in the agenda buffer. J would then be available to find the clock entry in the agenda, if it is present there. We could extend this command to show the clock entry in the other window if the line cannot be found in the agenda window... This is how it works - please let me know if it works okay. Thanks, -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: text color + highlight
Hi Dan,
I think you might have found the thread to which I had intented to
post my reply that now is in the thread, extensible syntax example
using link features. Not sure though. The last few paragraphs have
comments on a topic related to this.
Samuel
On 2010-08-10, Dan Davison davi...@stats.ox.ac.uk wrote:
Carsten Dominik carsten.domi...@gmail.com writes:
Hi,
Can we please first read Samuels post about extensible syntax? Before
we invent 20 other new syntaxes?
http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10204
May I add this thread to the discussion as an example of another feature
that was suggested as a possible use case for extensible syntax:
http://thread.gmane.org/gmane.emacs.orgmode/24431
This is the feature I currently want most in org-mode: org mode blocks
that behave exactly like org-mode blocks, except that their content in
reality lies in a different file. This would allow org-mode to improve
on its claim of inobtrusiveness: one could collaborate on a code project
without the other people knowing you were using org-mode to manage your
access points into the shared files. Also, I like the corollary, that a
version control system will track the code content in separate files
from the org content.
A related idea is having links with both a start and an end point:
following them would end up in a buffer to the specified region (window
links if window wasn't already used for a different meaning).
Any ideas welcome! (there are also ideas in that thread)
Dan
Thanks!
On Aug 10, 2010, at 8:14 AM, Christian Moe wrote:
Hi,
- this would be extensible, e.g.
[background[yellow] highlighted text]
could export to the following html
span style=background:yellow;highlighted text/span
- this would avoid {}s
- this would look more org-like than the pure latex solution
the only issue with the above is that it may conflate a new /
markup/
syntax with org-mode's existing /link/ syntax.
Thoughts? -- Eric
I'd like an extensible inline markup construct (not primarily for
coloring).
Would it make sense to hijack custom links for this purpose, and use
existing bracketed link syntax rather than add a new syntax?
For semantic tagging (my chief interest), one might e.g. define a
class' link type and an HTML export handler to wrap the contents in
span class=kewyord tags.
: [[class:animals][some text about animals]]
As for color: If one is satisfied with getting colors on export,
defining a `color' link type and appropriate export handlers will
do.
: [[color:red][some colored text]]
If one also wants the text to appear in the right color within Org-
mode, and does not want the pseudo-link markup to be underlined and
look like links, it would require additional Org functionality (I
think): User-defined custom faces for different link types.
What syntax to use...
I've thought briefly about the following syntax
[color[red] text to be colored red]
Nope, I am against this syntax. If we introduce a more general
syntax,
then it should be done in the way Samuel proposed. WHich means
we firs get a keyword indtroducing the piece, and then properties.
Like
$[style :color red the red text]
or
$[face :color :italic t red the red text]
Something like the $ before [ also would seem critical to
disambiguate
from other uses of [.
However, I am not too excited about extra syntax to get this kind
of thing.
Would not oppose it, but probably never use it.
- Carsten
Those examples are not very readable IMO -- without a separator it's
hard to see where the property values end and the marked up text
begins.
Yours,
Christian
- Carsten
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for 25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Finally jekyll and org-jekyll
I've been struggling for already too much time and I really don't get anywhere the few informations I need. I want to finally build my page with jekyll and org-mode, and I also have org-jekyll which looks pretty cool, but anything I tried until now didn't work The question basically is, what do I have to write myself and what will be automatically written? I see that jekyll wants something like this below, but do I need to define alli those things even using org-jekyll? I also tried the test example in org-jekyll but all I get is the same files repeated again in the directory. --8---cut here---start-8--- |-- _config.yml |-- _layouts | |-- default.html | `-- post.html |-- _posts | |-- 2007-10-29-why-every-programmer-should-play-nethack.textile | `-- 2009-04-26-barcamp-boston-4-roundup.textile |-- _site `-- index.html --8---cut here---end---8--- Any simple in two words explanation that could finally enlighten me please? Thanks a lot ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Clock history, C-u C-c C-x C-i not working properly
Bernt Hansen be...@norang.ca writes: Markus Heller helle...@gmail.com writes: Hello all, I have had this issue for quite a while, and now it's finally time to post it. I'm using emacs 23.2.1 and orgmode 7.01trans (release_7.01g.73.g29354) on windoze XP, together with Bernt's clock history setup. If I hit C-u C-c C-x C-i, the list of tasks to clock in starts somewhere in the middle, right now at ``[J]''. I've had this issue on emacs 22 and with orgmode 6.36 ... My list on Windows XP, Emacs 23.2.1 is also a bit weird. The choices for my list are: [d] [1] [2] [5] [6] [7] [8] [9] [A] [B] [C] [D] [M] [O] [R] On linux with a full clock history I get [d] [1] [2] ... [9] [A] [B] ... [R] [S] with no gaps I've noticed problems with the menu on my EEE PC which has a reduced screen size so it couldn't display the entire menu and displayed the end instead of beginning of the menu. I've since reduced org-clock-history-length from 36 to 28 so it fits on that device. I reduced org-clock-history-length to 12, to no avail. It's not that the list doesn't fit in the buffer ... It just shows items [J] through [Z] without any gaps... Any other suggestions? Thanks Markus ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Clock history, C-u C-c C-x C-i not working properly
Bernt Hansen be...@norang.ca writes: Markus Heller helle...@gmail.com writes: Hello all, I have had this issue for quite a while, and now it's finally time to post it. I'm using emacs 23.2.1 and orgmode 7.01trans (release_7.01g.73.g29354) on windoze XP, together with Bernt's clock history setup. If I hit C-u C-c C-x C-i, the list of tasks to clock in starts somewhere in the middle, right now at ``[J]''. I've had this issue on emacs 22 and with orgmode 6.36 ... My list on Windows XP, Emacs 23.2.1 is also a bit weird. The choices for my list are: [d] [1] [2] [5] [6] [7] [8] [9] [A] [B] [C] [D] [M] [O] [R] On linux with a full clock history I get [d] [1] [2] ... [9] [A] [B] ... [R] [S] with no gaps I've noticed problems with the menu on my EEE PC which has a reduced screen size so it couldn't display the entire menu and displayed the end instead of beginning of the menu. I've since reduced org-clock-history-length from 36 to 28 so it fits on that device. I tried reducing org-clock-history-length to 12, but to no avail. It's not that the list doesn't fit in the buffer, it starts at [J] and shows only [J] through [Z] with no gaps. I don't see an error message in the minibuffer ... Would it help if I attached a screenshot? Thanks Markus ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] C-c a is undefined
Hi! This about some keyboard shortcuts. I use emacs 23.2 on linux and orgmode 7.01 (latest). I have followed the instructions in the Compact Org-mode Guide. Still I cannot use the shortcuts for the agenda dispatcher. The message I get when trying is C-c a is undefined Can anyone lead me in the right direction? /C ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] C-c a is undefined
Hi Glasspen, Glasspen ckglasspe...@gmail.com writes: C-c a is undefined (define-key global-map \C-ca 'org-agenda) See section 1.3 of the compact guide. HTH, -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Mathematical Pseudocode in Source Block
Hi there,
I was wondering if there was any way to make the source blocks work
with LaTeX formulas. I wanted to use it for some pesudocode; for
example:
while not converged
for each state i
\( U^{'}_i = r_i + \underset{a}{argmax} \sum{Pa_{ij}U_j} \)
\( U_i \rightarrow U^{'}_i \)
end for
end while
If a source block isn't possible, is there at least a way to get a
textbox around it?
Thank you
--
Jeremiah M. Via
School of Computer Science
University of Birmingham
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Print / export TODO Tree
Sorry if this is a FAQ, but is there a way to export or print a TODO tree? Thanks, --Nate ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Print / export TODO Tree
You can highlight the tree (parent and its children) then use org-export-region-as-ascii. You can also export to any of the supported export formats. -Neil On 2010-08-11, at 2:10 PM, Nathan Neff wrote: Sorry if this is a FAQ, but is there a way to export or print a TODO tree? Thanks, --Nate ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Finally jekyll and org-jekyll
On 11/08/10 17:41, Andrea Crotti wrote: I've been struggling for already too much time and I really don't get anywhere the few informations I need. I want to finally build my page with jekyll and org-mode, and I also have org-jekyll which looks pretty cool, but anything I tried until now didn't work The question basically is, what do I have to write myself and what will be automatically written? I see that jekyll wants something like this below, but do I need to define alli those things even using org-jekyll? I also tried the test example in org-jekyll but all I get is the same files repeated again in the directory. --8---cut here---start-8--- |-- _config.yml |-- _layouts | |-- default.html | `-- post.html |-- _posts | |-- 2007-10-29-why-every-programmer-should-play-nethack.textile | `-- 2009-04-26-barcamp-boston-4-roundup.textile |-- _site `-- index.html --8---cut here---end---8--- Any simple in two words explanation that could finally enlighten me please? Thanks a lot Hi Andrea, I don't use org-jekyll myself. You can view my tutorial on the way I di it at http://orgmode.org/worg/org-tutorials/org-jekyll.php . Basically what you need to do is to organize your system so that org publishes your .org files to html in a place that jekyll can process them. Are you trying to write a blog ie. posts ordered in date format, or a static web site, or a combination of both? If you can tell me exactly what you want to achieve, I'll try and help out. Ian. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Proposed command: org-agenda-clock-goto
On Aug 11, 2010, at 4:24 PM, Bastien wrote: Carsten Dominik carsten.domi...@gmail.com writes: I have not looked up which way it is now, but thinking again it seems to me that this would be the right way: C-c C-x C-j jumps to the entry in the org buffer, both from the agenda and from normal buffers. This is how it works now. I updated the doc accordingly and I also added a line for the `J' command in the agenda buffer. J would then be available to find the clock entry in the agenda, if it is present there. We could extend this command to show the clock entry in the other window if the line cannot be found in the agenda window... This is how it works - please let me know if it works okay. Hmmm, I just pulled, and J jumps to the org-mode file while C-c C-x C- j goes to the agenda lines corresponding to the clocking item. I meant it the other way around. What am I missing? - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Clock history, C-u C-c C-x C-i not working properly
Markus Heller helle...@gmail.com writes: Bernt Hansen be...@norang.ca writes: Markus Heller helle...@gmail.com writes: Hello all, I have had this issue for quite a while, and now it's finally time to post it. I'm using emacs 23.2.1 and orgmode 7.01trans (release_7.01g.73.g29354) on windoze XP, together with Bernt's clock history setup. If I hit C-u C-c C-x C-i, the list of tasks to clock in starts somewhere in the middle, right now at ``[J]''. I've had this issue on emacs 22 and with orgmode 6.36 ... My list on Windows XP, Emacs 23.2.1 is also a bit weird. The choices for my list are: [d] [1] [2] [5] [6] [7] [8] [9] [A] [B] [C] [D] [M] [O] [R] On linux with a full clock history I get [d] [1] [2] ... [9] [A] [B] ... [R] [S] with no gaps I've noticed problems with the menu on my EEE PC which has a reduced screen size so it couldn't display the entire menu and displayed the end instead of beginning of the menu. I've since reduced org-clock-history-length from 36 to 28 so it fits on that device. I tried reducing org-clock-history-length to 12, but to no avail. It's not that the list doesn't fit in the buffer, it starts at [J] and shows only [J] through [Z] with no gaps. I don't see an error message in the minibuffer ... Would it help if I attached a screenshot? No I don't think attaching a screenshot will really add any value at this point. I'm looking at the org-clock-select-task function to try to determine why it comes up with these weird selections. -Bernt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Looking for a sample function to find a location for org-capture
I'm exploring the many features of org-capture and I see the documentation about a function for finding the location for refiling. I would like to see some sample code on how to do this. At the moment I am using a date tree to file my TODO items and notes. (I am writing an article about this and will publish soon) Let's say I had a headline structure for weeks of the year and I would like a function to add an item to the heading corresponding to the week of the year. Today (12th Aug) we are in Week 32. What would the function be to file under the appropriate heading: * 2010 ** 2010-Week-28 ** 2010-Week-29 ** 2010-Week-30 ** 2010-Week-31 ** 2010-Week-32 ** 2010-Week-33 Could the function create the heading if it didnt exist . just like org-capture handles creation of new brances on a date tree? Charles ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Proposed command: org-agenda-clock-goto
On Aug 12, 2010, at 3:43 AM, Bastien bastien.gue...@wikimedia.fr wrote: Carsten Dominik carsten.domi...@gmail.com writes: Hmmm, I just pulled, and J jumps to the org-mode file while C-c C-x C- j goes to the agenda lines corresponding to the clocking item. I meant it the other way around. What am I missing? Weird -- M-x org-reload? This diff shows the change in the keybindinds: http://repo.or.cz/w/org-mode.git/blobdiff/f0be9ff91bd52c530f0d7556872576eb9803cb38..a7a842457dd927df9eabc756c4c573720a3a7aa9:/lisp/org-agenda.el Let me know, For me J takes me to the org file entry not to the agenda entry. Thanks Noorul ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [Patch] org-capture.el
When capture templates with tags are finalized, those tags are not realigned. I think this fixes it (does in the cases I've tested). diff --git a/lisp/org-capture.el b/lisp/org-capture.el index ece5006..03911da 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -500,7 +500,8 @@ bypassed. (save-excursion (when (ignore-errors (org-back-to-heading)) (org-update-parent-todo-statistics) - (org-update-checkbox-count))) + (org-update-checkbox-count) + (org-set-tags nil t))) ;; FIXME Here we should do the sorting ;; If we have added a table line, maybe recompute? (when (and (eq (org-capture-get :type 'local) 'table-line) -- Mark Scala ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
