emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-orgmode] usage, ideas, suggestions, actually a braindumnp


From: nielsgiesen
Subject: [Emacs-orgmode] usage, ideas, suggestions, actually a braindumnp
Date: Thu, 27 Apr 2006 11:53:28 +0200 (CEST)

What's below is  a mixture of a description of  my org-usage and ideas
on further elaboration  of org-mode, which have partly  come up during
this writing. Pardon  me if it's kind of an  unorded brainstorm (it is
evident  from this  that I  am one  of the  person really  in  need of
org-mode).

* Main story    
Just discovered org-mode  about a week ago (on  #emacs).  Since then I
have  been a  proud user.   Am using  it for  professional as  well as
personal use.  For  professional use, I am using it to  make a kind of
html-template  which   I  will  tweak  for   automatic  generation  of
subsequent  html in  the  future. Sure  things  will come  up in  that
respect.   Further,   I  am   trying  to  use   it  as   a  bug/wanted
feature-tracking system.   As the only  developer is me, and  my input
mostly comes from one source only, this is feasible (I just let no one
else touch my list).  Some things have come up because of this use.  I
use a table for listing the  bugs and features (to export to csv), and
descriptions  are   put  in   headlines  below  that,   with  possible
subheadlines. One thing I needed was  a way to link the fields and the
headlines,  based  on  some  unique  identifier, and  possibly  in  an
automatic way.  The cleanest way I have  come up with so  far is using
the  radio link.   That  way I  just put  a  bug number  in the  table
automatically targeting the description .  That way I can export it to
csv -> xls (in oocalc), so the person I communicate with sees only the
bug number itself, and not  also the brackets, that are exported as-is
to csv.  On  this, see infra. For the generation of  a bug number link
for in the headlines I  have created the following small function, and
set it to a keyboard shortcut:

(defcustom org-bug-number 0
"number of current bug"
:type 'number)

(defun org-insert-bug-number (&optional skip-to)
  "Increment the org-bug-number with 1 and insert it at point as an internal 
link.

With numerical prefix  argument, insert the prefix number  at point as
an internal link.  If this number is greater than the current value of
org-bug-number, update org-bug-number to this value."

  (interactive "p")
  (insert-string "<<<"
      (cond ((> skip-to org-bug-number) (setq org-bug-number skip-to))
            ((eq skip-to 1) (setq org-bug-number (1+ org-bug-number)))
            (t skip-to)) ">>>")
  (org-ctrl-c-ctrl-c))

...I might revise  this with the use of an alist  or something, so you
can  have different  bug numbers  associated with  different projects,
based on which .org file you visit.

I  am thinking  of a  good way  of how  to integrate  this,  and other
typical bug-track-sheet stuff (such  as status: TODO/DONE...) with the
headlines. Automatic  generation of  a headline on  creation of  a new
bug-row is  not a  good option,  I believe, since  some things  are so
self-evident from the small description given in the table that giving
the  bug   a  seperate   headline  would  just   be  an   exercise  in
repetition. However, when a good and unique link between table row and
headline could be established, an update of the one based on the other
might be convenient. Perhaps this whole approach is flawed, because it
is based  on the table concept  for representing bugs  (my bosses just
said  like: ,,Kan  je die  bugs niet  gewoon ff  in  een Excel-sheetje
stoppen?''--trans:  ``can't  you  just  put  these bugs  in  an  Excel
sheet?''),  so that I  just began  drawing a  table. Maybe  some table
export function  to the view  generated by C-c  C-r would be  a better
idea. But  then, how do  you know which  words will have to  appear in
which field?  This would require setting properties to (sequences of),
which calls  for a different  syntax. More thinking  and code-studying
necessary...

I think using only TODO and DONE  is a good approach, as too much time
is  easily   wasted  figuring  out  for  yourself   what  the  precise
qualification should be.  
* Some other things that have come up during usage:
** option for clean export view of timestamps
** option to leave timestamps out in export function
** option to leave tags out in export function.
** org-export-to-LaTeX
** make follow-mode the default as customization option; 
for myself, I have just hacked the code to have follow-mode always on.
** strip links when unexportable as link
Export description, or, when lacking, only the content of the link.

When data can  be retrieved back from an  exported format, this would
be included /as/ /option/, as one will e.g. want to communicate to and fro
with csv tables.
** improvement of the outcome of C-h m would be welcome.
- all the self-inserting commands are not of great interest. Better
  skip them, or put at least put them at the end.
- things such as "Calls `(org-cycle t)'" do not give a reference;
  better say "Calls org-cycle with argument t". 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]