[Orgmode] Re: [PATCH] Indent code with TAB in Org buffer

[Dan Davison]

Carsten Dominik  writes:

> On Aug 15, 2010, at 8:43 AM, Dan Davison wrote:
>
>> With this patch TAB in a code block aligns the code according to the
>> major mode. The macro could be used to do the same thing for other
>> commands (i.e. allow other commands to be invoked in the Org buffer,
>> but
>> actually carried out in the code buffer.)
>>
>> Patch attached and in branch src-block-tab at
>> g...@github.com:dandavison/org-devel.git.
>>
>> diff --git a/lisp/org-src.el b/lisp/org-src.el
>> index baa2b11..fc15a83 100644
>> --- a/lisp/org-src.el
>> +++ b/lisp/org-src.el
>> @@ -435,6 +435,19 @@ the fragment in the Org-mode buffer."
>>   (message "%s" msg)
>>   t)))
>>
>> +(defmacro org-src-do-in-edit-buffer (&rest body)
>> +  "Evaluate BODY in edit buffer if there is a code block at point.
>> +Return t if a code block was found at point, nil otherwise."
>> +  `(when (org-edit-src-code)
>
> Wow, an excursion to the temp buffer for every TAB call
> in a source code block?
>
> Sounds heavy.  But I see that it could be nice together with
> the new fontification stuff.  My gut feeling would be to have
> both of these feature off by default.  But I have not tried
> them yet.

Hi Carsten,

In a small code block the TAB is actually not bad at all, but in a big
one there's a delay (that's worst case scenario: a netbook with an atom
processor).

I think it's clear that automatic fontification as you type by emacs
font-lock should be turned off by default. We could consider
fontification of code blocks e.g. on start up, and when
folding/unfolding, but let's discuss that in a separate thread.

We can go one further with the tab command, and supply a general
mechanism for calling major mode commands from the src buffer (patch
attached):

(defun org-src-do-key-sequence-in-edit-buffer (&optional key)
  "Read key sequence and execute the command in edit buffer."
  (interactive)
  (org-src-do-in-edit-buffer
   (call-interactively
(key-binding (or key (read-key-sequence nil))

So I'm proposing to bind that within the org-babel keymap (currently 
C-c C-v x, and C-c C-v C-x). That way for example:

- C-c C-v C-x TAB :: indent code natively

and with an interactive R session:

- C-c C-v C-x C-c C-c :: `ess-eval-function-or-paragraph-and-step'

I've included a variable `org-src-indent-natively' to control the native
TAB by default (currently defaulting to off, seeing as the C-v C-v x
alternative is always available).

Eric and I are planning on providing the inverse also: exposing the
babel keymap when in the edit buffer.

Dan

patch attached and at g...@github.com:dandavison/org-devel.git[1] branch 
src-block-tab

diff --git a/lisp/ob-keys.el b/lisp/ob-keys.el
index e9ba3d9..f953110 100644
--- a/lisp/ob-keys.el
+++ b/lisp/ob-keys.el
@@ -77,7 +77,9 @@ functions which are assigned key bindings, and see
 ("z" . org-babel-switch-to-session)
 ("\C-a" . org-babel-sha1-hash)
 ("a" . org-babel-sha1-hash)
-("h" . org-babel-describe-bindings))
+("h" . org-babel-describe-bindings)
+("\C-x" . org-src-do-key-sequence-in-edit-buffer)
+("x" . org-src-do-key-sequence-in-edit-buffer))
   "Alist of key bindings and interactive Babel functions.
 This list associates interactive Babel functions
 with keys.  Each element of this list will add an entry to the
