[O] Repeaters in plain timestamps

[François Pinard]

Hi, Org people.

The manual, section "8.3.2 Repeated tasks", says:

   Some tasks need to be repeated again and again.  Org mode helps to
   organize such tasks using a so-called repeater in a DEADLINE, SCHEDULED,
   or plain timestamp.

Examples and directions given in the page are related to DEADLINE, and a
few words suggest that SCHEDULED works the same.  But the page does not
say how one may handle repeaters with plain timestamps.

I merely would like to update them so they show the date for the next
iteration, a bit like command "t d" already does on a DEADLINE repeater.

François

P.S. Someone on the list strongly advise me to avoid DEADLINE and
SCHEDULED unless they are really meaningful for me, and so did I.  But
for many cases of events which are not heavy (birthdays are a good
example), repeaters are still meaningful.

Re: [O] [PATCH] Recenter around #+begin_src when moving to previous/next code block

[Carsten Dominik]

On 15.9.2013, at 21:06, Sebastien Vauban  wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>>> When moving with C-c C-v C-n (or p) from one code block to the next (or
>>> previous), it's much better if the code block gets centered (vs hidden,
>>> forcing the user to scroll down, as it currently is).
>>> 
>>> This is the purpose of this easy patch.
>> 
>> I don't think this patch is the right thing - is feels different from
>> standard Emacs behavior.
> 
> I'm not sure to understand which Emacs behavior we would deviate from?  This
> is a jump, and it'd be better located at a readable place. Without it, you're
> forced to follow 90% of your jumps by a `C-l'...
> 
> And isn't it very similar to the patch I sent earlier this week regarding the
> recenter after the jump with `C-c C-x C-j'?  I'd more easily understand that
> both are either accepted or rejected, but not a mixed case.

I think the difference is the following:

org-clock-goto is a jump to a specific location and can be
expected to be far away, so it is OK to recenter the screen.
org-babel-next-src-block is more like forward paragraph, or
like a forward search.  It is possible that there are several
src blocks on a page.  Only moving the window content when
necessary gives a better sense of space and location.  This is
why such commands in Emacs only scroll when the target position
is off screen.

Regards

- Carsten

