[O] Agenda with an archived indicator

2014-12-28 Thread Yuri Niyazov
I am trying to build an agenda view that includes both Archived and
non-Archived items, and includes an indicator whether an item is
archived or not. Here's how I've gotten it to work so far:

In custom agenda:

(... (org-agenda-prefix-format %(yn/org-archived-display)
%-11c%-11T%-11s) ... )

(defun yn/org-archived-display ()
  (if (get-text-property (point-at-bol) :org-archived)
  A
 ))


I figured if I learned how org-agenda skips over archived org entries
while building the display, that will give some insight into what the
code inside that expression should look like, so that code is derived
from org-agenda-skip.

This has an appreciable slow-down while building the agenda, I assume
it's because it is re-parsing the item.  Is there something in the
environment of the expressions in %() that can be efficiently
interrogated for archived/not archived status?



Re: [O] Bug: evaluation of a js block that ouputs a large array does not format the output as a table [8.2.10 (release_8.2.10 @ c:/Chocolatey/lib/Emacs.24.4.0.20141122/tools/share/emacs/24.4/lisp/org/

2014-12-28 Thread Nicolas Goaziou
Hello,

Victor Valdivia victor.valdi...@incentings.com writes:

 When I execute this snippet:
 #+BEGIN_SRC js
 return  [[1, 2, 3, 4],[1, 2, 3, 4],[1, 2, 3, 4], [1, 2, 3, 4],[1, 2, 3, 4]];
 #+END_SRC

 I get this result instead of a table.
 #+RESULTS:
 : [[1 (\, 2) (\, 3) (\, 4)] (\, [1 (\, 2) (\, 3) (\, 4)]) (\, [1 (\, 2) (\,
 3) (\, 4)]) (\, [1 (\, 2) (\, 3) (\, 4)]) (\, [1 (\, 2) (\, 3) (\, 4)])]

 But when I generate a shorter table like this
 #+BEGIN_SRC js
 return  [[1, 2, 3, 4],[1, 2, 3, 4],[1, 2, 3, 4], [1, 2, 3, 4]];
 #+END_SRC

 I get the expected result.
 #+RESULTS:
 | 1 | 2 | 3 | 4 |
 | 1 | 2 | 3 | 4 |
 | 1 | 2 | 3 | 4 |
 | 1 | 2 | 3 | 4 |


 I think that this happens when node.js generates a output with line
 breaks, then the function org-babel-js-read cannot parse the output, but I
 am not sure.

I think this was fixed in development branch recently.

Regards,

-- 
Nicolas Goaziou



[O] Typo in manual

2014-12-28 Thread Daniel E . Doherty

Carsten et al.,

I just noticed in footnote 2 of section 2.2 of the org manual, the following
typo:

,
| (2) Clocking only works with headings indented less then 30 stars.
`

The 'less then' should be 'less than'.

Regards,

-- 

Daniel E. Doherty
ded-...@ddoherty.net



Re: [O] changing cells in an org-mode table with Emacs lisp

2014-12-28 Thread Michael Brand
Hi Tamas

On Sat, Dec 27, 2014 at 5:37 PM, Tamas Papp tkp...@gmail.com wrote:
 | a   | a   |
 | aa  | aa  |
 | aaa | aaa |

 would be replaced by

 | *a* | *a*  |
 | aa  | *aa* |
 | aaa | aaa  |

#+BEGIN_SRC emacs-lisp :results silent
  (defun format-cell (cell row col)
(if (= (length cell) col)
(concat * cell *)
  cell))
#+END_SRC

| *a* | *a*  |
| aa  | *aa* |
| aaa | aaa  |
#+TBLFM: @$..@$ = '(format-cell @0$0 (org-table-current-dline)
(org-table-current-column))

or

#+TBLFM: @$..@$ = '(format-cell @0$0 @# $#)

For explanations please see the manual.

Michael



Re: [O] Efficiency of Org v. LaTeX v. Word

2014-12-28 Thread Pascal Fleury
On Sat, Dec 27, 2014 at 12:36 PM, Fabrice Popineau 
fabrice.popin...@supelec.fr wrote:

 I agree that this study is certainly not large enough to draw strong
 conclusions, but it raises a couple of questions
 and some points may require attention.

 I have spent many years in the TeX world. I see how lots of people use TeX
 : students, professionals, researchers etc...
 and I would easily draw 2 categories of people :
 - those who are programmers in their soul (DEK once said that 2% or so
 of the whole human race is gifted with programming, the same way some
 people are gifted to play music etc.)
 - those who use LaTeX because it is the best typesetting system
 People who belong to the intersection of those 2 categories will certainly
 be very efficient in producing documents with LaTeX, much more than what
 this study shows.
 But people from the first category may also be efficient in producing
 documents with Word (Word is programmable too and the typesetting engine is
 fancier than most people would believe).


That is funny, as I still face regularly Word typeset documents that do not
handle orphan lines properly, and have at least 2 fonts as body text.
Easy to fix, but a non-issue in Latex.

As a researcher, handling references and cross-references is not something
that is amortized on a one-off paper, it's something that pays off over a
few documents. And in a publish-or-perish world, this does usually not take
long.

As a programmer, I like to be able to run one command (call it 'make' if
you wish...) that will run some analysis and recompute both the figures and
the document into a new version, possibly versionned.

And now you know why I use orgmode too...

--paf




 The real problem is the guys from the second category who stick to use a
 tool they are not comfortable with but they don't want to admit it.
 Over the last years, I have seen more and more students come with LaTeX
 documents which had a very poor appearance.
 There has been a lot of pressure with the rise of Linux to use LaTeX.
 Unfortunately the results of using LaTeX may not be up to the expectations.
 The tool is too complex. It can produce beautiful documents when used
 right, but it can also easily produce awful documents.
 You can also spend a lot of time in fixing details, and it happens more
 frequently than even proficient LaTeX users would admit.
 In the end, I think the tendency is to a growing number of LaTeX users who
 use it poorly.

 Finally, today, my experience is that publishers charge much more for
 LaTeX documents than for Word (or similar tools) documents and they are
 reluctant to use LaTeX because of its complexity.

 That was my $0.02

 Fabrice

 2014-12-27 11:36 GMT+01:00 M elwood...@web.de:

  Von: Paul Rudin p...@rudin.co.uk
  Datum: Sat, 27 Dec 2014 10:05:19 +
  An: emacs-orgmode@gnu.org
  Betreff: Re: [O] Efficiency of Org v. LaTeX v. Word
 
  Ken Mankoff mank...@gmail.com writes:
 
  People here might be interested in a publication from [2014-12-19 Fri]
  available at http://dx.doi.org/10.1371/journal.pone.0115069
 
  Title: An Efficiency Comparison of Document Preparation Systems Used
  in Academic Research and Development
 
  Summary: Word users are more efficient and have less errors than even
  experienced LaTeX users.
 
  Someone here should repeat experiment and add Org into the mix, perhaps
  Org - ODT and/or Org - LaTeX and see if it helps or hurts. I assume
  Org would trump LaTeX, but would Org - ODT or Org - X - DOCX (via
  pandoc) beat straight Word?
 
 
  No mention of emacs... who uses anything else to prepare their LaTeX?
 
 Did you forget the  ;-) or are you serious?

 Emacs is for sure a very good one, but there are a lot of popular
 alternatives, if you have a look at the (for sure not representative)
 voting
 on the answers of this discussion here:

 http://tex.stackexchange.com/questions/339/latex-editors-ides

 (It's clear, that people may have voted for several of those editors, so
 that no valid statistics at all, but at least an idea...)

 Is there any real survey result about which editors LaTeX users use?

 Martin






 --
 Fabrice Popineau
 -
 SUPELEC
 Département Informatique
 3, rue Joliot Curie
 91192 Gif/Yvette Cedex
 Tel direct : +33 (0) 169851950
 Standard : +33 (0) 169851212
 --




Re: [O] Efficiency of Org v. LaTeX v. Word

2014-12-28 Thread Bob Newell

The study is an obvious diatribe couched in (poorly done) scientific
method. It almost seems like these researchers have at some time been
required to use LaTeX and are angry over it.

I will agree that LaTeX is slower and less efficient than LibreOffice (I
don't have Word on any of my computers but the argument I suppose is the
same), if your only interest is pounding out text of a first draft. But
the study didn't allow for the effects of proofreading, etc., and all
the things that are always done when producing something for
publication. I expect that the differences in grammar and orthographic
errors will be insignificant.

A 30-minute test is ridiculous. More meaningful would have been
end-to-end time to complete a given document. Maybe then Word would have
still been faster; I don't know. But that doesn't tell the whole story
by any means, including the very important matter of long-term storage
in a non-proprietary format.

-- 
Bob Newell
Honolulu, Hawai`i
* Sent via Ma Gnus 0.12-Emacs 24.3-Linux Mint 17 *



[O] Drawers and visibility cycling

2014-12-28 Thread Steven Arntson
I've never been able to get drawers to go through a visibility cycle,
and so have always avoided using them, but now I have a use-case in
which they would be very handy.

Here's my not working process:

+ type some sample text.
+ select the region and do `C-c C-x d'
+ I'm queried for the title of the drawer and type test

The result looks like this:

:testdrawer:
test content
:END:

However, when I put point on :testdrawer: and hit TAB, it doesn't go
through any kind of cycle---just sits there.

What am I doing wrong?

Thank you,
steven arntson




Re: [O] Drawers and visibility cycling

2014-12-28 Thread Bob Newell
Steven Arntson ste...@stevenarntson.com writes:

 Here's my not working process:

 + type some sample text.
 + select the region and do `C-c C-x d'
 + I'm queried for the title of the drawer and type test

 The result looks like this:

 :testdrawer:
 test content
 :END:

I've always had to put the drawer title in a line with all the drawer
names like this:

#+DRAWERS: EXPANSION PROPERTIES CLOCK LOGBOOK TESTDRAWER

-- 
Bob Newell
Honolulu, Hawai`i
* Sent via Ma Gnus 0.12-Emacs 24.3-Linux Mint 17 *



Re: [O] Drawers and visibility cycling

2014-12-28 Thread Steven Arntson
Bob Newell bobnew...@bobnewell.net writes:

 Steven Arntson ste...@stevenarntson.com writes:

 Here's my not working process:

 + type some sample text.
 + select the region and do `C-c C-x d'
 + I'm queried for the title of the drawer and type test

 The result looks like this:

 :testdrawer:
 test content
 :END:

 I've always had to put the drawer title in a line with all the drawer
 names like this:

 #+DRAWERS: EXPANSION PROPERTIES CLOCK LOGBOOK TESTDRAWER

I gave this a try, adding

#+DRAWERS: DATA

and then created a drawer:

:DATA:
test data
:END:

and I still can't get it to do anything when I put point on `DATA'. I
did `C-h k' just to verify that TAB is running `org-cycle', which it is.
I'm perplexed!




[O] Org-mode to feed a database

2014-12-28 Thread Vikas Rawal
This is, in all likelihood, a crazy idea. Please excuse me for that.

I often need to get a number of people enter complex survey data into a 
database using some kind of forms. The forms I need are fairly complex (with 
several nested grids, for example). I need radio-buttons and drop-down 
menus-equivalents.

I was thinking if it would be worth it to use Org-mode for data entry.

The idea would be something like this. We have a template org file that is 
copied for each survey respondent. The template contains “blank” org tables and 
some source blocks. Responses are filled into the org tables, and then the 
source blocks are evaluated to feed the data into the database. You can 
version-control the whole thing so that different people can create these 
records and push it to a centralised git repository.

Has anyone done anything like this? What has been the experience?

There are two aspects that immediately come to my mind.

1. Is org adequately feature rich for such a scenario? There are two concerns I 
can think of right now. 
   1.1 Would feeding information from one Org table to another become too 
complicated?
   1.2 Is there a way to build in tab-completion for columns in Org-table using 
pre-specified categories? 

2. In my case, people who would enter the data into org files would not have 
used emacs before. So, there is a learning curve. Is it worth it? Or should one 
just build a web-based graphic application for such people to use?

Vikas


Re: [O] Drawers and visibility cycling

2014-12-28 Thread Steven Arntson
Steven Arntson ste...@stevenarntson.com writes:

 Bob Newell bobnew...@bobnewell.net writes:

 Steven Arntson ste...@stevenarntson.com writes:

 Here's my not working process:

 + type some sample text.
 + select the region and do `C-c C-x d'
 + I'm queried for the title of the drawer and type test

 The result looks like this:

 :testdrawer:
 test content
 :END:

 I've always had to put the drawer title in a line with all the drawer
 names like this:

 #+DRAWERS: EXPANSION PROPERTIES CLOCK LOGBOOK TESTDRAWER

 I gave this a try, adding

 #+DRAWERS: DATA

 and then created a drawer:

 :DATA:
 test data
 :END:

 and I still can't get it to do anything when I put point on `DATA'. I
 did `C-h k' just to verify that TAB is running `org-cycle', which it is.
 I'm perplexed!


For the list: Bob wrote me the solution over email:

 Try closing the file and reopening. You have to force a re-read and
 re-eval. There is another way to do this but I can't recall it
 quickly.

It worked perfectly.

Thank you!
steven