Re: [O] Makefile restructuring
Hi Achim, Achim Gratz writes: > Bastien writes: >> Please test this and report any problem while using make >> to install Org. > > Here's another refinement to make "oldorg" the default target unless > local.mk is actively edited by the user. Applied, thanks. -- Bastien
Re: [O] Babel: communicating irregular data to R source-code block
Michael Hannon writes:
> On Wednesday, April 25, 2012 at 4:52 PM Thomas S. Dye wrote:
>
>>Michael Hannon writes:
>>
>>> On Monday, April 23, 2012 at 11:44 PM Thomas S. Dye wrote:
>>> .
>>> .
>>> .
The documentation of read.table has this:
>>>
The number of data columns is determined by looking at the first five
lines
of input (or the whole file if it has less than five lines), or from the
length of col.names if it is specified and is longer. This could
conceivably
be wrong if fill or blank.lines.skip are true, so specify col.names if
necessary (as in the ‘Examples’).
>>>
The example is this:
>>>
read.csv(tf, fill = TRUE, header = FALSE,
col.names = paste("V", seq_len(ncol), sep = ""))
>>>
where read.csv is a synonym of read.table with preset arguments.
>>>
This explains why the sixth line wraps.
>>> .
>>> .
>>> .
>>>
>>> Thanks, Tom. I had just run across this myself. I guess I need to walk a
>>> mile
>>> in somebody's moccasins before complaining, but this behavior on the part
>>> of R
>>> seems totally stupid to me.
>>>
>>> I'm going to have to mull this over some more.
>>>
>>> -- Mike
>>>
>>>
>>Aloha Mike,
>>
>>Eric Schulte has pushed up some patches designed to make R source block
>>variables accept irregular data. So, with pascals-triangle(8), for
>>instance, one gets a potentially useful dataframe in R:
>>
>>#+NAME: sanity-check
>>#+HEADER: :var sc_input=pascals-triangle
>>#+BEGIN_SRC R
>>sc_input
>>#+END_SRC
>>
>>#+RESULTS: sanity-check
>>| 1 | nil | nil | nil | nil | nil | nil | nil | nil |
>>| 1 | 1 | nil | nil | nil | nil | nil | nil | nil |
>>| 1 | 2 | 1 | nil | nil | nil | nil | nil | nil |
>>| 1 | 3 | 3 | 1 | nil | nil | nil | nil | nil |
>>| 1 | 4 | 6 | 4 | 1 | nil | nil | nil | nil |
>>| 1 | 5 | 10 | 10 | 5 | 1 | nil | nil | nil |
>>| 1 | 6 | 15 | 20 | 15 | 6 | 1 | nil | nil |
>>| 1 | 7 | 21 | 35 | 35 | 21 | 7 | 1 | nil |
>>| 1 | 8 | 28 | 56 | 70 | 56 | 28 | 8 | 1 |
>>
>>Could you pull the development version of Org mode and see if this
>>solves your problem?
>
> Well, NOW you've done it! Just when I thought I could beg off on this talk,
> it all seems to be working ;-) Thanks, Tom and Eric.
>
> I've appended a sample output, just FYI. I also tried it for n=7 and got the
> correct results. Magic!
>
> As an aside, the rows of the Pascal Triangle should sum to 2^n, which they do
> in my test cases. I haven't yet implemented Eric's (much sexier)
> "sum(sub-diagonal-elements) == Fibonacci nos." test, but I'll look into it.
>
> Thanks again,
>
> -- Mike
Good news. Please consider sharing your seminar talk on Worg, if you
think it might be appropriate.
All the best,
Tom
>
> #
>
> Org-mode version 7.8.09 (release_7.8.09-390-gfb7ebd @
> /usr/local/emacs.d/org-mode/org-devel/org-mode/lisp/org-install.el)
>
> -
>
> #+PROPERTY: session *R*
> * verify PT
>
> #+name: pascals_triangle
> #+begin_src python :var n=5 :exports none :results value
> def pascals_triangle(n):
> if n == 0:
> return [[1]]
> prev_triangle = pascals_triangle(n-1)
> prev_row = prev_triangle[n-1]
> this_row = map(sum, zip([0] + prev_row, prev_row + [0]))
> return prev_triangle + [this_row]
>
> pascals_triangle(n)
> #+end_src
>
> #+RESULTS: pascals_triangle
> | 1 | | | | | |
> | 1 | 1 | | | | |
> | 1 | 2 | 1 | | | |
> | 1 | 3 | 3 | 1 | | |
> | 1 | 4 | 6 | 4 | 1 | |
> | 1 | 5 | 10 | 10 | 5 | 1 |
>
>
> #+NAME: sanity-check(sc_input=pascals_triangle)
> #+BEGIN_SRC R :fill yes :results output
>
> pt <- sc_input
> pt[is.na(pt)] <- 0
> rowSums(pt)
>
>
> #+END_SRC
>
> #+RESULTS: sanity-check
> : [1] 1 2 4 8 16 32
>
>
--
Thomas S. Dye
http://www.tsdye.com
[O] missing autoloads / (void-variable org-version)
Since my Makefile branch was merged I've been getting flak for breaking certain setups. Now, the change didn't actually break them, but I did make (perhaps foolishly) a deliberate decision to make that particular breakage fatal rather than silent. It would be very easy to continue to paper over the breakage and pretend things are working when they're not. What irritates me greatly is that quite a few of the people that insist on this "solution" are the ones who would have to deal with the Heisenbugs thus introduced. So let me explain once more what is broken: Consider a core emacs library "test", consisting of the main "test.el" and auxiliary functions in "test-aux.el". The main entry points are in "test.el" and thus you'd "(require 'test)" in your .emacs to activate the package. The auxiliary functions are not needed in "test.el", so to make them available to the user or whatever function that needs to call them, these entry points are autoloaded (let's say the only function there is "test-aux"). When this package gets installed into emacs, the autoload forms will be extracted into "loaddefs.el" in the main lisp directory. You can then call "(test-aux)" without having to explicitly load "test-aux.el", since the autoload form has registered that association and will load "test-aux.el" automatically when encountering the first use of the function test-aux. Now the development version of this same package gets installed locally. The load-path is altered so that emacs finds the development version first. Thus "(require 'test)" will load the development version. If you now try to "(test-aux)", what happens? Autoload still has all the associations from "loaddefs.el" and thus tries to load "test-aux.el", which will end up finding the file in the development version. So all is well, right? Development progresses and as "test.el" grows larger some functions are moved to "test-extra.el". Also, "test-aux.el" is split into "test-aux1.el", while the function test-aux (yes, the same name as the old, but with different arguments) is moved to "test-aux2.el". The functions in "test-extra.el" become unavailable since autoload doesn't know about them — unless you explicitely load "test-aux.el" of course. Also, the calls to "(test-aux)" flip-flop between calling the old and new test-aux: if that call is made before a load of "test-aux2.el", emacs will look for it in "test-aux.el" and only find that file in its own install directory. If you happened to have loaded "test-aux2.el" (maybe due to a "(require 'test-aux2)" in "test-extra.el"), then the new definition of "(test-aux)" will be used. So you will have irritated users and developers alike and bugs that don't reproduce (or only with certain versions of emacs that happen to have specific versions of library test integrated). The real solution of course is to re-generate the autoloads file for the development version and explicitely load it, say "(require 'test-install)". That still leaves an open flank if you delete both a function and it's associated source file from the development version: if someone then uses "(test-deleted-function)", the autoload definition in Emacs will happily find the stale source it has installed since it is not shadowed anymore by the same file in the development version. I've no idea yet if that is fixable without touching the actual installation and how difficult it would be, but that's a minor worry at this point. If you've made it here, please weigh in on whether you want to have things correctly fixed or simply papered over. Either one is fine with me... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] HTML export fails with (void-variable org-version)
Bernt Hansen writes: > I tried that... and installed emacs under Cygwin (so it can find emacs > to run emacs -batch) and then had to fix permissions on org-install > (since it's on a windows drive) before make autoloads worked. It's preferrable to use NTEmacs for this step, even though the .elc files should be compatible. > I didn't spend any time trying to correct install locations in the > makefile. I run org-mode without compiling any sources normally and > having to do the extra make step each time I move around the source tree > isn't going to be very enjoyable. I have no idea if I need to rerun > this make autoloads command on a regular basis or not. Yes and no. As long as all the autoloaded functions continue to be in the same load-file and their names don't change and there are no new functions that need to be autoloaded, org-install.el effectively isn't going to change. But that's a deception, since there is no way you could determine if it should have been changed unless you actually generate it anew. As I said, I'm still working to provide specifically for the case that org-version.el is missing (which would normally produce an autoloaded defconst org-version...) and injecting an org-version from looking at the git version of the work-tree (if it finds one). That will also encompass an (autoloaded) function (with the load-file located in UTILITIES/ most likely) that you can call in emacs to re-generate org-install.el, since org-install.el is absolutely not optional. So going forward make will not be a requirement for simply using org either from Git or from tarball anymore. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] error on opening org-file with #+startup: indent
fkunze writes: > Regarding the installation instructions: At first I started here > (http://orgmode.org/manual/Installation.html#Installation) but since I am > running on windows 7, I have no access to "Make". I want to avoid installing > cywin as it typically fails to track windows 7 x64. As far as I can tell, > make > is unnecessary as well since you can hand compile all the files (as I > described > in my bug report). It's my mistake that I failed to notice the requirement to > add (require 'org-install). The make from MSys would also work. Again, it is not the (missing or not) byte-compilation that is the problem. I plan to provide a way to generate the autoloads without make, maybe even automatically when they are determined to be missing. Until then you'd have to do this by hand; start emacs (preferrably with options "--no-init -Q -l autoload") and enter this into the scratch buffer (the path must be an absolute one): --8<---cut here---start->8--- (setq generated-autoload-file "~/.emacs.d/org-7.8.09/lisp/org-install.el") (update-directory-autoloads "lisp") --8<---cut here---end--->8--- Then move the cursor to the end of each line and press C-j Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Babel: communicating irregular data to R source-code block
On Wednesday, April 25, 2012 at 4:52 PM Thomas S. Dye wrote:
>Michael Hannon writes:
>
>> On Monday, April 23, 2012 at 11:44 PM Thomas S. Dye wrote:
>> .
>> .
>> .
>>> The documentation of read.table has this:
>>
>>> The number of data columns is determined by looking at the first five
>>> lines
>>> of input (or the whole file if it has less than five lines), or from the
>>> length of col.names if it is specified and is longer. This could
>>> conceivably
>>> be wrong if fill or blank.lines.skip are true, so specify col.names if
>>> necessary (as in the ‘Examples’).
>>
>>> The example is this:
>>
>>> read.csv(tf, fill = TRUE, header = FALSE,
>>> col.names = paste("V", seq_len(ncol), sep = ""))
>>
>>> where read.csv is a synonym of read.table with preset arguments.
>>
>>> This explains why the sixth line wraps.
>> .
>> .
>> .
>>
>> Thanks, Tom. I had just run across this myself. I guess I need to walk a
>> mile
>> in somebody's moccasins before complaining, but this behavior on the part
>> of R
>> seems totally stupid to me.
>>
>> I'm going to have to mull this over some more.
>>
>> -- Mike
>>
>>
>Aloha Mike,
>
>Eric Schulte has pushed up some patches designed to make R source block
>variables accept irregular data. So, with pascals-triangle(8), for
>instance, one gets a potentially useful dataframe in R:
>
>#+NAME: sanity-check
>#+HEADER: :var sc_input=pascals-triangle
>#+BEGIN_SRC R
>sc_input
>#+END_SRC
>
>#+RESULTS: sanity-check
>| 1 | nil | nil | nil | nil | nil | nil | nil | nil |
>| 1 | 1 | nil | nil | nil | nil | nil | nil | nil |
>| 1 | 2 | 1 | nil | nil | nil | nil | nil | nil |
>| 1 | 3 | 3 | 1 | nil | nil | nil | nil | nil |
>| 1 | 4 | 6 | 4 | 1 | nil | nil | nil | nil |
>| 1 | 5 | 10 | 10 | 5 | 1 | nil | nil | nil |
>| 1 | 6 | 15 | 20 | 15 | 6 | 1 | nil | nil |
>| 1 | 7 | 21 | 35 | 35 | 21 | 7 | 1 | nil |
>| 1 | 8 | 28 | 56 | 70 | 56 | 28 | 8 | 1 |
>
>Could you pull the development version of Org mode and see if this
>solves your problem?
Well, NOW you've done it! Just when I thought I could beg off on this talk,
it all seems to be working ;-) Thanks, Tom and Eric.
I've appended a sample output, just FYI. I also tried it for n=7 and got the
correct results. Magic!
As an aside, the rows of the Pascal Triangle should sum to 2^n, which they do
in my test cases. I haven't yet implemented Eric's (much sexier)
"sum(sub-diagonal-elements) == Fibonacci nos." test, but I'll look into it.
Thanks again,
-- Mike
#
Org-mode version 7.8.09 (release_7.8.09-390-gfb7ebd @
/usr/local/emacs.d/org-mode/org-devel/org-mode/lisp/org-install.el)
-
#+PROPERTY: session *R*
* verify PT
#+name: pascals_triangle
#+begin_src python :var n=5 :exports none :results value
def pascals_triangle(n):
if n == 0:
return [[1]]
prev_triangle = pascals_triangle(n-1)
prev_row = prev_triangle[n-1]
this_row = map(sum, zip([0] + prev_row, prev_row + [0]))
return prev_triangle + [this_row]
pascals_triangle(n)
#+end_src
#+RESULTS: pascals_triangle
| 1 | | | | | |
| 1 | 1 | | | | |
| 1 | 2 | 1 | | | |
| 1 | 3 | 3 | 1 | | |
| 1 | 4 | 6 | 4 | 1 | |
| 1 | 5 | 10 | 10 | 5 | 1 |
#+NAME: sanity-check(sc_input=pascals_triangle)
#+BEGIN_SRC R :fill yes :results output
pt <- sc_input
pt[is.na(pt)] <- 0
rowSums(pt)
#+END_SRC
#+RESULTS: sanity-check
: [1] 1 2 4 8 16 32
Re: [O] Google Summer of Code -- 3 Org projects for our first participation!
This is way cool! Recently I have been deeply irritated by the lack of a functional server for Emacs Org Mode. I've run into this problem dealing with the weak presentation of Org Mode files on Github. Github uses the Ruby gem org-ruby (https://github.com/bdewey/org-ruby) to convert .org files to HTML. I've added a feature or two to org-ruby but really feel that trying to completely re-implement Org Mode in a Ruby gem is a losing battle. If I understand the project correctly, a working iOrg could be used to support Github's rendering of .org files. Github could just drop the use of org-ruby and use iOrg as an external converter for formatting .org files. At the risk of being flamed to a cinder, I'll say that I think that using iOrg to support .org files on Github would be a better pilot project than Bugpile. Besides my personal interest in better Github support for .org, I think that the Github project will be generally useful. Also, from the tone of postings, it sounds like the Bugpile project is not well specified. Being that Thorsten only has a summer to do the work, I think it will be hard to create a Bugpile specification and implementation and an iOrg specification and implementation in just one summer. As Github already has a specification for external markup converters (see https://github.com/github/markup), there is no need for writing any spec. For the first release of iOrg (ie: this summer's work), the iOrg implementation can be simplified to providing .org support for Github. If things go well, I imagine that Thorsten would be very happy to finish the summer with his iOrg a part of Github. Just my two cents, Neil PS: And the answer is "Yes. I am aware that vehemently suggesting a project is equivalent to offering to help with it." :-D I can help with the .org/Github side of the project though I'm sure others know more about the implementation of Org Mode than me. If needed, I could also help manage interactions between Thorsten and Github as I'm sure that Github will have some requirements before they accept a pull request into their repository. As far as Emacs internals, it's been 25 years since I last looked at the C source for Emacs so there must be better folk than I. In any case, any Emacs internal work that must be done for iOrg existed prior to my suggestion. In other words, it ain't my problem ;-) Neil Smithline http://www.neilsmithline.com Proud GNU Emacs user since 1986, v. 18.24. On 4/24 04:12 , Thorsten wrote: Ian Barton writes: Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and Org-mode (Thorsten) The Bugpile project has two goals: 1. Develop a bugtracker (called Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a dVCS. 2. As part of the engineering process, abstract out a web-framework (called iOrg) based on these GNU Emacs technologies. A web-framework written in Elisp, with Org files used for database functionality, is a new approach that enables interactive web applications built on top of GNU Emacs. Bugpile is an example application, but useful in itself. Great news! For the dim witted (me) can you explain if Bugpile is meant to be a bug tracker specifically for tracking bugs in Emacs and org, or can it be used as a generic bug tracker for any project. Thats a very interesting question, since there are two somehow conflicting goals involved. The original project idea was to extend Org-mode for a more interactive kind of web-programming, i.e. having buttons and forms on your webpages and a kind of database in the background that stores changing state, and some logic that reacts to user action (instead of just publishing static web content). Bugpile is kind of a (useful) pilot project for this idea, and during its development an Emacs/Org-mode based web-framework (iOrg=interactive Org) should emerge. Because this is about interactive web programming, bugpile should be rather generic and accessible for anybody - they don't need Emacs, they can use the web UI. A web-based bugtracker is nothing new, one could just choose one out of several free tools on the market. The exciting thing is being able to write one based on Org-mode and other Emacs libraries like Elnode, i.e. developing the web-frameworg iOrg. On the other hand, Emacs user don't like to use web-interfaces, they want to use Emacs to interact with the application. Thus the USP of bugpile could be that it is not only written on top of Emacs, but can be efficiently used from inside Emacs. Since time is limited, the main goal of the project is to develop the iOrg webframework and the generic webbased bugtracker bugpile as a tangible pilot project/ proof of concept. An optional, but highly desirable additional output would be a Magit-like bugpile-mode for Emacs. But I would prefer to keep it optional to limit the scope of my GSoC project. This is still not defined, I would be happy about some
Re: [O] Exporting to ACM format using new LaTeX exporter
Karl Voit writes: > * Thomas S. Dye wrote: >> >> AFAICT, the new exporter preserves most of the interface of the old >> exporter, but smooths over some of the rough edges. It shouldn't >> represent a barrier to your contribution. In fact, it might be useful >> to write a template for both exporters, then document how they differ as >> a guide to using the new exporter. > > Good idea! > >> I took a brief look at the ACM web site and saw that there is more than >> one LaTeX template. Which one are you interested in for Org-mode? > > I took the "Option 1: LaTeX2e - Strict Adherence to SIGS style" > >> Do you have a repository for the project? > > Yea, that might be appropriate. So I set up a github repos: > > https://github.com/novoid/orgmode-ACM-template > Hi Karl, Got it, thanks. IIUC, you'd like to configure Org-mode to export a LaTeX file that is functionally equivalent to sigproc-sp.tex. If this is the case, it might be best to change the name of orgmode.org to sigproc-sp.org or something similar. If the goal is to support both exporters, perhaps sigproc-sp-old.org and sigproc-sp-new.org? In my view, it is best to encapsulate as much of the Org-mode configuration as possible in an init.el file. That way, users of the Org-mode template can launch with emacs -Q etc. and not have to worry about their own customizations that might conflict with the configuration. An example is here: https://github.com/tsdye/LKFS.git. Perhaps two initialization files would be needed: init-new.el and init-old.el? > With the new exporter, I was not able to compile the Org-mode file > at all. Since the old exporter had troubles using this > "per-file-class" I do have a feeling that this might be the cause > for the error message with the new exporter too. I'll have a look at this and send you patches off list. > > Maybe someone more familiar with the (new) LaTeX exporter can send > me some patches ... All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Babel: communicating irregular data to R source-code block
Michael Hannon writes:
> On Monday, April 23, 2012 at 11:44 PM Thomas S. Dye wrote:
> .
> .
> .
>> The documentation of read.table has this:
>
>> The number of data columns is determined by looking at the first five lines
>> of input (or the whole file if it has less than five lines), or from the
>> length of col.names if it is specified and is longer. This could conceivably
>> be wrong if fill or blank.lines.skip are true, so specify col.names if
>> necessary (as in the ‘Examples’).
>
>> The example is this:
>
>> read.csv(tf, fill = TRUE, header = FALSE,
>> col.names = paste("V", seq_len(ncol), sep = ""))
>
>> where read.csv is a synonym of read.table with preset arguments.
>
>> This explains why the sixth line wraps.
> .
> .
> .
>
> Thanks, Tom. I had just run across this myself. I guess I need to walk a mile
> in somebody's moccasins before complaining, but this behavior on the part of R
> seems totally stupid to me.
>
> I'm going to have to mull this over some more.
>
> -- Mike
>
>
Aloha Mike,
Eric Schulte has pushed up some patches designed to make R source block
variables accept irregular data. So, with pascals-triangle(8), for
instance, one gets a potentially useful dataframe in R:
#+NAME: sanity-check
#+HEADER: :var sc_input=pascals-triangle
#+BEGIN_SRC R
sc_input
#+END_SRC
#+RESULTS: sanity-check
| 1 | nil | nil | nil | nil | nil | nil | nil | nil |
| 1 | 1 | nil | nil | nil | nil | nil | nil | nil |
| 1 | 2 | 1 | nil | nil | nil | nil | nil | nil |
| 1 | 3 | 3 | 1 | nil | nil | nil | nil | nil |
| 1 | 4 | 6 | 4 | 1 | nil | nil | nil | nil |
| 1 | 5 | 10 | 10 | 5 | 1 | nil | nil | nil |
| 1 | 6 | 15 | 20 | 15 | 6 | 1 | nil | nil |
| 1 | 7 | 21 | 35 | 35 | 21 | 7 | 1 | nil |
| 1 | 8 | 28 | 56 | 70 | 56 | 28 | 8 | 1 |
Could you pull the development version of Org mode and see if this
solves your problem?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
Matt Lundin writes: > Bastien writes: > >> Toby Cubitt writes: >> >>> In the patch I posted, I also took the opportunity to set >>> `cursor-type' to nil when opening the calendar in `org-read-date'. >>> The cursor obscures one digit of the selected date, making that bit >>> harder to read (as well as looking ugly). Did you intend to reject >>> this change too? >> >> I did because I found the not-bold-anymore face wasn't visible enough, >> and the shallow cursor made it visible. >> >> I use inverse-video now for this face, so cursor-type nil is okay, I >> applied a patch with this. > > This patch broke org-read-date. It will no longer parse date strings > such as "Aug 15" correctly, instead inserting the current day. > [snip] > If I comment out the following line: > > (org-eval-in-calendar '(setq cursor-type nil)) > > org-read-date works correctly. Note: It seems that adding the optional argument KEEPDATE is necessary for parsing to work. With the following line instead of the one above org-read-date works as expected: (org-eval-in-calendar '(setq cursor-type nil) t) Best, Matt
Re: [O] Exporting to ACM format using new LaTeX exporter
Hello, Karl Voit writes: > * Thomas S. Dye wrote: >> >> AFAICT, the new exporter preserves most of the interface of the old >> exporter, but smooths over some of the rough edges. It shouldn't >> represent a barrier to your contribution. In fact, it might be useful >> to write a template for both exporters, then document how they differ as >> a guide to using the new exporter. > > Good idea! > >> I took a brief look at the ACM web site and saw that there is more than >> one LaTeX template. Which one are you interested in for Org-mode? > > I took the "Option 1: LaTeX2e - Strict Adherence to SIGS style" > >> Do you have a repository for the project? > > Yea, that might be appropriate. So I set up a github repos: > > https://github.com/novoid/orgmode-ACM-template > > With the new exporter, I was not able to compile the Org-mode file > at all. Since the old exporter had troubles using this > "per-file-class" I do have a feeling that this might be the cause > for the error message with the new exporter too. > > Maybe someone more familiar with the (new) LaTeX exporter can send > me some patches ... I don't understand what you are trying to achieve. Would you mind summarizing it for someone too lazy to browse docs? Note that `org-splice-latex-header' belongs to neither the legacy exporter nor the new one: it's an org.el function. Thus your problem may lie elsewhere. Regards, -- Nicolas Goaziou
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
Bastien writes: > Toby Cubitt writes: > >> In the patch I posted, I also took the opportunity to set >> `cursor-type' to nil when opening the calendar in `org-read-date'. >> The cursor obscures one digit of the selected date, making that bit >> harder to read (as well as looking ugly). Did you intend to reject >> this change too? > > I did because I found the not-bold-anymore face wasn't visible enough, > and the shallow cursor made it visible. > > I use inverse-video now for this face, so cursor-type nil is okay, I > applied a patch with this. This patch broke org-read-date. It will no longer parse date strings such as "Aug 15" correctly, instead inserting the current day. Steps to reproduce 1. Start with a headline: , | * A Headline ` 2. Type C-c C-s (org-schedule) 3. Enter a future date (e.g., Aug 20). 4. Note the resulting headline: , | * A Headline |SCHEDULED: <2012-04-25 Wed> ` If I comment out the following line: (org-eval-in-calendar '(setq cursor-type nil)) org-read-date works correctly. Best, Matt
Re: [O] error on opening org-file with #+startup: indent
Mike McLean pobox.com> writes: > > > > On Apr 24, 2012, at 3:18 PM, Achim Gratz wrote: > Fritz Kunze writes: I ran M-x load-library org followed by M-x > org-version - which > > returned 7.8.09. > > You didn't generate and (require 'org-install). > > > If you have admin-rights / sudo access on your machine, the simplest method may be to just follow the true install process at http://orgmode.org/manual/Installation.html#Installation. Any reasonably setup Linux/Unix system will require sudo / root access for the make install step. > > If you are going to run Org-Mode without running “make install” (or don't > have the proper rights to run “make install”), the build process has recently changed. This is likely why you are picking up the old autoloads. Instead of = M-x cd ~/.emacs.d/org-7.8.09/ followed by C-u 0 M-x byte-recompile-directory)= do the following from your shell: > > $ cd ~/.emacs.d/org-7.8.09/ > $ make oldorg > > Back in Emacs: > > (add-to-list 'load-path "~/.emacs.d/org-7.8.09/lisp") > (require 'org-install) > Then immediately do a > > M-x org-version > > If you don't get a string similar to mine below, you still have conflicting versions of Org Mode. In particular you are looking for the part after the ' ' sign to point to an org-install.el that matches your ~/.emacs.d/org- 7.8.09/lisp directory location. Without it, Emacs and Org will be hopelessly confused. > > > =Org-mode version 7.8.09 (release_7.8.09-335-geabf89 /Users/mlm/.emacs.d/el-get/org-mode/lisp/org-install.el)= > > Mike > > > > Hi Mike, Thanks for your comments. Combining what you wrote with what Achim wrote I was able to get my upgraded installation (org-7.8.90) to work as it once did in org-6.36 (at least so far). I am unable to generate something similar to what you wrote that appears after the sign - (you got something that included a path (~/.emacs.d/org- 7.8.09/lisp directory location)), all I get is the string org-7.8.09. Is the path stashed away in some customization variable that I can examine? If I don't have access to Make and I hand compiled the code, should I continue to expect to encounter other types of problems? At the risk of being redundant (as I separately replied to Achim) - Regarding the installation instructions: At first I started here (http://orgmode.org/manual/Installation.html#Installation) but since I am running on windows 7, I have no access to "Make". I want to avoid installing cywin as it typically fails to track windows 7 x64. As far as I can tell, make is unnecessary as well since you can hand compile all the files (as I described in my bug report). It's my mistake that I failed to notice the requirement to add (require 'org-install). Here's a suggestion that might help others who encounter similar problems: Augment the installation description (http://orgmode.org/manual/Installation.html#Installation) with a short description for windows users (that avoids the use of make).
Re: [O] Exporting to ACM format using new LaTeX exporter
* Thomas S. Dye wrote: > > AFAICT, the new exporter preserves most of the interface of the old > exporter, but smooths over some of the rough edges. It shouldn't > represent a barrier to your contribution. In fact, it might be useful > to write a template for both exporters, then document how they differ as > a guide to using the new exporter. Good idea! > I took a brief look at the ACM web site and saw that there is more than > one LaTeX template. Which one are you interested in for Org-mode? I took the "Option 1: LaTeX2e - Strict Adherence to SIGS style" > Do you have a repository for the project? Yea, that might be appropriate. So I set up a github repos: https://github.com/novoid/orgmode-ACM-template With the new exporter, I was not able to compile the Org-mode file at all. Since the old exporter had troubles using this "per-file-class" I do have a feeling that this might be the cause for the error message with the new exporter too. Maybe someone more familiar with the (new) LaTeX exporter can send me some patches ... -- Karl Voit
Re: [O] HTML export fails with (void-variable org-version)
Jonathan Leech-Pepin writes: > Hello Bernt > > On Wed, Apr 25, 2012 at 12:21, Bernt Hansen wrote: >> Achim Gratz writes: >> >>> Bastien writes: In the meantime, if you don't want to compile (I do not) the stupid workaround is to set org-version in your config... but yeah, let's fix this upstream ASAP. >>> >>> Again, the issue here is not compilation, but missing autoloads. >>> >>> make autoloads >>> >>> And if you still think you must override this, the thing(s) to set is >>> >>> (defconst org-release) >>> (defconst org-git-release) >>> >>> ...which incidentally is what "make autoloads" will put into >>> org-install.el, with a docstring and all that. >> >> I don't think make autoloads is an option for me at work... I'm using >> GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO >> and I don't have make available... >> >> I use git under Cygwin to get the org-mode repository and access it from >> NT Emacs. > > If you're using Cygwin you should be able to install make. It's under > the devel section in the Cygwin installer. > > Of course this won't help anyone who is unable to install Cygwin/Mingw > to use make, which means an alternate solution would be useful. > I tried that... and installed emacs under Cygwin (so it can find emacs to run emacs -batch) and then had to fix permissions on org-install (since it's on a windows drive) before make autoloads worked. I didn't spend any time trying to correct install locations in the makefile. I run org-mode without compiling any sources normally and having to do the extra make step each time I move around the source tree isn't going to be very enjoyable. I have no idea if I need to rerun this make autoloads command on a regular basis or not. I'll continue working on the master branch tomorrow and see what breaks. Thanks, Bernt
Re: [O] error on opening org-file with #+startup: indent
Martyn Jago btinternet.com> writes: Hi Martyn, Thanks for your support on this issue. I appreciate it. The main issue for me seems to be the paucity of window's specific documentation. I understand that most people are linux users on this list.
Re: [O] error on opening org-file with #+startup: indent
Achim Gratz nexgo.de> writes: > > Fritz Kunze writes: > > I ran M-x load-library org followed by M-x org-version - which > > returned 7.8.09. > > You didn't generate and (require 'org-install). > > > (Incidentally, and for the sake of completeness in this > > report, I built the compiled version of this upgrade by using > > > > M-x cd ~/.emacs.d/org-7.8.09/ followed by C-u 0 M-x > > byte-recompile-directory) > > You still don't have org-install.el > > > I renamed the org-6.36 folder. I started up emacs and the error > > still appeared. > > You do not have org-install.el and you are picking up outdated autoload > definitions from your emacs installation. > > > As an experiment, I modified the load-path to consist only of one > > statement: > > (add-to-list 'load-path "~/.emacs.d/org-7.8.09/") > > ; (add-to-list 'load-path "~/.emacs.d/org-7.8.09/contrib/lisp") > > And suddenly the "bug" vanished. What's going on - do you have any > > idea? I thought I would certainly need this > > directory "~/.emacs.d/org-7.8.09/contrib/lisp" in my load-path. > > Fix the installation first and then worry about things in contrib/. > > Regards, > Achim. Hi Achim, I managed to fix my installation (at least so far) with the addition of (require 'org-install) Thanks for your comments as they led me to try this solution. One question: when you wrote "outdated autoload definitions" did you mean that I should be using some other form to specify the load path (I was loading from (add-to-list 'load-path "~/.emacs.d/org-7.8.09/") rather than from (add-to-list 'load-path "~/.emacs.d/org-6.36/lisp")? Regarding the installation instructions: At first I started here (http://orgmode.org/manual/Installation.html#Installation) but since I am running on windows 7, I have no access to "Make". I want to avoid installing cywin as it typically fails to track windows 7 x64. As far as I can tell, make is unnecessary as well since you can hand compile all the files (as I described in my bug report). It's my mistake that I failed to notice the requirement to add (require 'org-install). Here's a suggestion that might help others who encounter similar problems: Augment the installation description (http://orgmode.org/manual/Installation.html#Installation) with a short description for windows users (that avoids the use of make).
Re: [O] LaTeX-export to ACM SIG Proceedings format
On Wednesday, April 25, 2012, Achim Gratz wrote: > Mike McLean writes: > > So if I do not copy/move/link code from contrib/lisp/ to lisp/ I could > > still be using old contrib code from my Emacs system directories? > > There is no contrib code in Emacs unless you yourself installed it > there. The advantage of copying to lisp is that you don't need to add > contrib to the load-path and mostly don't need any further setup beyond > (require 'org-install). Sorry for the noise, I completely forgot that I added two directories (lisp and contrib/lisp) to my load path. If I had thought a few more seconds before replying, I would not have :(
Re: [O] error on opening org-file with #+startup: indent
Achim Gratz writes: >> Has it suddenly become a requirement to know emacs-lisp, and have a >> reasonable understanding of `autoload' to even install? > > No, but Something obviously got cut out before I sent this... it should read: No, but I've been in the same situation as to OP some time ago and it took me months to drill to the bottom of some mysterious (at the time) and seemingly random errors. Even a single-word answer would have saved me quite some time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] HTML export fails with (void-variable org-version)
Bernt Hansen writes: > I don't think make autoloads is an option for me at work... I'm using > GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO > and I don't have make available... > > I use git under Cygwin to get the org-mode repository and access it from > NT Emacs. That's exactly the same setup that I use at work. You can easily use the make from Cygwin with NTEmacs. I've even posted an example local.mk some time ago, something like this should get you started: --8<---cut here---start->8--- # local.mk Win7/NTemacs CYGWIN += nodosfilewarning prefix = C:/Freeware/Emacs-24.0.50 EMACS = $(prefix)/bin/emacs lispdir = $(prefix)/site-lisp/org SUDO = --8<---cut here---end--->8--- Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] LaTeX-export to ACM SIG Proceedings format
Mike McLean writes: > So if I do not copy/move/link code from contrib/lisp/ to lisp/ I could > still be using old contrib code from my Emacs system directories? There is no contrib code in Emacs unless you yourself installed it there. The advantage of copying to lisp is that you don't need to add contrib to the load-path and mostly don't need any further setup beyond (require 'org-install). Also, the new files in lisp will be compiled and installed just like anything else in lisp without further configuration. The latter of course means that you have to do a "make cleaninstall" if you later decide you don't want to have them installed anymore. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Makefile restructuring
Bastien writes: > Please test this and report any problem while using make > to install Org. Here's another refinement to make "oldorg" the default target unless local.mk is actively edited by the user. If you already have a local.mk file and would like this behaviour, just insert the following on the first line of local.mk: --8<---cut here---start->8--- oldorg: --8<---cut here---end--->8--- With this patch, the new Makefile produces the same results out-of-the box as the old one (modulo the bugs that got fixed: no need for a "make clean" unless you do something really unusual). The patch also adds a new target "uncompiled" that will remove any compiled lisp files that may be around and just creates the autoloads. If you fancy uncompiled installation, insert this as the first line to local.mk: --8<---cut here---start->8--- uncompiled: --8<---cut here---end--->8--- This will enable a plain and simple "make" to do what you want without taking anything away. If you'd rather do something else with a plain "make", you can add your own target definitions there as well (the first one will always be the default target): --8<---cut here---start->8--- fancy: help info uncompiled fancy-install: help install-info install-lisp help:: $(info My fancyness) $(info ) $(info ) $(info fancy - show help, update doc and autoloads) --8<---cut here---end--->8--- In this case, plain "make" would do "fancy" and you'd have a new target "fancy install" plus a documentation for these when doing a "make help", "make targets" or "make helpall". The patch: >From f9f0c7b4e367259bafac1cb5cbec17dd2cff625a Mon Sep 17 00:00:00 2001 From: Achim Gratz Date: Wed, 25 Apr 2012 19:04:29 +0200 Subject: [PATCH] Improve compatibility with old Makefile * targets.mk: change the "local.mk" template so that "oldorg" will be the default target for maximum compatibility. Admonish info message with a reminder to use "make help" for more information on targets and that "oldorg" is the default target for now. Add new convenience target "uncompiled" that will keep the lisp directory free from *.elc files and the autoload files up-to-date. * Makefile: make "targets" and "helpall" depend on "help" so that only "help::" or "helpall::" needs to be written for adding more help messages. Useful when users want to add their own messages to "make help" et al. --- Makefile | 14 -- targets.mk | 17 +++-- 2 files changed, 19 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 1258d52..66a637c 100644 --- a/Makefile +++ b/Makefile @@ -10,8 +10,10 @@ all:: # Describe valid make targets for org-mode. -.PHONY: targets help -targets help helpall:: +.PHONY: targets help helpall +targets: help +helpall:: help +help:: $(info ) $(info Getting Help) $(info ) @@ -61,18 +63,18 @@ helpall:: $(info ) $(info Documentation) $(info =) -targets help helpall:: +help:: $(info make doc - build all documentation) helpall:: $(info make docs - dito) -targets help helpall:: +help:: $(info make info - build Info documentation) helpall:: $(info make html - build HTML documentation) $(info make pdf - build PDF documentation) $(info make card - build reference cards) $(info make refcard - dito) -targets help helpall:: +help:: $(info ) $(info Installation) $(info ) @@ -81,7 +83,7 @@ helpall:: $(info make install-etc - build and install files in /etc) $(info make install-lisp - build and install Org Elisp files) $(info make install-info - build and install Info documentation) -targets help helpall:: +help:: @echo "" include targets.mk # toplevel make machinery diff --git a/targets.mk b/targets.mk index e208ad7..4ad5c5f 100644 --- a/targets.mk +++ b/targets.mk @@ -25,19 +25,24 @@ endif check test install info html pdf card doc docs $(INSTSUB) \ autoloads cleanall clean cleancontrib cleanrel clean-install \ cleanelc cleandirs cleanlisp cleandoc cleandocs cleantest \ - compile compile-dirty + compile compile-dirty uncompiled -oldorg: compile autoloads info # what the old makefile did when no target was specified +oldorg: compile autoloads info # what the old makefile did when no target was specified +uncompiled: cleanlisp autoloads # for developing refcard: card update update2:: up0 all .PRECIOUS: local.mk local.mk: - $(info ==) - $(info Created a local.mk template.) - $(info Please adapt local.mk to your local setup!) - $(info ==) + $(info ==) + $(info = Invok
Re: [O] LaTeX-export to ACM SIG Proceedings format
On Wednesday, April 25, 2012, Achim Gratz wrote: > > Here's my chance to upsell the new build system to you: to use code from > contrib, just link or copy it into lisp, then do whatever you let make > normally do. You usually don't need any extra requires since the > autoload cookies do their magic. If it turns out you don't want or need > that code from contrib, simply remove the files from lisp and re-make. So if I do not copy/move/link code from contrib/lisp/ to lisp/ I could still be using old contrib code from my Emacs system directories?
Re: [O] HTML export fails with (void-variable org-version)
Hello Bernt On Wed, Apr 25, 2012 at 12:21, Bernt Hansen wrote: > Achim Gratz writes: > >> Bastien writes: >>> In the meantime, if you don't want to compile (I do not) the stupid >>> workaround is to set org-version in your config... but yeah, let's >>> fix this upstream ASAP. >> >> Again, the issue here is not compilation, but missing autoloads. >> >> make autoloads >> >> And if you still think you must override this, the thing(s) to set is >> >> (defconst org-release) >> (defconst org-git-release) >> >> ...which incidentally is what "make autoloads" will put into >> org-install.el, with a docstring and all that. > > I don't think make autoloads is an option for me at work... I'm using > GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO > and I don't have make available... > > I use git under Cygwin to get the org-mode repository and access it from > NT Emacs. If you're using Cygwin you should be able to install make. It's under the devel section in the Cygwin installer. Of course this won't help anyone who is unable to install Cygwin/Mingw to use make, which means an alternate solution would be useful. > > Regards, > Bernt >
Re: [O] error on opening org-file with #+startup: indent
Martyn Jago writes: > I think this tone of reply is very harsh, and I feel for the OP. I certainly did not mean to offend anyone. > Has it suddenly become a requirement to know emacs-lisp, and have a > reasonable understanding of `autoload' to even install? No, but > A very formal announcement and good documentation would perhaps have been a > good idea. Don't get me wrong - I like the new makefile, but there *is* > now magic that there never was, without question. An announcement will surely be made by Bastien when the next release is made and the documentation should be ready by then. This problem has nothing to do with the new Makefile, it didn't even enter the picture (remember this change isn't on 7.8.09 and the OP didn't use make at all). The reason that the setup the OP described worked before is that the versions used by his Emacs (likely 6.33x) and the new Org he installed (6.36) were sufficiently similar. > I think it would be better to refer to some good documentation rather > than short terse admonishment over something that `used to work'. The documentation on orgmode.org does describe what to do when switching from Emacs' org version to a newer one. If you follow those instructions step-by-step, everything will work. http://orgmode.org/manual/Installation.html#Installation Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] HTML export fails with (void-variable org-version)
Achim Gratz writes: > Bastien writes: >> In the meantime, if you don't want to compile (I do not) the stupid >> workaround is to set org-version in your config... but yeah, let's >> fix this upstream ASAP. > > Again, the issue here is not compilation, but missing autoloads. > > make autoloads > > And if you still think you must override this, the thing(s) to set is > > (defconst org-release) > (defconst org-git-release) > > ...which incidentally is what "make autoloads" will put into > org-install.el, with a docstring and all that. I don't think make autoloads is an option for me at work... I'm using GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO and I don't have make available... I use git under Cygwin to get the org-mode repository and access it from NT Emacs. Regards, Bernt
Re: [O] Exporting to ACM format using new LaTeX exporter
Karl Voit writes: > * Thomas S. Dye wrote: >> >> One of the ideas behind the new exporter is that Org-mode source >> prepared for one target can be easily exported to other targets. > > I see. > >> My brief experience with the LaTeX exporter so far has been very >> positive and I'm relatively certain that it will be the default >> export engine in the not too distant future. If the ACM template >> is written for the new exporter, then its use life will likely be >> enhanced. > > Right. > >> Also, I agree with Jambunathan's comment that exercising the new >> exporter on a practical project might possibly indicate how it >> could be made better. > > To what extent does the new exporter differ from the features > described in the documentation and the tutorial? > > Where is the new exporter described? I could only find [1]. > >> On a practical note, using the new exporter is easy. I have these >> two lines (along with other configuration) in an Org-babel code >> block that I use to setup Org-mode: >> >> (require 'org-export) (require 'org-e-latex) >> >> Then, I can access the dispatcher with M-x org-export-dispatch and >> choose the target. It feels easy and natural from the get go. > > So no more «C-c C-e d»? You could bind those familiar keystrokes to the new command, if you like. > > > OK, you convinced me that it would be better to use the new method > then. As you can see in my naive questions: I am not really familiar > withe the old exporter and neither with the new one. So using the > (good) documentation on the old one, I planned to contribute to this > template as much as possible. But I am not sure whether I can > contribute to the new one. AFAICT, the new exporter preserves most of the interface of the old exporter, but smooths over some of the rough edges. It shouldn't represent a barrier to your contribution. In fact, it might be useful to write a template for both exporters, then document how they differ as a guide to using the new exporter. I took a brief look at the ACM web site and saw that there is more than one LaTeX template. Which one are you interested in for Org-mode? Do you have a repository for the project? All the best, Tom > > 1. http://orgmode.org/Changes.html -- Thomas S. Dye http://www.tsdye.com
Re: [O] LaTeX-export to ACM SIG Proceedings format
Thomas S. Dye writes: > On a practical note, using the new exporter is easy. I have these > two lines (along with other configuration) in an Org-babel code block > that I use to setup Org-mode: > > (require 'org-export) > (require 'org-e-latex) Here's my chance to upsell the new build system to you: to use code from contrib, just link or copy it into lisp, then do whatever you let make normally do. You usually don't need any extra requires since the autoload cookies do their magic. If it turns out you don't want or need that code from contrib, simply remove the files from lisp and re-make. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] problems with LaTex/BibTex
> -Original Message-
> From: emacs-orgmode-bounces+mlt=gmx...@gnu.org [mailto:emacs-orgmode-
> bounces+mlt=gmx...@gnu.org] On Behalf Of Eric Fraga
> Sent: Wednesday, April 25, 2012 6:21 AM
> To: Alan E. Davis
> Cc: Julian Burgos; emacs-orgmode@gnu.org
> Subject: Re: [O] problems with LaTex/BibTex
>
> "Alan E. Davis" writes:
>
> > I would have a use for this. I am curious, though...
> >
> > Suppose I use this as a standard init-file declaration for
> > org-latex-to-pdf-process . Does that mean that bibtex will always be
run,
> > every time, during the generation of PDFs via LaTex export?
>
> Yes but you can easily customise this variable on a per file basis. If
> you seldom use bibtex, have the default be to run pdflatex just
> once. Then, for any org file that needs bibtex, simply put in the
> following line (or a variation thereof):
>
> #+BIND: org-latex-to-pdf-process ("pdflatex %b" "bibtex %b" "pdflatex %b"
> "pdflatex %b")
Also, if you are on Windows with MikTeX, you can use texify, otherwise
latexmk can save you some time when it is not necessary to rebuild index
and/or bibliography.
M.
Re: [O] Exporting a presentation to both slides and handouts?
Hi,
I think most flexible would be to use tags
create tags like "handout" and "presentation"
Tag all blocks accordingly (handout, presentation or both)
Set the export tag to handout or resp. to presentation.
Since blocks in slides are represented by third level org headlines
one could easily remove blocks for either handouts or presentation.
Other blocks could be tagged "lecture-notes" giving guidance to the presenter
I did not try this but it should work
Torsten
On 25 April 2012 18:08, Eric Fraga wrote:
> Alan Schmitt writes:
>
>> Hello,
>>
>> I'm finishing a presentation with org-mode which is exported as beamer
>> slides. I would like to also export it as a handouts, which basically
>> means changing a couple lines in the preamble. Is there a way to do it
>> from the org-mode file, or do I need to edit the generated LaTeX
>> manually?
>>
>> (If the solution is to have some lines that specify the options and the name
>> of the exported LaTeX file commented out, it would work fine with me.)
>>
>> Thanks,
>>
>> Alan
>
> My solution is akin to yours except that I alter the org file
> instead. I have the following lines in my org file:
>
> --8<---cut here---start->8---
> ##+LaTeX_CLASS_OPTIONS: [bigger]
> #+LaTeX_CLASS_OPTIONS: [handout]
> #+latex_header: \mode{\usetheme{progressbar}}
> #+latex_header:
> \mode{\usecolortheme[rgb={0.5,0.5,0.5}]{structure}\usetheme[secheader]{Boadilla}\usepackage{pgfpages}\pgfpagesuselayout{4
> on 1}[a4paper,landscape,border shrink=5mm]}
> --8<---cut here---end--->8---
>
> and all I do is delete the extra # on the first line and add one to the
> second line to switch from generating handouts to generating my
> slides. Remembering to hit C-c C-c, of course, before doing the
> export.
>
> I use very different themes for handouts (e.g. grey colour theme) and
> for slides but those lines need not change.
>
> Of course, by default, the export generates the same file name in both
> cases. For my use case, this isn't an issue. I generate the handouts,
> copy the resulting PDF file to the web server and then generate the
> slides which I will actually present.
>
> HTH,
> eric
>
>
> --
> : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
> : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
>
>
Re: [O] [beamer] When are :BEAMER_envargs: used or ignored?
At Wed, 25 Apr 2012 18:09:18 +0800,
James Harkins wrote:
> > Whether it should be a feature request or not is debatable. The syntax
> > is, at present, fairly straightforward in that the headline text becomes
> > the argument to the environment defined.
>
> I think "the headline text becomes the argument..." is the opposite of
> straightforward. :-)
OK, wait, I get it:
\begin{alertblock}{HEADLINE TEXT HERE}
\begin{beamercolorbox}{HEADLINE TEXT HERE}
OK, it's a consistent translation. But I still have the issue with it that the
user has to adapt the org-file structure to suit beamer's requirements.
Org-mode is all about reflecting the content in a way that makes sense FIRST to
humans, and only secondarily to exporting engines.
hjh
--
James Harkins /// dewdrop world
jamshar...@dewdrop-world.net
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
Re: [O] S-TAB acts like M-TAB in console sessions
Thorsten Jolitz writes: > But then everything is fine with my setup, I just did not know about > this limitation of the console (I only recently started working on the > console after discovering tmux). > Thanks for the help. You're welcome. N.B. that there are a few other bindings that won't work, due to these console limitations. (info "(org) TTY keys") offers some idea what to expect from org-mode on the console and some alternative bindings that are already set up by default. -- WGG
Re: [O] [OT] Defining System, process, methodology and framework
Marcelo de Moraes Serpa writes: ... a very interesting philosophical email! [...] > level. I then asked myself "What the heck is a system" and what is the > relationship it has with "process", "methodology" and "frameworks" ? [...] Others have answered to some degree or another but I thought I'd throw in my view (as somebody that dabbles in systems... ;-): - system :: the set of units (building blocks) *and* their interconnections - process :: what the system actually "does" - framework :: the structure on which to /instantiate/ systems - methodology :: the /guide/ for using the framework to build a system but the boundaries between these different concepts or views are indeed fuzzy as it is difficult to talk about any single aspect without reference to the others. relating this to org, org is a system implemented on the framework provided by emacs (elisp) which allows one to execute a number of different processes (GTD, LP, publishing, ...). the methodology is rather less well defined ;-) This is a really nice point at which to stop reading my backlog of org mailing list messages! Time for bed now. Good night all. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] [beamer] When are :BEAMER_envargs: used or ignored?
James Harkins writes: > At Wed, 25 Apr 2012 14:11:51 +0930, > Eric Fraga wrote: >> > It kind of strikes me like an epic hack: you have to name the headline >> > after the Beamer color ID, instead of naming the headline after the > >> > content... not very /org/anized. >> >> Well, the problem is that a beamercolorbox is *not* a block and does not >> expect a title parameter. It actually expects only a colour (well, a >> beamer colour structure, to be precise, such as the one you have >> defined). What is /org/ expected to do with the entry you specify? > > If the subtree is folded, then the headline shows the color descriptor > but nothing about the content of the subtree! That's some distance > away from "an outline works like your brain." Yes. You could, of course, turn my suggestion inside out: have the block first and then the coloured box as a subheading... then the main heading would at least give you an indication of what follows. > It's not that I can't get the right output. It *is* a pretty stark > inconsistency against org-mode's governing principle. Here, formatting > information that is irrelevant to content is promoted to be the *most > important thing* (the headline) of that subtree. What I need to see, > in order to understand the structure of the content at a glance -- > this IMO is org-mode's genius -- is hidden if the subtree is > folded. Hm? > > It strikes me as flawed design. Well, it's a compromise, I would suggest. most compromises can indeed be considered flawed design from an aesthetic point of view. org is based on outlines, not on containers. Latex is based on containers (mostly). This basic inconsistency comes up all the time on this list (e.g. a lower level entry can only be ended by starting a new headline at the same or higher level). >> > Worth a bug report or feature request? >> >> It is not a bug, IMO. > > Okay, it's not a bug in the strict sense of a feature that doesn't behave as > designed. I would say it's a d@mn ugly design. Fine. That's one view. I would suggest that maybe you could suggest a better design, remembering, of course, that the basis of org is an outliner...? > It's also a matter of incomplete documentation. The syntax is Indeed. And I am partly to blame for this. I do have a number of outstanding TODO items with respect to the documentation of beamer support in org. But I also do have a real job which, unfortunately, seems to take increasingly more hours every day... > /perhaps/ straightforward, *after* spending some time wondering why it > didn't work to put the color into an environment argument (as one > might reasonably guess), and then spending more time constructing some > tests and looking at the *.tex output to find out which bit of org > text gets put where in the TeX code. > > C-c C-b lists 19 ways to tag headlines for Beamer environments. [1] Yes, because the documentation was written to illustrate how org could support beamer; a comprehensive document has never been written. I would be happy if you would consider contributing to the documentation? -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] problems with LaTex/BibTex
"Alan E. Davis" writes:
> I would have a use for this. I am curious, though...
>
> Suppose I use this as a standard init-file declaration for
> org-latex-to-pdf-process . Does that mean that bibtex will always be run,
> every time, during the generation of PDFs via LaTex export?
Yes but you can easily customise this variable on a per file basis. If
you seldom use bibtex, have the default be to run pdflatex just
once. Then, for any org file that needs bibtex, simply put in the
following line (or a variation thereof):
#+BIND: org-latex-to-pdf-process ("pdflatex %b" "bibtex %b" "pdflatex %b"
"pdflatex %b")
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] setting default BibTex file
Nick Dokos writes:
[...]
> ... but you can shorten it by setting BIBINPUTS in your
> .profile/.login/whatever
> and then using
>
> \bibliography{References}
>
> in your .org/.tex files.
On TeX systems based on kpathsea and texmf, there are defaults which are
quite reasonable. On Debian/Ubuntu, at the very least, you can put your
files under ~/texmf in an appropriate subdirectory. Specifically, bib
files can go in ~/texmf/bibtex/bib and they will automatically be found
by bibtex. Similar directories exist for .bst, .sty and .cls files,
etc.
The actual paths searched by latex et al. are defined by the texmf
configuration, usually found in /etc/texmf/texmf.cnf (again, on Debian
systems; YMMV). This file is worth looking at as it is better
documented than the man pages etc! In any case, that configuration file
defines the default settings for BIBINPUTS, BSTINPUTS and so on.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] [beamer] When are :BEAMER_envargs: used or ignored?
At Wed, 25 Apr 2012 14:11:51 +0930, Eric Fraga wrote: > > It kind of strikes me like an epic hack: you have to name the headline > > after the Beamer color ID, instead of naming the headline after the > > content... not very /org/anized. > > Well, the problem is that a beamercolorbox is *not* a block and does not > expect a title parameter. It actually expects only a colour (well, a > beamer colour structure, to be precise, such as the one you have > defined). What is /org/ expected to do with the entry you specify? If the subtree is folded, then the headline shows the color descriptor but nothing about the content of the subtree! That's some distance away from "an outline works like your brain." It's not that I can't get the right output. It *is* a pretty stark inconsistency against org-mode's governing principle. Here, formatting information that is irrelevant to content is promoted to be the *most important thing* (the headline) of that subtree. What I need to see, in order to understand the structure of the content at a glance -- this IMO is org-mode's genius -- is hidden if the subtree is folded. Hm? It strikes me as flawed design. > > Worth a bug report or feature request? > > It is not a bug, IMO. Okay, it's not a bug in the strict sense of a feature that doesn't behave as designed. I would say it's a d@mn ugly design. > Whether it should be a feature request or not is debatable. The syntax > is, at present, fairly straightforward in that the headline text becomes > the argument to the environment defined. I think "the headline text becomes the argument..." is the opposite of straightforward. :-) It's also a matter of incomplete documentation. The syntax is /perhaps/ straightforward, *after* spending some time wondering why it didn't work to put the color into an environment argument (as one might reasonably guess), and then spending more time constructing some tests and looking at the *.tex output to find out which bit of org text gets put where in the TeX code. C-c C-b lists 19 ways to tag headlines for Beamer environments. [1] doesn't describe any of them. I do understand about volunteer documentation efforts (if days were 48 hours long, I still wouldn't be able to write more than half of the documentation I want to contribute to SuperCollider [2]), but I can't help feeling something is missing here. James [1] http://orgmode.org/manual/Beamer-class-export.html#Beamer-class-export [2] http://supercollider.sourceforge.net -- James Harkins /// dewdrop world jamshar...@dewdrop-world.net http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman blog: http://www.dewdrop-world.net/words audio clips: http://www.dewdrop-world.net/audio more audio: http://soundcloud.com/dewdrop_world/tracks
Re: [O] Beamer confusion: environments are ignored
At Wed, 25 Apr 2012 12:30:59 +0930, Eric Fraga wrote: > > James Harkins writes: > > > (Sorry for breaking the thread -- I'm using the digest. Come to think > > of it, I was wondering -- how do other digest readers participate in > > discussions without messing up the thread IDs? Use a news reader, > > or...? Nabble?) > > You don't appear to have broken the thread; at least, in gnus, this > message is properly threaded with your earlier one... maybe it's a > matter of using an intelligent mail reader! ;-) I'm guessing that the mailing list software is smart enough to recognize that the subject matches an existing thread, and tweak the header IDs appropriately. > > Shall I file a bug report? There is a reproducer here: > > > > http://article.gmane.org/gmane.emacs.orgmode/52631 > > > > Can someone confirm? Bug or not? > > Works fine for me. The first slide is not /blocked/; the second one > /is/. Have you looked at the latex produced by the exporter? > > What version of org are you using? Water under the bridge -- I already figured out that the documentation on Beamer export assumes a more recent version of org than is packaged with Ubuntu Lucid. I've been using blocks, quotes etc. successfully with a newer org for a good 2, 2.5 months now. James -- James Harkins /// dewdrop world jamshar...@dewdrop-world.net http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman blog: http://www.dewdrop-world.net/words audio clips: http://www.dewdrop-world.net/audio more audio: http://soundcloud.com/dewdrop_world/tracks
Re: [O] Capture feature suggestion: place the mark from a template
Nick Dokos wrote: >Maybe - but in this particular case, you could just go to the end of the >buffer with M-> (end-of-buffer), right? Yeah. I could just do that. (Blushing with embarrassment. :-) >And there might be a problem with your proposal: if I push a bunch of >marks during the capture, what happens after the capture is done? Are >they still on the stack? If so, should they be? I guess I was mostly thinking of capture using indirect buffers, which have their own marks and mark rings, right? Does ":unnarrowed" use the actual buffer instead of an indirect one? If so, I can see a couple options (and we've already established that there are lots of options I don't see): - If you don't like capture to set the mark, don't set it. :-) - Arrange for clean-up in the case of org-capture-kill and (maybe?) org-capture-finalize. Carsten Dominik wrote: >You could also use a prompt for the headline. Or we could allow several %? >in the buffer, with a simple key to jump to the next one and delete it. Yeah, I could do that too. I don't know why I didn't consider that. I guess because I'm so used to the "pop-up" nature of the capture window. I'm not sure I would like/use the "multiple %?" approach. Another reason I can imagine for wanting to place the mark with capture is to define the region. (Being old, I'm somewhat ambivalent about this new-fangled "light-up" "active" region. :-) I can imagine wanting to place the mark and point (with %?), typing some stuff, and then wanting to M-w (kill-ring-save) that text. --Colin
Re: [O] Exporting a presentation to both slides and handouts?
Alan Schmitt writes:
> Hello,
>
> I'm finishing a presentation with org-mode which is exported as beamer
> slides. I would like to also export it as a handouts, which basically
> means changing a couple lines in the preamble. Is there a way to do it
> from the org-mode file, or do I need to edit the generated LaTeX
> manually?
>
> (If the solution is to have some lines that specify the options and the name
> of the exported LaTeX file commented out, it would work fine with me.)
>
> Thanks,
>
> Alan
My solution is akin to yours except that I alter the org file
instead. I have the following lines in my org file:
--8<---cut here---start->8---
##+LaTeX_CLASS_OPTIONS: [bigger]
#+LaTeX_CLASS_OPTIONS: [handout]
#+latex_header: \mode{\usetheme{progressbar}}
#+latex_header:
\mode{\usecolortheme[rgb={0.5,0.5,0.5}]{structure}\usetheme[secheader]{Boadilla}\usepackage{pgfpages}\pgfpagesuselayout{4
on 1}[a4paper,landscape,border shrink=5mm]}
--8<---cut here---end--->8---
and all I do is delete the extra # on the first line and add one to the
second line to switch from generating handouts to generating my
slides. Remembering to hit C-c C-c, of course, before doing the
export.
I use very different themes for handouts (e.g. grey colour theme) and
for slides but those lines need not change.
Of course, by default, the export generates the same file name in both
cases. For my use case, this isn't an issue. I generate the handouts,
copy the resulting PDF file to the web server and then generate the
slides which I will actually present.
HTH,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
[O] Exporting to ACM format using new LaTeX exporter (was: LaTeX-export to ACM SIG Proceedings format)
* Thomas S. Dye wrote: > > One of the ideas behind the new exporter is that Org-mode source > prepared for one target can be easily exported to other targets. I see. > My brief experience with the LaTeX exporter so far has been very > positive and I'm relatively certain that it will be the default > export engine in the not too distant future. If the ACM template > is written for the new exporter, then its use life will likely be > enhanced. Right. > Also, I agree with Jambunathan's comment that exercising the new > exporter on a practical project might possibly indicate how it > could be made better. To what extent does the new exporter differ from the features described in the documentation and the tutorial? Where is the new exporter described? I could only find [1]. > On a practical note, using the new exporter is easy. I have these > two lines (along with other configuration) in an Org-babel code > block that I use to setup Org-mode: > > (require 'org-export) (require 'org-e-latex) > > Then, I can access the dispatcher with M-x org-export-dispatch and > choose the target. It feels easy and natural from the get go. So no more «C-c C-e d»? OK, you convinced me that it would be better to use the new method then. As you can see in my naive questions: I am not really familiar withe the old exporter and neither with the new one. So using the (good) documentation on the old one, I planned to contribute to this template as much as possible. But I am not sure whether I can contribute to the new one. 1. http://orgmode.org/Changes.html -- Karl Voit
Re: [O] Beamer specific setupfile?
Eric Fraga writes: > Nick Dokos writes: > > [...] > >> org-infile-export-plist parses the current buffer and takes care of >> #+SETUPFILE: options (even recursive ones). It constructs an options > > This thread has been interesting for the effects it has had on my mail > reading experience. I use gnus and I have gnus configured to parse > *some* org syntax for fontifying messages. > > Interestingly, for these messages, org has tried to load in setup files! > With the original email message, I got the following error message: > > : Cannot read file "/home/xxx/org/aux/beamer-setup.org" > > and with the last line I quoted above from Nick's email, I got: > > : Cannot read file "/home/xxx/options (even recursive ones). It constructs an > options" > > Fun! > > The question is: I believe that I have only configured gnus to do > fontification on source code blocks and a few other constructs. None of > the patterns I have specified includes general #+ lines. I cannot see > how these #+SETUPFILE lines are being interpreted. Any ideas of where > to look? It must (?) be an org issue, not gnus per se, I believe. > > Thanks, > eric Umm, it turns out that gnus does indeed catch lines that start with #+: , | (org-meta-line | "^[ \t]*#\\+[[:alpha:]]+: " | "$" | mm-uu-org-src-code-block-extract)) ` I need to investigate mm-uu-org-src-code-block-extract why this leads to setup file directives being followed. I do worry a little about security implications, although there probably aren't any. Side note: that regex doesn't capture all org mode directives! Apologies for the noise. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] Simplify repeated same section with different variable value
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/12 00:25, Darlan Cavalcante Moreira wrote: > > If you like the call method (which is the best one IMHO) you can also add the > foo function to > the library of babel. In this way you will be able to call it from any org > file without having > to put the definition of the foo function in each of them. I like the #+call method. But I have one additional question: The #+call: should not only execute the source block, but also wrap the result from the source block in the org structure, so that the call results in the same as if writing manually in org: *** Data Checks Here is some text #+header: :results output #+begin_src R cat(SPECIES) #+end_src I could obviously create the org text by hand in the R function, but I do not like this. So I would like to have something like the following, i.e. a source org block, which is then evaluated. So * subroutine #+NAME: foo #+BEGIN_SRC org :var SPECIES="sp1" ,*** Data Checks ,Here is some text ,#+header: :results output ,#+begin_src R , cat(SPECIES) ,#+end_src #+END_SRC * call #+CALL: foo() This, I hoped, would result in: #+RESULTS: foo *** Data Checks Here is some text sp1 But I get an error message: No org-babel-execute function for org! I am stuck here. Is this possible? Thanks, Rainer > > -- Darlan > > At Tue, 24 Apr 2012 10:44:27 -0400, Nick Dokos wrote: >> >> Rainer M Krug wrote: >> >>> On 24/04/12 14:36, Myles English wrote: >> On Tue, 24 Apr 2012 14:22:48 +0200, Rainer M Krug said: > Hi I have a section which I want to repeat for different variable values. > At the moment > I am copying them, but I do not like it at all: > ** Species one :PROPERTIES: :var: SPECIES="sp1" :END: *** Data Checks > Here is some > text #+header: :results output #+begin_src R checkData(species=SPECIES) > #+end_src > ** Species 2 :PROPERTIES: :var: SPECIES="sp2" :END: *** Data Checks Here > is some text > #+header: :results output #+begin_src R checkData(species=SPECIES) > #+end_src > I am sure there must be an easier way with org? How about using yasnippet? >>> >>> Yasnippets would help in filling the file with the repeated code - but if I >>> want to change >>> e.g. "some text" to "some more text", I still have to do it manually. >>> Nevertheless, if I >>> could define the org section once and repeat it with different variable >>> values, this would >>> enable me to change it only once. >>> >> >> Use the #+call mechanism: >> >> --8<---cut here---start->8--- * >> subroutine >> >> #+name: foo #+BEGIN_SRC elisp :var x=1 (* x x) #+END_SRC >> >> * call >> >> #+call: foo(4) >> >> #+RESULTS: foo(4) : 16 >> >> * call >> >> #+call: foo(5) >> >> #+RESULTS: foo(5) : 25 --8<---cut >> here---end--->8--- >> >> Nick >> >> >> - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+XvGwACgkQoYgNqgF2egpzKQCfUMKhVD+/R53yure3HSntuZ0M z6gAn1FOFQDUZMsuQ90B57JmAiPQBdJg =1ajF -END PGP SIGNATURE-
Re: [O] S-TAB acts like M-TAB in console sessions
William Gardella writes: > Thorsten Jolitz writes: > >> Hi List, >> I have a strange problem with org-global-cycle (S-TAB) in console >> sessions. It mainly doesn't do anything, and C-h k shows "M-TAB is bound >> to pcomplete", which it actually is, but I'm hitting S-TAB not M-TAB. >> >> Otherwise, the "S" (shift) key work, I can type uppercase and all. Is >> that a hardware (keyboard) problem, or did anybody experience similar >> symptoms? > > Thorsten, > > This sounds pretty weird, because in console sessions, due to the > limitations of keyboard escape sequences, there is no way to type > shift-tab (what emacs calls ). The only way to do > org-global-cycle (or something like it) on console with the default > bindings is to use C-u TAB (startup visibility), C-u C-u TAB (CONTENTS), > C-u C-u C-u TAB (everything). But then everything is fine with my setup, I just did not know about this limitation of the console (I only recently started working on the console after discovering tmux). Thanks for the help. -- cheers, Thorsten
Re: [O] Beamer specific setupfile?
Nick Dokos writes: [...] > org-infile-export-plist parses the current buffer and takes care of > #+SETUPFILE: options (even recursive ones). It constructs an options This thread has been interesting for the effects it has had on my mail reading experience. I use gnus and I have gnus configured to parse *some* org syntax for fontifying messages. Interestingly, for these messages, org has tried to load in setup files! With the original email message, I got the following error message: : Cannot read file "/home/xxx/org/aux/beamer-setup.org" and with the last line I quoted above from Nick's email, I got: : Cannot read file "/home/xxx/options (even recursive ones). It constructs an options" Fun! The question is: I believe that I have only configured gnus to do fontification on source code blocks and a few other constructs. None of the patterns I have specified includes general #+ lines. I cannot see how these #+SETUPFILE lines are being interpreted. Any ideas of where to look? It must (?) be an org issue, not gnus per se, I believe. Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] S-TAB acts like M-TAB in console sessions
Thorsten Jolitz writes: > Hi List, > I have a strange problem with org-global-cycle (S-TAB) in console > sessions. It mainly doesn't do anything, and C-h k shows "M-TAB is bound > to pcomplete", which it actually is, but I'm hitting S-TAB not M-TAB. > > Otherwise, the "S" (shift) key work, I can type uppercase and all. Is > that a hardware (keyboard) problem, or did anybody experience similar > symptoms? Thorsten, This sounds pretty weird, because in console sessions, due to the limitations of keyboard escape sequences, there is no way to type shift-tab (what emacs calls ). The only way to do org-global-cycle (or something like it) on console with the default bindings is to use C-u TAB (startup visibility), C-u C-u TAB (CONTENTS), C-u C-u C-u TAB (everything). -- WGG
[O] S-TAB acts like M-TAB in console sessions
Hi List, I have a strange problem with org-global-cycle (S-TAB) in console sessions. It mainly doesn't do anything, and C-h k shows "M-TAB is bound to pcomplete", which it actually is, but I'm hitting S-TAB not M-TAB. Otherwise, the "S" (shift) key work, I can type uppercase and all. Is that a hardware (keyboard) problem, or did anybody experience similar symptoms? -- cheers, Thorsten
Re: [O] orgstuct++ does not lurk silently in the shadow
Christopher Schmidt writes: > Hi gurus, > > I have a problem with Org-mode version 7.8.03 > (release_7.8.03.351.g47eb3) on GNU Emacs 24.0.94.1 > (x86_64-unknown-linux-gnu, GTK+ Version 2.24.9) of 2012-03-08. > > (info "(org)Orgstruct mode") says that one is allowed to use orgtbl-mode > in message-mode. Unfortunately this does not work as expected. > > Recipe: > > emacs -q > C-x m > M-q # fill-paragraph ignores the message header > eval: (add-hook 'message-mode-hook 'turn-on-orgstruct++) > C-x m > M-q # fill-paragraph does ignore the message header > > The bug is caused by fill-paragraph-function not being set back to > message-fill-paragraph when orgstruct-hijacker-command-22 falls back to > fill-paragraph. > > Christopher Thanks for this. This behaviour has annoyed me for years now. I've never gotten around to figuring out why I got this behaviour because I get caught up with writing the email and forget by the time I finish... I hope somebody can indeed fix this as it sounds quite straightforward (for better elisp programmers than I...). -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] Size and placement of images in table in PDF export
On Wednesday, April 25, 2012 at 12:08 AM Eric Fraga wrote:
> Nick Dokos writes:
>> Michael Hannon wrote:
>>
>>> Greetings. I've got another export question. If I put two small images
>>> into
>>> an Org-mode table and export the containing document to HTML, I see the two
>>> images displayed side-by-side in an area of the page that is at least
>>> roughly
>>> the actual size of the concatenated images.
>>>
>>> If I export the same document to PDF, the two images are again displayed
>>> side-by-side, but image on the left is magnified to take up most of the
>>> horizontal space on the page; the image on the right is also magnified and
>>> runs off the page to the right.
[...]
>> Is there some way to override the default size/placement of the images in
>>> PDF export?
>>
>>
>> The trouble is that the default option says "width=.9\\linewidth" so
>> if you try to put two of them on the same "line", they end up overflowing
>> the page. For an image not inside a table, you could reset that with
>>
>> #+ATTR_LaTeX: width=.4\\linewidth
> By the way, there should be only one \ in this line as org or emacs do
> not need the \ escaped in this context.
>>
>> but this is a rather blunt instrument: for images inside a table, it
>> applies not only to the images but also to the table (and it ends up
>> producing a syntactically incorrect latex program - that's probably
>> a bug in the latex exporter.)
> There is indeed a problem with figures inside tables in that the same
> construct is used to pass arguments to \includegraphics
> and \begin{tabular}. Not ideal at all. We really should have different
> constructs for each...
> For the above problem from the OP, the best solution in latex directly
> would have been to specify the widths of the columns using p{2.5cm}
> column formats, say. If that is done, the default width for images,
> based on \linewidth, would work just fine as \linewidth is the width of
> the text within the actual latex structure (as opposed to \textwidth or
> \columnwidth, say). This works because the "p" tabular format changes
> \linewidth within that column.
>
> However, it is not possible to specify table attributes *if* you have
> images inside the table as the same latex attributes are passed to both
> table and images...
Hi, Eric. Thanks for the information. Just for the record, I ended up
"cheating" on this problem: I used the ImageMagick utility "montage" to
create, well, a montage of the images I wanted and then just loaded the
resulting, single image. I've been meaning to close the loop on this but kept
forgetting.
-- Mike
Re: [O] Size and placement of images in table in PDF export
Nick Dokos writes:
> Michael Hannon wrote:
>
>> Greetings. I've got another export question. If I put two small images into
>> an Org-mode table and export the containing document to HTML, I see the two
>> images displayed side-by-side in an area of the page that is at least roughly
>> the actual size of the concatenated images.
>>
>> If I export the same document to PDF, the two images are again displayed
>> side-by-side, but image on the left is magnified to take up most of the
>> horizontal space on the page; the image on the right is also magnified and
>> runs off the page to the right.
[...]
>> Is there some way to override the default size/placement of the images in PDF
>> export?
>>
>
> The trouble is that the default option says "width=.9\\linewidth" so
> if you try to put two of them on the same "line", they end up overflowing
> the page. For an image not inside a table, you could reset that with
>
> #+ATTR_LaTeX: width=.4\\linewidth
By the way, there should be only one \ in this line as org or emacs do
not need the \ escaped in this context.
>
> but this is a rather blunt instrument: for images inside a table, it
> applies not only to the images but also to the table (and it ends up
> producing a syntactically incorrect latex program - that's probably
> a bug in the latex exporter.)
There is indeed a problem with figures inside tables in that the same
construct is used to pass arguments to \includegraphics
and \begin{tabular}. Not ideal at all. We really should have different
constructs for each...
For the above problem from the OP, the best solution in latex directly
would have been to specify the widths of the columns using p{2.5cm}
column formats, say. If that is done, the default width for images,
based on \linewidth, would work just fine as \linewidth is the width of
the text within the actual latex structure (as opposed to \textwidth or
\columnwidth, say). This works because the "p" tabular format changes
\linewidth within that column.
However, it is not possible to specify table attributes *if* you have
images inside the table as the same latex attributes are passed to both
table and images...
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