> 
> Anyway, I'm not bothered if it's not in Org, I can simply defadvice the
> functions (the `after' case). So I respect your decision, even if it puzzles
> me: it's just that having to manually recenter after almost all jumps do not
> feel like a right behavior of Org to me, for the beginners who can't make such
> defadvice on their own.
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Remove Org and Tbl from menubar for derived mode

[Christian Wittern]

On 2013-09-14 13:42 , Jambunathan K wrote:

 (add-hook 'org-mode-hook
   (lambda nil
 (local-unset-key [menu-bar Org])))

Thanks, if I do this for my derived mode, it does exactly what I need!

Christian

--
Christian Wittern, Kyoto

[O] Bug: org-set-property does not leave the point still [8.1.1 (release_8.1.1-29-gc5f2ae @ /home/mboes/.emacs.d/lisp/org/lisp/)]

[Mathieu Boespflug]

Hi,

consider the following very simple org file:

* TODO Thing1[]

where "[]" marks where the point is. Now if I C-S-RET to insert a new
TODO heading, I get

* TODO Thing1
* TODO []

Note that there is a trailing space at the end of the last line, as
expected. The problem is that if I now press C-c C-x p to set
a property (any property), then I end up with the following situation:

* TODO Thing1
* TODO
  :PROPERTIES:
  :PROP: val
  :END: []

The point is now at the end of the property drawer, rather than where it
was before. Notice how the trailing whitespace in the heading has
moreover been moved to after the property drawer.

Expected behaviour:

After C-c C-x p, I expect to get:

* TODO Thing1
* TODO []
  :PROPERTIES:
  :PROP: val
  :END:

This is exactly what I get if there is *no trailing whitespace* in the
TODO heading before hitting C-c C-x p. So it seems that the bug is that
org-set-property does not deal well with trailing whitespace.

This is a problem because it messes up setting properties by advising
org-insert-todo-heading, say to set a CREATED property automatically for
new TODO items.

Emacs  : GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.2)
 of 2013-08-07 on -mnt-storage-buildroots-staging-x86_64-eric
Package: Org-mode version 8.1.1 (release_8.1.1-29-gc5f2ae @
/home/mboes/.emacs.d/lisp/org/lisp/)

Re: [O] customizing preamble for org-preview-latex-fragment

[Nick Dokos]

Julien Cubizolles  writes:

> How can I change the default packages used in the latex file generated
> by org-preview-latex-fragment ?
>

They are produced by the function org-create-formula--latex-header,
which uses  the variables

  org-latex-default-packages-alist
  org-latex-packages-alist

to construct the header of the latex file. These two have the same
format: they are both lists of three-element sublists, where each
sublist is of the form:

("options" "package" snippet-flag)

Note the snippet-flag. See the docstrings of the variables for
more details.

If the package you want to include is missing completely from these two
lists, then add it to the second variable above with a snippet-flag
setting of ``t'':

--8<---cut here---start->8---
(add-to-list 'org-latex-packages-alist
 '("options" "package" t))
--8<---cut here---end--->8---

If the package is included in one of them (probably the default list)
but has been banned from being included in a snippet (by setting its
snippet-flag to nil), then unban it by setting the flag to ``t''. It's
probably best to do that through the customize interface.

Untested, but I can't imagine anything going wrong - famous last words
:-) ...

-- 
Nick

Re: [O] org-schedule vs org-time-stamp

[Paul Rudin]

"Sebastien Vauban" 
writes:

> Paul Rudin,
>
> Paul Rudin wrote:
>> I'm not clear on how these two are intended to be used. The former
>> prefixes the timestamp with "SCHEDULED:" but I'm not sure what practical
>> consequences this has. Items appear in the agenda either way.
>
> You should absolutely read the chapter 8 ("Dates and Times") of the Org
> manual.
>
> In summary, active timestamps only will appear on the day of the timestamp.
> It's good for meetings or birthdays or events that naturally only occur at a
> certain day.
>
> SCHEDULED timestamps indicate when you want to start working on a task. Such
> items will appear every day, on and on, in your agenda until you mark them
> done.
>

Ah yes, I see. Thanks.

Re: [O] org-schedule vs org-time-stamp

[Sebastien Vauban]

Paul Rudin,

Paul Rudin wrote:
> I'm not clear on how these two are intended to be used. The former
> prefixes the timestamp with "SCHEDULED:" but I'm not sure what practical
> consequences this has. Items appear in the agenda either way.

You should absolutely read the chapter 8 ("Dates and Times") of the Org
manual.

In summary, active timestamps only will appear on the day of the timestamp.
It's good for meetings or birthdays or events that naturally only occur at a
certain day.

SCHEDULED timestamps indicate when you want to start working on a task. Such
items will appear every day, on and on, in your agenda until you mark them
done.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] no fontification of #+BEGIN_LaTeX blocks

[Sebastien Vauban]

Julien Cubizolles wrote:
> org-src-fontify-natively doesn't fontify quoted LaTeX code like
>
> #+BEGIN_LaTeX
> #+END_LaTeX
>
> the same as it does for LaTeX src blocks like
>
> #+BEGIN_SRC latex
> #+END_SRC
>
> Why is that, and is there a way to get fontification for both ?

Yes, you have different faces: `org-block-background' and face `org-block'.

It's always better to have more than not enough. Up to you to customize them
so that they look the same, if that's what you want.

PS- Use `C-u C-x =' with point where you want to know which are the faces in
question. Then, M-x customize-face...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [PATCH] Recenter around #+begin_src when moving to previous/next code block

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
>> When moving with C-c C-v C-n (or p) from one code block to the next (or
>> previous), it's much better if the code block gets centered (vs hidden,
>> forcing the user to scroll down, as it currently is).
>> 
>> This is the purpose of this easy patch.
>
> I don't think this patch is the right thing - is feels different from
> standard Emacs behavior.

I'm not sure to understand which Emacs behavior we would deviate from?  This
is a jump, and it'd be better located at a readable place. Without it, you're
forced to follow 90% of your jumps by a `C-l'...

And isn't it very similar to the patch I sent earlier this week regarding the
recenter after the jump with `C-c C-x C-j'?  I'd more easily understand that
both are either accepted or rejected, but not a mixed case.

Anyway, I'm not bothered if it's not in Org, I can simply defadvice the
functions (the `after' case). So I respect your decision, even if it puzzles
me: it's just that having to manually recenter after almost all jumps do not
feel like a right behavior of Org to me, for the beginners who can't make such
defadvice on their own.

Best regards,
  Seb

-- 
Sebastien Vauban

[O] org-schedule vs org-time-stamp

[Paul Rudin]

I'm not clear on how these two are intended to be used. The former
prefixes the timestamp with "SCHEDULED:" but I'm not sure what practical
consequences this has. Items appear in the agenda either way.

Re: [O] [PATCH] Make the point visible when jumping to the mark

[Ian Kelling]

Updated patch. Tiny commit message format fix.
>From c46db11ffe0cc0f9b4fbd5a1ede2b4be0175 Mon Sep 17 00:00:00 2001
From: Ian Kelling 
Date: Sun, 15 Sep 2013 00:32:08 -0700
Subject: [PATCH] Make the point visible when jumping to the mark

* lisp/org.el: advise `pop-global-mark', `exchange-point-and-mark', and
  `pop-global-mark' with `org-show-context', as appropriate.

TINYCHANGE
---
 lisp/org.el | 21 +
 1 file changed, 21 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 8e970a1..30b87d9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -23903,6 +23903,27 @@ To get rid of the restriction, use \\[org-agenda-remove-restriction-lock]."
 			   (outline-invisible-p)))
