texinfo manual links not working?

2020-06-20 Thread Leo Alekseyev
M-x org-store-link tells me "No method for storing a link from this
buffer", and info: type is not in the list when I try to insert a link
via C-c C-l. Has the support been deprecated or is there a problem
with my system?



Bug: Org with auto-fill does not insert linebreaks properly [9.3 (release_9.3 @ /snap/emacs/current/usr/share/emacs/27.0.90/lisp/org/)]

2020-04-12 Thread Leo Alekseyev
Consider the following text:
begin example
---
---
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
---
---
end example-

With auto-fill mode on, continuing to type on the "Lorem ipsum"
line results in the following:
begin example
---
---
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
---eiusmod asdf
---
end example-

Notice how "eiusmod" does not start on a new line, as would be expected.
Here is a GIF of this behavior in action:
https://www.dropbox.com/s/w9a803t0qotqe6j/org_autofill_bug.gif?dl=0

Tested with emacs -Q, org 9.3 (lisp that ships with emacs 27)


[O] Sum clocks into a custom property

2018-11-12 Thread Leo Alekseyev
I am using org-invoice.el, which expects either CLOCKSUM or WORK properties
to exist in an item; these properties contain some time duration record in
HH:MM format.

I can't figure out how to generate those properties from a series of clock
entries with any built-in user-facing functions, so I want to do it
programmatically -- I can get the sum of the clock entries
via (org-clock-sum-current-item), but how do I convert them to HH:MM format
and insert it as a property?


[O] How to generate CLOCKSUM property from time ranges?

2018-11-01 Thread Leo Alekseyev
Greetings all,
I am looking into using `org-invoice` to generate some invoices. It uses
the CLOCKSUM property, which according to the docs gets auto-generated when
the clock entries are summed in a subtree.

Concretely, docs say: "CLOCKSUM: The sum of CLOCK intervals in the
subtree.  ‘org-clock-sum’ must be run first to compute the values in the
current buffer."  However, `org-clock-sum` is a non-interactive function,
and evaluating it by hand doesn't do anything for me.

Org-clock-report is able to generate the table with total subtree sums, but
doesn't set the CLOCKSUM property.

Question: how do I get CLOCKSUM property generated and stored in a subtree
with timestamps so that org-invoice functions can pick it up?
--Leo


[O] Bug: org-git-link.el broken [9.0.5 (release_9.0.5 @ /home/leo/.emacs.d/elisp/org-mode.git/lisp/)]

2017-03-22 Thread Leo Alekseyev
org-store-link fails inside org-git-link if org-git-link is enabled with
(require 'org-git-link)

>From what I can tell in the debugger, the code walks up the directory tree
looking for .git files in a parent directory.  However, when I am inside
e.g. "~/foo.el", at some point the code will execute (org-git-split-dirpath
"~/")  (org-git-link.el line 129), which evaluates to (nil, "~").  dir will
subsequently be set to nil on line 132, which results in an error.


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 mailing list.




Emacs  : GNU Emacs 26.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.18.9)
 of 2017-03-20
Package: Org mode version 9.0.5 (release_9.0.5 @
/home/leo/.emacs.d/elisp/org-mode.git/lisp/)

current state:
==
(setq
 org-babel-results-keyword "results"
 org-src-mode-hook '((lambda nil (auto-save-mode t)) (lambda nil
(define-key org-src-mode-map " @" (quote
org-src-do-key-sequence-at-code-block)))
 org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-edit-src-content-indentation 0
 org-src-tab-acts-natively t
 org-agenda-files '("~/My Dropbox/notes.org/memos.txt")
 org-shiftup-final-hook '(windmove-up)
 org-cycle-include-plain-lists nil
 org-mode-hook '(er/add-org-mode-expansions turn-on-font-lock flyspell-mode
 (lambda nil (auto-fill-mode t) (setq adaptive-fill-regexp
nil) (setq comment-start nil))
 (closure
  (org-inlinetask-min-level org-mode-abbrev-table
org-mode-syntax-table buffer-face-mode-face org-mode-map org-tbl-menu
org-org-menu
   org-struct-menu org-entities org-last-state
org-id-track-globally org-clock-start-time texmathp-why remember-data-file
   org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist calc-embedded-open-mode calc-embedded-open-formula
   calc-embedded-close-formula align-mode-rules-list
org-emphasis-alist org-emphasis-regexp-components
org-export-registered-backends
   org-modules org-babel-load-languages t)
  nil (add-hook (quote change-major-mode-hook) (quote
org-show-block-all) (quote append) (quote local)))
 (closure
  (org-bracket-link-regexp org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no org-src-preserve-indentation
org-src-lang-modes
   org-edit-src-content-indentation
org-babel-library-of-babel t)
  nil (add-hook (quote change-major-mode-hook) (quote
org-babel-show-result-all) (quote append) (quote local)))
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-outline-path-complete-in-steps nil
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-shiftdown-final-hook '(windmove-down)
 org-babel-pre-tangle-hook '(save-buffer)
 org-file-apps '(("\\.nb\\'" .
"/opt/Wolfram/Mathematica/8.0/Executables/Mathematica %s") ("\\.xoj\\'" .
"xournal %s") ("\\.pdf\\'" . "evince %s")
 (" \\.pdf::\\([0-9]+\\)\\'" . "evince %s -p %1")
(auto-mode . emacs) ("\\.x?html?\\'" . default) ("\\.nb\\'" . "mathematica
%s"))
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-hide-leading-stars t
 org-babel-load-languages '((R . t) (shell . t) (python . t) (perl . t) (C
. t) (matlab . t) (latex . t) (scheme . t) (scala . t) (ruby . t) (sqlite .
t)
(java . t) (js . t) (elasticsearch . t))
 org-shiftright-final-hook '(windmove-right)
 org-occur-hook '(org-first-headline-recenter)
 outline-minor-mode-hook '(th-outline-minor-mode-init
   (lambda nil (define-key outline-minor-mode-map
(kbd "TAB") (quote org-cycle))
(define-key outline-minor-mode-map [(tab)]
(quote org-cycle))
(define-key outline-minor-mode-map [(shift
tab)] (quote org-global-cycle))
(define-key outline-minor-mode-map [backtab]
(quote org-global-cycle)))
   )
 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")
("c" "#+begin_center\n?\n#+end_center"
"\n?\n")
 

[O] Strange behavior with auto-fill

2014-02-02 Thread Leo Alekseyev
I've been observing a very annoying behavior with auto fill; it persist in
the latest org from git, as well as the version shipped with Emacs 24.3 for
OS X.

Consider starting a clean Emacs session with emacs -Q.  Start a new file,
foo.org.  Do M-x org-mode and M-x auto-fill-mode.  Now enter the following
3 lines:
---
---
---

