Re: [O] how to show deadlines in global to-do list?
At Fri, 02 Dec 2011 12:01:05 -0500, emacs-orgmode-requ...@gnu.org wrote: > Date: Fri, 2 Dec 2011 03:01:36 + (UTC) > From: Herbert Sitz > To: emacs-orgmode@gnu.org > Subject: Re: [O] how to show deadlines in global to-do list? > > James Harkins gmail.com> writes: > > > I like the out-of-the-box to-do list, except one thing: I would like > > to see the items' deadlines. The weekly agenda view shows the > > deadlines, but I need a view where I can see *only* to-do items and > > their deadlines. > > > Here is one way: > > Include this line in your org-file's config lines, or just stick it in if you > don't have config-line block: > > #+COLUMNS: %45ITEM %18DEADLINE ... snip Okay! This is great. Poking around orgmode's info docs turned up the variable org-columns-default-format. Supposedly the variable can be customized, but M-x customize-apropos doesn't find it. In any case: (setq org-columns-default-format "%45ITEM %18DEADLINE") in my .emacs forces the to-do column list to include the deadline, if available, with no #+COLUMNS line per file. That's good enough for now: C-a < t C-c C-x C-c -- and I know sometime later, when I have a little more time, I can try to crack the custom-search syntax. Thanks! I doubt I would've found my way to column view so quickly on my own. James -- James Harkins /// dewdrop world jamshar...@dewdrop-world.net http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman blog: http://www.dewdrop-world.net/words audio clips: http://www.dewdrop-world.net/audio more audio: http://soundcloud.com/dewdrop_world/tracks
Re: [O] M-RET and C-RET
Hello, Michael Brand writes: > I try to argue for some supposed common Org user that likes it simple > like me, is used to the behavior of M-RET and C-RET on headings and > is about to learn to use lists and M-RET but doesn't want to know > about org-M-RET-may-split-line that he prefers to leave on its default > as typical for trying out step by step. I don't argue for myself, I > had already found out and understand how to configure and how to do. > But if M-RET with point on "j" would insert _below_: > 1) it would be simpler to understand (from the user view, not >necessarily for implementation but often there too) because also >M-RET with point on "d" inserts already below > 2) it would make possible to add a new list item below the last with >M-RET already with the default org-M-RET-may-split-line or even >emacs -Q > I can not see anything that could not be done with this that can be > done now. What am I missing? Maybe nothing. I may be missing your point. Though, from what I read, I think that you really mean to argue for a change of the default value of `org-M-RET-may-split-line' (to, i.e. '((default . t) (item))) not for a change of code. >> Point isn't on "j". It's either before or after it. In your case, point >> is before "j". > > When I wrote this I exactly asked myself which of these two > perspectives I want to choose: > - "point is before 'j'": > - in some cases it leaves the question open if it means just before > or rather between something (e. g. beginning of line) and "j" > - sounds to me like referring to an edit cursor shape that is a bar > between characters which is not the cursor shape of all users > - "point is on 'j'": > - can refer to the position of point in the buffer like with "C-x =" > or the Emacs Lisp functions "point" and some "point-*" > - can refer to the character address or fsetpos() position in the > corresponding file > - can refer to an edit cursor shape that is a box on a character > (the only possibility for some terminal emulators and the default > for the windowed GNU Emacs on Linux, Mac OS X and Solaris) > I hope that this explains my preference for the second. I'm not talking about your cursor shape, but about Emacs' point representation. Point is never on "j" in Emacs, whatever you want to prefer. To convince yourself, you can experiment with: M-: (char-to-string (char-after (point))) >> And using M-RET on an item before its body start will >> result in creating an item before it. >> >> This is done so to avoid splitting counters or check-boxes. > > I don't understand this. What would be wrong with > - point on "-": M-RET inserts above > - point on "[X]": M-RET inserts below > (consistent with point on TODO on a line "*** TODO def") > - point on "j": M-RET inserts below > - point on "kl": M-RET splits (default config) > when considering the line "- [X] jkl"? I don't like it when I consider the line: " - jkl". It means that the new behaviour you suggest (adding an item below the current one) would only happen in one precise position on the line: just before the "j". Calling M-RET anywhere before that would create the item above, and anywhere after it would split the line (by default). I fail to see any logic here: point is still before the contents of the item, but M-RET adds a new item below nonetheless. I would call that a convenient hack. But it's just me. Moreover, with `org-M-RET-may-split-line' set to nil (at least for items), this hack is totally useless, as there's plenty of room to call M-RET from (like the end of _line_) when one wants to add an item below. So again, aren't you arguing for a change of `org-M-RET-may-split-line' value instead? >> You shouldn't compare lists and headlines behaviour, they don't have the >> same constraints. > > Nevertheless, wouldn't point 1) at the top add more consistency? Certainly, but not with the more simple choice, despite what you claimed at the beginning of this message. Again: - Actually, M-RET before item's body creates an item before, and it splits body otherwise. - Your suggestion: M-RET before item's bullet creates and item before, M-RET between item's bullet and item's body (which may be reduced to one position only) creates an item after, and it splits body otherwise. I can see the consistency with headlines, but not the simplicity. Also, from my obviously biased point of view, I could argue that you may modify headlines' behaviour to be more consistent with plain lists instead ;) >>> I configured it to nil for headline and item only to be able to insert >>> a new list item below the current with M-RET where I am forced to be >>> on or at right of "k" which by default splits which I want only in >>> very rare cases. >> >> If you want to split lines only on very rare occasions, why is it >> a problem to set `org-M-RET-may-split-line' to nil? > > Not a problem for me, trying to simplify for others
[O] Problem with export pdf and latex
Hi,
I loved emacs orgmode. It is very productive.
The problem is that i'm french and we use accent like é, à,...
And when i use export to pdf i lost my accent...
It is possible to include by default the :
\usepackage[latin1]{inputenc} % To use characters such as é
without typing \'e
\usepackage[cyr]{aeguill} % To display characters such as é
\usepackage{xspace} % To get the right spacings in front of : and so on
\usepackage[french]{babel} % To get into french mode
in the latex file... if yest can you explain (for a newbie, i'm not to geek lol)
Thanks
--
Posté par Steve Prud'Homme
sprud...@gmail.com
514 466-3951
Re: [O] Emacs Prelude
On Fri, 02 Dec 2011 20:25:21 -0600, SndChaser
wrote:
> 2) Has someone bound: org-do-promote, org-do-demote,
> org-promote-subtree. org-demote-subtree, org-move-subtree-up and
> org-move-subtree-down to another set of keys that is as handy / workable
> as the original bindings?
Well, I use the vi emulation provided by evil, and have bound
M-{h,j,k,l} to org-meta*:
#+BEGIN_SRC emacs-lisp
(mapcar (lambda (state)
(evil-declare-key state org-mode-map
(kbd "M-l") 'org-metaright
(kbd "M-h") 'org-metaleft
(kbd "M-k") 'org-metaup
(kbd "M-j") 'org-metadown
(kbd "M-L") 'org-shiftmetaright
(kbd "M-H") 'org-shiftmetaleft
(kbd "M-K") 'org-shiftmetaup
(kbd "M-J") 'org-shiftmetadown))
'(normal insert))
#+END_SRC
Tom
[O] Avoiding div from special blocks to be in …
Hi, I just uncommented a line in org-special-blocks.el that made div special blocks (like #+begin_foo) in html export to be between …… It seems to work well like this (and now the produced documents are W3C valid). Any clue on why it was commented ? diff --git a/lisp/org-special-blocks.el b/lisp/org-special-blocks.el index 2da57f0..d55e255 100644 --- a/lisp/org-special-blocks.el +++ b/lisp/org-special-blocks.el @@ -81,7 +81,7 @@ seen. This is run after a few special cases are taken care of." "Converts the special cookies into div blocks." ;; Uses the dynamically-bound variable `line'. (when (string-match "^ORG-\\(.*\\)-\\(START\\|END\\)$" line) -;(org-close-par-maybe) +(org-close-par-maybe) (message "%s" (match-string 1)) (if (equal (match-string 2 line) "START") (insert "\n") signature.asc Description: OpenPGP digital signature
Re: [O] Problem with export pdf and latex
"Steve Prud'Homme" writes:
> Hi,
> I loved emacs orgmode. It is very productive.
> The problem is that i'm french and we use accent like é, à,...
> And when i use export to pdf i lost my accent...
> It is possible to include by default the :
> \usepackage[latin1]{inputenc} % To use characters such as é
> without typing \'e
> \usepackage[cyr]{aeguill} % To display characters such as é
> \usepackage{xspace} % To get the right spacings in front of : and so on
> \usepackage[french]{babel} % To get into french mode
> in the latex file... if yest can you explain (for a newbie, i'm not to geek
> lol)
> Thanks
Yes, check out the info manual at
[[info:org#Header%20and%20sectioning][info:org#Header and sectioning]]
Basically, you can have any number of lines that look like this:
#+latex_header: \usepackage[french]{babel}
remember to type C-c C-c on one of these lines to re-initialise org if
you add such lines.
HTH,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.91.1
: using Org-mode version 7.7 (release_7.7.381.g05ea.dirty)
[O] Minimal overhead Org-mode blogging system
Hi! I got a nice idea on how a very easy to use Org-mode blog system should look like. Currently, I am using Serendipidy with web-based editor to write HTML. Org-mode enabled me to write blog entries and export it to HTML. Then I paste the HTML and have to modify minor things (images, ...) a bit. I guess the time from finishing the Org-mode entry to the final blog entry is approximately ten to twenty minutes. Overall, I do not want to do this process when I just want to quickly write a view paragraphs within a couple of minutes. I need a workflow with much less annoying overhead. Therefore I sat down and thought about a workflow that should be enough for writing simple weblog entries: - create an Org-mode heading (anywhere!) - make sure that there is an (uniq) :ID: property - add the tag :blog: to heading - - change state of top-heading to DONE - this enables blog entries «in the queue» - (manually) invoke generation-script This enables me quick blogging with a list of advantages: - a blog entry can be located anywhere in all of my Orgmode files - no extra formatting steps - very small (almost non-existent) overhead to create a blog entry - no duplicate information - updates only in Orgmode, not HTML or any in-between format - static (fast) pages - self-hosting without any fancy services behind like RDBS What do you think of my ideas so far? Of course, I looked into existing solutions and found those: - http://orgmode.org/worg/org-blog-wiki.html - cool overview page for various solutions - http://orgmode.org/worg/blorgit.html - pretty complex set up :-( - I do not need a web-interface to edit Org-mode files - seem to have «different» use cases - http://orgmode.org/worg/org-tutorials/org-jekyll.html - uses HTML as in-between format; seems to provide many error possibilities(?) - converting whole files only (not desired) - have to try it someday - http://emacs-fu.blogspot.com/2009/05/writing-and-blogging-with-org-mode.html - uses only HTML export - http://blog.herraiz.org/archives/241 - uses only HTML export - https://github.com/chrismgray/ikiwiki-org-plugin - promising but only one part of a possible solution So nothing offers the features and small footprint as my idea above :-( With some prerequisites, it should not be that hard to even implement it by myself: - usage of only very basic markup - paragraphs (p) - headings (h1..n) - http-references (a href) - lists (ul) - images (img) - quote (verbatim) Still there are some open issues: - comments - simplest form: generate unique Email link and add at bottom - very easy to be done for catch-all MTAs - automatically derive whitelist for MTA to avoid old spam - simple HTML form - POST to script, adding comment to my inbox.org (containing link to ID) - disqus: I do not want to outsource comment hosting :-( - how to include and format graphics? - sometimes, I e.g. want to have an image aligned right with text flowing around it - probably: usage of in-between format like ikiwiki - Orgmode syntax -> ikiwiki markup (markdown?) -> usual ikiwiki-workflow - should be not much effort since prerequisites limit to few markup things - benefits from not having to re-implement many things - in-between-format HTML (like Manoj uses) is way too complicated causing misc potential error sources The basic script workflow is not that complicated: - find all headings with state DONE and tag :blog: - optionally: add all other tags starting with "blog-" as blog tags - one entry starts at such a heading until EOF OR same or less level heading is found - compare raw text and IDs with last run - known ID, raw text unchanged: ignore, no change - new ID - generate new blog entry - extract -MM-DD from LOGBOOK-drawer (first *->DONE transformation) - generate /MM/DD-folder structure in blog accordingly - generate sanitized blog title as file name - known ID, raw text differs - generate update of existing entry - add "(Update n)" (with n is the n-th update) to entry title - optionally: add this also to URL - disadvantage: broken old URLs - advantage: URL reflects update state - on any activity: - re-write RSS feed for last n entries - optionally: generate overview page for last n entries - optionally: generate calendar archive page(s) - optionally: generate tag overview page(s) -- Karl Voit
[O] Stars in headlines
Hi, Is it possible to replace the initial stars in headlines with any other utf-8 symbol? Thank you
Re: [O] Avoiding div from special blocks to be in …
Hi, I submitted a patch to this effect a month and a half back. http://patchwork.newartisans.com/patch/979/ Apart from uncommenting that line, I put in an org-open-par after the div and rearranged a few lines to follow the same structure as other similar bits of code. Yours, Christian On 12/4/11 5:01 PM, Jonathan BISSON wrote: Hi, I just uncommented a line in org-special-blocks.el that made div special blocks (like #+begin_foo) in html export to be between…… It seems to work well like this (and now the produced documents are W3C valid). Any clue on why it was commented ?
Re: [O] Avoiding div from special blocks to be in …
On 12/04/2011 07:57 PM, Christian Moe wrote: > Hi, > > I submitted a patch to this effect a month and a half back. > > http://patchwork.newartisans.com/patch/979/ > > Apart from uncommenting that line, I put in an org-open-par after the > div and rearranged a few lines to follow the same structure as other > similar bits of code. > > > Yours, > Christian > Neater implementation, I vote for it :) Jonathan signature.asc Description: OpenPGP digital signature
Re: [O] Stars in headlines
Francisco Javier Molina Lopez writes: > Is it possible to replace the initial stars in headlines with any > other utf-8 symbol? There was a huge discussion on this a way back. I think the outcome was to hardcode * everywhere. You could use regexp to display something in place of stars if so desire. In particular you could look into org-icons (although I don't know if a maintained version exists). –Rasmus -- Sent from my Emacs
Re: [O] M-RET and C-RET
Hi Nicolas Thank you for all the explanations. On Sun, Dec 4, 2011 at 11:33, Nicolas Goaziou wrote: > Though, from what I read, > I think that you really mean to argue for a change of the default value > of `org-M-RET-may-split-line' (to, i.e. '((default . t) (item))) not for > a change of code. With my better understanding of the "insert anchor" (see below): Yes. > I'm not talking about your cursor shape, but about Emacs' point > representation. Point is never on "j" in Emacs, whatever you want to > prefer. To convince yourself, you can experiment with: > > M-: (char-to-string (char-after (point))) Interesting. At least when referring with the word "point" I better switch... > I fail to see any logic here: point is still before the contents of the > item, but M-RET adds a new item below nonetheless. I would call that > a convenient hack. But it's just me. Finally I got it and this lets me readjust my opinion too. Before I could only think of the list item bullet as the "insert anchor" for the decision whether to insert above or below. Now I realize that there is also the different and also valid perspective to have just the first character of the item text as this "insert anchor". > Moreover, with `org-M-RET-may-split-line' set to nil (at least for > items), this hack is totally useless, as there's plenty of room to call > M-RET from (like the end of _line_) when one wants to add an item below. > > So again, aren't you arguing for a change of `org-M-RET-may-split-line' > value instead? With my better understanding of the "insert anchor": Yes. > I can see the consistency with headlines, but not the simplicity. Also, > from my obviously biased point of view, I could argue that you may > modify headlines' behaviour to be more consistent with plain lists > instead ;) Indeed. Seriously, for me this would now be the better way to go to increase consistency, if this is of a broader interest than only mine. > Then the documentation with regards to that variable may be > defective. How do you think it can be improved? I don't see a problem with the doc itself. More with me not reading and remembering the right thing at the right time. But your suggestion to change the default of org-M-RET-may-split-line seems the right thing to me. My vote for the _default_ is (defcustom org-M-RET-may-split-line '((default . t) (item)) Who is interested to vote for a default? The Org-mode customization survey from January 2009 on Worg showed only one user differing from the default still in use: nil for headline (John Wiegley, CCed). The other 35 had the default (I claim that some of them don't care). With a default of nil for item I would not have followed the wrong path of using "-" and TAB to insert list items and not have made the noise related to this and more. Michael
[O] [OT] The joy of elisp
Hi list! I decided to finally get my hands dirty and build a small function to improve my org-based productivity system. Let me explain: I have a subdirectory under ~/org which has a bunch of files named after different subjects. Originally it was supposed to model a wiki, but in practice, I create a file there whenever I start studying a new (often complex) subject and that I know I will come back often and edit / improve. It's indeed like a wiki. However, I don't keep those files in the agenda. It would slow it down a lot. To keep the organization as organic as possible, I simply use tags to bring them together semantically. So, I have other files with items that are tagged, say, business, and I have a "wiki file" with a headline like this: * tags :business: I use the tags headline to tag those files. Now, what I wanted was to get a list of files related to say, the business tag. It's quite useful to find myself in the (good) chaos of tagged "wiki files", I came up with a small elisp function that does just that! (progn (shell-command "cd ~/org; ack \"\\* tags.*(business).*\" --all" "mybuf") (set-buffer "mybuf") (beginning-of-buffer) (ignore-errors (while (search-forward-regexp "\\(.*?\\):") (replace-match "[[~/org/\\1]]" ) )) (org-mode) ) Bear in mind this is my first elisp program ever. It's not even a function yet, actually. But it works pretty well for what I want :) Took me around 1 hour to bring it up. The joy of breaking your head on something! Cheers! (Suggestions on how to improve it welcome!) Marcelo.
Re: [O] Emacs Prelude
Hi Tom,
I'm very interested in the "vi emulation in emacs" subject. I've tried
viper-mode but it's quite slow with org, so I gave up on it. What's evil
and how's the vi emulation it provides? Could you elaborate on it? I'd
appreciate it, a lot.
Thanks,
Marcelo.
On Sun, Dec 4, 2011 at 10:01 AM, Tom Prince wrote:
> On Fri, 02 Dec 2011 20:25:21 -0600, SndChaser
> wrote:
> > 2) Has someone bound: org-do-promote, org-do-demote,
> > org-promote-subtree. org-demote-subtree, org-move-subtree-up and
> > org-move-subtree-down to another set of keys that is as handy / workable
> > as the original bindings?
>
> Well, I use the vi emulation provided by evil, and have bound
> M-{h,j,k,l} to org-meta*:
>
> #+BEGIN_SRC emacs-lisp
>(mapcar (lambda (state)
> (evil-declare-key state org-mode-map
> (kbd "M-l") 'org-metaright
> (kbd "M-h") 'org-metaleft
> (kbd "M-k") 'org-metaup
> (kbd "M-j") 'org-metadown
> (kbd "M-L") 'org-shiftmetaright
> (kbd "M-H") 'org-shiftmetaleft
> (kbd "M-K") 'org-shiftmetaup
> (kbd "M-J") 'org-shiftmetadown))
> '(normal insert))
> #+END_SRC
>
> Tom
>
>