(org-show-context 'bookmark-jump)))
 
+(eval-after-load "simple"
+  '(defadvice set-mark-command (after org-make-visible activate)
+ "Make the point visible with `org-show-context'."
+ (org-mark-jump-unhide)))
+
+(eval-after-load "simple"
+  '(defadvice exchange-point-and-mark (after org-make-visible activate)
+ "Make the point visible with `org-show-context'."
+ (org-mark-jump-unhide)))
+
+(eval-after-load "simple"
+  '(defadvice pop-global-mark (after org-make-visible activate)
+ "Make the point visible with `org-show-context'."
+ (org-mark-jump-unhide)))
+
+(defun org-mark-jump-unhide ()
+  "Make the point visible with `org-show-context' after jumping to the mark."
+  (and (derived-mode-p 'org-mode)
+   (outline-invisible-p)
+   (org-show-context 'mark-goto)))
+
 ;; Make session.el ignore our circular variable
 (defvar session-globals-exclude)
 (eval-after-load "session"
-- 
1.8.3.1

Re: [O] [PATCH] Fix incorrect time calculation for org-extend-today-until

[Ian Kelling]

Updated patch, fixed commit message format.
>From 0c23ccb9b00fd42f830f5a7472e2980b93c6040f Mon Sep 17 00:00:00 2001
From: Ian Kelling 
Date: Sun, 15 Sep 2013 08:03:24 -0700
Subject: [PATCH] Fix incorrect time calculation for `org-extend-today-until'

* lisp/org-clock.el (org-clock-get-sum-start): Fix bad date
  math, affecting mode line and clock tables.

TINYCHANGE
---
 lisp/org-clock.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 9f22562..3195dc1 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1368,10 +1368,12 @@ decides which time to use."
   (current-time))
  ((equal cmt "today")
   (setq msg-extra "showing today's task time.")
-  (let* ((dt (decode-time (current-time
-	(setq dt (append (list 0 0 0) (nthcdr 3 dt)))
-	(if org-extend-today-until
-	(setf (nth 2 dt) org-extend-today-until))
+  (let* ((dt (decode-time (current-time)))
+	 (hour (nth 2 dt))
+	 (day (nth 3 dt)))
+	(if (< hour org-extend-today-until) (setf (nth 3 dt) (1- day)))
+	(setf (nth 2 dt) org-extend-today-until)
+	(setq dt (append (list 0 0) (nthcdr 2 dt)))
 	(apply 'encode-time dt)))
  ((or (equal cmt "all")
 	  (and (or (not cmt) (equal cmt "auto"))
-- 
1.8.3.1

[O] Normalized Parse-Tree readable by other Lisps (Languages)

[Thorsten Jolitz]

Hi List,

I now got a first working version of code that transforms the parse-tree
produced by `org-element-parse-buffer' into a normalized form - in the
sense that special Emacs Lisp syntax is converted into plain standard
Lisp syntax:

The transformation steps can be seen in this code excerpt from the core
function

,---
| (defun iorg-normalize-parse-tree
|   (&optional data buffer-or-file &rest args) ... )
`---

,
|  [ ... ]
|  ;; do the transformation
|  (normalized-parse-tree-as-string
|   (iorg--fix-read-syntax
|(iorg--tag-org-data-element
| (iorg--add-children-list
|  (iorg--unwind-circular-list
|   (iorg--tag-elems-with-id-attributes
|(if map?
|(org-element-map
|dat typ fun inf 1st-match no-recur with-affil)
|  dat
| buf
| ;; upcase nil and t?
| (if preserve-nil-and-t-p
| normalized-parse-tree-as-string
|   (iorg--nil-and-t-to-uppercase normalized-parse-tree-as-string
`

The parse-tree produced by `org-element-parse-buffer' is optionally
mapped first, then

 1. each element is tagged with a :elem-id attribute
 2. circular list references are unwind, i.e. ':parent #2#' becomes ':parent
2' (with parent having :elem-id 2)
 3. in addition to its :parent attribute, each headline gets a :children
attribute (a list of sub-headlines)
 4. the top 'org-data' element is tagged with meta-data and a unique ID,
making each parse-tree unique and easy to reference.
 5. finally, other object references (#1=\"text\" and #1#) as well as read
syntax for text with properties (#(\"text\" 0 4 ...)) is fixed in the
sense that the three constructs are replaced by three functions:

- (hashtag '(\"text\" 0 4 ...))
- (hashtag-equal '(1 \"text\"))
- (enclosing-hashtag 1)

These should be defined as functions in the target language, e.g.
PicoLisp, and should produce the original Emacs Lisp read syntax when
evaluated.
 6. as a last optional step, nil and t are upcased to NIL and T

I can now directly import an org parse-tree into PicoLisp after this
transformation, as a PicoLisp list, and start working on it.

Since PicoLisp is a pure and simple List, I would guess that the transformed
parse-tree can be read as-is by other Lisps too (untested), and maybe by
non-lisps that can read lists. The only remaining special syntax is ':keyword'.

Thereby one could avoid to write many Org-mode parsers for other Lisps
(languages), but rather use org-element (the de-facto specification of
Org-mode) for parsing and then import the transformed parse-tree as described.

The code is here, still under development:
[[https://github.com/tj64/iorg/blob/master/picoLisp/iorg/el/iorg.el][iorg.el]]

PS 
I know I could have used ox.el for the transformation, but decided to
work directly on the parse-tree - for the good or for the bad, who
knows...

--
cheers,
Thorsten

[O] [PATCH] Fix incorrect time calculation for org-extend-today-until

[Ian Kelling]

During the extra hours of org-extend-today-until, when
org-clock-mode-line-total is 'today, the clocked time shown in the
modeline is wrong. It ignores all previously clocked time, when it
should add them starting from the past day beyond
org-extend-today-until hours.  This also affects clock tables.

The problem can be reproduced in emacs with the following code,
as long as the current time is not between 11 PM and 12 AM:

  (progn
(require 'org-clock)
(setq org-clock-mode-line-total 'today)
(setq org-extend-today-until 23)
(format-time-string "%a %D %l:%M %p" (org-clock-get-sum-start)))

expected result:
A date of yesterday, time of 11:00 PM

Actual result:
A date of today, time of 11:00 PM

Note this patch only fixes a bug where org-extend-today-until
is already used.


- Ian Kelling
>From 619572e221cafc17f0a1c33654eb22d7ca5f4d89 Mon Sep 17 00:00:00 2001
From: Ian Kelling 
Date: Sun, 15 Sep 2013 08:03:24 -0700
Subject: [PATCH] Fix incorrect time calculation for org-extend-today-until

* lisp/org-clock.el Fix bad date math. Affects mode line and
  clock tables.

TINYCHANGE
---
 lisp/org-clock.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 9f22562..3195dc1 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1368,10 +1368,12 @@ decides which time to use."
   (current-time))
  ((equal cmt "today")
   (setq msg-extra "showing today's task time.")
-  (let* ((dt (decode-time (current-time
-	(setq dt (append (list 0 0 0) (nthcdr 3 dt)))
-	(if org-extend-today-until
-	(setf (nth 2 dt) org-extend-today-until))
+  (let* ((dt (decode-time (current-time)))
+	 (hour (nth 2 dt))
+	 (day (nth 3 dt)))
+	(if (< hour org-extend-today-until) (setf (nth 3 dt) (1- day)))
+	(setf (nth 2 dt) org-extend-today-until)
+	(setq dt (append (list 0 0) (nthcdr 2 dt)))
 	(apply 'encode-time dt)))
  ((or (equal cmt "all")
 	  (and (or (not cmt) (equal cmt "auto"))
-- 
1.8.3.1

Re: [O] [export] Easy way to make children of Beamer frames generate list items?

[John Hendy]

On Sun, Sep 15, 2013 at 5:57 AM, Suvayu Ali  wrote:
> On Sat, Sep 14, 2013 at 09:49:18PM -0500, John Hendy wrote:
>>
>> In any case, I'm mostly in agreement that Org's changed and thus the
>> file structure should change... but not all of us use the git and/or
>> snapshot Org version with regular frequency and thus I expect a fair
>> amount of trickling in of users surprised at the incompatibility.
>
> As I outlined towards the end of my earlier message, it is not possible
> (at least easily with some config magic) to get back the old behaviour
> with the new exporter.  Maybe then we should have an FAQ stating so and
> outlining how one could make the format switch (again, a possible path
> provided in my previous message).
>

My response was geared toward "Is there a handy workaround in the mean
time so that Christoph can get quicker access to his materials" than
"Can we program Org-mode to handle all legacy forms of input to the
exporter." Sorry if it seemed that I was requesting an "official" fix.
It was more of a prompt for someone clever with LaTeX and/or the new
exporter guts to possibly give him some magic to convert lower
headlines to list while he changes over vs. simply saying, "No. You
can't do that."

Now I understand it really just isn't possible at all, and that's a
good answer to have as well :)

> Do you think that would be a good idea?  If so, I'll add a short FAQ
> with a pointer to this thread for now.  We can clean it up later.

I'm not sure on this. I was thinking about your answer some more, and
perhaps I'm trying to be empathetic with those who aren't subscribed
to the mailing list and thus weren't submerged in constant discussions
about the new exporter, opportunities to try it on an experimental
branch, tons of warnings that "it's coming," and so on. Then again, I
countered myself with realizing that it's not like extreme computer
novices are installing this on a daily basis -- each of us probably
had to stumble on it when looking for outlining program alternatives,
either already knew or endured Emacs to use Org (like me), and are
aware of things like mailing lists and StackOverflow.

So... maybe my concern is unfounded. Org users are most likely more
familiar than many with reading manuals/help files, seeking help, etc.
I think there's a decent amount out there about the new exporter, but
it can seem a bit scattered between the manual and Worg. When I wanted
to constantly refer back to the upgrade instructions page that
Bastien/Nicolas created, I was constantly googling "upgrade Org 8.0."
At the time, I don't think it worked with just "upgrade" and no
version. So things like that make me wonder how easy it is to find
these things without sort of knowing where they are.

Alright -- enough wind out of me. All that said, yes, more info and
references/links can't hurt. That's probably the most helpful thing
for newcomers/non-mailing-list people -- something smack-dab on the
Org-mode webpage about FAQs or troubleshooting.


Thanks for the explanations and dialog!
John

>
> Cheers,
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>

Re: [O] [export] Should sidewaystable option automatically add rotating package?

[Nicolas Girard]

2013/9/15 Carsten Dominik :
>
> Does anyone know about conflicts arising from loading wrapfig and rotating?
>


Not that I know of.

[O] customizing preamble for org-preview-latex-fragment

[Julien Cubizolles]

How can I change the default packages used in the latex file generated
by org-preview-latex-fragment ?

Julien.

Re: [O] removing "Figure x" from a caption

[Matt Price]

On Sat, Sep 14, 2013 at 10:28 AM, Eric S Fraga  wrote:
> Matt Price  writes:
>> Unfortunatey, I'm exporting to HTML (deck.js) not Beamer.  I guess I
>> still on't understand how to use beamer -- I tried it just now and it
>> seemed to produce a very plain pdf, not a slideshow at all.  sigh.
>
> It may or may not have worked.  I cannot tell from your comment.  It
> depends on what you mean by "plain PDF" and "slideshow".
>
> Beamer is a document style and a collection of macros for LaTeX.  The
> output of LaTeX will be a PDF file typically.  For a beamer document,
> the PDF output is a set of pages where each page corresponds to a single
> "slide".  The slide show is the sequence of these PDF pages.  Whether
> this corresponds to your meaning of a slide show, I cannot tell.
>
> I hope that makes some sort of sense...

Yes, it does make sense, thank you Eric.  The PDF document produced
was not a one-heading-per-page slideshow, but a more ordinary PDF with
continuous flow from page to page.  I have no doubt there are numerous
errors in my setup -- I don't use LaTex at all so I haven't realy
investigated what woud be necesary to fix them.

Thanks!
Matt

>
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.1.1-17-gf76e8c
>

Re: [O] [export] Easy way to make children of Beamer frames generate list items?

[Suvayu Ali]

Hi Christoph and others,

On Sun, Sep 15, 2013 at 01:41:32PM +0200, Carsten Dominik wrote:
> 
> On 15.9.2013, at 13:07, Christoph LANGE  wrote:
> 
> > Dear all,
> > 
> > many thanks for your extensive feedback.  You more than answered my
> > question: I conclude for myself that it is not a good idea to use Org
> > tree entries if one wants list items.  This was "accidentally" supported
> > by the old exporter, but with the new exporter it makes sense to
> > manually (or automatically, with some scripting or macro-recording)
> > convert tree entries to plain lists.  This is what I will now do with my
> > Beamer presentations.
> 
> Dear Christopher,
> 
> thank you for this summary, which will help others to see
> the balance that had to be struck with the new exporter.

I added these entries on Worg.  Do you think this helps future users
with similar questions?




Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Jumping from source block to Org block ...

[Eric Schulte]

aditya siram  writes:

> I've included new versions of both patches with most of the changes you
> suggested. I guess you'll apply the longer one when you've been notified by
> the FSF?
>

Once you receive your confirmation from the FSF please let Bastien or
Carsten know, and they'll add you to the list of contributors at [1].
Then I'll apply this patch.

>
> Is this a one-time deal that covers future patches or do I have to do this
> with every patch that's over 15 lines long?
>

This is a one time deal that covers not only future patches to Org-mode,
but future patches to any part of Emacs.

Thanks again,

>
> Thanks!
> -deech
>
>
> On Sat, Sep 14, 2013 at 10:53 AM, aditya siram wrote:
>
>> Thanks for your feedback and your work on org-babel!
>>
>> Oops, the maintain-point was a hold-over and isn't actually used in the
>> code. I'll remove it.
>>
>> I will incorporate your suggestions.
>>
>> However, regarding the cascading if statements, how would I use `cond`
>> when the predicates are `and`ed and when I need different behavior in the
>> else cases?
>>
>>
>> On Sat, Sep 14, 2013 at 10:44 AM, Eric Schulte wrote:
>>
>>> aditya siram  writes:
>>>
>>> > Attached is a patch that fixes a bug with jumping from source block
>>> back to
>>> > the Org file. The problem is that the current detangling behavior does
>>> not
>>> > take the :padlline flag into account. This stopped.
>>> >
>>> > Hopefully this is helpful to others ...
>>> > -deech
>>> >
>>>
>>> Hi deech,
>>>
>>> Please see the Org-mode contribution instructions at [1].  A patch of
>>> this length would require that you fill out the FSF copyright assignment
>>> paperwork before the patch could be applied.
>>>
>>> As for the content of the patch, my only question is why do you add an
>>> optional maintain-point argument to `org-babel-tangle-jump-to-org'?  Is
>>> there ever a case when you would not want to maintain the point?
>>>
>>> Of much less importance I have a couple of stylistic notes about the
>>> code which are largely unrelated to its functionality and are included
>>> to make future changes easier to read and because I'm a cranky old lisp
>>> programmer.
>>>
>>> - you should indent the code s.t. no lines are longer than 79 characters
>>> - comments which float after code (e.g., ";; end of first delimiter")
>>>   should only use 1 ; character
>>> - the series of if statements (if should-be-padded... if
>>>   possibly-padded... if actually-padded...) would be more legible if
>>>   written as a single `cond' form.
>>>
>>> Thanks for this change.  It appears to pass all tests, so after the
>>> above have been addressed I'd be very happy to apply it.
>>>
>>> Thanks for contributing, this is much appreciated!
>>>
>>> If you have the time and inclination to include a test which fails
>>> without this patch applied that would be icing on the cake.
>>>
>>> Best,
>>>
>>> Footnotes:
>>> [1]  http://orgmode.org/worg/org-contribute.html
>>>
>>> --
>>> Eric Schulte
>>> https://cs.unm.edu/~eschulte
>>> PGP: 0x614CA05D
>>>
>>
>>
>
>


Footnotes: 
[1]  http://orgmode.org/worg/org-contribute.html

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] Jumping from source block to Org block ...

[Eric Schulte]

aditya siram  writes:

> Thanks for your feedback and your work on org-babel!
>

I'm happy you're finding it useful.

>
> Oops, the maintain-point was a hold-over and isn't actually used in the
> code. I'll remove it.
>
> I will incorporate your suggestions.
>
> However, regarding the cascading if statements, how would I use `cond` when
> the predicates are `and`ed and when I need different behavior in the else
> cases?
>

Maybe cascading if statements are the best thing here.  Perhaps changing
the order of the then/else branches could ensure the conditionals are
still visible from the branches, but this is an exceedingly minor point.

I guess any use of cond could easily get overly verbose.  Please
disregard this suggestion.

Cheers,

>
>
> On Sat, Sep 14, 2013 at 10:44 AM, Eric Schulte wrote:
>
>> aditya siram  writes:
>>
>> > Attached is a patch that fixes a bug with jumping from source block back
>> to
>> > the Org file. The problem is that the current detangling behavior does
>> not
>> > take the :padlline flag into account. This stopped.
>> >
>> > Hopefully this is helpful to others ...
>> > -deech
>> >
>>
>> Hi deech,
>>
>> Please see the Org-mode contribution instructions at [1].  A patch of
>> this length would require that you fill out the FSF copyright assignment
>> paperwork before the patch could be applied.
>>
>> As for the content of the patch, my only question is why do you add an
>> optional maintain-point argument to `org-babel-tangle-jump-to-org'?  Is
>> there ever a case when you would not want to maintain the point?
>>
>> Of much less importance I have a couple of stylistic notes about the
>> code which are largely unrelated to its functionality and are included
>> to make future changes easier to read and because I'm a cranky old lisp
>> programmer.
>>
>> - you should indent the code s.t. no lines are longer than 79 characters
>> - comments which float after code (e.g., ";; end of first delimiter")
>>   should only use 1 ; character
>> - the series of if statements (if should-be-padded... if
>>   possibly-padded... if actually-padded...) would be more legible if
>>   written as a single `cond' form.
>>
>> Thanks for this change.  It appears to pass all tests, so after the
>> above have been addressed I'd be very happy to apply it.
>>
>> Thanks for contributing, this is much appreciated!
>>
>> If you have the time and inclination to include a test which fails
>> without this patch applied that would be icing on the cake.
>>
>> Best,
>>
>> Footnotes:
>> [1]  http://orgmode.org/worg/org-contribute.html
>>
>> --
>> Eric Schulte
>> https://cs.unm.edu/~eschulte
>> PGP: 0x614CA05D
>>

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] [export] Easy way to make children of Beamer frames generate list items?

[Carsten Dominik]

On 15.9.2013, at 13:07, Christoph LANGE  wrote:

> Dear all,
> 
> many thanks for your extensive feedback.  You more than answered my
> question: I conclude for myself that it is not a good idea to use Org
> tree entries if one wants list items.  This was "accidentally" supported
> by the old exporter, but with the new exporter it makes sense to
> manually (or automatically, with some scripting or macro-recording)
> convert tree entries to plain lists.  This is what I will now do with my
> Beamer presentations.

Dear Christopher,

thank you for this summary, which will help others to see
the balance that had to be struck with the new exporter.

Regards

- Carsten

> 
> Cheers,
> 
> Christoph
> 
> -- 
> Christoph Lange, School of Computer Science, University of Birmingham
> http://cs.bham.ac.uk/~langec/, Skype duke4701
> 
> → Mathematics in Computer Science Special Issue on “Enabling Domain
>  Experts to use Formalised Reasoning”; submission until 31 October.
>  http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [export] Easy way to make children of Beamer frames generate list items?

[Christoph LANGE]

Dear all,

many thanks for your extensive feedback.  You more than answered my
question: I conclude for myself that it is not a good idea to use Org
tree entries if one wants list items.  This was "accidentally" supported
by the old exporter, but with the new exporter it makes sense to
manually (or automatically, with some scripting or macro-recording)
convert tree entries to plain lists.  This is what I will now do with my
Beamer presentations.

Cheers,

Christoph

-- 
Christoph Lange, School of Computer Science, University of Birmingham
http://cs.bham.ac.uk/~langec/, Skype duke4701

→ Mathematics in Computer Science Special Issue on “Enabling Domain
  Experts to use Formalised Reasoning”; submission until 31 October.
  http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/

Re: [O] [export] Easy way to make children of Beamer frames generate list items?

[Suvayu Ali]

On Sat, Sep 14, 2013 at 09:49:18PM -0500, John Hendy wrote:
> 
> In any case, I'm mostly in agreement that Org's changed and thus the
> file structure should change... but not all of us use the git and/or
> snapshot Org version with regular frequency and thus I expect a fair
> amount of trickling in of users surprised at the incompatibility.

As I outlined towards the end of my earlier message, it is not possible
(at least easily with some config magic) to get back the old behaviour
with the new exporter.  Maybe then we should have an FAQ stating so and
outlining how one could make the format switch (again, a possible path
provided in my previous message).

Do you think that would be a good idea?  If so, I'll add a short FAQ
with a pointer to this thread for now.  We can clean it up later.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

[O] [PATCH] Make the point visible when jumping to the mark

[Ian Kelling]

An example of the problem:

* headline-1
** one of many headlines I want to remain folded...
** headline
*** headline
The point starts here. I set a mark on this line.
Then I fold headline-1. This becomes invisible.
* headline-2
I move the point here. After I'm done here, I want to go back to my
mark. I do C-u C-space (pop-to-mark-command), but it doesn't go to the
mark. Instead, it takes me to the end of the still folded
headline-1. To get back to my mark without globally unfolding
everything requires tediously unfolding each headline and sub-headline
until the marked location is exposed.

There are some other non-org commands that would have this same
problem (isearch, bookmark-jump, save-place), but org-mode has code to
fix them. org-mark-ring-goto also handles this. I followed those examples
and wrote a patch. It is attached.

- Ian Kelling


>From 066595dd9350f06a1df2e99a341f96782ac8dfed Mon Sep 17 00:00:00 2001
From: Ian Kelling 
Date: Sun, 15 Sep 2013 00:32:08 -0700
Subject: [PATCH] Make the point visible when jumping to the mark

* lisp/org.el advise `pop-global-mark', `exchange-point-and-mark', and
  `pop-global-mark' with `org-show-context', as appropriate.

TINYCHANGE
---
 lisp/org.el | 21 +
 1 file changed, 21 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 8e970a1..30b87d9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -23903,6 +23903,27 @@ To get rid of the restriction, use \\[org-agenda-remove-restriction-lock]."
 			   (outline-invisible-p)))
(org-show-context 'bookmark-jump)))
 
+(eval-after-load "simple"
+  '(defadvice set-mark-command (after org-make-visible activate)
+ "Make the point visible with `org-show-context'."
+ (org-mark-jump-unhide)))
+
+(eval-after-load "simple"
+  '(defadvice exchange-point-and-mark (after org-make-visible activate)
+ "Make the point visible with `org-show-context'."
+ (org-mark-jump-unhide)))
+
+(eval-after-load "simple"
+  '(defadvice pop-global-mark (after org-make-visible activate)
+ "Make the point visible with `org-show-context'."
+ (org-mark-jump-unhide)))
+
+(defun org-mark-jump-unhide ()
+  "Make the point visible with `org-show-context' after jumping to the mark."
+  (and (derived-mode-p 'org-mode)
+   (outline-invisible-p)
+   (org-show-context 'mark-goto)))
+
 ;; Make session.el ignore our circular variable
 (defvar session-globals-exclude)
 (eval-after-load "session"
-- 
1.8.3.1