(yes, that's a bunch of dashes).  Now try putting a long line in between
the second and third set of dashes, and wait for auto-fill to wrap the
line.  Here is what I observe:

---
---
This is a long line designed to exhibit a bug in auto-fill.  It's
---almost as if auto-fill thinks the dashes are a comment symbol.
---

Notice how after wrapping the line acquired a leading ---!  Why does this
happen, and how can it be turned off?

--Leo


Re: [O] Babel blocks not indented

2013-05-13 Thread Leo Alekseyev
On Fri, May 10, 2013 at 3:32 PM, Nick Dokos ndo...@gmail.com wrote:

 Leo Alekseyev dnqu...@gmail.com writes:

  I've brought this up before, but I think there's value in SRC blocks
  /not/ being indented, and in fact, I would love it if there were a way
  to make the contents of the SRC blocks / not/ be indented (as opposed
  to the default 2 space offset).   Whitespace often matters,
  particularly when working with Python, and every now and then I find
  myself having to manually delete the extra spacing when pasting code
  into the Python interpreter.  Other times I want to paste code
  snippets from SRC blocks into source files -- again, indentation gets
  in the way.  I agree that it's aesthetically appealing, but my
  workflow would be easier without it.
 

  --Leo
 

 Does this help?

 ,
 | org-edit-src-content-indentation is a variable defined in `org-src.el'.
 | Its value is 2
 |
 | Documentation:
 | Indentation for the content of a source code block.
 | This should be the number of spaces added to the indentation of the
 #+begin
 | line in order to compute the indentation of the block content after
 | editing it with M-x org-edit-src-code.  Has no effect if
 | `org-src-preserve-indentation' is non-nil.
 `

 --
 Nick


 Yes! I had no idea this existed!  I could've sworn I've asked about this
before and came up empty :/


Re: [O] Babel blocks not indented

2013-05-10 Thread Leo Alekseyev
On Thu, May 9, 2013 at 8:32 PM, J. David Boyd da...@adboyd.com wrote:

 Julien Cubizolles j.cubizol...@free.fr writes:

  Eric Schulte schulte.e...@gmail.com writes:
 
  Julien Cubizolles j.cubizol...@free.fr writes:
 
  I'm new to babel and I'm experiencing a strange problem. A
  src_block created with s TAB is not indented as the heading it's
  in. Here is an example:
 
 
  Try TAB s TAB instead.
 
  That's what I was doing but it seems the problem lies with
  org-indent-mode and is also present with regular text. Apparently,
  disabling and re-enabling seems to fix it. I'll investigate further.
 
  Julien.

 I change my mode to whatever my src is in when I want indenting to work
 properly, then change it back when I want to see it as an org file again.

 Dave



I've brought this up before, but I think there's value in SRC blocks /not/
being indented, and in fact, I would love it if there were a way to make
the contents of the SRC blocks /not/ be indented (as opposed to the default
2 space offset).   Whitespace often matters, particularly when working with
Python, and every now and then I find myself having to manually delete the
extra spacing when pasting code into the Python interpreter.  Other times I
want to paste code snippets from SRC blocks into source files -- again,
indentation gets in the way.  I agree that it's aesthetically appealing,
but my workflow would be easier without it.

--Leo


Re: [O] Is it possible to create links to M-x occur results?

2013-05-02 Thread Leo Alekseyev
Nice!  Short and sweet, and works great.  It should go on
orgmode.orgsomewhere in the cool hacks section.


On Thu, May 2, 2013 at 7:07 AM, Rick Frankel r...@rickster.com wrote:

 On 01.05.2013 18:41, Leo Alekseyev wrote:

 Howdy Org-folks,

 Something that I've found myself wishing for time and time again is to
 be able to follow the link to a file and immediately pop into a set of
 M-x occur results given some search term for that file.  That way I
 could link to an overview of a file's class/function definitions, or
 config stanzas, or other useful things.  Given that we can create
 links to arbitrary elisp, I am sure that this can be done in
 principle, but if there's a quick recipe that someone has come up
 with, I'd love to hear about it!


 That seems like a fun exercise. so:

 #+BEGIN_SRC elisp
   (defun org-occur-open (uri)
 Visit the file specified by URI, and run `occur' on the fragment
   \(anything after '#') in the uri.
 (let ((list (split-string uri #)))
(org-open-file (car list) t)
(occur (mapconcat 'identity (cdr list) #
   (org-add-link-type occur 'org-occur-open)
 #+END_SRC

 and you can use a link like:

 occur:m/file.txt#regex

 rick



[O] Is it possible to create links to M-x occur results?

2013-05-01 Thread Leo Alekseyev
Howdy Org-folks,

Something that I've found myself wishing for time and time again is to be
able to follow the link to a file and immediately pop into a set of M-x
occur results given some search term for that file.  That way I could link
to an overview of a file's class/function definitions, or config stanzas,
or other useful things.  Given that we can create links to arbitrary elisp,
I am sure that this can be done in principle, but if there's a quick recipe
that someone has come up with, I'd love to hear about it!

--Leo


Re: [O] Is it possible to run shell script src blocks as root or to export individual blocks?

2012-03-19 Thread Leo Alekseyev
On Mon, Mar 5, 2012 at 10:24 AM, Eric Schulte eric.schu...@gmx.com wrote:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Eric Schulte eric.schu...@gmx.com writes:

 Leo Alekseyev dnqu...@gmail.com writes:

 I was wondering if there was an easy way to execute some shell
 commands contained in a src block as root.  Alternatively, is there a
 quick way to export _just_ that one source block to a temp file so
 that I could run it as root manually?


 Just call org-babel-tangle with a prefix argument and it only tangles
 the current block

Hi all,

I just pulled a fresh version of org, and this tangling an individual
block only works if there's a :tangle header argument present.  I
don't think this is the intended behavior!  The problem, it seems, is
that when :tangle is not present, the (or ...) in the code below
always evaluates to true.

#+begin_src emacs-lisp
  (unless (or (cdr (assoc :tangle (nth 2 (org-babel-get-src-block-info
  target-file)
(setq target-file
  (read-from-minibuffer Tangle to:  (buffer-file-name)
#+end_src



[O] Blank first line in a tangled file prevents src block execution

2012-03-09 Thread Leo Alekseyev
I have the following source block that I tangle to produce a short script:

#+begin_src sh :tangle code/get_wavs.sh
  #!/bin/bash
  for fn_in in $@; do
  fn_out=$(sed -e 's|\.3gp$||g' -e 's|$|.wav|g'  $fn_in)
  ffmpeg -i $fn_in -vn -f wav -acodec pcm_u8 $fn_out
  done
#+end_src

However, the tangled file has a blank first line.  As a result, I
can't seem to run this script either using sh -c, or by putting it
inside a code block.  In other words, the following line fails:

sh -c code/test.sh data/salsa/20120308_av_jc/song2/*.3gp
code/test.sh: 4: Syntax error: redirection unexpected

And, similarly, this fails

#+begin_src sh
  code/get_wavs.sh data/salsa/20120308_av_jc/song2/*.3gp
#+end_src


On the other hand, the script runs fine from the command line, or from
an org-mode shell: link, i.e. just running

code/test.sh data/salsa/20120308_av_jc/song2/*.3gp

at bash prompt produces the desired result.


I am not sure what the rules are about blank lines before the
hash-bang directive in Bash, and why in particular the blank line
seems to cause sh -c ... and orb-babel src execution to break, but the
current behavior seems broken.



[O] Is it possible to run shell script src blocks as root or to export individual blocks?

2012-03-02 Thread Leo Alekseyev
I was wondering if there was an easy way to execute some shell
commands contained in a src block as root.  Alternatively, is there a
quick way to export _just_ that one source block to a temp file so
that I could run it as root manually?



[O] org-mode code / verbatim delimiters don't work with quotation marks

2012-02-20 Thread Leo Alekseyev
I noticed that strings like ='foo'= or =di= don't get recognized by
org as code, which is somewhat unfortunate because it forces me to
edit exported HTML by hand.  Are there any workarounds for this
behavior?

--Leo



Re: [O] org-mode code / verbatim delimiters don't work with quotation marks

2012-02-20 Thread Leo Alekseyev
Null character /sort of/ works: it makes org-mode insert the code
delimiters on export, but the presence of null characters breaks
export down the road, at least in my case.  This time, I could
intercept the exported text and remove the null characters by hand,
but it might not always be the case.

What org really needs is a stronger verbatim quoting construct.  In a
lot of cases, you just want your text to be displayed verbatim, with
no interpretation, period.  Near as I can see, there's nothing in org
that can currently do this -- please correct me if I'm wrong.  For
instance, things like =[[foo]]= should _not_ undergo further parsing /
be interpreted as links.  Same goes for quotes, or virtually anything.
 = signs should be allowed provided they are escaped in the usual
manner (=\==).  The current behavior is very unsatisfactory.

On Mon, Feb 20, 2012 at 12:47 PM, Michael Hannon jm_han...@yahoo.com wrote:
 I noticed that strings like ='foo'= or =di= don't get recognized by org as
 code, which is somewhat unfortunate because it forces me to edit exported
 HTML by hand.  Are there any workarounds for this behavior?

 Hi, Leo.  You might try inserting a null character before and after the
 quotation marks, as:

     =^@'foo'^@=

 where:

     ^@

 means CTRL-@, in the usual, text-based notation.

 -- Mike



Re: [O] bug / regression: C-x C-s is broken in org-edit-special

2012-02-13 Thread Leo Alekseyev
In case anyone is curious, C-x C-s functionality in org-edit-special
can be easily restored via

  (define-key org-src-mode-map \C-x\C-s 'org-edit-src-save)


On Thu, Feb 9, 2012 at 4:49 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 Previously, C-x C-s in an org-edit-special buffer (invoked via C-')
 would save the underlying org buffer (provided (setq
 org-src-window-setup (quote current-window)) was set; it was buggy
 with other settings, see
 http://thread.gmane.org/gmane.emacs.orgmode/50979 for discussion).
 Currently, C-x C-s prompts to save the temporary source edit buffer in
 a new file, which is almost certainly not what the user intends.  I
 hope someone can look into this, C-x C-s shouldn't be broken in any
 context.

 This broke some time between commit
 fc93b6f34071703d5a154a51540f3f4e3f15b8a2 (Jan. 18) and this week,
 _possibly_ as a result of the change ensuring that buffer-file-name is
 nil in temporary org-src buffers.  Buffer-file-name not being nil in a
 temp buffer is incorrect behavior, but in this context having C-x C-s
 not working is a much worse behavior, so perhaps that change ought to
 be reverted if it's the culprit.

 --Leo



Re: [O] org-babel autosave

2012-02-13 Thread Leo Alekseyev
Yes, but the question is -- what is the desired behavior?  If you just
want to autosave the temporary org-src buffer, see my question on
stack overflow:

http://stackoverflow.com/q/8849661/133234

In short, you'd just need to   (add-hook 'org-src-mode-hook '(lambda
() (auto-save-mode t))) and specify the appropriate file name.

This has the drawback that the autosave fill will never be removed,
since the org-src buffers never actually get saved.

A better solution would be to auto-save the underlying org-buffer.  I
am not sure how to do this for timed autosave.  For manual
do-auto-save, the following works.

 (defadvice do-auto-save (around do-auto-save-org-src activate)
   (if org-src-mode
   (org-src-in-org-buffer (do-auto-save))
 ad-do-it))

I tried putting this into an autosave-hook and disable the hook on
invocation from org, but couldn't avoid infinite recursion.  Perhaps
someone more experienced can come up with the right solution.


On Mon, Feb 13, 2012 at 7:36 PM, Colin Maxwell cs.maxw...@gmail.com wrote:
 Hello,
 I've noticed that autosaving does not operate when you are editing an 
 org-babel buffer via C-c '. Is there a way to turn it on?


 cheers,
 Colin



[O] bug / regression: C-x C-s is broken in org-edit-special

2012-02-09 Thread Leo Alekseyev
Previously, C-x C-s in an org-edit-special buffer (invoked via C-')
would save the underlying org buffer (provided (setq
org-src-window-setup (quote current-window)) was set; it was buggy
with other settings, see
http://thread.gmane.org/gmane.emacs.orgmode/50979 for discussion).
Currently, C-x C-s prompts to save the temporary source edit buffer in
a new file, which is almost certainly not what the user intends.  I
hope someone can look into this, C-x C-s shouldn't be broken in any
context.

This broke some time between commit
fc93b6f34071703d5a154a51540f3f4e3f15b8a2 (Jan. 18) and this week,
_possibly_ as a result of the change ensuring that buffer-file-name is
nil in temporary org-src buffers.  Buffer-file-name not being nil in a
temp buffer is incorrect behavior, but in this context having C-x C-s
not working is a much worse behavior, so perhaps that change ought to
be reverted if it's the culprit.

--Leo



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-02-08 Thread Leo Alekseyev
I am afraid this might have caused a regression (although it could've
been something else).  With the latest org-mode pull, C-x C-s in
org-src buffer does not save the underlying org-file (as expected) but
instead prompts for file name to save.  This is rather bad behavior.

On Tue, Jan 24, 2012 at 9:25 AM, Bastien b...@altern.org wrote:
 Hi Leo,

 Leo Alekseyev dnqu...@gmail.com writes:

 Folks, I still think that the fact that buffer-file-name is not nil is
 a bug and should be fixed.

 So do I.  I think this is fixed now -- thanks!

 --
  Bastien



[O] Semantics of the colon (can it be considered a general markup element?)

2012-02-08 Thread Leo Alekseyev
I started prefixing certain lines with the colon (:) in my org-files,
because it is a convenient way to get verbatim behavior.  It has
advantages over markup such as =code= or ~verbatim~ in that it looks
better, can be used with text that spans multiple lines, and actually
ignores org-markup (for instance ~[[foo]]~ in org-mode will still turn
foo into a link, whereas : [[foo]] will render verbatim).

The question that I have is this: is that a legitimate / intended use
of the : markup?  I haven't seen it discussed in the docs, and only
found its existence when org-babel results blocks started returning
lines prefixed with :.  I think having a general lightweight syntax
for verbatim lines is very desirable, and if : indeed fits this
role, it should be mentioned in the manual under markup (since it is
a logical place to turn to when looking for verbatim/comment
constructs).

--Leo



[O] Using org-babel with Scheme

2012-02-08 Thread Leo Alekseyev
Is anyone on the list using a recent org-babel with Scheme?  I
recently started working through SICP, and I'm running into issues
evaluating scheme src  blocks.  Org-babel error buffer pops up with
ERROR: Wrong number of arguments to #primitive-generic display,
and the minibuffer prompts me for a lisp expression.  Is there
anything I need to configure beyond   (org-babel-do-load-languages
'org-babel-load-languages  '((scheme . t)))?

(Running latest org from git in Emacs 24; have Chicken scheme and
guile installed).

--Leo



Re: [O] [code] Small elisp snippet to search among toplevel headlines in a file

2012-02-05 Thread Leo Alekseyev
Another possible way to do it might be to create a wrapper around
org-goto with alternative interface where you set org-goto-max-level
to 1.  I've been using org-goto (alt. interface) with ido mode for a
while, and it's great (although I haven't tried restricting headlines
to just the top level).

On Sat, Feb 4, 2012 at 10:03 PM, Jude DaShiell jdash...@shellworld.net wrote:
 Another possible idea may be to write project titles in bold while on
 headlines.  That way all you need search for is the beginning of a line
 followed by a single * followed by a blank followed by the opening mark
 for bolding and if this is only done with project titles you got yourself
 an index.On Sat, 4 Feb 2012, Marc-Oliver Ihm wrote:

 Hello,

 I have one big org-file for a lot of smaller projects,
 each of them represented by a toplevel item.

 And I have difficulties finding them quickly:
 In most cases I know a buzzword from the headline;
 however, if I do a search-forward I normally find
 some other text within the body of an unrelated project
 further above in the file; and only after several
 repetitions of search I find the toplevel heading
 (i.e. the project) I was looking for.

 To make it easier to search only among toplevel headings
 (i.e. among the the titles of my projects),
 I wrote this small piece of elisp,
 which lives in my initialization-file (e.g. .emacs):

 (define-key org-mode-map
   [(f11)]
   (lambda () (interactive)
     (progn
       (occur (concat ^\\* .*
                      (read-from-minibuffer
                       Occur for toplevel headlines containing: ))
              nil)
       (pop-to-buffer *Occur*)
       (use-local-map (copy-keymap (current-local-map)))
       (local-set-key (kbd RET)
                      (lambda () (interactive)
                        (progn
                          (occur-mode-goto-occurrence)
                          (delete-other-windows)))


 To find a project I just press f11 (please choose your own key) and
 enter a keyword to do an occur for this keyword. Normally several toplevel
 headings are found and the right one is chosen by typing return.

 I hope, that someone might find this useful too.

 with kind regards, Marc-Oliver Ihm





 
 Jude jdashiel-at-shellworld-dot-net
 http://www.shellworld.net/~jdashiel/nj.html





[O] How to turn off flyspell for source code blocks?

2012-02-05 Thread Leo Alekseyev
How does one prevent flyspell from operating on code blocks in org?
I've tried adding (+begin_src . +end_src) to
ispell-skip-region-alist, but it didn't seem to work.



Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails

2012-01-28 Thread Leo Alekseyev

 -snip--
 #+property: session *R-babel*

 #+NAME: foo
 #+HEADER: :var a=a1.png
 #+BEGIN_SRC R :results output silent
   cat(in foo block\n)
   cat.a - function() { cat(a,\n,sep=) }
   cat.a()
 #+END_SRC
 #+call: foo(a=a1.png)

 #+begin_src R :results output raw replace :exports results
  cat.a()
 #+end_src
 --snip-


 OK, I see what you mean.  When I evaluate this buffer multiple times the
 results of the #+call: line *are* replaced as expected, but the final
 code block can not replace it's results because of the raw option to
 the :results header argument.  The raw and replace header arguments
 are not compatible because with raw results there is no way to know
 where the results end.  I believe this is mentioned in the manual, if
 not it should be.

Ok, I see.  Ideally, incompatible arguments should trigger an error
condition that would be communicated to the user (at the very least,
by printing a message in the minibuffer).  Silent failures are
annoying, even if documented :)

On a more practical note, is there _a_ method of achieving what I'm
trying to do here, namely, to place an image in the buffer in a way
that would be understood by Org and that would be properly imported in
HTML?

 Referring to what I said in another thread (the principle of least
 surprise):  it makes a lot of sense for the call lines to behave the
 same way a function call, or a source() statement would behave in the
 interpreter session of the original language.  From that perspective,
 the current behavior seems wrong.  Can you come up with a scenario /
 usage pattern where the current behavior is more desirable?


 The only loss of functionality would be the ability in the existing
 model to have a call line and it's results live in separate locations.
 Given that call lines can not currently be named their results are named
 by the information on the call line (called function, header arguments,
 etc...) which will be identical for identical call lines, leading to the
 current confusing behavior.

 I think the best way forward would be to

 1. stop auto-naming #+call: lines as we are currently and instead leave
   their results anonymous as with code blocks, and by default inserted
   immediately after the #+call: line.

 2. allow names to be applied to call lines, which can then be used to
   identify their results and locate their results remotely in the
   buffer.

 If this sounds like a good way forward then I'll put it on my queue for
 some time in the when-I-have-more-time future. :)

Yes, I think it's a good long-term plan.  Enqueue it :)  In the
meantime, the current behavior (and the possible workaround) should
probably be mentioned in the docs if it isn't already.

--Leo



Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails

2012-01-24 Thread Leo Alekseyev

 If /inline blocks/ above don't replace their results above then that is
 expected.  If you can find instances where call lines or blocks don't
 replace their results then that is a bug.

Yes, I was finding that neither inline nor regular blocks replace: run
the following with C-c C-v b a few times and look at the block output

-snip--
#+property: session *R-babel*

#+NAME: foo
#+HEADER: :var a=a1.png
#+BEGIN_SRC R :results output silent
  cat(in foo block\n)
  cat.a - function() { cat(a,\n,sep=) }
  cat.a()
#+END_SRC

#+call: foo(a=a1.png)

#+begin_src R :results output raw replace :exports results
 cat.a()
#+end_src
--snip-




 Finally, in the last file of my original message I try to use #+call's
 everywhere instead of source blocks.  Cleaned up example is pasted
 below.  It looks broken (the first #+call bar is out of order, the
 second and third #+call bar's don't run), see
 http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
 broken


 Ah, this is a different issue, but one which should be discussed.  I'm
 happy we're working through all of these before the Emacs24 release.

 The problem below is not order of evaluation but rather insertion of
 results.  The elements are evaluated in order, but the results from the
 bar() call lines are all inserted in the same place.  In the current
 code the raw text of the call line is used to insert the results, so
 identical call lines replace each other's results.

...

 Although the above is a workaround, it may be cumbersome.  I'm on the
 fence about whether to try to change the existing behavior.  If each
 identical call line is thought of as a token of the same call then maybe
 it makes sense to have only one location in which to insert the results
 of that call (also it is possible that some users are relying on the
 current behavior).  That said it is certainly confusing...

I see no reason why we should think of each call line as a token of
the same call; do you?  In fact, it's probably a fundamentally flawed
way of thinking, because nothing guarantees that the global state of
the session hasn't changed between call invocations.  In fact, in that
sense, we can't even technically regard the _same_ call line as being
a token of the same call, if we consider it at different times :)

Referring to what I said in another thread (the principle of least
surprise):  it makes a lot of sense for the call lines to behave the
same way a function call, or a source() statement would behave in the
interpreter session of the original language.  From that perspective,
the current behavior seems wrong.  Can you come up with a scenario /
usage pattern where the current behavior is more desirable?

--Leo



Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails

2012-01-23 Thread Leo Alekseyev
On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte eric.schu...@gmx.com wrote:
 Leo Alekseyev dnqu...@gmail.com writes:

 Since all source blocks are evaluated on export, I don't think it
 should be necessary to issue org-babel-execute-buffer before invoking
 export.  However, running HTML export without org-babel-execute-buffer
 currently produces garbage output.


 What do you mean by garbage output?

That wasn't a very good description, sorry.
..
I just wrote a detailed description of the bug, and then remembered
that I forgot to copy the latest org pull into
/usr/share/emacs/24/lisp/org.  This bug is now gone, probably as a
result of you fixing export evaluation order.  However, the
description of replace results bug is still relevant.  I'll denote
issues that are now fixed with appropriate markup.

#+BEGIN_MOOT_POINT
Take test-export4.org from my original message, and export (C-c C-e h;
don't evaluate the buffer beforehand).  You will see the following
output: http://i.imgur.com/IM3oy.png

There are two problems:
(1) Notice that the output of _every_ src_R block is images/conv2.png
It should be conv1.png on the first invocation conv2.png on the
second, and conv3.png on the third.
(2) The last src_R block is not evaluated and, in fact, appears in the
output (which it shouldn't), mangled, as the underscore is taken as a
subscript.
#+END_MOOT_POINT

For comparison, if you first evaluate the buffer, and then export, you
will see this:
http://i.imgur.com/V6PXq.png

The output of the src_R blocks is now correct, but I don't see why one
needs to pre-evaluate the buffer to get correct output on export.  The
overall output, as you can see, is _not_ correct, since the results
from invocation of src_R blocks via the export are _appended_ to those
that were generated via C-c C-v b.


 Could you isolate a minimal example demonstrating just the failure of
 results replacement?

Run the below code a few times with C-c C-v b, and you'll see

snip-
#+property: session *R-babel*

#+NAME: foo
#+HEADER: :var plot.filename=conv1.png
#+BEGIN_SRC R :results output silent
  cat.fname.link - function() { cat(plot.filename,\n,sep=) }
  cat.fname.link()
#+END_SRC

src_R[:results output replace]{ cat.fname.link() }
snip-


You can also replace src_R with

#+begin_src R :results output raw replace :exports results
 cat.fname.link()
#+end_src

and it will also fail to replace results.

All the above examples were run with the latest pull of org.

HTH,

--Leo



Re: [O] [BUG] Inconsistency in src block hiding

2012-01-23 Thread Leo Alekseyev
 statement above.  The tag-line to the Drawers section in the manual is
 Tucking stuff away which I think is often how drawers are used.
 Changing the default drawer export behavior from don't export to do
 export would be surprising, would break many existing work flows, and
 would likely make drawers less useful.

 In general I think the Org-mode specification is best defined by how
 Org-mode is used and how it may be more easily and intuitively used in
 the future.  Org-mode doesn't currently have a formal specification, and
 I think that is a good thing.  Formal specification don't prevent bugs,
 they just move them from the code to the spec.

Tucking stuff away can mean different things to different users.
Personally, I have treated them purely as an organizational device for
supplementary information (I have :DETAILS: drawers all over my org
files).  The problem is that I may or may not want this supplementary
information in the export, and will really vary from case to case.
(Personally, in most cases, I do want to export that information --
but not always!)  Furthermore, assuming that I _do_ want drawers
exported, I may or may not want the drawer markup to be exported, i.e.
if drawers are used purely for organizing the presentation of
information, the drawer markup doesn't belong in the export.  On the
other hand, in certain cases one might want to denote the information
as supplementary, either by exporting drawer markup (or, more likely,
by putting drawer contents inside something like a code block).

If I were designing this behavior from scratch, I would allow for
maximum flexibility by
(1) creating e.g. org-drawers-to-export variable which could take on
the values nil (don't export), 'all (all drawers except :PROPERTIES:)
exported, or a list of drawer names to export
(2) introducing drawer flags that would control the export and display
behavior of individual drawers.  For instance, something like
:FOO: -vis -export
stuff...
:END:
would indicate that this drawer is to be kept unfolded and exported by default.
(3) controlling whether the drawer contents are separated out from the
rest of the contents by some markups (hr's or  a code block)

I'm not sure how easy and/or practical any of this would be.  My
general philosophy is that if a behavior isn't specified, many
possible (sensible) behaviors should be considered and accommodated.

In that sense, hiding #+name: blocks is a good thing, because it
increases the amount of allowed sensible usage patterns.  If we were
to take it away, I think it would be necessary to compensate for this
by increasing the amount of allowed sensible usage patterns of the
drawers, kind of along the lines of what I described above.

--Leo



Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails

2012-01-23 Thread Leo Alekseyev
On Mon, Jan 23, 2012 at 10:05 PM, Eric Schulte eric.schu...@gmx.com wrote:
 Leo Alekseyev dnqu...@gmail.com writes:

 On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte eric.schu...@gmx.com wrote:
 Leo Alekseyev dnqu...@gmail.com writes:

 Since all source blocks are evaluated on export, I don't think it
 should be necessary to issue org-babel-execute-buffer before invoking
 export.  However, running HTML export without org-babel-execute-buffer
 currently produces garbage output.


 What do you mean by garbage output?

 That wasn't a very good description, sorry.

 No problem, thanks for clarifying.

 [... moot bug removed ...]


 Could you isolate a minimal example demonstrating just the failure of
 results replacement?

 Run the below code a few times with C-c C-v b, and you'll see

 snip-
 #+property: session *R-babel*

 #+NAME: foo
 #+HEADER: :var plot.filename=conv1.png
 #+BEGIN_SRC R :results output silent
   cat.fname.link - function() { cat(plot.filename,\n,sep=) }
   cat.fname.link()
 #+END_SRC

 src_R[:results output replace]{ cat.fname.link() }
 snip-


 You can also replace src_R with

 #+begin_src R :results output raw replace :exports results
  cat.fname.link()
 #+end_src

 and it will also fail to replace results.

 All the above examples were run with the latest pull of org.


 Ah, I see now.  Unfortunately it is not possible to replace the results
 of inline code blocks.  This is because there is no general way to
 identify where the results begin and end.  Maybe adding [:results
 silent] to your inline code blocks would solve the problem.  Then you
 could evaluate the whole buffer, and could previews the values produced,
 but would not have to worry about duplicate results.

Yes, that's a good suggestion.

Just to be clear, do you consider the following to be an inline block?
 (I usually think of inline as limited to src_R{ ...} type things).
Or are you generally talking about the distinction between #+begin_src
/ #+end_src lines vs #+call lines?

#+begin_src R :results output raw replace :exports results
 cat.fname.link()
#+end_src

Finally, in the last file of my original message I try to use #+call's
everywhere instead of source blocks.  Cleaned up example is pasted
below.  It looks broken (the first #+call bar is out of order, the
second and third #+call bar's don't run), see
http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
broken

--snip-
#+property: session *R-babel*

#+NAME: foo
#+HEADER: :var a=a1.png
#+BEGIN_SRC R :results output silent
  cat(in foo block\n)
  cat.a - function() { cat(a,\n,sep=) }
  cat.a()
#+END_SRC

#+NAME: bar
#+begin_src R :results output raw replace :exports none
 cat.a()
#+end_src


Should have all a1 stuff

#+call: foo(a=a1.png)

#+call: bar()

Should have all a2 stuff

#+call: foo(a=a2.png)

#+call: bar()

Should have all a3 stuff

#+call: foo(a=a3.png)

#+call: bar()



[O] [bug] :eval header argument ignored in the #+call: block

2012-01-20 Thread Leo Alekseyev
Suppose I have a code block foo, and I want to call it several times
in my org file.  However, foo may be a slow function, and so any time
I evaluate buffer non-interactively (e.g. HTML export) I want to
enable only one out of many calls to :foo

The following doesn't work, but I think it should, since the #+call:
line should run foo with the header argument :eval no-export

#+NAME: foo
#+BEGIN_SRC R :var turn_on_output=FALSE
if(turn_on_output) { X11() }
#+END_SRC

#+CALL: foo[:eval no-export](turn_on_output=TRUE)  ## this STILL
evaluates on export

Furthermore, a better solution to the situation I described above
might be to set the :eval no-export header argument in the source
block definition, and then over-ride it in the one #+call line that I
want to run during export.  Unfortunately, it doesn't seem that this
is currently possible.

--Leo



[O] [bug] src_language blocks seem broken in org-babel-execute-buffer

2012-01-20 Thread Leo Alekseyev
With the latest Org, issuing org-babel-execute-buffer on any buffer
that has inline src_language blocks fails with wrong type argument:
consp, nil

For instance, Eric Schulte's own code sample on
http://eschulte.me/org-scraps/scraps/2011-08-21-inline-code-block-and-downstream-src-blocks.html
doesn't run.

Can anyone confirm and/or offer a fix?

--Leo



Re: [O] org-babel order of evaluation

2012-01-20 Thread Leo Alekseyev
On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel r...@rickster.com wrote:
 On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote:
 Rick Frankel r...@rickster.com writes:

 Turns out it was not that difficult to change this behavior.  You and
 Leo are both correct that in-buffer-order evaluation is more natural and
 expected than the previous behavior.  I've just pushed up a fix after
 which evaluating the following

Eric,
The fix doesn't seem to be working for me when I export the buffer to
HTML.  The ordering of call and source blocks once again becomes
randomized, and in general, exported file is missing a bunch of stuff
unless I run org-babel-execute-buffer prior to export.  Since the
export engine does its own evaluation, it doesn't seem like
org-babel-execute-buffer should be a necessity.  But I can't run
org-babel-execute-buffer on anything with a src_language inline
block as it gives me an error.

I'm attaching two files which do not export correctly, at least when
one doesn't run org-babel-execute-buffer; just do C-c C-e h and look
at the output.

--Leo


test-export4.org
Description: Binary data


test-export6.org
Description: Binary data


[O] Is it possible to include #+call lines in HTML export?

2012-01-20 Thread Leo Alekseyev
Currently, my org files look something like this:

* And now, let's do the analysis !
#+call: foo(bar)

#+results:
:  earth-shattering results
:  gonna land me a Nobel /and/ a Fields!

But because #+call is not exported, it's not clear what function was
called and with what parameters.  It makes a lot of sense for it to be
included in the export (unless its evaluation is turned off via e.g.
:eval no-export), but I can't find an option for this.

--Leo



[O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails

2012-01-20 Thread Leo Alekseyev
Since all source blocks are evaluated on export, I don't think it
should be necessary to issue org-babel-execute-buffer before invoking
export.  However, running HTML export without org-babel-execute-buffer
currently produces garbage output.

On the other hand, I have several examples where running HTML export
_after_ org-babel-execute-buffer produces the wrong output due to the
fact that :results replace directive appears to append instead of
replacing the output

I am attaching three simple examples where I simulate generating and
exporting image data (I just generate and print filenames).  If I
understand the documentation correctly, they are all supposed to
produce identical output on HTML export; however, none of the files
produces the expected output, namely, blocks of the form:


| some output
| images/conv1.png
|
| images/conv1.png
\--

Here, the first two lines should be enclosed in a code block, and the
last line should be raw org output.

To reproduce, load any of my examples, do

C-c C-e h - will produce garbage output on export
C-c C-v b - will produce expected output in the buffer
C-c C-e h - will produce extraneous output on export despite :results
replace being on
C-c C-v b - will produce extraneous output in the buffer

This was tested on my test-export4.org, but the other examples behave
in a similar fashion.

--Leo


test-export4.org
Description: Binary data


test-export5.org
Description: Binary data


test-export7.org
Description: Binary data


Re: [O] Capitalisation and good taste ?

2012-01-20 Thread Leo Alekseyev
 A long time ago all capitals was the only way these keywords were
 supported.  Since then they have become case insensitive and I use all
 lowercase for most of my keywords now (#+begin_src:, #+begin_example:
 etc)

 With fontification these stand out enough now and the capitalization can
 be removed.

So I'm kind of late to this party, but like Bernt, I've been favoring
lowercase #+ keywords; I believe it looks cleaner and easier on the
eyes.  However, if functions that autogenerate keywords (e.g.
#+results from code blocks and easy templates) default to a particular
case, forcing a different case as a user becomes unappealing
(consistency trumps aesthetics).

If we want to keep org truly keyword-case-agnostic, then there should
be a user-customized variable that easy templates and org-babel result
blocks would follow.

--Leo



Re: [O] [BUG] Inconsistency in src block hiding

2012-01-18 Thread Leo Alekseyev
 Why can't you? Wouldn't it be related to drawers configuration
 (org-export-with-drawers for example)?

 Yes... but I don't think I can configure which drawers I get, and I
 don't want my LOGBOOK drawer with all my clock lines in my export.

 -Bernt

 Is there still a way to hide results output with the current master?

 Yes, within a drawer.

Yes, but is it possible to hide the drawer name in the HTML export?
If drawers are designed to be used as an organization device (and not
an outlining device), the drawer delimiters shouldn't be exported to
HTML.



[O] Verbatim URL in HTML export

2012-01-18 Thread Leo Alekseyev
I would like to have a plain-text URL with no formatting in my HTML
output.  I can't figure out how to avoid having it turn into a link on
HTML export.  Surrounding it with ~tildes~ puts it in a code block,
which is not what I need; I simply need that particular URL to be
treated as plain text.  Is there a markup/option for this?

--Leo



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-13 Thread Leo Alekseyev

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.


 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?


 I am using 24.0.92 and I have no problems at all (just tried right
 now).

 One difference, however, could be the window configurations we
 use.  Specifically, I have

       (setq org-src-window-setup (quote current-window))


 Yes, this works. It's also a more sensible default. However, it
 doesn't change the fact that there's a bug, it just switches to a case
 where the bug isn't triggered :)


 It is also not triggered by the other-window option, which behaves more
 like
 reorganize-frame than current-window (emacs 24.0.92)

Folks, I still think that the fact that buffer-file-name is not nil is
a bug and should be fixed.  If I'm wrong, can someone point out why
this is so?

I have seen many functions that test whether or not a buffer is
visiting a file by checking buffer-file-name.  For instance, if I
wanted to enable autosave for org-src buffers, it would break since my
make-auto-save-file-name checks whether a file is being visited.

--Leo



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-12 Thread Leo Alekseyev
On Thu, Jan 12, 2012 at 4:14 AM, Andreas Leha
andreas.l...@med.uni-goettingen.de wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 Leo Alekseyev dnqu...@gmail.com writes:

 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience

 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?

 I am using 24.0.92 and I have no problems at all (just tried right
 now).

 One difference, however, could be the window configurations we
 use.  Specifically, I have

       (setq org-src-window-setup (quote current-window))

Yes, this works. It's also a more sensible default. However, it
doesn't change the fact that there's a bug, it just switches to a case
where the bug isn't triggered :)



Re: [O] org-babel order of evaluation

2012-01-12 Thread Leo Alekseyev
 Therefore, when executing an entire buffer, there is no way to have
 the execution of a call block dependent on the prior execution of a
 source block.


 It would be better to make the dependency explicit by passing the
 results of the call line as a (potentially unused) variable to the code
 block.  For example;
[snip]

 There is (at least currently) no guarantee that evaluation order will be
 buffer order.

I've been extremely confused by this in the past; this should be
prominently documented.  In the long run, I would like to see this
behavior changed.  One would intuitively expect all the source code in
the file to be evaluated in order.  This is how it works in pretty
much any other interpreter, why should org-babel be different?

(I'm a big fan of the principle of least surprise, and this behavior
violates it with vengeance :)  )

This is particularly nasty because many users start by treating an
org-babel file as a fancier version of the original source code with
nice annotations and outline levels; typically in a single language.
Thus, operationally, there isn't a distinction between tangling the
blocks into a single source file and feeding that to the interpreter
and running execute on the whole buffer.  But then, of course, one
might start using named blocks, variables, and #+call directives.  It
achieves the same effect as writing wrapper functions (or issuing
statements like source(somefile)) in the original language.  So,
when it results in a completely different execution order, it's a huge
surprise.

Even if this can be fixed by putting dummy dependencies in by hand,
this fix  seems inelegant and hacky.

Is there some deep rationale for the current behavior that I'm not
seeing?  Are there big obstacles to enforcing ligeral execution order?

--Leo



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Leo Alekseyev
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

It appears that this bug is Emacs-version dependent: it functions as
you describe with 23.2, but the buffer gets buried (with an error
message basic-save-buffer: Wrong type argument: stringp, nil) in
24.0.92.  Org mode is the current git HEAD.  I tried to step through
basic-save-buffer in edebug, but I couldn't catch the error (I'm not
very experienced with edebug).  Can someone test this on Emacs 24 and
confirm what I'm seeing?



Re: [O] Minor org mode for achieve code folding effects

2012-01-11 Thread Leo Alekseyev
 For instance, when I was doing a lot of Java programming, I used
 hideshow.el all the time to hide block and function bodies.  Works very
 well (although the default key bindings are annoying to me).  Have a
 look!  It's a standard package in emacs, at least in Emacs 24 but much
 earlier than that I believe.

 There's a small add-on called hideshow-org.el which may be useful as
 well:

Having read the OP, I'll second Eric's vote for hideshow-org.  It's a
better solution for folding functions.  However, the combination of
org/outline-minor-mode/Tassilo's code works well for splitting a file
into foldable sections.  Incidentally, you can use both of these
methods at the same time; they don't conflict too much.

--l



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Leo Alekseyev
On Wed, Jan 11, 2012 at 7:40 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?

I've done some more digging into why this is broken. I see a few
issues, but no clear indication of where the problem is.  This,
however, should be fixed: pressing C-x C-s should not break window
configuration.

On Emacs 24, with latest Org:

1. Somehow, (org-edit-src-save) screws up the window configuration and
buries the source edit buffer.  It appears that save-window-excursion
is not restoring windows correctly.  What's going on exactly is
unclear: in the process of getting saved, the source edit buffer is
killed and subsequently restored with   (org-src-switch-to-buffer
buffer 'edit).  Maybe this doesn't play well with
save-window-excursion in Emacs 24?

I stepped through the calls in Emacs 23 and 24, and it all looks
identical -- except for in 24, the call to save-window-excursion does
not in fact restore windows.

2. In file.el:4435 (basic-save-buffer)
(nthcdr 10 (file-attributes buffer-file-name)) often leads to
wrong-type-argument error.  The reason for this is that
buffer-file-name sometimes corresponds to the base .org buffer (no
error in this case), sometimes it corresponds to the name of the
src-edit buffer and sometimes it's nil (leads to wrong-type-argument
error).  By this point, the file should have been written using
'write-contents-functions that is set to (org-edit-src-save), so I
don't know if this error is important (nonetheless, buffer-file-name
should probably be valid).

3. Related, in the same function:
(if (or (buffer-modified-p)
;; handle the case when no modification has been made but
;; the file disappeared since visited
(and buffer-file-name
 (not (file-exists-p buffer-file-name

This if statement is always triggered, because buffer-file-name is not
nil, and because the buffer doesn't correspond to the file.  (Note
that in Emacs 23 this was just (if (buffer-modified-p)...).  This is
not be the appropriate behavior, but it persists because
buffer-file-name is not nil (which it probably should be).

--l



Re: [O] Minor org mode for achieve code folding effects

2012-01-10 Thread Leo Alekseyev
On Tue, Jan 10, 2012 at 3:08 PM, Eric S Fraga e.fr...@ucl.ac.uk wrote:
 Giovanni Giorgi j...@gioorgi.com writes:



 Hi all,
  I'd like to edit some ruby/python/shell script using
 functions folding.

 I'd like to get a way to fold functions or method.

 Carsten has already given you one possible solution; another is to use
 org + babel with tangling to have each function or method within a
 separate headline in an org document.  Check out the manual

I have used both Carsten's and Eric's solution, as well as
hideshow-org (https://github.com/secelis/hideshow-org), which works
rather well and deserves a mention.

Expanding a bit on Carsten's post: Tassilo Horn wrote some convenience
functions to set the outline minor mode regexps to correspond to the
current comment syntax.  Thus, if I'm (for instance) in shell-script
mode, # * and # ** become the outline level 1 and 2 markers.

One issue with this approach is that you might prefer finer control
over what sections appear folded and what sections appear visible by
default. To deal with this, I hacked org.el watch for special
visibility-control markers in the heading line, so that e.g. * A
heading ending with tilde-tilde like so ~~ would appear always
visible.  I hope to come up with a better solution for this in the
future.

The other issue is that Tassilo's code is currently broken for c-mode
(possibly due to conflating *'s in /* comment syntax with *'s in the
outline header level syntax).  If you can fix it, that would be useful
:)

The code:

(require 'outline)
(add-hook 'outline-minor-mode-hook  
  '(lambda ()
 (define-key outline-minor-mode-map (kbd TAB) 'org-cycle)
 (define-key outline-minor-mode-map [(tab)] 'org-cycle)
 (define-key outline-minor-mode-map [(shift tab)] 'org-global-cycle)
 (define-key outline-minor-mode-map [backtab] 'org-global-cycle)))


;; Tassilo Horn's outline-minor-mode enhancement: derive regex from
comment syntax
(defvar th-outline-minor-mode-font-lock-keywords
 '((eval . (list (concat ^\\(?: outline-regexp \\).*)
 0 '(outline-font-lock-face) t t)))
 Additional expressions to highlight in Orgstruct Mode and Outline minor mode.
The difference to `outline-font-lock-keywords' is that this will
overwrite other highlighting.)

(defun th-outline-regexp ()
 Calculate the outline regexp for the current mode.
 (let ((comment-starter (replace-regexp-in-string
 [[:space:]]+  comment-start)))
   (when (string= comment-starter ;)
 (setq comment-starter ;;))
   (when (string= comment-starter #)
 (setq comment-starter ##))
   (concat comment-starter  [*]+ )))

(defun th-outline-minor-mode-init ()
 (interactive)
 (unless (eq major-mode 'latex-mode)
   (setq outline-regexp (th-outline-regexp))
   (font-lock-add-keywords
nil
th-outline-minor-mode-font-lock-keywords)
(font-lock-fontify-buffer)))

(add-hook 'outline-minor-mode-hook 'th-outline-minor-mode-init)



Re: [O] Minor org mode for achieve code folding effects

2012-01-10 Thread Leo Alekseyev
On Tue, Jan 10, 2012 at 7:21 PM, David Rogoff da...@therogoffs.com wrote:



   David Rogoff da...@therogoffs.com
  January 10, 2012 4:34 PM
  Carlos Russo mestre.adamastor at gmail.com writes:
 I have used both Carsten's and Eric's solution, as well as
 hideshow-org (https://github.com/secelis/hideshow-org), which works
 rather well and deserves a mention.

 Expanding a bit on Carsten's post: Tassilo Horn wrote some convenience
 functions to set the outline minor mode regexps to correspond to the
 current comment syntax.  Thus, if I'm (for instance) in shell-script
 mode, # * and # ** become the outline level 1 and 2 markers.

  This is great info! I was just looking for this in the last couple of
 days and appreciate everyone's code since it's way beyond my elisp
 abilities.
 I like this a lot more than the folding.el I had been using since I
 already use orgmode.  However, I've got a question:

 I'm using this with verilog-mode which uses //  to start comments.  The
 problem is that when I indent my file, the comments indent too and it seems
 that output-minor-mode (and, I assume, orgmode) only recognize headings
 that start in column 0.  How/where can I change this so it will recognize
 any line that is whitepace followed by the comment-start?


  I've done a little bit of digging into how Tassilo's code works, and
realized that it's somewhat broken in the following way: if a mode provides
its own outline-level function, chances are, his code will break (this is
why c-mode doesn't work).  Even if default outline-level is used, it will
determine the level incorrectly since it just counts characters in the
current outline regex.  Thus, with the ouline regexp set to something like
## *  this function will say that you are on outline level 5.  This might
lead to some unexpected behavior.  Long story short, here is the fixed code
that provides and sets proper outline level:

  (defun th-outline-regexp ()
   Calculate the outline regexp for the current mode.
   (let ((comment-starter (replace-regexp-in-string
   [[:space:]]+  comment-start)))
 (setq comment-starter (replace-regexp-in-string * [*]
comment-starter))
 (when (string= comment-starter ;)
   (setq comment-starter ;;))
 (when (string= comment-starter #)
   (setq comment-starter ##))
 (concat \\( comment-starter \\) \\( [*]+ \\

  (defun th-lva-outline-level ()
Calculates appropriate outline level by counting the stars in the
regex
(let ((stars-regex [*]+) (outline-start-string (match-string 2)))
   ;; ideally, second group obtained by (match-string 2) will be just
the stars
  (if (string-match stars-regex outline-start-string)
  (- (match-end 0) (match-beginning 0))
0)))

  (defun th-outline-minor-mode-init ()
   (interactive)
   (unless (eq major-mode 'latex-mode)
 (setq outline-regexp (th-outline-regexp))
 (setq outline-level 'th-lva-outline-level)
 (font-lock-add-keywords
  nil
  th-outline-minor-mode-font-lock-keywords)
  (font-lock-fontify-buffer)))
postbox-contact.jpg

[O] Org-edit-special and C-x C-s strange behavior

2012-01-10 Thread Leo Alekseyev
I often edit my org-babel code blocks via org-edit-special (C-'), in
part because I find the tabbing behavior within the code blocks to be
somewhat flaky. Inevitably, when editing the code block I will press
C-x C-s (muscle memory). This causes all sorts of annoying
consequences: the buffer with the code block gets buried, window
splitting disappears, and if I go back to the original org buffer,
find the relevant code block and try to edit again via C-', I'm faced
with a rather cryptic message Return to existing edit buffer? [n]
will revert changes: (y or n) .

Since C-x C-s is such a basic operation, I think it should do
something more sensible in an edit buffer (for instance, it should
save the original org document and not screw with the window
configuration).  Alternatively, it could be configured to save, and
exit the edit buffer (i.e. simulate the effect of pressing C-' and
then C-x C-s in the original org buffer).  This would go a long way to
making working with code blocks more pleasant.  From my viewpoint /
usage patterns it makes a lot of sense for an edit buffer to behave
like a version of the original org buffer narrowed to the source code
block. If there's a particular reason for the current behavior, I'd be
very curious to know it.

--Leo



Re: [O] fast navigation

2011-12-22 Thread Leo Alekseyev
The patch indeed fixes the problem, but has the following side effect:
the org-goto prompt now acquires a (possibly invalid) default
location, e.g. after I go to node foo in some file (file1), and do
an org-goto in some other file (file2), it will give me foo as a
default location, even though there's no node foo in file2.  This is
mostly a cosmetic bug, but a bug nonetheless, because the signature of
the function in the patch is
(org-refile-get-location optional PROMPT DEFAULT-BUFFER NEW-NODES
NO-EXCLUDE) and we are in fact passing nil to default-buffer.  I would
expect this to suppress the showing of the default prompt.


On Wed, Dec 21, 2011 at 8:31 AM, Yagnesh Raghava Yakkala
yagn...@live.com wrote:
 Hi,

 Leo Alekseyev dnqu...@gmail.com writes:

 I recorded the bug in a short screencast.  emacs was started with -Q;
 in the second part of the screencast it was restarted with a config
 file that only included ido mode

 http://www.youtube.com/watch?v=z6nDUh0RH_cfeature=youtu.be


 The attached highly unrelible online PATCH fixes the problem. I dont know
 it has any side effects.




 --
 YYR




[O] org-goto outline-path-completion bugs

2011-12-20 Thread Leo Alekseyev
I recently upgraded to the latest version of org (from 7.4) and found
that org-goto started exhibiting the following bugs when used in
outline-path-completion mode:


1. If the point is before the first heading, org-goto will fail with
Before first headline at position 1 in buffer 

2. If the point is on a heading, org-goto will effectively not see
this heading or its children.  For instance, in the following
hierarchy:
* foo
** bar
* baz

when the point is somewhere on * foo, the whole * foo subtree is
effectively invisible in org-goto

3. Similarly, when used with ido completion, the current heading and
its children are excluded from ido completion list and are
inaccessible.

I am seeing this on Linux Mint 12, GNU Emacs 24.0.92.1
(x86_64-pc-linux-gnu, GTK+ Version 3.2.0)

With a different version of emacs, GNU Emacs 23.3.1
(x86_64-pc-linux-gnu, GTK+ Version 2.24.5), I don't see behavior (2)
-- the heading at point is in fact visible to org-goto.  However, the
ido completing read is still broken.



Re: [O] fast navigation

2011-12-20 Thread Leo Alekseyev
This very much looks like a bug to me.  I just upgraded from 7.4 to
7.8 of org and am starting to see this behavior.  It's even more
broken when combined with ido completion (which is what I use).  I
just wrote a separate post to the mailing list (I wrote it before I
saw this thread); it might be useful to take the conversation there.

--Leo

On Tue, Dec 20, 2011 at 7:24 AM, sergio mail...@sergio.spb.ru wrote:
 On 12/20/2011 11:54 AM, Eric Abrahamsen wrote:

 I just removed org-mode package. With org-mode from emacs (6.33x) all
 works fine. After this I've downloaded and installed org-mode from the
 web --- problem comes back.


 --
 sergio.




Re: [O] fast navigation

2011-12-20 Thread Leo Alekseyev
I recorded the bug in a short screencast.  emacs was started with -Q;
in the second part of the screencast it was restarted with a config
file that only included ido mode

http://www.youtube.com/watch?v=z6nDUh0RH_cfeature=youtu.be

On Tue, Dec 20, 2011 at 5:27 PM, Bastien b...@altern.org wrote:
 Hi Sergio,

 sergio mail...@sergio.spb.ru writes:

 On 12/20/2011 11:54 AM, Eric Abrahamsen wrote:

 I just removed org-mode package. With org-mode from emacs (6.33x) all
 works fine. After this I've downloaded and installed org-mode from the
 web --- problem comes back.

 I'm lost here -- can you restate the bug and provide a simple way to
 reproduce it with emacs -Q (no configuration) and Org 7.8.02?

 Thanks!

 --
  Bastien




[O] [babel] Error when exporting a trivial org file to HTML: Wrong type argument: stringp, (results . )

2011-09-29 Thread Leo Alekseyev
Here is what's in my org file:

8
#+title:   My org file
#+babel: :session *R-babel* :tangle yes

* The problem
** The code
This is going to fail on export:

#+source: test_code
#+BEGIN_SRC R :results output silent :exports none :var foo
  bar - foo
#+END_SRC

Why does this fail?
#+call: test_code(foo=200)
#+results: test_code(foo=200)
8

Simple, right?  Yet, when I try to do org-export-as-html, I get:

executing R code block (test_code)...
result is 

executing Emacs-Lisp code block...

(results (quote ))

Code block produced no output.
org-babel-exp-code: Wrong type argument: stringp, (results . )

This happens with the latest org-mode from trunk, as well as my
few-months-old version.  What's going on?



Re: [O] [babel] Error when exporting a trivial org file to HTML: Wrong type argument: stringp, (results . )

2011-09-29 Thread Leo Alekseyev
I changed the line to #+BEGIN_SRC R :results output silent :exports
none :var foo=0, but it gives me the same error as before.  Running on
the old-ish version of org (from January, commit
8be17c8c62a8fb402a2ebf1c963a4e9f8f5dec53).

On 9/29/11, Eric Schulte schulte.e...@gmail.com wrote:
 Hi Leo,

 On my system with the latest Org-mode I get the following slightly more
 helpful error message.

   variable foo must be assigned a default value

 Please add a default value to the foo variable for export and evaluation
 of the code block to work.

 Best -- Eric

 Leo Alekseyev dnqu...@gmail.com writes:

 Here is what's in my org file:

 8
 #+title:   My org file
 #+babel: :session *R-babel* :tangle yes

 * The problem
 ** The code
 This is going to fail on export:

 #+source: test_code
 #+BEGIN_SRC R :results output silent :exports none :var foo
   bar - foo
 #+END_SRC

 Why does this fail?
 #+call: test_code(foo=200)
 #+results: test_code(foo=200)
 8

 Simple, right?  Yet, when I try to do org-export-as-html, I get:

 executing R code block (test_code)...
 result is 
 
 executing Emacs-Lisp code block...

 (results (quote ))

 Code block produced no output.
 org-babel-exp-code: Wrong type argument: stringp, (results . )

 This happens with the latest org-mode from trunk, as well as my
 few-months-old version.  What's going on?


 --
 Eric Schulte
 http://cs.unm.edu/~eschulte/




[O] Org buffers scroll to the very bottom on their own

2011-09-29 Thread Leo Alekseyev
I just pulled the latest org from trunk and byte-compiled under
Windows; I am seeing bizarre behavior, where the point in an org-mode
buffer scrolls to the very bottom of the buffer.  It's as if someone
keeps pressing the down arrow key, or even S-M-[period].  Org is now
unusable.  Has anyone seen this before and can tell me what in the
world is happening?



Re: [O] Org buffers scroll to the very bottom on their own

2011-09-29 Thread Leo Alekseyev
Please ignore my last post; turns out I've merged some custom changes
with the trunk, and my merge appears to be buggy

On Thu, Sep 29, 2011 at 5:23 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 I just pulled the latest org from trunk and byte-compiled under
 Windows; I am seeing bizarre behavior, where the point in an org-mode
 buffer scrolls to the very bottom of the buffer.  It's as if someone
 keeps pressing the down arrow key, or even S-M-[period].  Org is now
 unusable.  Has anyone seen this before and can tell me what in the
 world is happening?




[O] Org-indent mode - is it possible to change auto-fill column based on indentation level?

2011-05-19 Thread Leo Alekseyev
I like using org-indent, however, when I'm on e.g. the third level of
an outline, this means that the effective line starts 7 characters
away from the left buffer edge.  Most often, I have two buffers side
by side on a laptop, and they are 77 columns wide.  I set fill-column
to 77 in order to not waste space.  Now, if I'm on the third level of
the outline, auto-fill will only kick in on the 84th column or
thereabout.

Are there any hacks to dynamically adjust the fill-column value
depending on the outline level?  (Solutions like get a bigger screen
or live with narrower default fill are valid, but less desirable :)
)

--Leo



Re: [Orgmode] org-git-link does not support locational information within file

2011-02-13 Thread Leo Alekseyev
 ** Shortcomings of git-link in current org HEAD
 Yet, org-git-link currently is too greedy for my daily use:
  1. they kill org-links for org headings, if the org files are
    versioned in a git repository (and all of mine are!) and
  2. they kill in-file-search information for versioned non-org files.

The discussion so far focused on extending the link syntax to allow
multiple pieces of location information (e.g. location within the
repository + location within the file), which is a good idea.
However, I think the bigger problem with org-git-link in its current
incarnation is that it forces me to use git:// links for all files
under version control, which is NOT what I want to do 90% of the time.
 I have a quick hack to deal with this -- namely, commenting out

;; (add-hook 'org-store-link-functions 'org-git-store-link t)

and using a separate keybinding for storing git links using the
following function:

(defun org-git-store-link-interactively (arg)
  Store git link to current file.
  (interactive P)
  (let ((org-store-link-functions (cons 'org-git-store-link
org-store-link-functions)))
(call-interactively 'org-store-link arg)
))


In addition, I'm not crazy about using the branch@{date} format for
storing links by default, so I hacked something that uses SHA1
instead...  I could post a patch if anyone is curious.

--Leo

___
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: Make text below heading not part of the heading

2011-01-27 Thread Leo Alekseyev
Christian Moe mail at christianmoe.com writes:

 
 For my money, it's neither bug nor feature, but a (minor) restriction 
 that follows from the (hugely enabling) feature of simple-to-use 
 outline folding. An exception would be an added feature. For my part, 
 I've not yet had a use case where inserting an extra heading was not a 
 satisfactory solution.
 

Christian is right that it's just a design limitation, but he makes it sound
like the restriction follows from having simple-to-use folding, or that because
simple folding is so useful by itself, we can overlook minor inconveniences like
lack of fine-grained control over folding.

I disagree.  I would argue that _because_ folding and outlining is so central to
org mode's usefulness, it would be good to introduce better control over
folding.  I, for one, would like to see a feature like Marcelo suggests. 
Implementing it the way he describes would probably be somewhat non-trivial,
because it does interfere with the fundamental model of an org document. 
However, there are very simple ways to achieve the desired effect.  For
instance, a special mark-up of a heading (e.g. * ~~ heading) could be made
equivalent to setting the visibility:true property.  I've played with the
relevant code in org.el, and it wouldn't be hard to implement.  

Another example where I would very much like to see more control over folding
are the #+begin_src/#+end_src, #+begin_example/#+end_example, etc. blocks.  In
particular, I'd like an option to see #+begin... blocks in the outline view as
I'm cycling through visibility with shift-tab.  In a lengthy org-babel document,
such an ability would be invaluable.

In short, for complicated org documents with many outline levels, visiblity
requirements, :DETAILS: drawers and #+begin/#+end blocks, the current level of
control over folding is not entirely satisfactory. It doesn't look hard to fix,
but unfortunately it seems that everyone is content with the status quo...

--Leo



 
 On 1/26/11 10:05 PM, Jeff Horn wrote:
  On Wed, Jan 26, 2011 at 3:55 PM, Marcelo de Moraes Serpa
  celoserpa at gmail.com  wrote:
  Would the current behavior be considered a bug or a feature?
 
  I consider it a feature. I don't know what your use case is (why you
  want to do this), but if you want to callout particular information,
  as a header, without messing with folding, I suggest trying
  org-inlinetask-insert-task. You can delete the TODO keyword if it
  pops up.
 
  You could also use list items instead of headers if you want to
  visually separate text from the body, like a note to self.
 
 
 ___
 Emacs-orgmode mailing list
 Please use `Reply All' to send replies to the list.
 Emacs-orgmode at 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] Make file:... directory links open dired by default

2011-01-23 Thread Leo Alekseyev
I am working under Windows, and by default links like file:~/path...
open in Explorer.  I can manually change the link to
file+emacs:~/path... and then it opens in dired -- but is there a way
to change the default behavior so that when I press C-c C-l to store
the directory links as file+emacs to begin with?..  Alternatively, is
there a way to make file: links behave like file+emacs? (I'm not sure
if this is a good idea since it might impact things other than
directories).
--Leo

___
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: evaluating all R code blocks (newbie question)

2011-01-20 Thread Leo Alekseyev
Julian Burgos jmburgos at uw.edu writes:

 
 Dear list,
 
 Hopefully this is not too basic, nor has been answered before.
 
 I would like to know if there is away to have alll R code blocks in a
 document evaluated automatically (i.e. without query) when exporting
 to Latex.  Now I have to answer yes multiple times to the question
 Evaluate this R code block in your system every time I do an export,
 which is somewhat annoying.
 Many thanks,

I don't have experience w/ LaTeX export, but try this to turn off the evaluate
this block? prompt: (setq org-confirm-babel-evaluate nil)





___
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] Handling file links under Windows

2011-01-16 Thread Leo Alekseyev
Guided by Matt's suggestion I started digging further.  I see the
problem, but I don't know how to fix it other than by making crude
changes directly to source in org.el.

Both the command path and the file link path need to be properly
formatted for Windows.  In particular, in org-file-apps list, I need
something like (\\.jnt\\' . (format %s %%s (w32-short-file-name
C:\\Program Files\\Windows Journal\\Journal.exe))).  But, this
expression doesn't work verbatim.  If I evaluate (format) and
paste the result as the cdr of the dotted pair, e.g. (\\.jnt\\' .
c:/PROGRA~1/WI0FCF~1/Journal.exe %s), the command is invoked.  So,
question 1: How do I eval the (format...) expression automatically?..

A more serious problem is that emacs is failing to correctly convert
slashes to backslashes in the file path.  My emacs is launched by
cygwin, and so apparently it thinks that slashes are OK, but in fact
they are not.  Here are the explicit modifications to org-find-file in
org.el that are needed to get things to work:

Original code (doesn't work under Windows):
(setq cmd (replace-match
   (save-match-data
 (shell-quote-argument
  (convert-standard-filename file)))
   t t cmd)))

Here's what works:
(setq cmd (replace-match
(w32-short-file-name (save-match-data
   (convert-standard-filename
(replace-regexp-in-string / \\ 
file t t t t cmd))

Note that instead of (convert-standard-filename file) I need to
explicitly replace slashes with backslashes, and shell-quote-argument
must be replaced with w32-short-file-name.  So, question 2: Is there a
way to make these modifications without patching org?..

--Leo

On Sat, Jan 15, 2011 at 10:27 PM, Matthew Fidler
matthew.fid...@gmail.com wrote:
 Leo,

 I am not at my computer, so I can't try this out.  However I believe
 it may be the spaces in your commands. Try:

 ((\\.jnt\\' . (format %s %%s (w32-short-file-name C:\\Program 
 Files\\Windows
 Journal\\Journal.exe))
 (\\.pdf\\' . (format %s %%s (w32-short-file-name C:\\Program Files 
 (x86)\\Adobe\\Acrobat
 10.0\\Acrobat\\Acrobat.exe)
 (auto-mode . emacs)
 (\\.x?html?\\' . default))

 Matt

 On Jan 15, 2011, at 9:03 PM, Leo Alekseyev dnqu...@gmail.com wrote:

 Dear All,
 I would like to have links to PDF files open those files in Acrobat
 and links to Windows Journal (JNT) files open them in Windows Journal
 -- very simple; same as it would be as if I double-clicked them
 anywhere in Windows.

 Here is what happens now: PDF files open in emacs doc-view mode, and
 JNT files fail to open with the message ShellExecute failed:
 Application not found^M (sic).

 If I try to explicitly set the variable org-file-apps, so that its
 value is ((\\.jnt\\' . C:\\Program Files\\Windows
 Journal\\Journal.exe %s)
 (\\.pdf\\' . C:\\Program Files (x86)\\Adobe\\Acrobat
 10.0\\Acrobat\\Acrobat.exe %s)
 (auto-mode . emacs)
 (\\.x?html?\\' . default))

 -- but in this case, opening those links silently fails (even though I
 can type e.g.  C:\Program Files\Windows Journal\Journal.exe foo.jnt
 from Windows command line and it works fine).

 Can anyone help with getting this to work right?..  Links are rather
 fundamental to org-mode and it's annoying not to have them working
 right.

 --Leo

 ___
 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] Handling file links under Windows

2011-01-15 Thread Leo Alekseyev
Dear All,
I would like to have links to PDF files open those files in Acrobat
and links to Windows Journal (JNT) files open them in Windows Journal
-- very simple; same as it would be as if I double-clicked them
anywhere in Windows.

Here is what happens now: PDF files open in emacs doc-view mode, and
JNT files fail to open with the message ShellExecute failed:
Application not found^M (sic).

If I try to explicitly set the variable org-file-apps, so that its
value is ((\\.jnt\\' . C:\\Program Files\\Windows
Journal\\Journal.exe %s)
 (\\.pdf\\' . C:\\Program Files (x86)\\Adobe\\Acrobat
10.0\\Acrobat\\Acrobat.exe %s)
 (auto-mode . emacs)
 (\\.x?html?\\' . default))

-- but in this case, opening those links silently fails (even though I
can type e.g.  C:\Program Files\Windows Journal\Journal.exe foo.jnt
from Windows command line and it works fine).

Can anyone help with getting this to work right?..  Links are rather
fundamental to org-mode and it's annoying not to have them working
right.

--Leo

___
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] Tab/S-Tab cycling behavior: how to include #+begin_src and #+results blocks

2011-01-13 Thread Leo Alekseyev
I rely heavily on org-cycling/org-global-cycling to see an outline
view of the document.  It would help if I could use  #+begin_src and
#+results blocks, and possibly some others, in this outline view.
Specifically, I would like to be able to do the following:

(a) When cycling with S-Tab, between contents and show all I would
like a step where all the #+begin_src and #+results blocks are folded.
 I realize that they start out open and then remember their folding
state; the remembered state of these blocks, if it is different from
all folded or all open, could potentially be included as another
step before show all.
(b) Same when I'm cycling with Tab; I would like to have an option of
showing the subtree with all #+begin_src and #+results blocks folded
before showing the completely unfolded subtree.

Is this possible to implement?..  Let me know!

--Leo

___
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] org-babel, R, and org-babel-open-src-block-result

2011-01-11 Thread Leo Alekseyev
I recently started using org-babel with R, and so far I think it's
pretty great!  I'm still getting accustomed to org-babel workflow and
am playing with available options.  I have a couple of questions:

I noticed that C-c C-o (org-babel-open-src-block-result) always gives
me an empty *Org-Babel Results* buffer, even if there's output printed
to #+results section.  Is this a bug?  Am I doing something wrong?

On a similar note, is there an option for the #+ results session to be
completely suppressed?..  I can see situations where I might simply
want to send the code to the inferior process and examine the results
there using :results output :session, or perhaps I'm running the code
just for the side effects.  It would be nice if I could say e.g.
:results none.

Thanks and keep up the good work with org-babel!

--Leo

___
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: org-babel, R, and org-babel-open-src-block-result

2011-01-11 Thread Leo Alekseyev
Erik Iverson eriki at ccbr.umn.edu writes:

 
 On 01/11/2011 04:22 AM, Leo Alekseyev wrote:
  I recently started using org-babel with R, and so far I think it's
  pretty great!  I'm still getting accustomed to org-babel workflow and
  am playing with available options.  I have a couple of questions:
 
  I noticed that C-c C-o (org-babel-open-src-block-result) always gives
  me an empty *Org-Babel Results* buffer, even if there's output printed
  to #+results section.  Is this a bug?  Am I doing something wrong?
 
  On a similar note, is there an option for the #+ results session to be
  completely suppressed?..  I can see situations where I might simply
  want to send the code to the inferior process and examine the results
  there using :results output :session, or perhaps I'm running the code
  just for the side effects.  It would be nice if I could say e.g.
  :results none.
 
  From the manual:
 
 The following results options indicate what happens with the results once 
 they 
 are collected.
 
  * silent
 The results will be echoed in the minibuffer but will not be inserted into 
 the 
 Org-mode buffer. E.g., :results output silent.

Thanks Erik.  It would be nice if section 14.9 of the Org manual could 
reference 
14.8.2.  In general, it would be nice if the org HTML documents could support 
the same outline folding cycling behavior that you see in Emacs buffers, 
otherwise it's difficult to see the surrounding context.

I'd still like to know what (org-babel-open-src-block-result) is supposed to 
do...  Haven't found that in the manual.


___
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] Help with org-link-translation-function

2011-01-04 Thread Leo Alekseyev
Hi All,
I am trying to achieve the following: any link of the form
[[/ssh:host:/path/to/file]] should, when followed, be translated to
[[/plink:host:/path/to/file]] (without being textually altered, of
course).

The reason for this is that Emacs Tramp under Windows refuses to
cooperate with OpenSSH and can't handle SSH links.  The only
workaround I've found is to use the plink protocol instead of SSH.

I think what I'm trying to achieve is possible with
org-link-translation-function, but my naive attempts haven't been
successful...  Any help would be greatly appreciated!

--Leo

___
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] Windmove keybindings pass-through

2010-12-20 Thread Leo Alekseyev
Thanks for the suggestion, but this is a non-solution.  My preference
would be to (a) in org-mode, move outline manipulation to e.g.
C-arrows from S-arrows, and if that is too difficult, then (b) get
rid of outline manipulation altogether.  I use S-arrows in windmove
orders of magnitude more often than I mess with my org outlines.
Surely there must be a way to customize org keybindings without having
to source-dive?..

--Leo

On Thu, Dec 16, 2010 at 3:20 PM, suvayu ali fatkasuvayu+li...@gmail.com wrote:
 On Thu, Dec 16, 2010 at 2:24 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 Optionally, it would be nice
 if I can map the shift-arrow functionality to something like M-arrows
 or C-arrows or C-M-arrows (whichever might be not taken / less
 useful).  However, getting rid of org-mode's stealing shift-arrows is
 a priority.  Any help is appreciated :)

 I would recommend (windmove-default-keybindings 'control) for
 `C-arrow'. That seems to be the modifier key least used by org-mode
 and least likely to be overridden.

 --
 Suvayu

 Open source is the future. It sets us free.


___
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] Windmove keybindings pass-through

2010-12-20 Thread Leo Alekseyev
To answer my own question: here's how you avoid clobbering the
windmove commands.  This method should probably be added to the org
manual section which discusses the (add-hook 'org-shiftup-final-hook
'windmove-up), etc commands.

;; don't clobber windmove bindings: code must be placed _before_ org
loads
;; also, the (add-hook 'org-shiftup-final-hook 'windmove-up), etc
lines don't seem to do squat
;; default disputed keys remap so that windowmove commands aren't
overridden
(setq org-disputed-keys '(([(shift up)] . [(meta p)])
  ([(shift down)] . [(meta n)])
  ([(shift left)] . [(meta -)])
  ([(shift right)] . [(meta +)])
  ([(meta return)] . [(control meta return)])
  ([(control shift right)] . [(meta shift +)])
  ([(control shift left)] . [(meta shift -)])))
(setq org-replace-disputed-keys t)


On Mon, Dec 20, 2010 at 12:37 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 Thanks for the suggestion, but this is a non-solution.  My preference
 would be to (a) in org-mode, move outline manipulation to e.g.
 C-arrows from S-arrows, and if that is too difficult, then (b) get
 rid of outline manipulation altogether.  I use S-arrows in windmove
 orders of magnitude more often than I mess with my org outlines.
 Surely there must be a way to customize org keybindings without having
 to source-dive?..

 --Leo

 On Thu, Dec 16, 2010 at 3:20 PM, suvayu ali fatkasuvayu+li...@gmail.com 
 wrote:
 On Thu, Dec 16, 2010 at 2:24 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 Optionally, it would be nice
 if I can map the shift-arrow functionality to something like M-arrows
 or C-arrows or C-M-arrows (whichever might be not taken / less
 useful).  However, getting rid of org-mode's stealing shift-arrows is
 a priority.  Any help is appreciated :)

 I would recommend (windmove-default-keybindings 'control) for
 `C-arrow'. That seems to be the modifier key least used by org-mode
 and least likely to be overridden.

 --
 Suvayu

 Open source is the future. It sets us free.



___
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] Windmove keybindings pass-through

2010-12-16 Thread Leo Alekseyev
As per the docs, I have (add-hook 'org-shiftup-final-hook
'windmove-up) and similar hooks set.  That way, shift-arrow keys work
as they do in windmove (that is, they switch between windows) _unless_
I am on an org heading.

I would like to make that behavior universal -- I want to disable any
sort of shift-arrow key handling in org-mode.  I switch windows way
more often than I manipulate headings.  Optionally, it would be nice
if I can map the shift-arrow functionality to something like M-arrows
or C-arrows or C-M-arrows (whichever might be not taken / less
useful).  However, getting rid of org-mode's stealing shift-arrows is
a priority.  Any help is appreciated :)

--Leo

___
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] Problems with hyperlinked files

2010-03-23 Thread Leo Alekseyev
Hi all,
I am unable to open locally linked files if I use angle brackets to
protect spaces, like so:

   [[file:E:\ebooks\math\Probability and statistics\The Elements of
Statistical Learning (2nd ed).pdf][Hastie et al]]

-- the echo area displays no such file: E:\ebooks\math\Probability
and statistics\The Elements of Statistical Learning (2nd ed).pdf
 note the right angle bracket here.  Generally, any file links
with angle brackets refuse to open.  Is this a known bug?...  is there
a patch?..  (Org mode 6.31a, emacs 23.1)


___
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] How to open pdf file links with evince under linux?..

2010-03-23 Thread Leo Alekseyev
When using org mode under windows, links to local PDF files bring up
Acrobat.  However, under linux, these links just spawn a new empty
buffer in emacs in fundamental mode.  How can I make PDF links bring
up evince?...


___
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] Problems with hyperlinked files

2010-03-23 Thread Leo Alekseyev

 I could reproduce this, but I don't know if this is really a bug.
 (I never heard of protecting spaces with angle brackets.)

Actually, it's right there in section 4.3 of the manual, last
sentence: if you need to remove ambiguities about the end of the
link, enclose them in angular brackets. 

 You do not have to protect spaces, because the URL is surrounded by the
 square brackets. I could only insert angle brackets into a link by
 editing it manually; when you edit a link with C-c C-l and enclose the
 URL in angle brackets, Org will automatically remove them.

Thanks, both these methods work -- although I still think it would be
nice if org mode could properly handle angle brackets inside square
ones; the motivation here is that often I just paste in file paths
instead of  using C-c C-l, and then I have to use angle brackets to
deal w/ spaces; if I later want to change it to an annotated link, it
would be nice not to have to strip the angle brackets before wrapping
it in square ones...


___
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] Search in headings before searching in leaves

2009-11-15 Thread Leo Alekseyev
I thought it would be a rather useful behavior for isearch to search
only in the displayed text.  That is to say, if I have a structure
such as

cursor is here
* Folded Heading 1...
* Folded Heading 2... [ whose body has 1 bazillion occurrences of SearchTerm  ]
* Folded Heading With SearchTerm...
* Folded Heading 4...

when I do an isearch I would like to jump to the heading (and if I
continue pressing C-s cycle back to the occurrences of SearchTerm
within Heading 2.

Are there existing hacks for org mode or outline mode that would
result in such behavior?..  If not, consider this a feature request :)

--Leo


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode


[Orgmode] Clocking TODO list subitems?..

2009-11-02 Thread Leo Alekseyev
I often structure my TODO lists like so:

* TODO a bunch of stuff
  - [ ] thing 1
  - [ ] thing 2
...

I would like to clock the time spent on thing1 and thing2, however it
seems that all clock operations only pertain to the main * TODO
heading.  Is there a way to clock the subitems?

Thanks,
--Leo


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode