Re: [Orgmode] 23.0.94; [PATCH] org-store-link broken within kbd macros
Hi Bastien, It happens on all tabs. (note ?n * %? %i -- %a %U\n%i) Thanks. On Wed, Jul 1, 2009 at 22:52, Bastienbastiengue...@googlemail.com wrote: Samuel Wales samolog...@gmail.com writes: I cannot use org-remember to save all my w3m tabs using remember and keyboard macros. Are you using a specific remember template when remembering those w3m tabs? My guess is that your remember template tries to fetch a title or same tab-related info that isn't available for some tab. Says command rang the bell, but I don't know which even with stack trace on. call-last-kbd-macro(nil kmacro-loop-setup-function) kmacro-call-macro(nil nil) kmacro-end-and-call-macro(nil) call-interactively(kmacro-end-and-call-macro) Is this related? Looks like some tab prevents the macro from being repeated correctly. Maybe you can try to debug this like this: 1. use several identic tabs (and see if the error occurs); 2. use two different tabs, then three, etc. HTH -- Bastien -- Myalgic encephalomyelitis is causing death and severe suffering worse than MS. Conflicts of interest are destroying research. People get the disease at any time permanently. Do science and justice matter to you? http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm ___ 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
Re: [Orgmode] 23.0.94; [PATCH] org-store-link broken within kbd macros
Samuel Wales samolog...@gmail.com writes: It happens on all tabs. You mean on *each* tab? (note ?n * %? %i -- %a %U\n%i) Can you remember at least one tab with this template? Can you send the full macro? -- Bastien ___ 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
Re: [Orgmode] LaTeX export bugs?
On Jun 26, 2009, at 3:34 PM, Sébastien Vauban wrote:
Hello,
To make things clear, I love Org-mode (yes, I voted) and its LaTeX
export.
More than you can imagine: I now look for avoiding writing any LaTeX
document,
and have the export do all the work for me...
BTW, any solution for exporting to a Beamer presentation? I'd be
very very
very interested by anything in that direction. That's the last piece
of the
whole puzzle, IMHO.
Though, working more and more in that direction (Org-mode - LaTeX),
I've seen
a couple of weird things that I've compiled into an ECM, for ease of
use:
--8---cut here---start-8---
* Org
- If you have a level 3 item under a level 1 item, the level 3
doesn't get
exported to LaTeX. I know this is not a normal situation, but it
happens
when restructuring some text, and you loose it in the exported
view...
Yes, the parser currently requires the structure to be consistent
and does not fail gracefully if not.
* THIS SECTION WILL DISAPPEAR!!
This text is not exported. Though, I'm not always aware of it,
when
sections are long (spreading over more than one screen page)...
*** Level 2 -- is there a level 3 above?
- Table with formulas and environment /framed/ :
The following table will be framed, but TBL formulas do not work
anymore.
#+ATTR_LaTeX: align=lrrr
#+LaTeX: \begin{framed}
| Code | \euro{} | \% | \euro{} |
|---+-+-+-|
| GSM | | |0.00 |
| Internet | 168.45 | 100 | 168.45 |
| Matériel | 295.99 | 100 | 295.99 |
| Publicité | 214.25 | 33 | 70.70 |
| Autres| | |0.00 |
|---+-+-+-|
| Total | | | 535.14 |
#+LaTeX: \end{framed}
#+TBLFM: $4=$2*$3/100;%.2f::@7$4=vsum(@-...@-ii)
Swapping these two last lines gives LaTeX errors... What's the
solution
for having both: an environment around the table and formulas
that work?
This is a hard problem. It is on my list, but will not be fixed soon.
Why do I have to escape the sign symbol as soon as I put LaTeX
commands
(and not BEGIN..END_LaTeX) near it?
I do not understand what you mean here.
- Hyperlink to other sections: see [[To be referenced]]. Looking
in the
produced LaTeX code, it always link to the current section
instead!
Have not yet looked into this. Use IDs or custom IDs to links to
sections, that is much better.
- Quotes are sometimes exported in a weird /fashion/ : see
Industriels,
et commerçants. And compare with the quotes in the next sample
(Industriels et commerçants).
Fixed.
See as well that /fashion/ is not in italic above.
It is for me
Apparently because of
the special non-breaking space following the second slash...
Looks like the non-breaking space did not make it through
the mailing process. What exactly are you using?
BTW, a
possibility would be to translate the non-breaking space to
its LaTeX
equivalent syntax (the tilde sign).
* To be referenced
This should be the landing point for the hyperreference above.
--8---cut here---end---8---
Once again, thanks to all of you that provide us with those wonderful
features...
Best regards,
Seb
--
Sébastien Vauban
___
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
___
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
Re: [Orgmode] Re: LaTeX export bugs?
On Jul 1, 2009, at 10:21 PM, Sébastien Vauban wrote: Other things I've noticed: - Even with version 6.28, the `#+TBLNAME' tag must be located in column 0 (at least, for the highlighting features to work) Fixed, thanks. - Remote references to other tables are great, but they only work with absolute references, not with named cells. They actually do work fine. A call like remote(mytbl,$name) will work in this table | _ | name | | | value | - Carsten On the wishlist (easy to say ;-)), I image it'd be utmost useful to be able to name a cell and reuse its name in a remote ref. Thanks for any commentary on the above... Thank you very much Carsten, Bastien and Co... Seb -- Sébastien Vauban ___ 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 ___ 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
Re: [Orgmode] Feature or Help request: Expand ALL before ispell-buffer
On Jul 1, 2009, at 2:39 PM, Scot Becker wrote: Is there any easy way that a call to M-X ispell or M-X ispell-buffer could expand all collapsed org-mode nodes before doing the spell check? (defun my-ispell-buffer () (interactive) (show-all) (call-interactively 'ispell-buffer)) HTH - Carsten ___ 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
Re: [Orgmode] Re: Release 6.28
On Jul 1, 2009, at 1:17 PM, Ulf Stegemann wrote: Yes, both shifting by the same amount and setting a fixed date can be useful. I usually re-schedule leftover todos by shifting them by one or two working days to the future. So originally I had a bulk version of `org-agenda-do-date-later' and friends in mind as opposed to `org-agenda-schedule'. But the latter one would be useful to. Ideally, S-left, C-cC-s et al. would trigger a bulk shift/bulk schedule whenever there are marked agenda items. I am not so sure about this last point. I am not a fan of automatic bulk action if several items are selected. - these lists can become long, and selected entries might be off the screen - for this to make sense, selected entries should remain selected after action, increasing the danger of unwanted action - you might be in the process of selecting some entries, when you want to do a quick action on an individual entry you come across. But you cannot, because any action will act on all selected ones. So I do prefer a special command like B to introduce bulk action. Opinions? - Carsten ___ 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
Re: [Orgmode] Feature or Help request: Expand ALL before ispell-buffer
Of course! I (apparently) don't have the 'emacs mind' quite enough to have thought of that myself, but when i see it, it seems bleeding obvious. Many thanks for that little tutorial. Scot On Thu, Jul 2, 2009 at 9:53 AM, Carsten Dominikcarsten.domi...@gmail.com wrote: On Jul 1, 2009, at 2:39 PM, Scot Becker wrote: Is there any easy way that a call to M-X ispell or M-X ispell-buffer could expand all collapsed org-mode nodes before doing the spell check? (defun my-ispell-buffer () (interactive) (show-all) (call-interactively 'ispell-buffer)) HTH - Carsten ___ 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
Re: [Orgmode] Feature or Help request: Expand ALL before ispell-buffer
On Jul 2, 2009, at 11:58 AM, Scot Becker wrote: Of course! I (apparently) don't have the 'emacs mind' quite enough to have thought of that myself, but when i see it, it seems bleeding obvious. Yes, it is easy to forget that all the power of Emacs is for free while using Org. :-) - Carsten Many thanks for that little tutorial. Scot On Thu, Jul 2, 2009 at 9:53 AM, Carsten Dominikcarsten.domi...@gmail.com wrote: On Jul 1, 2009, at 2:39 PM, Scot Becker wrote: Is there any easy way that a call to M-X ispell or M-X ispell-buffer could expand all collapsed org-mode nodes before doing the spell check? (defun my-ispell-buffer () (interactive) (show-all) (call-interactively 'ispell-buffer)) HTH - Carsten ___ 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] problem: emacs hangs when there is an error in latex code
Hi,
First, let me say I think orgmode is just fantastic. I discovered it
recently and pretty much live within it now.
I think however that I have found an issue (I have searched the forums, but
didnt seem to find an answer to my question)
When exporting from org to pdf, if the Latex code has an error, emacs hangs
taking the CPU all the way up.
For example, when trying to org-export-as-pdf the following file:
--
* Some stuff here
\begin{multline}
2+ 3 = 5
\end{multine}
-
my emacs hangs eating 100% of the CPU and needs to be killed from the
terminal.
I am running the git version of Org (6.28trans). And my emacs version is:
23.0.91.1.
I am running this in Ubuntu 64bit.
Manuel Amador
___
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
Re: [Orgmode] Shotcut Icon and PDF problem in the HTML output
Xin Shi shixin...@gmail.com writes:
Hello Experts,
I noticed two problems with recent org publishing HTML with js support.
To make is specific, one can use this page as example:
http://orgmode.org/Changes.html
1.) The shortcut icon is no longer displayed (the small icon in the address
bar)
There seems to be a bug in FF. Opera shows the icon, FF hides it after a
short while. I guess this is due to the new handling of links (maybe FF
finds `link' tags if do `document.getElementsByTagName(a)' ??).
In the HTML, the line is still there:
link rel=SHORTCUT ICON href=/org-mode-unicorn.ico type=image/x-icon /
2.) Print one webpage into PDF is not working:
The browsers print, what's visible on screen. To print the whole page,
press `m' and `F' (repeatadly) until all the sections are visible.
I agree, this is not very elegant/obvious. We could change the media
type the style sheet is for and use a second stylesheet (or section) for
printing. That would be a good thing, as the TOC is printed on each page
now (which is a waste of ink...).
@media all
{
/* Fonts and colors, print and screen */
}
@media screen
{
/* Screen only styles */
}
@media print
{
/* Explicitly show all sections here, no fixed TOC */
}
Not sure if this will help. I'll better experiement with it a bit before
changing the stylesheets online.
What I could do, is to provide a print function though (switch to plain
view-mode, unfold everything automatically and call `window.print()')
Xin Shi, you keep me busy :)
As you see, I have no quick solutions to these problems - but a weekend
of investigations should make things more clear.
Best wishes,
Sebastian
___
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] footnote renumber bug
Hi, after reopening a file with two footnotes inside, inserting a third footnote between first and second, it fails to renumber it. below the test-buffer Should I'm right so far --even seeing footnote reimplemented-- maybe have a look at https://code.launchpad.net/~a-roehler/s-x-emacs-werkstatt/footnote-init.el https://code.launchpad.net/~a-roehler/s-x-emacs-werkstatt/GNU-Emacs-footnote.diff https://code.launchpad.net/~a-roehler/s-x-emacs-werkstatt/XEmacs-footnote.diff Thanks all Andreas Röhler -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ GNU Emacs 23.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2009-05-25 asdfs [fn:1] [fnx:3] sdfs [fn:2] * Footnotes [fn:1] asdfs d [fn:2] x [fn:3] ___ 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
Re: [Orgmode] Changing way hlines in tables are exported?
Carsten Dominik carsten.domi...@gmail.com writes:
On Jun 30, 2009, at 4:15 PM, Rainer Hansen wrote:
Hi,
I wonder if there is an easy way to change the style of the exported hlines
in tables. This should not only be possible per table but per single hline,
e.g. the first hline should be thick and in blue, the next two one are
ordinary ones and the third should be thick and red. This should be possible
for HTML, LaTeX and other export formats.
Not currently, I guess this would need a look by CSS exports. Org
uses the hlines to define different tbody groups.
We could probably assign classes to them, but I don't have a recipe
on how to do this differently on a per-table base. Would get complex,
it would require new #+ inbuffer settings.
Well, this is possible already:
#+ATTR_HTML: class=tableTypeA
| Table Header |
|--|
| Simple rows |
| ... |
|--|
| Table Foot |
CSS:
table.tableTypeA thead { /* styles for the thead ... */ }
table.tableTypeA thead tr { /* styles for tr in thead ... */ }
table.tableTypeA thead td { /* styles for td in thead ... */ }
table.tableTypeA tbody { /* styles for the thead ... */ }
table.tableTypeA tfoot { /* styles for the thead ... */ }
___
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
Re: [Orgmode] problem: emacs hangs when there is an error in latex code
Fixed, thanks.
- Carsten
On Jul 2, 2009, at 7:37 AM, Manuel Amador wrote:
Hi,
First, let me say I think orgmode is just fantastic. I discovered it
recently and pretty much live within it now.
I think however that I have found an issue (I have searched the
forums, but didnt seem to find an answer to my question)
When exporting from org to pdf, if the Latex code has an error,
emacs hangs taking the CPU all the way up.
For example, when trying to org-export-as-pdf the following file:
--
* Some stuff here
\begin{multline}
2+ 3 = 5
\end{multine}
-
my emacs hangs eating 100% of the CPU and needs to be killed from
the terminal.
I am running the git version of Org (6.28trans). And my emacs
version is: 23.0.91.1.
I am running this in Ubuntu 64bit.
Manuel Amador
___
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
___
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
Re: [Orgmode] footnote renumber bug
Andreas Roehler schrieb: after reopening a file with two footnotes inside, inserting a third footnote between first and second, it fails to renumber it. Did you try the new C-u C-c C-x f S feature of the latest git-version? Org does not renumber footnotes automatically when they are inserted. You have to use the command above to do that. BTW: the third footnote marker in your example is [fnx:3]. Shouldn't it be just [fn:3]? Karl ___ 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] German number format in tables?
Hi, I wonder what I need to do to so that I can work with the German number format in tables? E.g. instead of writing 100,000.00 I would like to write 100.000,00. All automatic formatting and calculations of Org-Mode should of course still be fine. The output of calculations should also be shown in German number format. Regards, Rainer ___ 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
Re: [Orgmode] German number format in tables?
On Jul 2, 2009, at 1:54 PM, Rainer Hansen wrote: Hi, I wonder what I need to do to so that I can work with the German number format in tables? E.g. instead of writing 100,000.00 I would like to write 100.000,00. All automatic formatting and calculations of Org-Mode should of course still be fine. The output of calculations should also be shown in German number format. I don't think calc can write such formats. Much worse, it cannot read them back in. If this is for publishing, your best bet would be to write a function that will change this during publishing and hook it into the publishing preprocessor. In an Org-buffer, writing numbers like this would be a very bad idea. - Carsten Regards, Rainer ___ 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 ___ 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
Re: [Orgmode] footnote renumber bug
Karl Maihofer wrote: Andreas Roehler schrieb: after reopening a file with two footnotes inside, inserting a third footnote between first and second, it fails to renumber it. Did you try the new C-u C-c C-x f S feature of the latest git-version? No. Just check this feature for curiosity, as I dealt with that bug at common footnote.el Org does not renumber footnotes automatically when they are inserted. You have to use the command above to do that. IMO a decent program should renumber automatically. Patched footnote.el meanwhile does if called with footnote-init. Unfortunately your footnote-machine is written fairly different from footnote.el. Otherwise I'd send a patch. BTW: the third footnote marker in your example is [fnx:3]. Shouldn't it be just [fn:3]? Probably a typo caused by mail-writing. Grüße Andreas Karl ___ 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 ___ 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] Re: footnote renumber bug
Andreas Röhler andreas.roeh...@easy-emacs.de writes: Karl Maihofer wrote: Andreas Roehler schrieb: after reopening a file with two footnotes inside, inserting a third footnote between first and second, it fails to renumber it. Did you try the new C-u C-c C-x f S feature of the latest git-version? No. Just check this feature for curiosity, as I dealt with that bug at common footnote.el Org does not renumber footnotes automatically when they are inserted. You have to use the command above to do that. IMO a decent program should renumber automatically. Patched footnote.el meanwhile does if called with footnote-init. Unfortunately your footnote-machine is written fairly different from footnote.el. Otherwise I'd send a patch. There is nothing preventing a user from using footnote.el (and your patch) within org mode instead of the built in org-footnote-action. Simply set up a hook to load footnote-mode for org files. But the lack of automatic renumbering in org-footnote is *not* a bug. Unlike footnote.el, org-mode views footnote notation primarily as markup, not as some form of final output. The source text simply contains footnote markup, which can be exported as normalized footnotes. And of course, at any point, user has the option of normalizing footnotes in the source text if he/she so desires. Footnote.el, by contrast, was designed for short email messages in which there is no distinction between source text and exported text. Though it serves this limited purpose admirably, it offers only a very rudimentary numbering system rather than a complete markup solution. For any complex writing (e.g., a research paper with dozens of footnotes), footnote.el is well-nigh impossible to use. There are simply too many chances of broken or mixed up links. Org-mode's handling of footnotes is considerably more robust. Several different types of footnote styles are available: - numbered[1] - labeled[fn:label] - inline[fn::Here is an inline footnote.] Footnotes: [1] Numbered [fn:label] Here is a labeled footnote. -- All of these can be mixed together in the same document. Upon export to pdf, ascii, or html they will be properly sorted and numbered, but the labels in the source will remain the same, ensuring that the source text remains *exactly* as the user wants it to be. At any point, however, the user can sort and/or renumber the footnotes in the source text. For instance, the footnotes above can very quickly and easily converted to the following: , | | - numbered[1] | | - labeled[2] | | - inline[3] | | Footnotes: | | [1] Numbered | | [2] Here is a labeled footnote. | | [3] Here is an inline footnote. ` The key here, however, is that the process is completely under the user's control. Footnotes will not be sorted or reorganized in the source text unless the user desires it. In my view, this is the proper behavior for a robust markup system. The whole point of markup is to avoid the sorts of automated, global alterations of the source text that are characteristic of word-processors. With labeled footnotes in org-footnote, I can rearrange my text and rest assured that none of my footnote links will be broken. And if I delete a footnote reference without deleting its corresponding definition (or vice-versa), org-mode will alert me to the problem when I export or sort the footnotes. All this is to explain why the lack of automatic renumbering is *not* a bug. And of course, anyone who prefers a different behavior can easily use footnote.el instead. Regards, Matt ___ 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] Re: footnote renumber bug
Matthew Lundin m...@imapmail.org writes: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Karl Maihofer wrote: Andreas Roehler schrieb: after reopening a file with two footnotes inside, inserting a third footnote between first and second, it fails to renumber it. A follow up to my previous email: Though org-mode does not automatically renumber footnotes, it does a fantastic job of detecting footnotes that already exist in a file and creating uniquely numbered footnote IDs for each new footnote. For this one needs either of the following settings: (setq org-footnote-auto-label t) or (setq org-footnote-auto-label 'plain) Best, Matt ___ 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] Re: footnote renumber bug
Matthew Lundin wrote: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Karl Maihofer wrote: Andreas Roehler schrieb: after reopening a file with two footnotes inside, inserting a third footnote between first and second, it fails to renumber it. Did you try the new C-u C-c C-x f S feature of the latest git-version? No. Just check this feature for curiosity, as I dealt with that bug at common footnote.el Org does not renumber footnotes automatically when they are inserted. You have to use the command above to do that. IMO a decent program should renumber automatically. Patched footnote.el meanwhile does if called with footnote-init. Unfortunately your footnote-machine is written fairly different from footnote.el. Otherwise I'd send a patch. There is nothing preventing a user from using footnote.el (and your patch) within org mode instead of the built in org-footnote-action. Simply set up a hook to load footnote-mode for org files. But the lack of automatic renumbering in org-footnote is *not* a bug. Unlike footnote.el, org-mode views footnote notation primarily as markup, not as some form of final output. The source text simply contains footnote markup, which can be exported as normalized footnotes. And of course, at any point, user has the option of normalizing footnotes in the source text if he/she so desires. Footnote.el, by contrast, was designed for short email messages in which there is no distinction between source text and exported text. Though it serves this limited purpose admirably, it offers only a very rudimentary numbering system rather than a complete markup solution. For any complex writing (e.g., a research paper with dozens of footnotes), footnote.el is well-nigh impossible to use. There are simply too many chances of broken or mixed up links. Hi Matthew, thanks for you explanation. As often several solutions are possible and different people choose different options. Ignoring the guts of org-modes footnote implementation, just my impression of footnote.el: it's fine by architecture and --if patched-- well capable for all things you want to do with footnotes. Can't see any limitation concerning larger texts. It simply wasn't --or isn't-- written to the end. Org-mode's handling of footnotes is considerably more robust. Several different types of footnote styles are available: - numbered[1] - labeled[fn:label] - inline[fn::Here is an inline footnote.] Footnotes: [1] Numbered [fn:label] Here is a labeled footnote. -- All of these can be mixed together in the same document. Upon export to pdf, ascii, or html they will be properly sorted and numbered, but the labels in the source will remain the same, ensuring that the source text remains *exactly* as the user wants it to be. At any point, however, the user can sort and/or renumber the footnotes in the source text. For instance, the footnotes above can very quickly and easily converted to the following: , | | - numbered[1] | | - labeled[2] | | - inline[3] | | Footnotes: | | [1] Numbered | | [2] Here is a labeled footnote. | | [3] Here is an inline footnote. ` Transformation looks interesting indeed. Should org-modes footnote better fit my purposes, I'll not hesitate to use it. Andreas The key here, however, is that the process is completely under the user's control. Footnotes will not be sorted or reorganized in the source text unless the user desires it. In my view, this is the proper behavior for a robust markup system. The whole point of markup is to avoid the sorts of automated, global alterations of the source text that are characteristic of word-processors. With labeled footnotes in org-footnote, I can rearrange my text and rest assured that none of my footnote links will be broken. And if I delete a footnote reference without deleting its corresponding definition (or vice-versa), org-mode will alert me to the problem when I export or sort the footnotes. All this is to explain why the lack of automatic renumbering is *not* a bug. And of course, anyone who prefers a different behavior can easily use footnote.el instead. Regards, Matt ___ 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] Re: LaTeX export bugs?
Hi Carsten,
Carsten Dominik wrote:
Sébastien Vauban wrote:
Other things I've noticed:
- Even with version 6.28, the `#+TBLNAME' tag must be located in column 0
(at least, for the highlighting features to work)
Fixed, thanks.
Euh, no, *I* am supposed to answer: Fixed, thanks, and I'm doing it... ;-)
- Remote references to other tables are great, but they only work with
absolute references, not with named cells.
They actually do work fine. A call like remote(mytbl,$name) will work
in this table
| _ | name |
| | value |
OK. I did not understand from the doc (section 3.5.1) that I had to prefix the
name of the cell with $:
REF is an absolute field [...] as described above.
I admit that, knowing it, I understand the above text better. Maybe is such
an example missing?
Now, more important question, one of the few that's not answered from my
previous post: how can I shade or frame a table? For me, inserting #+LaTeX
tags is different from inserting #+BEGIN_LaTeX and #+END_LaTeX tags: the first
one should have no impact on the rest of the text.
Though, it isn't as you can see with my following example:
--8---cut here---start-8---
#+LaTeX: \begin{framed}
#+ATTR_LaTeX: align=lrrr
| Code | \euro{} | \% | \euro{} |
|---+-+-+-|
| GSM | | |0.00 |
| Internet | 168.45 | 100 | 168.45 |
| Matériel | 295.99 | 100 | 295.99 |
| Publicité | 214.25 | 33 | 70.70 |
| Autres| | |0.00 |
|---+-+-+-|
| Total | | | 535.14 |
#+TBLFM: $4=$2*$3/100;%.2f::@7$4=vsum(@-...@-ii)
#+LaTeX: \end{framed}
--8---cut here---end---8---
Am I misunderstanding section 12.7.2 or is this a feature?
Best regards,
Seb
--
Sébastien Vauban
___
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
Re: [Orgmode] Re: Release 6.28
On Jul 1, 2009, at 12:26 PM, Christian Egli wrote: Hi all Carsten Dominik carsten.domi...@gmail.com writes: On Jul 1, 2009, at 9:20 AM, Ulf Stegemann wrote: Carsten Dominik carsten.domi...@gmail.com wrote: Bulk action We can add more actions, if you convince me they make sense. IMHO setting scheduled (and maybe deadline) date would make sense. In what sense? Shifting all dates by the same amount, or setting them all to a fixed date? I usually display unscheduled TODO items in my agenda as well (org-agenda-include-all-todo), so if I decide that I should work on some of them next week then a bulk action to schedule them might come in handy. So one use case is to set a fixed scheduled date for a number of TODOs. In my case these are tasks that have not been scheduled yet. Another use case is when I decide that there will not be enough time this week to complete all scheduled tasks. I want to move some of the tasks to next week. This could be either a shift by 7 days or a rescheduling to next monday (a fixed date). This should work now, I added s and d as bulk commands. Both commands will prompt for a date, and that date will be set for all entries. If you specify something like ++2d at the prompt, all dates will be shifted by the same amount. - Carsten ___ 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
Re: [Orgmode] error while updating from git
Fixed, thanks. - Carsten On Jul 2, 2009, at 11:02 PM, Manuel Amador wrote: I tried to update org from git. and after doing the pull, i get the following error: $ git pull make clean make make doc In toplevel form: lisp/org-latex.el:1699:29:Error: Invalid read syntax: ) make: *** [lisp/org-latex.elc] Error 1 My emacs version is: 23.0.91.1 on Ubuntu 64bit. Manuel ___ 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 ___ 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] Ignore sub-items of Scheduled TODOs?
Hello, I'd like to know the best way for removing TODO items from the agenda if they have a parent item that's been scheduled. Currently, I have items like this: * TODO top level item, scheduled for future SCHEDULED: 2009-07-16 Thu ** TODO A sub-item I don't want to see until 7/16 ** TODO Another sub-item I don't want to see until 7/16 If I set org-agenda-todo-ignore-with-date to non-nil and go to the agenda C-c a a, then I still see the second and third todos. Is this a bug, or is there a quick way of removing these todos that are under a scheduled item from the agenda list? Or, am I probably going about this the wrong way? Thanks, --Nate ___ 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] Re: Ignore sub-items of Scheduled TODOs?
Nathan Neff nathan.n...@gmail.com writes: Hello, I'd like to know the best way for removing TODO items from the agenda if they have a parent item that's been scheduled. Currently, I have items like this: * TODO top level item, scheduled for future SCHEDULED: 2009-07-16 Thu ** TODO A sub-item I don't want to see until 7/16 ** TODO Another sub-item I don't want to see until 7/16 If I set org-agenda-todo-ignore-with-date to non-nil and go to the agenda C-c a a, then I still see the second and third todos. Is this a bug, or is there a quick way of removing these todos that are under a scheduled item from the agenda list? Or, am I probably going about this the wrong way? Probably the simplest thing to do is to add SCHEDULED timestamps to the sub-items as well. As I understand it, org-mode timestamps cannot be inherited by subheadings. I imagine someone else will quickly come along and correct me if I'm wrong. :) Best, Matt ___ 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] Publishing change
Hi, I have just pushed a change to the publishing system that implements better support for publishing files in multiple ways, for example HTML and as source file. This change means that all of your files will be republished once, in order to create the new timestamp files. After that first republishing, everything should be back to normal. You don't need to do anything special, just don't be surprised if the next time you publish a project, the entire projects will be republished. You might even consider to clear out the .org-timestamps directory once, to get rid of any old timestamp files which will no longer be used. - Carsten ___ 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
Re: [Orgmode] Re: LaTeX export bugs?
On Jul 2, 2009, at 10:40 PM, Sébastien Vauban wrote:
Hi Carsten,
Carsten Dominik wrote:
Sébastien Vauban wrote:
Other things I've noticed:
- Even with version 6.28, the `#+TBLNAME' tag must be located in
column 0
(at least, for the highlighting features to work)
Fixed, thanks.
Euh, no, *I* am supposed to answer: Fixed, thanks, and I'm doing
it... ;-)
The thanks is short for thanks for your report/idea :-)
- Remote references to other tables are great, but they only work
with
absolute references, not with named cells.
They actually do work fine. A call like remote(mytbl,$name) will
work
in this table
| _ | name |
| | value |
OK. I did not understand from the doc (section 3.5.1) that I had to
prefix the
name of the cell with $:
REF is an absolute field [...] as described above.
I admit that, knowing it, I understand the above text better. Maybe
is such
an example missing?
Fixed, thanks.
Now, more important question, one of the few that's not answered
from my
previous post: how can I shade or frame a table? For me, inserting #
+LaTeX
tags is different from inserting #+BEGIN_LaTeX and #+END_LaTeX tags:
the first
one should have no impact on the rest of the text.
Though, it isn't as you can see with my following example:
--8---cut here---start-8---
#+LaTeX: \begin{framed}
#+ATTR_LaTeX: align=lrrr
| Code | \euro{} | \% | \euro{} |
|---+-+-+-|
| GSM | | |0.00 |
| Internet | 168.45 | 100 | 168.45 |
| Matériel | 295.99 | 100 | 295.99 |
| Publicité | 214.25 | 33 | 70.70 |
| Autres| | |0.00 |
|---+-+-+-|
| Total | | | 535.14 |
#+TBLFM: $4=$2*$3/100;%.2f::@7$4=vsum(@-...@-ii)
#+LaTeX: \end{framed}
--8---cut here---end---8---
Am I misunderstanding section 12.7.2 or is this a feature?
This does not work. What is happening here is that during
LaTeX export, these begin/end lines are inserted into the buffer.
Then the LaTeX exporter marks the entire content of this environment
as something that should be exported literally to LaTeX, this is
why you can write
\begin{equation}
a=b
\end{equation}
and it will all be exported literally to LaTeX.
The fact that the table is transformed into a LaTeX table at
all is actually a bug which I will fix.
So there is not really a standard way to do what you want.
However, you could take a look as Chris Gray's contributes package
org-special-blocks.el
http://orgmode.org/worg/org-contrib/org-special-blocks.php
which was made just for this use case.
Another workaround (hack, really) would be
#+LATEX_HEADER: \def\noop{}
\noop\begin{framed}
...
\noop\end{framed}
This will trick Org-mode by not having the \begin macro at
the beginning of a line, so it will not protect the content
of the environment. Dirty, but works.
HTH
- Carsten
___
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