diff --git a/lisp/org-src.el b/lisp/org-src.el
index baa2b11..c9e6f73 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -321,6 +321,8 @@ the edited version. Optional argument CONTEXT is used by
  (if (eq context 'edit) (delete-other-windows))
  (org-switch-to-buffer-other-window buffer)
  (if (eq context 'exit) (delete-other-windows)))
+('switch-invisibly
+ (set-buffer buffer))
 (t
  (message "Invalid value %s for org-src-window-setup"
 	  (symbol-name org-src-window-setup))
@@ -435,6 +437,31 @@ the fragment in the Org-mode buffer."
   (message "%s" msg)
   t)))
 
+(defmacro org-src-do-in-edit-buffer (&rest body)
+  "Evaluate BODY in edit buffer if there is a code block at point.
+Return t if a code block was found at point, nil otherwise."
+  `(let ((org-src-window-setup 'switch-invisibly))
+ (when (org-edit-src-code)
+   ,@body
+   (org-edit-src-exit) t)))
+
+(defun org-src-do-key-sequence-in-edit-buffer (&optional key)
+  "Read key sequence and execute the command in edit buffer."
+  (interactive)
+  (org-src-do-in-edit-buffer
+   (call-interactively
+(key-binding (or key (read-key-sequence nil))
+
+(defvar org-src-indent-natively nil
+  "If non-nil, TAB in a code block indents the code as if it were
+called in the edit buffer.")
+
+(defun org-src-tab-command ()
+  "Do what TAB does in the edit buffer for code block at point."
+  (and org-src-indent-natively
+   (org-src-do-key-sequence-in-edit-buffer (kbd "TAB"
+
+(add-hook 'org-tab-first-hook 'org-src-tab-command)
 (defun org-edit-src-find-region-and-lang ()
   "Find the region and language for a local edit.
 Return a list wi

[Orgmode] See total effort in my agenda

[Flavio Souza]

Hi everybody!

I need a little help with org agenda:

I'd like to see in my daily view or weekly view my effort.

The idea is to see how much time is already comitted with my tasks and
projects.

Is there an easy way to do that?

Regards,

-- 
Flavio Souza
http://www.flaviosouza.org


___
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: [ANN] List improvement v.2

[Glauber Alex Dias Prado]

Carsten Dominik  writes:

> On Aug 15, 2010, at 10:45 AM, Glauber Alex Dias Prado wrote:
>
>> Carsten Dominik  writes:
>>
>>> Hi Nicolas,
>>>
>>> I have finally started to look at your changes to the list
>>> implementation.
>>> Lots of it is very good!  I like for example that TAB indentation now
>>> works
>>> a lot better.
>>>
>>> Here are a few problems I noted so far:
>>>
>>> 1 Error when pressing M-RET in second line after list
>>> ~~
>>>
>>>  - Example item1
>>>  - Exmaple item2
>>>
>>> With cursor position at "@", M-RET throws an error
>>>
>>> 2 Incompatibility 1
>>> 
>>>  - Example 1
>>>  - Ex 2
>>>
>>>  This used to be outside of the list.  The HTML exporter still treats
>>>  it as being outside of the list.  The LaTeX exporter treats it as
>>>  part of the last item.  If I add a second empty line, then both
>>>  exporters handle it well.
>>>
>>>  So this breaks with documented properties of the lists.  I guess
>>>  this is unavoidable because this is just how the new list definition
>>>  works.  But it will break existing documents when exported to LaTeX
>>>
>>> 3 Text between two sublists
>>> 
>>>
>>>  - Ex1
>>>  - Ex2
>>>- Ex2a
>>>- Ex2b
>>>Some text between two sublists
>>>- A new list starts
>>>
>>> This always was an inconsistency between HTML and LaTeX export, and
>>> it
>>> still is now.  There seems to be no way now to do what I intend here,
>>> putting some text between two lists.
>>
>> preferably not only for lists, something like:
>>
>> * some stuff
>>  quick intro
>> ** nest 1
>>   stuff about nest1
>>  now what i dont think is possible and dont even know if it is usually
>>  done on latex something that belongs to some stuff and is in between
>>  nest 1 and 2, i find it usefull for commenting on nests(thats why
>>  i miss it) and looks like it is the same thing you are wishing for
>> lists?
>>  My use case for this is mostly note-taking.
>> ** nest 2
>>   stuff about nest2
>>
>> could be also usefull, if it makes sense, btw the lists are taking
>> shape :).
>
> This has been discussed here a million times and it is not going to
> happen.
>
> - Carsten

Sorry i cant catchup on everything. I was thinking here could this be
done as footnotes on org headings? the look certainly wouldnt be the
same but perhaps the effect would, am gonna try it later, never played
with footnotes export.

cheers,
glauber.

>
>>
>>>
>>>
>>> On Jul 22, 2010, at 11:08 PM, Nicolas Goaziou wrote:
>>>
 Hello,

 Here is a new, and probably final feature-wise, suggestion of list
 improvement in Org Mode.

 Table of Contents
 =
 1 What is it about again ?
 2 Is that all ?
   2.1 Preserving blank lines
   2.2 Timer lists
   2.3 Automatic rules
   2.4 `org-apply-on-list'
 3 Where can it be tried ?


 1 What is it about again ?
 ~~~

 I redefined lists in Org Mode. Lists start, as before, at a bullet
 (whose true regexp is at `org-item-beginning-re'), and end at either
 `org-list-end-regexp', a new headline, or, obviously, end of buffer.

 `org-list-end-regexp' is customizable and defaults to 2 blank lines,
 but `org-empty-line-terminates-plain-lists' has precedence over it.
 Moreover, any `org-list-end-regexp' found in special blocks does not
 end list. Here are two examples of valid lists:

 Case 1: `org-list-end-regexp' is at default value


 - First item

   - Sub item

 #+BEGIN_EXAMPLE
 Two blank lines below


 Two blank lines above
 #+END_SRC

   - Last sub item


 List has ended at the beginning of this line.

 Case 2: `org-list-end-regexp' is "^[ \t]*___[ \t]*\n"


 - item 1
 - item 2
   - sub-item
   - sub-item 2
 - item 3
 __
 List has ended at the beginning of this line.

 Now, Org Mode knows when a list has ended and how to indent line
 accordingly. In other words, you can `org-return-indent' three times
 to exit a list and be at the right column to go on with the text.

 This new definition is also understood by exporters (LaTeX, DocBook,
 HTML or ASCII) and `org-list-end-regexp' will appear in source as a
 blank line, whatever its value is (as long as it starts with a caret
 and ends with a newline character, as specified in doc-string).

 Another advantage is that you can have two lists of different types
 in a row like in the example below:


 - item
 - item


 1. item
 2. item

 In this example, you can move (or cycle, or indent) items in the
 second list without worrying about changing the first one.

 2 Is that all ?
 

 Yes and no. I tried as much as possible to keep compatibility 

Re: [Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles

[David Maus]

Sébastien Vauban wrote:

>Just to say I'm back online -- after a week holiday and an almost nil access
>to the newsgroups.

>Thanks a lot for trying to get Gnus better behaving in face of slow servers
>like Courier...

>Do "you" want me to test something special to move things forward?

Okay, could you try the attached patch?  It is based on current master
and tries to look up the article number (uid) in NOVCACHE and falls
back to UID SEARCH when the message is not cached.

To make a message enter Gnus' cache you might to modify
`gnus-cache-enter-articles'.  The cache setting I used to test the
patch are:

,[ gnus.el ]
| (setq nnimap-nov-is-evil nil)
| (setq gnus-use-cache t)
| (setq gnus-cache-enter-articles '(ticked dormant unread read))
`

NOTE: This patch is deliberately not attached as text/plain to avoid
the patchtracker catching it (no proper commit message and all).

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


0001-Try-fix-1.patch
Description: Binary data
___
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] Re: keys and command name info

[Andreas Röhler]

Am 15.08.2010 09:39, schrieb Carsten Dominik:


On Aug 15, 2010, at 9:37 AM, Carsten Dominik wrote:



On Aug 13, 2010, at 9:30 PM, Andreas Röhler wrote:


Am 11.08.2010 12:05, schrieb Carsten Dominik:


On Aug 9, 2010, at 9:28 PM, Dan Davison wrote:


Dan Davison  writes:


Gregor Zattler  writes:


Hi Andreas, org-mode developers,
* Andreas Burtzlaff  [09. Aug. 2010]:

Carsten Dominik  writes:

I have put a version of the manual as modified by Andreas here:

http://orgmode.org/org-manual-with-command-names.pdf

Not all the command names are in there, but quite a few are.
I'd like to hear from more people

- if they would like to have the names there (i.e. if it would
help them finding a command)


I would like the command names in the manual.

- Emacs-lisp has a lovely tradition of naming functions *very*
descriptively and not being afraid to use long names in the interests
of accuracy. It's a shame to lose all that by displaying only key
sequences. It's a linguistic world of its own and I like being
exposed
to it.
- While one can do C-h k, that's not the same as the way one
learns the
function names by skimming the manual


Also, it does not add length to the HTML version of the manual,
because
the key sequences are already on a line of their own. And the same is
true for a certain proportion of the pdf entries (when the key
sequence
is long, then it seems to go on its own line).





- if the position (first thing in the command description)
is right, or if it would be better to have it
- last thing in the description
- or after the first sentence, this is how the GNUS manual
does it.


I definitely would want them out on a line of their own with the key
sequence. I liked the right-aligned model.

Or if not right-aligned, is it possible not to have the comma?
Maybe a
different font?


I also like the position on the key line best. So if there is a
more-or-less
general agreement that we should get the names in, this would be my
preferred
location as well. I knot that this is different from what the emacs
and gnus manuals do - but I still think that a solution like this would
be better.

Andreas, can you be bothered to rework the patch?

Unfortunately I have no idea if/how the right-aligned model could be
made to
work. So I think the safest way to do this would be to introduce the
macro,
and we can then work on the macro to get the formatting right, and also
to do the
key and function index stuff fully automatically.

Here is my proposal for now:

@macro orgcmd{key,command}
@kindex \key\
@findex \command\
@item \key\ @ @ @ @ @ @ @ @ @ @ @r{(}\comma...@r{)}
@end macro

And then define keys/commands like this:

@table @kbd
.
@orgc...@key{tab}, org-cycle}
Here follows the description of the command

@end table

- Carsten



[ ... ]

Hi Carsten,

attached a sreenshot, how it comes out for C-c C-b.
Doesn't look ok for me, as back-tick and quote are uncommon that way.


Hi Andreas, you are correct, this does not look right.
Seems like we will have to make the table ins @asis and
then have the macro apply the formatting. Sigh... :)


If you do insert all the macro calls with the command names, I will take
care of the formatting.

- Carsten



Hi,

will do that.

Let us check nonetheless a working example first.

While trying to  put @asis at the right place, I get error messages and 
it refuses to compile.


Could you re-write the example for me?

Sorry being that stupid :-)

Andreas




___
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: [ANN] List improvement v.2

[Carsten Dominik]

On Aug 15, 2010, at 10:45 AM, Glauber Alex Dias Prado wrote:


Carsten Dominik  writes:


Hi Nicolas,

I have finally started to look at your changes to the list
implementation.
Lots of it is very good!  I like for example that TAB indentation now
works
a lot better.

Here are a few problems I noted so far:

1 Error when pressing M-RET in second line after list
~~

 - Example item1
 - Exmaple item2

With cursor position at "@", M-RET throws an error

2 Incompatibility 1

 - Example 1
 - Ex 2

 This used to be outside of the list.  The HTML exporter still treats
 it as being outside of the list.  The LaTeX exporter treats it as
 part of the last item.  If I add a second empty line, then both
 exporters handle it well.

 So this breaks with documented properties of the lists.  I guess
 this is unavoidable because this is just how the new list definition
 works.  But it will break existing documents when exported to LaTeX

3 Text between two sublists


 - Ex1
 - Ex2
   - Ex2a
   - Ex2b
   Some text between two sublists
   - A new list starts

This always was an inconsistency between HTML and LaTeX export, and  
it

still is now.  There seems to be no way now to do what I intend here,
putting some text between two lists.


preferably not only for lists, something like:

* some stuff
 quick intro
** nest 1
  stuff about nest1
 now what i dont think is possible and dont even know if it is usually
 done on latex something that belongs to some stuff and is in between
 nest 1 and 2, i find it usefull for commenting on nests(thats why
 i miss it) and looks like it is the same thing you are wishing for  
lists?

 My use case for this is mostly note-taking.
** nest 2
  stuff about nest2

could be also usefull, if it makes sense, btw the lists are taking  
shape :).


This has been discussed here a million times and it is not going to  
happen.


- Carsten






On Jul 22, 2010, at 11:08 PM, Nicolas Goaziou wrote:


Hello,

Here is a new, and probably final feature-wise, suggestion of list
improvement in Org Mode.

Table of Contents
=
1 What is it about again ?
2 Is that all ?
  2.1 Preserving blank lines
  2.2 Timer lists
  2.3 Automatic rules
  2.4 `org-apply-on-list'
3 Where can it be tried ?


1 What is it about again ?
~~~

I redefined lists in Org Mode. Lists start, as before, at a bullet
(whose true regexp is at `org-item-beginning-re'), and end at either
`org-list-end-regexp', a new headline, or, obviously, end of buffer.

`org-list-end-regexp' is customizable and defaults to 2 blank lines,
but `org-empty-line-terminates-plain-lists' has precedence over it.
Moreover, any `org-list-end-regexp' found in special blocks does not
end list. Here are two examples of valid lists:

Case 1: `org-list-end-regexp' is at default value


- First item

  - Sub item

#+BEGIN_EXAMPLE
Two blank lines below


Two blank lines above
#+END_SRC

  - Last sub item


List has ended at the beginning of this line.

Case 2: `org-list-end-regexp' is "^[ \t]*___[ \t]*\n"


- item 1
- item 2
  - sub-item
  - sub-item 2
- item 3
__
List has ended at the beginning of this line.

Now, Org Mode knows when a list has ended and how to indent line
accordingly. In other words, you can `org-return-indent' three times
to exit a list and be at the right column to go on with the text.

This new definition is also understood by exporters (LaTeX, DocBook,
HTML or ASCII) and `org-list-end-regexp' will appear in source as a
blank line, whatever its value is (as long as it starts with a caret
and ends with a newline character, as specified in doc-string).

Another advantage is that you can have two lists of different types
in a row like in the example below:


- item
- item


1. item
2. item

In this example, you can move (or cycle, or indent) items in the
second list without worrying about changing the first one.

2 Is that all ?


Yes and no. I tried as much as possible to keep compatibility with
previous implementation. But, as I was at it, I made a number of
minor improvements I am now going to describe.

2.1 Preserving blank lines
===

 `org-move-item-up' and `org-move-item-down' will not eat blank
 lines anymore. You can move an item up and down and stay assured
 list will keep its integrity.

 The same is true for `org-sort-list' that would previously collapse
 the list being sorted. Sorting is now safe.

 `org-insert-item', when 'plain-list-item is set to 'auto in
 `org-blank-before-new-entry' (the default, I think), will work hard
 to guess the appropriate number of blank lines to insert before the
 item to come. The function is also much more predictable (in
 previous version, trying to insert an item with point on a blank
 line between 2 items would create a new headline).

2.2 Timer lists


 There are three improvements in timer lists (

Re: [Orgmode] .ods opens file in Emacs, not OpenOffice

[David Maus]

C64 Whiz wrote:
>[1  ]
>[1.1  ]

>[1.2  ]
>Though I love the command line, I was hoping for a mouse-click solution.  I.e. 
>I click on the link and it properly opens up
>in OO.

What about customizing `org-file-apps'?

,
| org-file-apps is a variable defined in `org.el'.
| Its value is 
| ((auto-mode . emacs)
|  ("\\.mm\\'" . default)
|  ("\\.x?html?\\'" . default)
|  ("\\.pdf\\'" . default))
| 
| 
| Documentation:
| External applications for opening `file:path' items in a document.
| Org-mode uses system defaults for different file types, but
| you can use this variable to set the application for a given file
| extension.  The entries in this list are cons cells where the car identifies
| files and the cdr the corresponding command.  Possible values for the
| file identifier are
`

HTH,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpUSpThqHCdo.pgp
Description: PGP signature
___
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] Bug: org-insert-link path promt lacks tab-completion [7.01trans]

[David Maus]

Aidan Gauland wrote:
>[1  ]
>[1.1  ]
>If I enter or edit a link with org-insert-link, I only get
>tab-completion for the URL prefix (e.g. fi  puts "file"), but not for
>the path name for "file:" links.  So, if I type C-c C-l file:~/.ema
>, I expect to get file:~/.emacs (the possibilities are .emacs and
>.emacs.d/), but all I get is the message "[No prefix completions]" in
>the minibuffer juxtaposed to what's already there (the message
>disappears after about a second).

I cannot reproduce this with

Org-mode version 7.01trans (release_7.01h.115.g1f17)

on

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-08-14 on raven, modified by Debian

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp5VneOD7tzp.pgp
Description: PGP signature
___
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] Capture and checkitem

[David Maus]

julien cubizolles wrote:
>I'm also confused about the checkitem type of template.

>The following template :

>("T" "test" checkitem (file+headline "~/org/orgfiles/test.org" "Test")
>"%?")

>doesn't work as I expected : the capture buffer is not narrowed and no
>item is created...

I can confirm this for

Org-mode version 7.01trans (release_7.01h.115.g1f17)

on

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of
 2010-08-14 on raven, modified by Debian

with emacs -Q an this capture template:

(setq org-capture-templates
  '(("t" "Todo" checkitem (file+headline "/tmp/org/inbox.org" "TEST")
 "Test")))

The file and the headline do exists; when calling `org-capture' Org
creates the indirect buffer, does not narrow to headline TEST and
point is at the beginning of this headline.

Best,
  -- David

--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpzfMkcnsBtw.pgp
Description: PGP signature
___
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] [ANN] List improvement v.2

[Nicolas Goaziou]

Argh, it should be:

(defun org-switch-to-new-lists ()
  "Make current buffer compatible with new list definition."
  (goto-char (point-min))
  (let ((case-fold-search t))
(while (< (point) (point-max))
  (while (and (org-in-item-p)
  (not (org-at-item-p))
  (not (looking-at "^[ \t]*$"))
  (not (and (org-in-regexps-block-p
 "^[ \t]*#\\+begin_" "^[ \t]*#\\+end_")
(not (looking-at "^[ \t]*#\\+begin_"
  (<= (org-get-indentation)
  (save-excursion
(org-beginning-of-item)
(org-get-indentation
(newline))
  (beginning-of-line 2

Sorry for the noise.

Regards,

-- Nicolas

___
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] MathJax is now the default for HTML math

[Jan Böcker]

I have now published the code used to create the static version:
http://www.jboecker.de/2010/08/15/staticmathjax.html

Below is a first stab at HTML export integration fresh out of my
*scratch* buffer (which lacks the possibility to configure this for each
file).

-- Jan


(defun jb/static-mathjax-hook-installer ()
  "adds jb/static-mathjax-process to the local after-save hook"
  (add-hook 'after-save-hook 'jb/static-mathjax-process nil t))

(defun jb/static-mathjax-process ()
  (let ((app-ini-path "/home/jan/work/staticmathjax/application.ini")
(output-file-name (concat (file-name-sans-extension 
buffer-file-name)
  
"-static.html")))
  (call-process "xulrunner" nil nil nil app-ini-path buffer-file-name
output-file-name "--embed-fonts")))

(add-hook 'org-export-html-final-hook 'jb/static-mathjax-hook-installer)


___
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] [ANN] List improvement v.2

[Nicolas Goaziou]

> Carsten Dominik writes:
Hello,

> But it will break existing documents when exported to LaTeX

It will break existing documents when exporting to anything (except
ASCII). You can use the following (quick and dirty) code to make the
transition easier:

(defun org-switch-to-new-lists ()
  "Make current buffer compatible with new list definition."
  (goto-char (point-min))
  (while (< (point) (point-max))
(while (and (org-in-item-p)
(not (org-at-item-p))
(not (looking-at "^[ \t]*$"))
(not (and (org-in-regexps-block-p
   "^[ \t]*#\\+begin_" "^[ \t]*#\\+end_")
  (not (looking-at "^[ \t]*#\\+begin_"
(<= (org-get-indentation)
(save-excursion
  (org-beginning-of-item)
  (org-get-indentation
  (newline))
(beginning-of-line 2)))

Regards,

-- Nicolas

___
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: [ANN] List improvement v.2

[Nicolas Goaziou]

Hello,

> Glauber Alex Dias Prado writes:
>> Carsten Dominik  writes:

>> 1 Error when pressing M-RET in second line after list
>> ~~
>> 
>> - Example item1
>> - Exmaple item2
>> 
>> With cursor position at "@", M-RET throws an error

This is now fixed.


>> 2 Incompatibility 1
>> 
>> - Example 1
>> - Ex 2
>> 
>> This used to be outside of the list.  The HTML exporter still treats
>> it as being outside of the list.  The LaTeX exporter treats it as
>> part of the last item.  If I add a second empty line, then both
>> exporters handle it well.
>> 
>> So this breaks with documented properties of the lists.  I guess
>> this is unavoidable because this is just how the new list definition
>> works.  But it will break existing documents when exported to LaTeX

According to the new list definition, LaTeX exporter is correct here.
Now, DocBook and HTML exporters will also treat it as being part of
the last item (unless `org-empty-line-terminates-plain-lists' is t,
obviously).


>> 3 Text between two sublists
>> 
>> 
>> - Ex1
>> - Ex2
>>   - Ex2a
>>   - Ex2b
>>   Some text between two sublists
>>   - A new list starts
>> 
>> This always was an inconsistency between HTML and LaTeX export, and it
>> still is now.  There seems to be no way now to do what I intend here,
>> putting some text between two lists.

I removed this inconsistency (see 2.).

Alas, what you want to achieve here isn't possible. Lists are now a
strong structural element. Think of them as mini headings. Indentation
of body means nothing in both of them. In the case of headings, only
the number of stars matters, while lists only pay attention to
indentation of bullets.

There's somewhat a workaround though, as you can indent the very first
item of a list to any column, making this possible:

- List 1, item 1
  - List 1, sub item 1


Some comments after list 1 has ended

  - List 2, item 1
  - List 2, item 2


- List 3, item 1


While there are in fact 3 different lists, it more or less looks like
what you want to do (and it could be cleaner with
`org-empty-line-terminates-plain-lists' set to t). Please note that
trick won't survive an export.

If export matters, there are quote blocks, or verbatim, or example.
But I won't teach you all of this! ;)


> preferably not only for lists, something like:

> * some stuff
>   quick intro
> ** nest 1  
>stuff about nest1
>   now what i dont think is possible and dont even know if it is usually
>   done on latex something that belongs to some stuff and is in between
>   nest 1 and 2, i find it usefull for commenting on nests(thats why
>   i miss it) and looks like it is the same thing you are wishing for lists?
>   My use case for this is mostly note-taking.
> ** nest 2
>stuff about nest2

> could be also usefull, if it makes sense, btw the lists are taking shape :).

You are right, this is exactly the same problem. I think there are 2
ways to handle this:

1. either indentation brings information, and there can't possibly be
   a working automatic indentation (like previous list implementation)
   as you can never tell for sure if current line is badly indented or
   sending information on something.

2. either indentation is given by structural elements (like headings
   in your example) and there's no "in between nest 1 and 2".
   

Since Org is about structure, option 2 is, in my opinion, clearly the
way to go.

Regards,

-- Nicolas

___
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: [ANN] List improvement v.2

[Glauber Alex Dias Prado]

Carsten Dominik  writes:

> Hi Nicolas,
>
> I have finally started to look at your changes to the list
> implementation.
> Lots of it is very good!  I like for example that TAB indentation now
> works
> a lot better.
>
> Here are a few problems I noted so far:
>
> 1 Error when pressing M-RET in second line after list
> ~~
>
>   - Example item1
>   - Exmaple item2
>
> With cursor position at "@", M-RET throws an error
>
> 2 Incompatibility 1
> 
>   - Example 1
>   - Ex 2
>
>   This used to be outside of the list.  The HTML exporter still treats
>   it as being outside of the list.  The LaTeX exporter treats it as
>   part of the last item.  If I add a second empty line, then both
>   exporters handle it well.
>
>   So this breaks with documented properties of the lists.  I guess
>   this is unavoidable because this is just how the new list definition
>   works.  But it will break existing documents when exported to LaTeX
>
> 3 Text between two sublists
> 
>
>   - Ex1
>   - Ex2
> - Ex2a
> - Ex2b
> Some text between two sublists
> - A new list starts
>
> This always was an inconsistency between HTML and LaTeX export, and it
> still is now.  There seems to be no way now to do what I intend here,
> putting some text between two lists.

preferably not only for lists, something like:

* some stuff
  quick intro
** nest 1  
   stuff about nest1
  now what i dont think is possible and dont even know if it is usually
  done on latex something that belongs to some stuff and is in between
  nest 1 and 2, i find it usefull for commenting on nests(thats why
  i miss it) and looks like it is the same thing you are wishing for lists?
  My use case for this is mostly note-taking.
** nest 2
   stuff about nest2

could be also usefull, if it makes sense, btw the lists are taking shape :).

>
>
> On Jul 22, 2010, at 11:08 PM, Nicolas Goaziou wrote:
>
>> Hello,
>>
>> Here is a new, and probably final feature-wise, suggestion of list
>> improvement in Org Mode.
>>
>> Table of Contents
>> =
>> 1 What is it about again ?
>> 2 Is that all ?
>>2.1 Preserving blank lines
>>2.2 Timer lists
>>2.3 Automatic rules
>>2.4 `org-apply-on-list'
>> 3 Where can it be tried ?
>>
>>
>> 1 What is it about again ?
>> ~~~
>>
>>  I redefined lists in Org Mode. Lists start, as before, at a bullet
>>  (whose true regexp is at `org-item-beginning-re'), and end at either
>>  `org-list-end-regexp', a new headline, or, obviously, end of buffer.
>>
>>  `org-list-end-regexp' is customizable and defaults to 2 blank lines,
>>  but `org-empty-line-terminates-plain-lists' has precedence over it.
>>  Moreover, any `org-list-end-regexp' found in special blocks does not
>>  end list. Here are two examples of valid lists:
>>
>>  Case 1: `org-list-end-regexp' is at default value
>>
>>
>>  - First item
>>
>>- Sub item
>>
>>  #+BEGIN_EXAMPLE
>>  Two blank lines below
>>
>>
>>  Two blank lines above
>>  #+END_SRC
>>
>>- Last sub item
>>
>>
>>  List has ended at the beginning of this line.
>>
>>  Case 2: `org-list-end-regexp' is "^[ \t]*___[ \t]*\n"
>>
>>
>>  - item 1
>>  - item 2
>>- sub-item
>>- sub-item 2
>>  - item 3
>>  __
>>  List has ended at the beginning of this line.
>>
>>  Now, Org Mode knows when a list has ended and how to indent line
>>  accordingly. In other words, you can `org-return-indent' three times
>>  to exit a list and be at the right column to go on with the text.
>>
>>  This new definition is also understood by exporters (LaTeX, DocBook,
>>  HTML or ASCII) and `org-list-end-regexp' will appear in source as a
>>  blank line, whatever its value is (as long as it starts with a caret
>>  and ends with a newline character, as specified in doc-string).
>>
>>  Another advantage is that you can have two lists of different types
>>  in a row like in the example below:
>>
>>
>>  - item
>>  - item
>>
>>
>>  1. item
>>  2. item
>>
>>  In this example, you can move (or cycle, or indent) items in the
>>  second list without worrying about changing the first one.
>>
>> 2 Is that all ?
>> 
>>
>>  Yes and no. I tried as much as possible to keep compatibility with
>>  previous implementation. But, as I was at it, I made a number of
>>  minor improvements I am now going to describe.
>>
>> 2.1 Preserving blank lines
>> ===
>>
>>   `org-move-item-up' and `org-move-item-down' will not eat blank
>>   lines anymore. You can move an item up and down and stay assured
>>   list will keep its integrity.
>>
>>   The same is true for `org-sort-list' that would previously collapse
>>   the list being sorted. Sorting is now safe.
>>
>>   `org-insert-item', when 'plain-list-item is set to 'auto in
>>   `org-blank-before-new-entry' (the default, I think), will work hard
>>   to guess the appropriate number of blank lines to insert before t

Re: [Orgmode] Re: keys and command name info

[Carsten Dominik]

On Aug 15, 2010, at 9:37 AM, Carsten Dominik wrote:



On Aug 13, 2010, at 9:30 PM, Andreas Röhler wrote:


Am 11.08.2010 12:05, schrieb Carsten Dominik:


On Aug 9, 2010, at 9:28 PM, Dan Davison wrote:


Dan Davison  writes:


Gregor Zattler  writes:


Hi Andreas, org-mode developers,
* Andreas Burtzlaff  [09. Aug. 2010]:

Carsten Dominik  writes:

I have put a version of the manual as modified by Andreas here:

http://orgmode.org/org-manual-with-command-names.pdf

Not all the command names are in there, but quite a few are.
I'd like to hear from more people

- if they would like to have the names there (i.e. if it would
help them finding a command)


I would like the command names in the manual.

- Emacs-lisp has a lovely tradition of naming functions *very*
descriptively and not being afraid to use long names in the  
interests

of accuracy. It's a shame to lose all that by displaying only key
sequences. It's a linguistic world of its own and I like being  
exposed

to it.
- While one can do C-h k, that's not the same as the way one  
learns the

function names by skimming the manual


Also, it does not add length to the HTML version of the manual,  
because
the key sequences are already on a line of their own. And the  
same is
true for a certain proportion of the pdf entries (when the key  
sequence

is long, then it seems to go on its own line).





- if the position (first thing in the command description)
is right, or if it would be better to have it
- last thing in the description
- or after the first sentence, this is how the GNUS manual
does it.


I definitely would want them out on a line of their own with the  
key

sequence. I liked the right-aligned model.

Or if not right-aligned, is it possible not to have the comma?  
Maybe a

different font?


I also like the position on the key line best. So if there is a
more-or-less
general agreement that we should get the names in, this would be my
preferred
location as well. I knot that this is different from what the emacs
and gnus manuals do - but I still think that a solution like this  
would

be better.

Andreas, can you be bothered to rework the patch?

Unfortunately I have no idea if/how the right-aligned model could be
made to
work. So I think the safest way to do this would be to introduce  
the macro,
and we can then work on the macro to get the formatting right, and  
also

to do the
key and function index stuff fully automatically.

Here is my proposal for now:

@macro orgcmd{key,command}
@kindex \key\
@findex \command\
@item \key\ @ @ @ @ @ @ @ @ @ @ @r{(}\comma...@r{)}
@end macro

And then define keys/commands like this:

@table @kbd
.
@orgc...@key{tab}, org-cycle}
Here follows the description of the command

@end table

- Carsten



[ ... ]

Hi Carsten,

attached a sreenshot, how it comes out for C-c C-b.
Doesn't look ok for me, as back-tick and quote are uncommon that way.


Hi Andreas, you are correct, this does not look right.
Seems like we will have to make the table ins @asis and
then have the macro apply the formatting.  Sigh... :)


If you do insert all the macro calls with the command names, I will  
take care of the formatting.


- Carsten




___
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] [PATCH] Indent code with TAB in Org buffer

[Carsten Dominik]

On Aug 15, 2010, at 8:43 AM, Dan Davison wrote:


With this patch TAB in a code block aligns the code according to the
major mode. The macro could be used to do the same thing for other
commands (i.e. allow other commands to be invoked in the Org buffer,  
but

actually carried out in the code buffer.)

Patch attached and in branch src-block-tab at
g...@github.com:dandavison/org-devel.git.

diff --git a/lisp/org-src.el b/lisp/org-src.el
index baa2b11..fc15a83 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -435,6 +435,19 @@ the fragment in the Org-mode buffer."
  (message "%s" msg)
  t)))

+(defmacro org-src-do-in-edit-buffer (&rest body)
+  "Evaluate BODY in edit buffer if there is a code block at point.
+Return t if a code block was found at point, nil otherwise."
+  `(when (org-edit-src-code)


Wow, an excursion to the temp buffer for every TAB call
in a source code block?

Sounds heavy.  But I see that it could be nice together with
the new fontification stuff.  My gut feeling would be to have
both of these feature off by default.  But I have not tried
them yet.

- Carsten


___
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] Re: keys and command name info

[Carsten Dominik]

On Aug 13, 2010, at 9:30 PM, Andreas Röhler wrote:


Am 11.08.2010 12:05, schrieb Carsten Dominik:


On Aug 9, 2010, at 9:28 PM, Dan Davison wrote:


Dan Davison  writes:


Gregor Zattler  writes:


Hi Andreas, org-mode developers,
* Andreas Burtzlaff  [09. Aug. 2010]:

Carsten Dominik  writes:

I have put a version of the manual as modified by Andreas here:

http://orgmode.org/org-manual-with-command-names.pdf

Not all the command names are in there, but quite a few are.
I'd like to hear from more people

- if they would like to have the names there (i.e. if it would
help them finding a command)


I would like the command names in the manual.

- Emacs-lisp has a lovely tradition of naming functions *very*
descriptively and not being afraid to use long names in the  
interests

of accuracy. It's a shame to lose all that by displaying only key
sequences. It's a linguistic world of its own and I like being  
exposed

to it.
- While one can do C-h k, that's not the same as the way one  
learns the

function names by skimming the manual


Also, it does not add length to the HTML version of the manual,  
because
the key sequences are already on a line of their own. And the same  
is
true for a certain proportion of the pdf entries (when the key  
sequence

is long, then it seems to go on its own line).





- if the position (first thing in the command description)
is right, or if it would be better to have it
- last thing in the description
- or after the first sentence, this is how the GNUS manual
does it.


I definitely would want them out on a line of their own with the  
key

sequence. I liked the right-aligned model.

Or if not right-aligned, is it possible not to have the comma?  
Maybe a

different font?


I also like the position on the key line best. So if there is a
more-or-less
general agreement that we should get the names in, this would be my
preferred
location as well. I knot that this is different from what the emacs
and gnus manuals do - but I still think that a solution like this  
would

be better.

Andreas, can you be bothered to rework the patch?

Unfortunately I have no idea if/how the right-aligned model could be
made to
work. So I think the safest way to do this would be to introduce  
the macro,
and we can then work on the macro to get the formatting right, and  
also

to do the
key and function index stuff fully automatically.

Here is my proposal for now:

@macro orgcmd{key,command}
@kindex \key\
@findex \command\
@item \key\ @ @ @ @ @ @ @ @ @ @ @r{(}\comma...@r{)}
@end macro

And then define keys/commands like this:

@table @kbd
.
@orgc...@key{tab}, org-cycle}
Here follows the description of the command

@end table

- Carsten



[ ... ]

Hi Carsten,

attached a sreenshot, how it comes out for C-c C-b.
Doesn't look ok for me, as back-tick and quote are uncommon that way.


Hi Andreas, you are correct, this does not look right.
Seems like we will have to make the table ins @asis and
then have the macro apply the formatting.  Sigh... :)

- Carsten


___
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] [PATCH] org.texi: Document quick insertion of empty structural elements

[Carsten Dominik]

Applied, thanks

- Carsten

On Aug 14, 2010, at 1:55 AM, Jambunathan K wrote:



org.texi: Document quick insertion of empty structural elements

Sources:

1. http://article.gmane.org/gmane.emacs.orgmode/6670/
  See section titled 'Completion of structure elements'

2. http://article.gmane.org/gmane.emacs.orgmode/18004/

From 540d8f2c03d300b6007c0d8595bb78ad172d8eac Mon Sep 17 00:00:00 2001
From: Jambunathan K 
Date: Sat, 14 Aug 2010 04:24:34 +0530
Subject: [PATCH] org.texi: Document quick insertion of empty  
structural elements


* org.texi (Easy Templates): New section. Documents quick insertion  
of empty

structural elements.

TINYCHANGE
---
doc/org.texi |   49 -
1 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index ac52c70..508d2ce 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -12320,6 +12320,7 @@ emacsclient \
@chapter Miscellaneous

@menu
+* Easy Templates:: Quick insertion of structural elements
* Completion::  M-TAB knows what you need
* Speed keys::  Electric commands at the beginning of a headline
* Code evaluation security::Org mode files evaluate inline code
@@ -12331,8 +12332,54 @@ emacsclient \
* Interaction:: Other Emacs packages
@end menu

+...@node Easy Templates, Completion, Miscellaneous, Miscellaneous
+...@section Easy Templates
+...@cindex insertion, of '#+begin_src #+end_src'
+...@cindex insertion, of '#+begin_example #+end_example'
+...@cindex insertion, of '#+begin_quote #+end_quote'
+...@cindex insertion, of '#+begin_verse #+end_verse'
+...@cindex insertion, of '#+begin_center #+end_center'
+...@cindex insertion, of '#+begin_latex #+end_latex'
+...@cindex insertion, of '#+latex:'
+...@cindex insertion, of '#+begin_html #+end_html'
+...@cindex insertion, of '#+html:'
+...@cindex insertion, of '#+begin_ascii #+end_ascii'
+...@cindex insertion, of '#+ascii:'
+...@cindex insertion, of '#+include:'
+
+Org-mode supports insertion of empty structural elements (like # 
+BEGIN_SRC
+and #+END_SRC pairs) with just a few key strokes. This is achieved  
through a

+native template expansion mechanism.
+
+To insert a structural element, type a '<', followed by a template  
selector
+and TAB. Completion takes effect only when the above keystrokes are  
typed on

+a line by itself.
+
+Following template selectors are currently supported.
+
+...@multitable @columnfractions 0.1 0.9
+...@item s @tab Insert '#+begin_src #+end_src'
+...@item e @tab Insert '#+begin_example #+end_example'
+...@item q @tab Insert '#+begin_quote #+end_quote'
+...@item v @tab Insert '#+begin_verse #+end_verse'
+...@item c @tab Insert '#+begin_center #+end_center'
+...@item l @tab Insert '#+begin_latex #+end_latex'
+...@item L @tab Insert '#+latex:' line
+...@item h @tab Insert '#+begin_html #+end_html'
+...@item H @tab Insert '#+html:' line
+...@item a @tab Insert '#+begin_ascii #+end_ascii'
+...@item A @tab Insert '#+ascii:' line
+...@item i @tab Insert '#+include:' line
+...@end multitable
+
+For example, on an empty line, typing "will expand

+into a complete EXAMPLE template.
+
+You can install additional templates by customizing the variable
+...@code{org-structure-template-alist}. Refer docstring of the  
variable for

+additional details.

-...@node Completion, Speed keys, Miscellaneous, Miscellaneous
+...@node Completion, Speed keys, Easy Templates, Miscellaneous
@section Completion
@cindex completion, of @TeX{} symbols
@cindex completion, of TODO keywords
--
1.7.0.4


Jambunathan K.
___
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


- Carsten




___
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] Re: [Patch] Org-fontify

[Carsten Dominik]

Hi,

I have applied this patch.

Thanks!

- Carsten

On Aug 14, 2010, at 11:04 PM, Sébastien Vauban wrote:


Hi Erik and all,


Erik Iverson wrote:
Having not tried this out, are the aims different than David  
O'Toole's

mode-specific fontification of org-mode source blocks?

http://www.mail-archive.com/emacs-orgmode@gnu.org/msg28160.html

See a picture of what he's done here:

http://imagebin.ca/view/iRVK_as7.html


Nothing to do, in fact. Complementary, I hope...

The fact is that, when you use faces with background, you see the  
whole line
fontified (up to the right fringe), or only up to the end of the  
line (last

character, =C-e=).

My patch cares for the first behavior.


See http://www.mygooglest.com/sva/highlight-whole-ines.png
for the results on my minimal example file.

Best regards,
 Seb

--
Sébastien Vauban


___
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


- Carsten




___
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] [Bug] or not?

[Carsten Dominik]

On Aug 14, 2010, at 11:34 PM, Sébastien Vauban wrote:


Hello,

Here a sample of Org code put in a document.

#+begin_src org
,SCHEDULED: <2010-08-12 Thu 10:20-10:45>
#+end_src

The =,= should render the line "inactive" and should not trigger any  
line in

the agenda. Though, it does. Bug or not?


Hi Sebastien,

it would be really tough to escape all Org code in these blocks.
The comma only covers headines and meta lines, as they influence
the document structure.

- Carsten


___
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] MathJax is now the default for HTML math

[Carsten Dominik]

On Aug 15, 2010, at 12:16 AM, Jan Böcker wrote:


On 08/14/2010 10:59 PM, Carsten Dominik wrote:

Hi Jan,

can you expand a bit on why this is interesting to do?  What are the
advantages?

Thanks!

- Carsten


Advantages are:
- The user is not required to have JavaScript enabled
- In some cases, there is a speed advantage, because
 there is no rendering stage. This is especially
 noticeable on high-latency connections when the MathJax files
 are not already cached.
- Fonts can be embedded into the HTML file itself, so it feels
 more 'document-like' (no need to move additional files around)
- The approach might be interesting for HTML email, because it
 would require neither JavaScript nor attachments

Of course, there are disadvantages too:
- No interactive MathJax features (zoom, view source, switch rendering
backend)
- no fallback to image fonts (although AFAIK, all current versions
 of major browsers support CSS3 custom fonts)
- slightly different spacing and font sizes in non-Firefox browsers
- if fonts are embedded within the HTML file:
 * IE will not show the correct font (but in my test the
   formatting was still correct and readable)
 * The HTML file will be larger (my small example grew by 436 KB).
   Bandwidth is wasted because the fonts are base64-encoded.


Hi Jan,

thanks for these explanations.

- Carsten



I would not recommend this for regular publishing on the web. As  
long as

JavaScript is enabled (as it is in most cases), the disadvantages
outweigh the advantages. It might come in handy if you want to send
someone a single file (although you can always use PDF for that) or if
you want to provide an alternative for users who have JavaScript  
disabled.


Ideally, there would be some sort of graceful degradation, so that  
users
without JavaScript see the non-JS version, but if JavaScript is  
enabled,
the math gets re-rendered and all MathJax features are available. I  
have

not explored the feasibility of that.


On 08/14/2010 10:39 PM, Detlef Steuer wrote:

Could you post the org file to give dummies like me a head start?
Especially the serializing back to HTML? How is it done?


I have attached the (very simple) example org file to this email. The
first example is the result of exporting this file with C-c C-e h  
(like

Carsten said, it Just Works). The second example is the result of
processing the first one with a xulrunner application I hacked  
together
(which is independent of emacs). I'll try to get that application  
into a

publishable form tomorrow (remove hard-coded values, make embedding
fonts into the HTML file optional, etc).

My aim is to provide an elisp function to be called from an export  
hook

which makes the appropriate call to create the non-JS version.

-- Jan



- Carsten




___
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: Menu-bar bug (was Org menu dropdown disappears -- bug??)

[Bastian Beischer]

What version of emacs are you running?
This is a known issue (with emacs 23.1 for example) and has been fixed by
now:

see
https://bugs.launchpad.net/ubuntu/+source/emacs-snapshot/+bug/415101

The
link also contains a workaround setting GDK_NATIVE_WINDOWS=1.

I'm now working with emacs 23.2 and there is no such problem any more.

Cheers
Bastian

On Sat, Aug 14, 2010 at 5:26 PM, Rustom Mody  wrote:

> On Aug 14, 5:40 pm, rustom  wrote:
> > Some time back I found that the menu (drop-down) under python
> > 'disappeared' ie clicking there did not show anything
> >
> > Today I found the same thing happened for the org and tbl menus --
> > click there and nothing happens/shows.
> >
> > Restarted emacs -Q and it was there.
> > Ok so something in my setup.
> >
> > So tried
> > a My org specific setup (which is in a separate el-file) and no init
> > -- the menu is there
> > b My init but no org setups -- the menu has disappeared
> >
> > Now I can of course hunt down which setup is the culprit. (Just have
> > to start and stop emacs about 30 times!!) But I was just wondering if
> > some tip/bug etc is already known in this regard
> >
> > emacs version 23.1.1
> > org version 7.01trans
>
> Update -- Now it seems more likely theres some bug somewhere.
> Start emacs -Q
> The menu-bar line is as expected ie it has
> File Edit Options Buffers Tools Lisp-Interaction Help
>
> Under Lisp-Interaction there are 5 entries:
> Complete-Lisp-SymbolEvaluate-Defun
>
> Now I do M-x org-mode
> The menu-bar now has
> File Edit Options Buffers Tools Org Tbl Help
>
> Note Lisp-Interaction has disappeared
>
> But under Org I see the same entries that were earlier under lisp
> interaction.
>
> emacs version 23.1.1
> org version 7.01trans
> debian squeeze
>
>


-- 
Bastian Beischer

I. Physikalisches Institut B (RWTH Aachen)
Sommerfeldstr. 14
52074 Aachen
GERMANY

Office: 28-C-203
Phone: +49 241 - 8027205
___
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