[PATCH] latex export - title placement

[PATCH] latex export - title placement

[Sebastian Hofer]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

Hi all,

This patch addresses the problem of ambiguous conventions for the
placement of the title related macros (\author, \date,...) with
respect to the main document body in different latex classes. It
introduces the following changes:

* org-exp.el:
    - added the following options:
      - title-position (tpos)
      - with-title (wtitle)
      - with-author (wauth)
      - with-date (wdate)
      - with-maketitle (wmtitle)
    
* org-latex.el:
    - implemented handling of new options (see above):
      - title-position controls placement of \title, \author, \date;
        possible values are "b" = before \begin{document},
        any other values default to after \begin{document}
      - with-* controls if the corresponding macro is exported at all
        this can be convenient for more complex titles (e.g. several
        authors including affiliations,...)

The patch seems to work for me so far. What do you all think? IMO it
would be useful to integrate this, as it gives slightly more control
over the export process. Of course one might want to think about
better option names. The diff is done against commit
bc161ded3693f752616dcd247fc9d638789025ee.

Let me briefly describe my current use case:
I disable all commands except \title, use babel to created a title.tex
file (including several authors and affiliations) by tangling latex
code and then include the file (into the main body of the document,
not the preamble). That's the only decent way I've found to do this,
if anyone knows an easier way (I have the feeling that I might be
overlooking an obvious solution) please let me know!

Cheers
Sebastian


[-- Attachment #2: org-patch.diff --]
[-- Type: application/octet-stream, Size: 5733 bytes --]

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index d6ed193..e8086a6 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -618,6 +618,8 @@ table.el tables."
 (defvar org-min-level nil) ; dynamically scoped variable
 (defvar org-levels-open nil) ; dynamically scoped parameter
 
+;; patched
+;; Time-stamp: <2011-05-27 19:12:11 c705264>
 (defconst org-export-plist-vars
   '((:link-up		      nil	  org-export-html-link-up)
     (:link-home		      nil	  org-export-html-link-home)
@@ -672,7 +674,13 @@ table.el tables."
     (:select-tags	      nil	  org-export-select-tags)
     (:exclude-tags	      nil	  org-export-exclude-tags)
 
-    (:latex-image-options     nil	  org-export-latex-image-default-option))
+    (:latex-image-options     nil	  org-export-latex-image-default-option)
+    (:latex-title-position    "tpos"	  org-export-latex-title-position)
+    (:latex-with-author       "wauth"	  org-export-latex-with-author)
+    (:latex-with-date         "wdate"	  org-export-latex-with-date)
+    (:latex-with-title        "wtitle"	  org-export-latex-with-title)
+    (:latex-with-maketitle    "wmtitle"	  org-export-latex-with-maketitle)
+    )
   "List of properties that represent export/publishing variables.
 Each element is a list of 3 items:
 1. The property that is used internally, and also for org-publish-project-alist
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 764a48d..c2dc8df 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -78,6 +78,26 @@
 
 ;;; User variables:
 
+;; begin patched
+;; Time-stamp: <2011-05-27 18:31:51 c705264>
+
+(defvar org-export-latex-title-position "b"
+  "Determines if \\title, \\author, \\email and \\date commands are inserted before (default) or
+  after (\"a\") \\begin{document}.")
+
+(defvar org-export-latex-with-maketitle t
+  "Determines if \\maketitle is inserted")
+
+(defvar org-export-latex-with-author t
+  "Determines if \\author is inserted")
+
+(defvar org-export-latex-with-date t
+  "Determines if \\date is inserted")
+
+(defvar org-export-latex-with-title t
+  "Determines if \\title is inserted")
+;; end patched
+
 (defgroup org-export-latex nil
   "Options for exporting Org-mode files to LaTeX."
   :tag "Org Export LaTeX"
@@ -1334,6 +1354,8 @@ LEVEL indicates the default depth for export."
   "The function formatting returning the string to create the table of contents.
 The function mus take one parameter, the depth of the table of contents.")
 
+;; patched
+;; Time-stamp: <2011-05-27 19:06:33 c705264>
 (defun org-export-latex-make-header (title opt-plist)
   "Make the LaTeX header and return it as a string.
 TITLE is the current title from the buffer or region.
@@ -1344,7 +1366,12 @@ OPT-PLIST is the options plist for current buffer."
 	(email (replace-regexp-in-string
 		"_" "\\\\_"
 		(org-export-apply-macros-in-string
-		 (plist-get opt-plist :email)))))
+		 (plist-get opt-plist :email))))
+	(title-position (plist-get opt-plist :latex-title-position))
+	(with-author (plist-get opt-plist :latex-with-author))
+	(with-date (plist-get opt-plist :latex-with-date))
+	(with-title (plist-get opt-plist :latex-with-title))
+	(with-maketitle (plist-get opt-plist :latex-with-maketitle)))
     (concat
      (if (plist-get opt-plist :time-stamp-file)
 	 (format-time-string "%% Created %Y-%m-%d %a %H:%M\n"))
@@ -1359,33 +1386,43 @@ OPT-PLIST is the options plist for current buffer."
      (org-export-apply-macros-in-string org-export-latex-append-header)
      ;; define alert if not yet defined
      "\n\\providecommand{\\alert}[1]{\\textbf{#1}}"
+     "\n\n"
+     ;; beginning of the document (title after \begin{document})
+     (when (not (string= "b" title-position))
+       "\n\\begin{document}\n\n")
      ;; insert the title
-     (format
-      "\n\n\\title{%s}\n"
-      (org-export-latex-fontify-headline title))
+     (when with-title
+       (format
+       "\\title{%s}\n"
+       (org-export-latex-fontify-headline title)))
      ;; insert author info
-     (if (plist-get opt-plist :author-info)
-	 (format "\\author{%s%s}\n"
-		 (org-export-latex-fontify-headline (or author user-full-name))
-		 (if (and (plist-get opt-plist :email-info) email
-			  (string-match "\\S-" email))
-		     (format "\\thanks{%s}" email)
-		   ""))
-       (format "%%\\author{%s}\n"
-	       (org-export-latex-fontify-headline (or author user-full-name))))
+     (when with-author
+       (if (plist-get opt-plist :author-info)
+	  (format "\\author{%s%s}\n"
+		  (org-export-latex-fontify-headline (or author user-full-name))
+		  (if (and (plist-get opt-plist :email-info) email
+			   (string-match "\\S-" email))
+		      (format "\\thanks{%s}" email)
+		    ""))
+	(format "%%\\author{%s}\n"
+		(org-export-latex-fontify-headline (or author user-full-name)))))
      ;; insert the date
-     (format "\\date{%s}\n"
-	     (format-time-string
-	      (or (plist-get opt-plist :date)
-		  org-export-latex-date-format)))
-     ;; beginning of the document
-     "\n\\begin{document}\n\n"
+     (when with-date
+       (format "\\date{%s}\n"
+	      (format-time-string
+	       (or (plist-get opt-plist :date)
+		   org-export-latex-date-format))))
+
      ;; insert the title command
-     (when (string-match "\\S-" title)
+     (when (and (string-match "\\S-" title) with-maketitle)
+       "\n\n"
        (if (string-match "%s" org-export-latex-title-command)
 	   (format org-export-latex-title-command title)
 	 org-export-latex-title-command))
      "\n\n"
+     ;; beginning of the document (maketitle before \begin{document})
+     (when (string= "b" title-position)
+       "\n\\begin{document}\n\n")
      ;; table of contents
      (when (and org-export-with-toc
 		(plist-get opt-plist :section-numbers))

Re: [PATCH] latex export - title placement

[Sebastian Hofer]

[-- Attachment #1: Type: text/plain, Size: 157 bytes --]

I just now saw the FAQ entry on sending patches, sorry for that!
I'm reposting the patch with the proper mime-type. Hope it's correct this time!

Sebastian


[-- Attachment #2: org-patch.diff --]
[-- Type: text/plain, Size: 5733 bytes --]

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index d6ed193..e8086a6 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -618,6 +618,8 @@ table.el tables."
 (defvar org-min-level nil) ; dynamically scoped variable
 (defvar org-levels-open nil) ; dynamically scoped parameter
 
+;; patched
+;; Time-stamp: <2011-05-27 19:12:11 c705264>
 (defconst org-export-plist-vars
   '((:link-up		      nil	  org-export-html-link-up)
     (:link-home		      nil	  org-export-html-link-home)
@@ -672,7 +674,13 @@ table.el tables."
     (:select-tags	      nil	  org-export-select-tags)
     (:exclude-tags	      nil	  org-export-exclude-tags)
 
-    (:latex-image-options     nil	  org-export-latex-image-default-option))
+    (:latex-image-options     nil	  org-export-latex-image-default-option)
+    (:latex-title-position    "tpos"	  org-export-latex-title-position)
+    (:latex-with-author       "wauth"	  org-export-latex-with-author)
+    (:latex-with-date         "wdate"	  org-export-latex-with-date)
+    (:latex-with-title        "wtitle"	  org-export-latex-with-title)
+    (:latex-with-maketitle    "wmtitle"	  org-export-latex-with-maketitle)
+    )
   "List of properties that represent export/publishing variables.
 Each element is a list of 3 items:
 1. The property that is used internally, and also for org-publish-project-alist
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 764a48d..c2dc8df 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -78,6 +78,26 @@
 
 ;;; User variables:
 
+;; begin patched
+;; Time-stamp: <2011-05-27 18:31:51 c705264>
+
+(defvar org-export-latex-title-position "b"
+  "Determines if \\title, \\author, \\email and \\date commands are inserted before (default) or
+  after (\"a\") \\begin{document}.")
+
+(defvar org-export-latex-with-maketitle t
+  "Determines if \\maketitle is inserted")
+
+(defvar org-export-latex-with-author t
+  "Determines if \\author is inserted")
+
+(defvar org-export-latex-with-date t
+  "Determines if \\date is inserted")
+
+(defvar org-export-latex-with-title t
+  "Determines if \\title is inserted")
+;; end patched
+
 (defgroup org-export-latex nil
   "Options for exporting Org-mode files to LaTeX."
   :tag "Org Export LaTeX"
@@ -1334,6 +1354,8 @@ LEVEL indicates the default depth for export."
   "The function formatting returning the string to create the table of contents.
 The function mus take one parameter, the depth of the table of contents.")
 
+;; patched
+;; Time-stamp: <2011-05-27 19:06:33 c705264>
 (defun org-export-latex-make-header (title opt-plist)
   "Make the LaTeX header and return it as a string.
 TITLE is the current title from the buffer or region.
@@ -1344,7 +1366,12 @@ OPT-PLIST is the options plist for current buffer."
 	(email (replace-regexp-in-string
 		"_" "\\\\_"
 		(org-export-apply-macros-in-string
-		 (plist-get opt-plist :email)))))
+		 (plist-get opt-plist :email))))
+	(title-position (plist-get opt-plist :latex-title-position))
+	(with-author (plist-get opt-plist :latex-with-author))
+	(with-date (plist-get opt-plist :latex-with-date))
+	(with-title (plist-get opt-plist :latex-with-title))
+	(with-maketitle (plist-get opt-plist :latex-with-maketitle)))
     (concat
      (if (plist-get opt-plist :time-stamp-file)
 	 (format-time-string "%% Created %Y-%m-%d %a %H:%M\n"))
@@ -1359,33 +1386,43 @@ OPT-PLIST is the options plist for current buffer."
      (org-export-apply-macros-in-string org-export-latex-append-header)
      ;; define alert if not yet defined
      "\n\\providecommand{\\alert}[1]{\\textbf{#1}}"
+     "\n\n"
+     ;; beginning of the document (title after \begin{document})
+     (when (not (string= "b" title-position))
+       "\n\\begin{document}\n\n")
      ;; insert the title
-     (format
-      "\n\n\\title{%s}\n"
-      (org-export-latex-fontify-headline title))
+     (when with-title
+       (format
+       "\\title{%s}\n"
+       (org-export-latex-fontify-headline title)))
      ;; insert author info
-     (if (plist-get opt-plist :author-info)
-	 (format "\\author{%s%s}\n"
-		 (org-export-latex-fontify-headline (or author user-full-name))
-		 (if (and (plist-get opt-plist :email-info) email
-			  (string-match "\\S-" email))
-		     (format "\\thanks{%s}" email)
-		   ""))
-       (format "%%\\author{%s}\n"
-	       (org-export-latex-fontify-headline (or author user-full-name))))
+     (when with-author
+       (if (plist-get opt-plist :author-info)
+	  (format "\\author{%s%s}\n"
+		  (org-export-latex-fontify-headline (or author user-full-name))
+		  (if (and (plist-get opt-plist :email-info) email
+			   (string-match "\\S-" email))
+		      (format "\\thanks{%s}" email)
+		    ""))
+	(format "%%\\author{%s}\n"
+		(org-export-latex-fontify-headline (or author user-full-name)))))
      ;; insert the date
-     (format "\\date{%s}\n"
-	     (format-time-string
-	      (or (plist-get opt-plist :date)
-		  org-export-latex-date-format)))
-     ;; beginning of the document
-     "\n\\begin{document}\n\n"
+     (when with-date
+       (format "\\date{%s}\n"
+	      (format-time-string
+	       (or (plist-get opt-plist :date)
+		   org-export-latex-date-format))))
+
      ;; insert the title command
-     (when (string-match "\\S-" title)
+     (when (and (string-match "\\S-" title) with-maketitle)
+       "\n\n"
        (if (string-match "%s" org-export-latex-title-command)
 	   (format org-export-latex-title-command title)
 	 org-export-latex-title-command))
      "\n\n"
+     ;; beginning of the document (maketitle before \begin{document})
+     (when (string= "b" title-position)
+       "\n\\begin{document}\n\n")
      ;; table of contents
      (when (and org-export-with-toc
 		(plist-get opt-plist :section-numbers))

Re: [PATCH] latex export - title placement

[Thomas S. Dye]

Sebastian Hofer <sebhofer@gmail.com> writes:

> Hi all,
>
> This patch addresses the problem of ambiguous conventions for the
> placement of the title related macros (\author, \date,...) with
> respect to the main document body in different latex classes. It
> introduces the following changes:
>
> * org-exp.el:
>     - added the following options:
>       - title-position (tpos)
>       - with-title (wtitle)
>       - with-author (wauth)
>       - with-date (wdate)
>       - with-maketitle (wmtitle)
>     
> * org-latex.el:
>     - implemented handling of new options (see above):
>       - title-position controls placement of \title, \author, \date;
>         possible values are "b" = before \begin{document},
>         any other values default to after \begin{document}
>       - with-* controls if the corresponding macro is exported at all
>         this can be convenient for more complex titles (e.g. several
>         authors including affiliations,...)
>
> The patch seems to work for me so far. What do you all think? IMO it
> would be useful to integrate this, as it gives slightly more control
> over the export process. Of course one might want to think about
> better option names. The diff is done against commit
> bc161ded3693f752616dcd247fc9d638789025ee.
>
> Let me briefly describe my current use case:
> I disable all commands except \title, use babel to created a title.tex
> file (including several authors and affiliations) by tangling latex
> code and then include the file (into the main body of the document,
> not the preamble). That's the only decent way I've found to do this,
> if anyone knows an easier way (I have the feeling that I might be
> overlooking an obvious solution) please let me know!
>
> Cheers
> Sebastian
>
>
Aloha Sebastian,

Your patch should prove useful in the situation where one has to use a
particular class file that requires \title and friends to be declared in
the body of the document rather than the preamble.  That functionality
is a welcome addition to the LaTeX exporter, IMO.

Another way to achieve your current use case, IIUC, which might or might
not seem easier, is to redefine \maketitle along the lines suggested by
Nick Dokos (see
http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-11_2).

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [PATCH] latex export - title placement

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Sebastian Hofer <sebhofer@gmail.com> writes:
> 
> > Hi all,
> >
> > This patch addresses the problem of ambiguous conventions for the
> > placement of the title related macros (\author, \date,...) with
> > respect to the main document body in different latex classes. It
> > introduces the following changes:
> >
> > * org-exp.el:
> >     - added the following options:
> >       - title-position (tpos)
> >       - with-title (wtitle)
> >       - with-author (wauth)

[This is mostly addressed to Sebastian even though I'm replying to Tom's
reply.]

An empty

#+AUTHOR:

disables the insertion of author (assuming that TITLE is not empty -
see below.)


> >       - with-date (wdate)

An empty

#+DATE:

disables the insertion of date (same assumption.)

> >       - with-maketitle (wmtitle)

An empty

#+TITLE:

disables the insertion of \maketitle.

So if TITLE is not empty, you can get what you want with existing
machinery. I could not find a way to make the title empty  and still
have author and/or date fields.

Given all this, I think the only things you need is title-position and
with-title, the latter in the unlikely event that you want a title page
with author or date but without a title. Personally, I'd consider this
last one unimportant and not worry about it, but you may disagree.

> >     
> > * org-latex.el:
> >     - implemented handling of new options (see above):
> >       - title-position controls placement of \title, \author, \date;
> >         possible values are "b" = before \begin{document},
> >         any other values default to after \begin{document}
> >       - with-* controls if the corresponding macro is exported at all
> >         this can be convenient for more complex titles (e.g. several
> >         authors including affiliations,...)
> >
> > The patch seems to work for me so far. What do you all think? IMO it
> > would be useful to integrate this, as it gives slightly more control
> > over the export process. Of course one might want to think about
> > better option names. The diff is done against commit
> > bc161ded3693f752616dcd247fc9d638789025ee.
> >
> > Let me briefly describe my current use case:
> > I disable all commands except \title, use babel to created a title.tex
> > file (including several authors and affiliations) by tangling latex
> > code and then include the file (into the main body of the document,
> > not the preamble). That's the only decent way I've found to do this,
> > if anyone knows an easier way (I have the feeling that I might be
> > overlooking an obvious solution) please let me know!
> >

I'm not sure what problem you are trying to solve here: can you explain?
It seems to me that all this can be done in standard ways.

> > Cheers
> > Sebastian
> >
> >
> Aloha Sebastian,
> 
> Your patch should prove useful in the situation where one has to use a
> particular class file that requires \title and friends to be declared in
> the body of the document rather than the preamble.  That functionality
> is a welcome addition to the LaTeX exporter, IMO.
> 

IIUC, the only remaining thing is the position of the \title etc macros
in the preamble or the body (or both).

There are three categories of LaTeX classes: the ones that implement
Lamport's dictum that \title etc can come anywhere before \maketitle,
the ones like RevTeX that insist on having them in the body and the ones
like the thesis document class at Suvayu's university, that insist on
having them in the preamble. I consider both of the latter two as buggy:
has anybody submitted a bug report on them?

Has anybody researched the prevalence of these bugs? Are there lots of
classes in one or the other of the buggy categories?

Be that as it may, it seems that org needs a patch to work around these
bugs.  Personally, since it is a class problem, I'd rather have this
kind of information in the class template.  You set it once for each
class that needs it and you forget about it. Assuming the maintainers
agree, any chance of reworking the patch along these lines? Maybe make
it extensible as well: a property list that can accumulate all the junk
in one place perhaps. That way the RevTeX class can be configured
appropriately and the rest of the world can live in blissful ignorance
of the problem. You might detect a bias here: I prefer these things in
the preamble by default.

> Another way to achieve your current use case, IIUC, which might or might
> not seem easier, is to redefine \maketitle along the lines suggested by
> Nick Dokos (see
> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-11_2).
> 

As I mentioned, I'm not really sure what Sebastian is looking for, so I
can't really say whether the above would help, but if it can be done
this way, I think it would be preferable to introducing new user options
for the exlusive use of the org latex exporter. There are legitimate uses
for user options but working around bugs in downstream packages is
not one of them. IMO, of course.

Nick

Re: [PATCH] latex export - title placement

[Thomas S. Dye]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Sebastian Hofer <sebhofer@gmail.com> writes:
>> 
>> > Hi all,
>> >
>> > This patch addresses the problem of ambiguous conventions for the
>> > placement of the title related macros (\author, \date,...) with
>> > respect to the main document body in different latex classes. It
>> > introduces the following changes:
>> >
>> > * org-exp.el:
>> >     - added the following options:
>> >       - title-position (tpos)
>> >       - with-title (wtitle)
>> >       - with-author (wauth)
>
> [This is mostly addressed to Sebastian even though I'm replying to Tom's
> reply.]
>
> An empty
>
> #+AUTHOR:
>
> disables the insertion of author (assuming that TITLE is not empty -
> see below.)
>
>
>> >       - with-date (wdate)
>
> An empty
>
> #+DATE:
>
> disables the insertion of date (same assumption.)
>
>> >       - with-maketitle (wmtitle)
>
> An empty
>
> #+TITLE:
>
> disables the insertion of \maketitle.
>
> So if TITLE is not empty, you can get what you want with existing
> machinery. I could not find a way to make the title empty  and still
> have author and/or date fields.
>
> Given all this, I think the only things you need is title-position and
> with-title, the latter in the unlikely event that you want a title page
> with author or date but without a title. Personally, I'd consider this
> last one unimportant and not worry about it, but you may disagree.
>
>> >     
>> > * org-latex.el:
>> >     - implemented handling of new options (see above):
>> >       - title-position controls placement of \title, \author, \date;
>> >         possible values are "b" = before \begin{document},
>> >         any other values default to after \begin{document}
>> >       - with-* controls if the corresponding macro is exported at all
>> >         this can be convenient for more complex titles (e.g. several
>> >         authors including affiliations,...)
>> >
>> > The patch seems to work for me so far. What do you all think? IMO it
>> > would be useful to integrate this, as it gives slightly more control
>> > over the export process. Of course one might want to think about
>> > better option names. The diff is done against commit
>> > bc161ded3693f752616dcd247fc9d638789025ee.
>> >
>> > Let me briefly describe my current use case:
>> > I disable all commands except \title, use babel to created a title.tex
>> > file (including several authors and affiliations) by tangling latex
>> > code and then include the file (into the main body of the document,
>> > not the preamble). That's the only decent way I've found to do this,
>> > if anyone knows an easier way (I have the feeling that I might be
>> > overlooking an obvious solution) please let me know!
>> >
>
> I'm not sure what problem you are trying to solve here: can you explain?
> It seems to me that all this can be done in standard ways.
>
>> > Cheers
>> > Sebastian
>> >
>> >
>> Aloha Sebastian,
>> 
>> Your patch should prove useful in the situation where one has to use a
>> particular class file that requires \title and friends to be declared in
>> the body of the document rather than the preamble.  That functionality
>> is a welcome addition to the LaTeX exporter, IMO.
>> 
>
> IIUC, the only remaining thing is the position of the \title etc macros
> in the preamble or the body (or both).
>
> There are three categories of LaTeX classes: the ones that implement
> Lamport's dictum that \title etc can come anywhere before \maketitle,
> the ones like RevTeX that insist on having them in the body and the ones
> like the thesis document class at Suvayu's university, that insist on
> having them in the preamble. I consider both of the latter two as buggy:
> has anybody submitted a bug report on them?
>
> Has anybody researched the prevalence of these bugs? Are there lots of
> classes in one or the other of the buggy categories?
>
> Be that as it may, it seems that org needs a patch to work around these
> bugs.  Personally, since it is a class problem, I'd rather have this
> kind of information in the class template.  You set it once for each
> class that needs it and you forget about it. Assuming the maintainers
> agree, any chance of reworking the patch along these lines? Maybe make
> it extensible as well: a property list that can accumulate all the junk
> in one place perhaps. That way the RevTeX class can be configured
> appropriately and the rest of the world can live in blissful ignorance
> of the problem. You might detect a bias here: I prefer these things in
> the preamble by default.
>
>> Another way to achieve your current use case, IIUC, which might or might
>> not seem easier, is to redefine \maketitle along the lines suggested by
>> Nick Dokos (see
>> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-11_2).
>> 
>
> As I mentioned, I'm not really sure what Sebastian is looking for, so I
> can't really say whether the above would help, but if it can be done
> this way, I think it would be preferable to introducing new user options
> for the exlusive use of the org latex exporter. There are legitimate uses
> for user options but working around bugs in downstream packages is
> not one of them. IMO, of course.
>
> Nick
>

Aloha Nick,

Your analysis and explanation makes it clear to me that the class
template is the best place for title-position.  I hope it proves
possible to put it there.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [PATCH] latex export - title placement

[Nick Dokos]

Nick Dokos <nicholas.dokos@hp.com> wrote:

> IIUC, the only remaining thing is the position of the \title etc macros
> in the preamble or the body (or both).
> 
> There are three categories of LaTeX classes: the ones that implement
> Lamport's dictum that \title etc can come anywhere before \maketitle,
> the ones like RevTeX that insist on having them in the body and the ones
> like the thesis document class at Suvayu's university, that insist on
> having them in the preamble. I consider both of the latter two as buggy:
> has anybody submitted a bug report on them?
> 

I tried an experiment:

I cannot get at the thesis document class at Suvayu's university but I
most certainly can get to RevTeX. So I started with a simple org file:

,----
| #+LATEX_CLASS: revtex4-1
| #+TITLE: foo
| #+AUTHOR: nick
| #+DATE:
| 
| * foo
| 
| bar
`----


I then added a definition for the revtex4-1 class to org-export-latex-classes.
I just copied the article class and renamed appropriately:

,----
|     ...
|     ("revtex4-1"
|      "\\documentclass[11pt]{revtex4-1}"
|      ("\\section{%s}" . "\\section*{%s}")
|      ("\\subsection{%s}" . "\\subsection*{%s}")
|      ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
|      ("\\paragraph{%s}" . "\\paragraph*{%s}")
|      ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
|     ...
`----


Exporting to latex and compiling gives errors, the first one of which says:

,----
| ...
| *hyperref using default driver hpdftex*
| (/usr/share/texmf-texlive/tex/latex/hyperref/hpdftex.def)
| ! Undefined control sequence.
| <argument> \collaboration@sw 
|                              {\advance \c@collab \@ne \@argswap {\CO@grp \CO...
| l.21 \author{nick}
| ...
`----

Basically, \author{nick} got expanded into something involving \collaboration@sw which
is currently undefined. So off to /usr/share/texmf-texlive/tex/latex/revtex/revtex4-1.cls
I went and found the following expansion sequence:

   \author -> \frontmatter@author -> \@author@def -> \move@AU -> \collaboration@sw -> ...

So let's see where the latter is initialized:

,----
| \def\collaboration{% implicit #1
|  \@author@def{\@booleantrue\collaboration@sw}% implicit #2
| }%
| 
| \appdef\frontmatter@init{%
|  \@booleanfalse\collaboration@sw
| }%
| 
| \def\@author@init{%
|  \let\@author\@author@cleared
|  \@booleanfalse\collaboration@sw
| }%
`----


So \collaboration@sw is a boolean (when it is defined) and I gueesed that the most likely place
was the \frontmatter@init macro. So what happens if we call the macro in the preamble just before
the \title, \author and \date junk?
To do that, create a revtexbug.sty file with the following contents:

--8<---------------cut here---------------start------------->8---
\makeatletter
\frontmatter@init
\makeatother
--8<---------------cut here---------------end--------------->8---

and modify the org file to

--8<---------------cut here---------------start------------->8---
#+LATEX_CLASS: revtex4-1
#+TITLE: foo
#+AUTHOR: nick
#+DATE:

#+LATEX_HEADER: \usepackage{revtexbug}

* foo

bar
--8<---------------cut here---------------end--------------->8---

Export to latex, process and voilà: no errors.

I don't want to pretend of course that this solves the problem: it might
cause more problems than it solves, particularly since I know nothing about
revtex and all the above is (more-or-less informed) guesswork.

Nevertheless, it might be worth trying on a real document and seeing if
it resolves the problem without causing undue misery. If it does, you
can have a more-or-less permanent solution by just moving the
revtexbug.sty file to some directory where latex can find it (don't
forget to run texhash) and use the above as a template. You can probably
customize the class template to do the \usepackage for you.

Please report back whether it works or not. If it does, maybe you can
ask the RevTeX maintainers to fix the package: it's much more likely to
happen if you tell them how to fix it ;-) And we can add an item to the
FAQ. I just hope that there are no other classes that misbehave this way...

Nick

Re: [PATCH] latex export - title placement

[Sebastian Hofer]

At Wed, 01 Jun 2011 18:05:28 -0400,
Nick Dokos wrote:
> 
> Thomas S. Dye <tsd@tsdye.com> wrote:
> 
> > Sebastian Hofer <sebhofer@gmail.com> writes:
> > 
> > > Hi all,
> > >
> > > This patch addresses the problem of ambiguous conventions for the
> > > placement of the title related macros (\author, \date,...) with
> > > respect to the main document body in different latex classes. It
> > > introduces the following changes:
> > >
> > > * org-exp.el:
> > >     - added the following options:
> > >       - title-position (tpos)
> > >       - with-title (wtitle)
> > >       - with-author (wauth)
> 
> [This is mostly addressed to Sebastian even though I'm replying to Tom's
> reply.]
> 
> An empty
> 
> #+AUTHOR:
> 
> disables the insertion of author (assuming that TITLE is not empty -
> see below.)
> 
> 
> > >       - with-date (wdate)
> 
> An empty
> 
> #+DATE:
> 
> disables the insertion of date (same assumption.)
> 
> > >       - with-maketitle (wmtitle)
> 
> An empty
> 
> #+TITLE:
> 
> disables the insertion of \maketitle.

To be honest, I didn't try setting empty author and date (which of
course makes sense) I just tried not setting them at all, which gives
default values. The main reason I submitted this patch, however, is
having better control of \maketitle. Personally I would like to be
able to have the title and author at the beginning of the file, just
for the looks, and still be able to produce a customized title. Of
course it is highly debatable if this is a sound reason to introduce
new options (I would argue yes).

> So if TITLE is not empty, you can get what you want with existing
> machinery. I could not find a way to make the title empty  and still
> have author and/or date fields.
> 
> Given all this, I think the only things you need is title-position and
> with-title, the latter in the unlikely event that you want a title page
> with author or date but without a title. Personally, I'd consider this
> last one unimportant and not worry about it, but you may disagree.

I agree concerning the author but no title case, this also does not
seem interesting to me.

> > >     
> > > * org-latex.el:
> > >     - implemented handling of new options (see above):
> > >       - title-position controls placement of \title, \author, \date;
> > >         possible values are "b" = before \begin{document},
> > >         any other values default to after \begin{document}
> > >       - with-* controls if the corresponding macro is exported at all
> > >         this can be convenient for more complex titles (e.g. several
> > >         authors including affiliations,...)
> > >
> > > The patch seems to work for me so far. What do you all think? IMO it
> > > would be useful to integrate this, as it gives slightly more control
> > > over the export process. Of course one might want to think about
> > > better option names. The diff is done against commit
> > > bc161ded3693f752616dcd247fc9d638789025ee.
> > >
> > > Let me briefly describe my current use case:
> > > I disable all commands except \title, use babel to created a title.tex
> > > file (including several authors and affiliations) by tangling latex
> > > code and then include the file (into the main body of the document,
> > > not the preamble). That's the only decent way I've found to do this,
> > > if anyone knows an easier way (I have the feeling that I might be
> > > overlooking an obvious solution) please let me know!
> > >
> 
> I'm not sure what problem you are trying to solve here: can you explain?
> It seems to me that all this can be done in standard ways.
> 

I'm using revtex4-1 at the moment. I need a title which looks like
this (within the document environment):

\begin{abstract}
 some blabla
\end{abstract}
\author{First author}
\affiliation{First affiliation}
\affiliation{Second affiliation}
\author{Second author}
\affiliation{Third affiliation}
...
\keywords{optional keywords}
\pacs{optional pacs}
\maketitle

How would you solve this problem?

> > > Cheers
> > > Sebastian
> > >
> > >
> > Aloha Sebastian,
> > 
> > Your patch should prove useful in the situation where one has to use a
> > particular class file that requires \title and friends to be declared in
> > the body of the document rather than the preamble.  That functionality
> > is a welcome addition to the LaTeX exporter, IMO.
> > 
> 
> IIUC, the only remaining thing is the position of the \title etc macros
> in the preamble or the body (or both).
> 
> There are three categories of LaTeX classes: the ones that implement
> Lamport's dictum that \title etc can come anywhere before \maketitle,
> the ones like RevTeX that insist on having them in the body and the ones
> like the thesis document class at Suvayu's university, that insist on
> having them in the preamble. I consider both of the latter two as buggy:
> has anybody submitted a bug report on them?
> 
> Has anybody researched the prevalence of these bugs? Are there lots of
> classes in one or the other of the buggy categories?
> 
> Be that as it may, it seems that org needs a patch to work around these
> bugs.  Personally, since it is a class problem, I'd rather have this
> kind of information in the class template.  You set it once for each
> class that needs it and you forget about it. Assuming the maintainers
> agree, any chance of reworking the patch along these lines? Maybe make
> it extensible as well: a property list that can accumulate all the junk
> in one place perhaps. That way the RevTeX class can be configured
> appropriately and the rest of the world can live in blissful ignorance
> of the problem. You might detect a bias here: I prefer these things in
> the preamble by default.

Last time this topic came up (because of Suvayu Ali's thesis) I posted
something along these lines (http://article.gmane.org/gmane.emacs.orgmode/41129),
wondering what's the best place to fix this problem. I never got any replies
(maybe also because the thread was already a month old by that time).
Back then I concluded that the class templates are not the best place
to handle this, as they are only concerned with the preamble, but not
with the body of the document. And I still don't see how this should
fit in exactly. I agree of course that it would be the nicest thing to
set this on a per class basis.
 
> > Another way to achieve your current use case, IIUC, which might or might
> > not seem easier, is to redefine \maketitle along the lines suggested by
> > Nick Dokos (see
> > http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-11_2).
> > 
> 
> As I mentioned, I'm not really sure what Sebastian is looking for, so I
> can't really say whether the above would help, but if it can be done
> this way, I think it would be preferable to introducing new user options
> for the exlusive use of the org latex exporter. There are legitimate uses
> for user options but working around bugs in downstream packages is
> not one of them. IMO, of course.
> 
> Nick
> 

Thanks for the detailed response, I'm hopeful that we can finally find
a solution to this problem. I have some other comments to your later
post about revtex, I will reply to this separately.

Sebastian

Re: [PATCH] latex export - title placement

[Sebastian Hofer]

At Wed, 01 Jun 2011 19:55:51 -0400,
Nick Dokos wrote:
> 
> Nick Dokos <nicholas.dokos@hp.com> wrote:
> 
> > IIUC, the only remaining thing is the position of the \title etc macros
> > in the preamble or the body (or both).
> > 
> > There are three categories of LaTeX classes: the ones that implement
> > Lamport's dictum that \title etc can come anywhere before \maketitle,
> > the ones like RevTeX that insist on having them in the body and the ones
> > like the thesis document class at Suvayu's university, that insist on
> > having them in the preamble. I consider both of the latter two as buggy:
> > has anybody submitted a bug report on them?
> > 
> 
> I tried an experiment:
> 
> I cannot get at the thesis document class at Suvayu's university but I
> most certainly can get to RevTeX. So I started with a simple org file:
> 
> ,----
> | #+LATEX_CLASS: revtex4-1
> | #+TITLE: foo
> | #+AUTHOR: nick
> | #+DATE:
> | 
> | * foo
> | 
> | bar
> `----
> 
> 
> I then added a definition for the revtex4-1 class to org-export-latex-classes.
> I just copied the article class and renamed appropriately:
> 
> ,----
> |     ...
> |     ("revtex4-1"
> |      "\\documentclass[11pt]{revtex4-1}"
> |      ("\\section{%s}" . "\\section*{%s}")
> |      ("\\subsection{%s}" . "\\subsection*{%s}")
> |      ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
> |      ("\\paragraph{%s}" . "\\paragraph*{%s}")
> |      ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
> |     ...
> `----
> 
> 
> Exporting to latex and compiling gives errors, the first one of which says:
> 
> ,----
> | ...
> | *hyperref using default driver hpdftex*
> | (/usr/share/texmf-texlive/tex/latex/hyperref/hpdftex.def)
> | ! Undefined control sequence.
> | <argument> \collaboration@sw 
> |                              {\advance \c@collab \@ne \@argswap {\CO@grp \CO...
> | l.21 \author{nick}
> | ...
> `----
> 
> Basically, \author{nick} got expanded into something involving \collaboration@sw which
> is currently undefined. So off to /usr/share/texmf-texlive/tex/latex/revtex/revtex4-1.cls
> I went and found the following expansion sequence:
> 
>    \author -> \frontmatter@author -> \@author@def -> \move@AU -> \collaboration@sw -> ...
> 
> So let's see where the latter is initialized:
> 
> ,----
> | \def\collaboration{% implicit #1
> |  \@author@def{\@booleantrue\collaboration@sw}% implicit #2
> | }%
> | 
> | \appdef\frontmatter@init{%
> |  \@booleanfalse\collaboration@sw
> | }%
> | 
> | \def\@author@init{%
> |  \let\@author\@author@cleared
> |  \@booleanfalse\collaboration@sw
> | }%
> `----
> 
> 
> So \collaboration@sw is a boolean (when it is defined) and I gueesed that the most likely place
> was the \frontmatter@init macro. So what happens if we call the macro in the preamble just before
> the \title, \author and \date junk?
> To do that, create a revtexbug.sty file with the following contents:
> 
> --8<---------------cut here---------------start------------->8---
> \makeatletter
> \frontmatter@init
> \makeatother
> --8<---------------cut here---------------end--------------->8---
> 
> and modify the org file to
> 
> --8<---------------cut here---------------start------------->8---
> #+LATEX_CLASS: revtex4-1
> #+TITLE: foo
> #+AUTHOR: nick
> #+DATE:
> 
> #+LATEX_HEADER: \usepackage{revtexbug}
> 
> * foo
> 
> bar
> --8<---------------cut here---------------end--------------->8---
> 
> Export to latex, process and voilà: no errors.
> 
> I don't want to pretend of course that this solves the problem: it might
> cause more problems than it solves, particularly since I know nothing about
> revtex and all the above is (more-or-less informed) guesswork.
> 
> Nevertheless, it might be worth trying on a real document and seeing if
> it resolves the problem without causing undue misery. If it does, you
> can have a more-or-less permanent solution by just moving the
> revtexbug.sty file to some directory where latex can find it (don't
> forget to run texhash) and use the above as a template. You can probably
> customize the class template to do the \usepackage for you.
> 
> Please report back whether it works or not. If it does, maybe you can
> ask the RevTeX maintainers to fix the package: it's much more likely to
> happen if you tell them how to fix it ;-) And we can add an item to the
> FAQ. I just hope that there are no other classes that misbehave this way...


Unfortunately I couldn't get this to work just right now, also not for
the minimal example you provided. I will probably look into it when I
have more time on my hands. 
The real problem, however, is a different one: I use the revtex class
to submit research papers to the American Physical Society. And I
don't think they will be happy with me providing my own package which
works around one of the "features" of their own class. So unless we
can get them to fix the class, we (or I for that matter) are out of
luck. I haven't consider reporting this to them as I thought it would
be useless, but of course one could always try...
 
I still think that we should implement a way to handle this situation
in org, I'm pretty sure this is not the only class which doesn't
conform to the standards out there.

Sebastian

Re: [PATCH] latex export - title placement

[Nick Dokos]

Sebastian Hofer <sebhofer@gmail.com> wrote:

> At Wed, 01 Jun 2011 18:05:28 -0400,
> Nick Dokos wrote:
> > 
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> > 
> > > Sebastian Hofer <sebhofer@gmail.com> writes:
> > > 
> > > > Hi all,
> > > >
> > > > This patch addresses the problem of ambiguous conventions for the
> > > > placement of the title related macros (\author, \date,...) with
> > > > respect to the main document body in different latex classes. It
> > > > introduces the following changes:
> > > >
> > > > * org-exp.el:
> > > >     - added the following options:
> > > >       - title-position (tpos)
> > > >       - with-title (wtitle)
> > > >       - with-author (wauth)
> > 
> > [This is mostly addressed to Sebastian even though I'm replying to Tom's
> > reply.]
> > 
> > An empty
> > 
> > #+AUTHOR:
> > 
> > disables the insertion of author (assuming that TITLE is not empty -
> > see below.)
> > 
> > 
> > > >       - with-date (wdate)
> > 
> > An empty
> > 
> > #+DATE:
> > 
> > disables the insertion of date (same assumption.)
> > 
> > > >       - with-maketitle (wmtitle)
> > 
> > An empty
> > 
> > #+TITLE:
> > 
> > disables the insertion of \maketitle.
> 
> To be honest, I didn't try setting empty author and date (which of
> course makes sense) I just tried not setting them at all, which gives
> default values. The main reason I submitted this patch, however, is
> having better control of \maketitle. Personally I would like to be
> able to have the title and author at the beginning of the file, just
> for the looks, and still be able to produce a customized title. Of
> course it is highly debatable if this is a sound reason to introduce
> new options (I would argue yes).
> 

Before anybody else wastes their time on this: I'm not sure whether I
was in an alternative universe yesterday, or I am in one today, but
I can't even reproduce my own results. I'll start again and try to get it
right this time, but I'm not going to be able to do that immediately.

Apologies for the confusion.

Nick

Re: [PATCH] latex export - title placement

[Sebastian Hofer]

At Thu, 02 Jun 2011 11:57:07 -0400,
Nick Dokos wrote:
> 
> Sebastian Hofer <sebhofer@gmail.com> wrote:
> 
> > At Wed, 01 Jun 2011 18:05:28 -0400,
> > Nick Dokos wrote:
> > > 
> > > Thomas S. Dye <tsd@tsdye.com> wrote:
> > > 
> > > > Sebastian Hofer <sebhofer@gmail.com> writes:
> > > > 
> > > > > Hi all,
> > > > >
> > > > > This patch addresses the problem of ambiguous conventions for the
> > > > > placement of the title related macros (\author, \date,...) with
> > > > > respect to the main document body in different latex classes. It
> > > > > introduces the following changes:
> > > > >
> > > > > * org-exp.el:
> > > > >     - added the following options:
> > > > >       - title-position (tpos)
> > > > >       - with-title (wtitle)
> > > > >       - with-author (wauth)
> > > 
> > > [This is mostly addressed to Sebastian even though I'm replying to Tom's
> > > reply.]
> > > 
> > > An empty
> > > 
> > > #+AUTHOR:
> > > 
> > > disables the insertion of author (assuming that TITLE is not empty -
> > > see below.)
> > > 
> > > 
> > > > >       - with-date (wdate)
> > > 
> > > An empty
> > > 
> > > #+DATE:
> > > 
> > > disables the insertion of date (same assumption.)
> > > 
> > > > >       - with-maketitle (wmtitle)
> > > 
> > > An empty
> > > 
> > > #+TITLE:
> > > 
> > > disables the insertion of \maketitle.
> > 
> > To be honest, I didn't try setting empty author and date (which of
> > course makes sense) I just tried not setting them at all, which gives
> > default values. The main reason I submitted this patch, however, is
> > having better control of \maketitle. Personally I would like to be
> > able to have the title and author at the beginning of the file, just
> > for the looks, and still be able to produce a customized title. Of
> > course it is highly debatable if this is a sound reason to introduce
> > new options (I would argue yes).
> > 
> 
> Before anybody else wastes their time on this: I'm not sure whether I
> was in an alternative universe yesterday, or I am in one today, but
> I can't even reproduce my own results. I'll start again and try to get it
> right this time, but I'm not going to be able to do that immediately.
> 
> Apologies for the confusion.

Concerning confusion: What I actually wanted to say above was that the
main focus of the patch was to provide means for controlling the
placement of \author, \date, \email etc., not \maketitle.

Apologies for the confusion :)

Sebastian

[bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Sebastien Vauban]

Hello,

In conditions which I consider unchanged (I speak of my emacs config file),
with the latest Org-mode version, I now have the message:

    let*: Symbol's function definition is void: org-pop-to-buffer-same-window

when doing, for example, `C-c C-x C-j' to jump on the currently clocked item.

Explicitly Loading `org-compat' does cure this problem... But we must miss a
`require' somewhere, but where?  In `org.el' itself?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Kenny Meyer]

I am getting the same message here upon calling various org-functions
(e.g.: org-drill, org-submit-bug-report), since I have compiled
org-mode from git, but I am not sure where exactly the error was
introduced.

> Explicitly Loading `org-compat' does cure this problem...
Requiring org-compat does not fix that here.
Can you tell me where exactly you loaded org-compat?

Org-mode version 7.7 (release_7.7.617.gb1f2)
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29

--
Kenny Meyer



On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
<wxhgmqzgwmuf@spammotel.com> wrote:
> Hello,
>
> In conditions which I consider unchanged (I speak of my emacs config file),
> with the latest Org-mode version, I now have the message:
>
>    let*: Symbol's function definition is void: org-pop-to-buffer-same-window
>
> when doing, for example, `C-c C-x C-j' to jump on the currently clocked item.
>
> Explicitly Loading `org-compat' does cure this problem... But we must miss a
> `require' somewhere, but where?  In `org.el' itself?
>
> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Nick Dokos]

Kenny Meyer <knny.myer@gmail.com> wrote:

> I am getting the same message here upon calling various org-functions
> (e.g.: org-drill, org-submit-bug-report), since I have compiled
> org-mode from git, but I am not sure where exactly the error was
> introduced.
> 
> > Explicitly Loading `org-compat' does cure this problem...
> Requiring org-compat does not fix that here.
> Can you tell me where exactly you loaded org-compat?
> 
> Org-mode version 7.7 (release_7.7.617.gb1f2)
> GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
> 
> --
> Kenny Meyer
> 

IIRC, the cure for macro problems like this is to

      make clean
      make

(alternatively, make clean and just use uncompiled code). There might be
something missing to cause it, but I don't think so in this case: I
tried a minimal .emacs with the same version as above (Org-mode version
7.7 (release_7.7.617.gb1f2) and I can start, goto the active clock and
stop it with no errors.

Nick


> 
> 
> On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
> <wxhgmqzgwmuf@spammotel.com> wrote:
> > Hello,
> >
> > In conditions which I consider unchanged (I speak of my emacs config file),
> > with the latest Org-mode version, I now have the message:
> >
> >    let*: Symbol's function definition is void: org-pop-to-buffer-same-window
> >
> > when doing, for example, `C-c C-x C-j' to jump on the currently clocked item.
> >
> > Explicitly Loading `org-compat' does cure this problem... But we must miss a
> > `require' somewhere, but where?  In `org.el' itself?
> >
> > Best regards,
> >  Seb
> >
> > --
> > Sebastien Vauban
> >
> >
> 

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Nick Dokos]

Nick Dokos <nicholas.dokos@hp.com> wrote:

> Kenny Meyer <knny.myer@gmail.com> wrote:
> 
> > I am getting the same message here upon calling various org-functions
> > (e.g.: org-drill, org-submit-bug-report), since I have compiled
> > org-mode from git, but I am not sure where exactly the error was
> > introduced.
> > 
> > > Explicitly Loading `org-compat' does cure this problem...
> > Requiring org-compat does not fix that here.
> > Can you tell me where exactly you loaded org-compat?
> > 
> > Org-mode version 7.7 (release_7.7.617.gb1f2)
> > GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
> > 
> > --
> > Kenny Meyer
> > 
> 
> IIRC, the cure for macro problems like this is to
> 

Sorry - I thought it was a macro but it isn't. Nevertheless,
the note below still stands.

Nick

>       make clean
>       make
> 
> (alternatively, make clean and just use uncompiled code). There might be
> something missing to cause it, but I don't think so in this case: I
> tried a minimal .emacs with the same version as above (Org-mode version
> 7.7 (release_7.7.617.gb1f2) and I can start, goto the active clock and
> stop it with no errors.
> 
> Nick
> 
> 
> > 
> > 
> > On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
> > <wxhgmqzgwmuf@spammotel.com> wrote:
> > > Hello,
> > >
> > > In conditions which I consider unchanged (I speak of my emacs config file),
> > > with the latest Org-mode version, I now have the message:
> > >
> > >    let*: Symbol's function definition is void: org-pop-to-buffer-same-window
> > >
> > > when doing, for example, `C-c C-x C-j' to jump on the currently clocked item.
> > >
> > > Explicitly Loading `org-compat' does cure this problem... But we must miss a
> > > `require' somewhere, but where?  In `org.el' itself?
> > >
> > > Best regards,
> > >  Seb
> > >
> > > --
> > > Sebastien Vauban
> > >
> > >
> > 
> 

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Kenny Meyer]

According to this discussion on the mailing list,
http://comments.gmane.org/gmane.emacs.orgmode/48571 , this is a known
bug.

I fixed this by loading "org-compat" after requiring org-mode from
git, just like Sebastian said.

--
Kenny Meyer



On Thu, Dec 1, 2011 at 12:05 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> Nick Dokos <nicholas.dokos@hp.com> wrote:
>
>> Kenny Meyer <knny.myer@gmail.com> wrote:
>>
>> > I am getting the same message here upon calling various org-functions
>> > (e.g.: org-drill, org-submit-bug-report), since I have compiled
>> > org-mode from git, but I am not sure where exactly the error was
>> > introduced.
>> >
>> > > Explicitly Loading `org-compat' does cure this problem...
>> > Requiring org-compat does not fix that here.
>> > Can you tell me where exactly you loaded org-compat?
>> >
>> > Org-mode version 7.7 (release_7.7.617.gb1f2)
>> > GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
>> >
>> > --
>> > Kenny Meyer
>> >
>>
>> IIRC, the cure for macro problems like this is to
>>
>
> Sorry - I thought it was a macro but it isn't. Nevertheless,
> the note below still stands.
>
> Nick
>
>>       make clean
>>       make
>>
>> (alternatively, make clean and just use uncompiled code). There might be
>> something missing to cause it, but I don't think so in this case: I
>> tried a minimal .emacs with the same version as above (Org-mode version
>> 7.7 (release_7.7.617.gb1f2) and I can start, goto the active clock and
>> stop it with no errors.
>>
>> Nick
>>
>>
>> >
>> >
>> > On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
>> > <wxhgmqzgwmuf@spammotel.com> wrote:
>> > > Hello,
>> > >
>> > > In conditions which I consider unchanged (I speak of my emacs config file),
>> > > with the latest Org-mode version, I now have the message:
>> > >
>> > >    let*: Symbol's function definition is void: org-pop-to-buffer-same-window
>> > >
>> > > when doing, for example, `C-c C-x C-j' to jump on the currently clocked item.
>> > >
>> > > Explicitly Loading `org-compat' does cure this problem... But we must miss a
>> > > `require' somewhere, but where?  In `org.el' itself?
>> > >
>> > > Best regards,
>> > >  Seb
>> > >
>> > > --
>> > > Sebastien Vauban
>> > >
>> > >
>> >
>>

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Nick Dokos]

Kenny Meyer <knny.myer@gmail.com> wrote:

> According to this discussion on the mailing list,
> http://comments.gmane.org/gmane.emacs.orgmode/48571 , this is a known
> bug.
> 
> I fixed this by loading "org-compat" after requiring org-mode from
> git, just like Sebastian said.
> 

I don't think it's a bug in org: if you start with a clean copy of the
repo (make clean; make) and have your load-path pointing there, you
should not see any problems.

IIUC, Michael Bach's problem (a fairly common one, btw) was that he was
mixing different installations: he was picking up a recent org-capture
that was using org-pop-to-buffer-same-window, but an older org-compat
that did not include the definition of that function.

You have to make sure that all of the pieces come from the same place,
but there is still a gotcha in the sense that an old .elc file will
be picked up by emacs in preference to a new .el file (possibly with
a warning, but who looks at warnings?)

Hence assuming you are using git to keep up to date:

	make clean
	make
	C-h v load-path RET
	[make sure that your load path points at your git directory *first*]
	M-x org-reload RET
	[or perhaps safer: restart emacs]

And use M-x locate-library to make sure that emacs agrees with you about
where things are picked up from.

Nick


> --
> Kenny Meyer
> 
> 
> 
> On Thu, Dec 1, 2011 at 12:05 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> > Nick Dokos <nicholas.dokos@hp.com> wrote:
> >
> >> Kenny Meyer <knny.myer@gmail.com> wrote:
> >>
> >> > I am getting the same message here upon calling various org-functions
> >> > (e.g.: org-drill, org-submit-bug-report), since I have compiled
> >> > org-mode from git, but I am not sure where exactly the error was
> >> > introduced.
> >> >
> >> > > Explicitly Loading `org-compat' does cure this problem...
> >> > Requiring org-compat does not fix that here.
> >> > Can you tell me where exactly you loaded org-compat?
> >> >
> >> > Org-mode version 7.7 (release_7.7.617.gb1f2)
> >> > GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
> >> >
> >> > --
> >> > Kenny Meyer
> >> >
> >>
> >> IIRC, the cure for macro problems like this is to
> >>
> >
> > Sorry - I thought it was a macro but it isn't. Nevertheless,
> > the note below still stands.
> >
> > Nick
> >
> >>       make clean
> >>       make
> >>
> >> (alternatively, make clean and just use uncompiled code). There might be
> >> something missing to cause it, but I don't think so in this case: I
> >> tried a minimal .emacs with the same version as above (Org-mode version
> >> 7.7 (release_7.7.617.gb1f2) and I can start, goto the active clock and
> >> stop it with no errors.
> >>
> >> Nick
> >>
> >>
> >> >
> >> >
> >> > On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
> >> > <wxhgmqzgwmuf@spammotel.com> wrote:
> >> > > Hello,
> >> > >
> >> > > In conditions which I consider unchanged (I speak of my emacs config file),
> >> > > with the latest Org-mode version, I now have the message:
> >> > >
> >> > >    let*: Symbol's function definition is void: org-pop-to-buffer-same-window
> >> > >
> >> > > when doing, for example, `C-c C-x C-j' to jump on the currently clocked item.
> >> > >
> >> > > Explicitly Loading `org-compat' does cure this problem... But we must miss a
> >> > > `require' somewhere, but where?  In `org.el' itself?
> >> > >
> >> > > Best regards,
> >> > >  Seb
> >> > >
> >> > > --
> >> > > Sebastien Vauban
> >> > >
> >> > >
> >> >
> >>
> 

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Sebastien Vauban]

Hi Nick,

Nick Dokos wrote:
> Kenny Meyer <knny.myer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> According to this discussion on the mailing list,
>> http://comments.gmane.org/gmane.emacs.orgmode/48571 , this is a known
>> bug.
>> 
>> I fixed this by loading "org-compat" after requiring org-mode from
>> git, just like Sebastian said.
>
> I don't think it's a bug in org: if you start with a clean copy of the
> repo (make clean; make) and have your load-path pointing there, you
> should not see any problems.
>
> IIUC, Michael Bach's problem (a fairly common one, btw) was that he was
> mixing different installations: he was picking up a recent org-capture
> that was using org-pop-to-buffer-same-window, but an older org-compat
> that did not include the definition of that function.

I don't see why I would suddenly have mixed paths in my .emacs file -- though
this can always happen, as it is changed almost daily, here and there.

> You have to make sure that all of the pieces come from the same place,
> but there is still a gotcha in the sense that an old .elc file will
> be picked up by emacs in preference to a new .el file (possibly with
> a warning, but who looks at warnings?)
>
> Hence assuming you are using git to keep up to date:
>
> 	make clean

I don't use compiled files, so problem is not that.

> 	make
> 	C-h v load-path RET

load-path's value is
(...
"c:/home/sva/src/org-mode/contrib/lisp"
"c:/home/sva/src/org-mode/lisp"
...
"c:/Program Files/Emacs-24.0/lisp/org"
...)

> 	[make sure that your load path points at your git directory *first*]

Checked.

> 	M-x org-reload RET
> 	[or perhaps safer: restart emacs]
>
> And use M-x locate-library to make sure that emacs agrees with you about
> where things are picked up from.

Library is file ~/src/org-mode/lisp/org-compat.el

Library is file ~/src/org-mode/lisp/org.el

It's not obvious what I would have changed for getting this now... but I'll
diff my emacs config files, if you say you don't have such a problem.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Nick Dokos]

Sebastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:

> > I don't think it's a bug in org: if you start with a clean copy of the
> > repo (make clean; make) and have your load-path pointing there, you
> > should not see any problems.
> >
> > IIUC, Michael Bach's problem (a fairly common one, btw) was that he was
> > mixing different installations: he was picking up a recent org-capture
> > that was using org-pop-to-buffer-same-window, but an older org-compat
> > that did not include the definition of that function.
> 
> I don't see why I would suddenly have mixed paths in my .emacs file -- though
> this can always happen, as it is changed almost daily, here and there.
> 
> > You have to make sure that all of the pieces come from the same place,
> > but there is still a gotcha in the sense that an old .elc file will
> > be picked up by emacs in preference to a new .el file (possibly with
> > a warning, but who looks at warnings?)
> >
> > Hence assuming you are using git to keep up to date:
> >
> > 	make clean
> 
> I don't use compiled files, so problem is not that.
> 
> > 	make
> > 	C-h v load-path RET
> 
> load-path's value is
> (...
> "c:/home/sva/src/org-mode/contrib/lisp"
> "c:/home/sva/src/org-mode/lisp"
> ...
> "c:/Program Files/Emacs-24.0/lisp/org"
> ...)
> 
> > 	[make sure that your load path points at your git directory *first*]
> 
> Checked.
> 
> > 	M-x org-reload RET
> > 	[or perhaps safer: restart emacs]
> >
> > And use M-x locate-library to make sure that emacs agrees with you about
> > where things are picked up from.
> 
> Library is file ~/src/org-mode/lisp/org-compat.el
> 
> Library is file ~/src/org-mode/lisp/org.el
> 
> It's not obvious what I would have changed for getting this now... but I'll
> diff my emacs config files, if you say you don't have such a problem.
> 

It is possible that any particular pull from the git repo will get you
a buggy version - so when I said it's not a bug, I should have said:
it's not a bug with the version that I tested at the time. That's
reason #357 for *always* reporting the org version one is using.

With that caveat stated, if the steps above don't resolve the problem,
then it might be a bug in org, but, given the history of problems with
mixed installs[fn:1], it behooves one to make sure that one's install does
*not* have that problem: locate-library is your friend.

And, fwiw, I don't see the problem with Org-mode version 7.7
(release_7.7.617.gb1f2).

Nick

Footnotes:

[fn:1] ... assuming I have not misinterpreted the underlying cause of
       Michael Bach's problem in the thread that Kenny Myers quoted, of
       course.

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Shelagh Manton]

On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:

> I am getting the same message here upon calling various org-functions
> (e.g.: org-drill, org-submit-bug-report), since I have compiled org-mode
> from git, but I am not sure where exactly the error was introduced.
> 
>> Explicitly Loading `org-compat' does cure this problem...
> Requiring org-compat does not fix that here. Can you tell me where
> exactly you loaded org-compat?
> 
> Org-mode version 7.7 (release_7.7.617.gb1f2) GNU Emacs 24.0.50.1
> (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
> 
> --
> Kenny Meyer
> 
> 
> 
> On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
> <wxhgmqzgwmuf@spammotel.com> wrote:
>> Hello,
>>
>> In conditions which I consider unchanged (I speak of my emacs config
>> file), with the latest Org-mode version, I now have the message:
>>
>>    let*: Symbol's function definition is void:
>>    org-pop-to-buffer-same-window
>>
>> when doing, for example, `C-c C-x C-j' to jump on the currently clocked
>> item.
>>
>> Explicitly Loading `org-compat' does cure this problem... But we must
>> miss a `require' somewhere, but where?  In `org.el' itself?
>>
>> Best regards,
>>  Seb
>>
>> --
>> Sebastien Vauban
>>
>>

Hi

I've just been bitten by this as well. requiring org-compat manually did 
nothing. My config files have not changed, just pulled latest org-mode, 
did a make clean and make. Suddenly my org-drill sessions don't work. 

Regards

Shelagh

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Nick Dokos]

Shelagh Manton <shelagh.manton@gmail.com> wrote:

> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
> 
> > I am getting the same message here upon calling various org-functions
> > (e.g.: org-drill, org-submit-bug-report), since I have compiled org-mode
> > from git, but I am not sure where exactly the error was introduced.
> > 
> >> Explicitly Loading `org-compat' does cure this problem...
> > Requiring org-compat does not fix that here. Can you tell me where
> > exactly you loaded org-compat?
> > 
> > Org-mode version 7.7 (release_7.7.617.gb1f2) GNU Emacs 24.0.50.1
> > (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
> > 
> > --
> > Kenny Meyer
> > 
> > 
> > 
> > On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
> > <wxhgmqzgwmuf@spammotel.com> wrote:
> >> Hello,
> >>
> >> In conditions which I consider unchanged (I speak of my emacs config
> >> file), with the latest Org-mode version, I now have the message:
> >>
> >>    let*: Symbol's function definition is void:
> >>    org-pop-to-buffer-same-window
> >>
> >> when doing, for example, `C-c C-x C-j' to jump on the currently clocked
> >> item.
> >>
> >> Explicitly Loading `org-compat' does cure this problem... But we must
> >> miss a `require' somewhere, but where?  In `org.el' itself?
> >>
> >> Best regards,
> >>  Seb
> >>
> >> --
> >> Sebastien Vauban
> >>
> >>
> 
> Hi
> 
> I've just been bitten by this as well. requiring org-compat manually did 
> nothing. My config files have not changed, just pulled latest org-mode, 
> did a make clean and make. Suddenly my org-drill sessions don't work. 
> 

Did you restart emacs?

Nick

> Regards
> 
> Shelagh
> 
> 

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Shelagh Manton]

On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:

> Shelagh Manton <shelagh.manton@gmail.com> wrote:
> 
>> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
>> 
>> > I am getting the same message here upon calling various org-functions
>> > (e.g.: org-drill, org-submit-bug-report), since I have compiled
>> > org-mode from git, but I am not sure where exactly the error was
>> > introduced.
>> > 
>> >> Explicitly Loading `org-compat' does cure this problem...
>> > Requiring org-compat does not fix that here. Can you tell me where
>> > exactly you loaded org-compat?
>> > 
>> > Org-mode version 7.7 (release_7.7.617.gb1f2) GNU Emacs 24.0.50.1
>> > (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
>> > 
>> > --
>> > Kenny Meyer
>> > 
>> > 
>> > 
>> > On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
>> > <wxhgmqzgwmuf@spammotel.com> wrote:
>> >> Hello,
>> >>
>> >> In conditions which I consider unchanged (I speak of my emacs config
>> >> file), with the latest Org-mode version, I now have the message:
>> >>
>> >>    let*: Symbol's function definition is void:
>> >>    org-pop-to-buffer-same-window
>> >>
>> >> when doing, for example, `C-c C-x C-j' to jump on the currently
>> >> clocked item.
>> >>
>> >> Explicitly Loading `org-compat' does cure this problem... But we
>> >> must miss a `require' somewhere, but where?  In `org.el' itself?
>> >>
>> >> Best regards,
>> >>  Seb
>> >>
>> >> --
>> >> Sebastien Vauban
>> >>
>> >>
>> >>
>> Hi
>> 
>> I've just been bitten by this as well. requiring org-compat manually
>> did nothing. My config files have not changed, just pulled latest
>> org-mode, did a make clean and make. Suddenly my org-drill sessions
>> don't work.
>> 
>> 
> Did you restart emacs?

Yes. I did just then and same thing.

Shelagh
> 
> Nick
> 
>> Regards
>> 
>> Shelagh
>> 
>>

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Nick Dokos]

Shelagh Manton <shelagh.manton@gmail.com> wrote:

> On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:
> 
> > Shelagh Manton <shelagh.manton@gmail.com> wrote:
> > 
> >> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
> >> 
> >> > I am getting the same message here upon calling various org-functions
> >> > (e.g.: org-drill, org-submit-bug-report), since I have compiled
> >> > org-mode from git, but I am not sure where exactly the error was
> >> > introduced.
> >> > 
> >> >> Explicitly Loading `org-compat' does cure this problem...
> >> > Requiring org-compat does not fix that here. Can you tell me where
> >> > exactly you loaded org-compat?
> >> > 
> >> > Org-mode version 7.7 (release_7.7.617.gb1f2) GNU Emacs 24.0.50.1
> >> > (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
> >> > 
> >> > --
> >> > Kenny Meyer
> >> > 
> >> > 
> >> > 
> >> > On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
> >> > <wxhgmqzgwmuf@spammotel.com> wrote:
> >> >> Hello,
> >> >>
> >> >> In conditions which I consider unchanged (I speak of my emacs config
> >> >> file), with the latest Org-mode version, I now have the message:
> >> >>
> >> >>    let*: Symbol's function definition is void:
> >> >>    org-pop-to-buffer-same-window
> >> >>
> >> >> when doing, for example, `C-c C-x C-j' to jump on the currently
> >> >> clocked item.
> >> >>
> >> >> Explicitly Loading `org-compat' does cure this problem... But we
> >> >> must miss a `require' somewhere, but where?  In `org.el' itself?
> >> >>
> >> >> Best regards,
> >> >>  Seb
> >> >>
> >> >> --
> >> >> Sebastien Vauban
> >> >>
> >> >>
> >> >>
> >> Hi
> >> 
> >> I've just been bitten by this as well. requiring org-compat manually
> >> did nothing. My config files have not changed, just pulled latest
> >> org-mode, did a make clean and make. Suddenly my org-drill sessions
> >> don't work.
> >> 
> >> 
> > Did you restart emacs?
> 
> Yes. I did just then and same thing.
> 

Do you get the error with org-drill only or do you get it in the
instances that Seb and Kenny Meyer report? If the former, it may be a
bug with org-drill. Otherwise, I throw up my hands: I certainly cannot
reproduce it.

Nick

GNU Emacs 24.0.90.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-10-27
Org-mode version 7.7 (release_7.7.622.g92d30)

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Sebastien Vauban]

Hi all,

Nick Dokos wrote:
> Shelagh Manton <shelagh.manton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:
>>> Shelagh Manton <shelagh.manton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
>>>>> On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
>>>>> I am getting the same message here upon calling various org-functions
>>>>> (e.g.: org-drill, org-submit-bug-report), since I have compiled org-mode
>>>>> from git, but I am not sure where exactly the error was introduced.
>>>>>
>>>>>> Explicitly Loading `org-compat' does cure this problem...
>>>>>
>>>>> Requiring org-compat does not fix that here. Can you tell me where
>>>>> exactly you loaded org-compat?
>>>>>
>>>>> Org-mode version 7.7 (release_7.7.617.gb1f2) GNU Emacs 24.0.50.1
>>>>> (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
>>>>>
>>>>>> In conditions which I consider unchanged (I speak of my emacs config
>>>>>> file), with the latest Org-mode version, I now have the message:
>>>>>>
>>>>>>    let*: Symbol's function definition is void:
>>>>>>    org-pop-to-buffer-same-window
>>>>>>
>>>>>> when doing, for example, `C-c C-x C-j' to jump on the currently
>>>>>> clocked item.
>>>>>>
>>>>>> Explicitly Loading `org-compat' does cure this problem... But we
>>>>>> must miss a `require' somewhere, but where?  In `org.el' itself?
>>>>
>>>> I've just been bitten by this as well. requiring org-compat manually did
>>>> nothing. My config files have not changed, just pulled latest org-mode,
>>>> did a make clean and make. Suddenly my org-drill sessions don't work.
>>>
>>> Did you restart emacs?
>>
>> Yes. I did just then and same thing.
>
> Do you get the error with org-drill only or do you get it in the instances
> that Seb and Kenny Meyer report? If the former, it may be a bug with
> org-drill. Otherwise, I throw up my hands: I certainly cannot reproduce it.

FYI:

- I don't use .elc files.

- I've recently upgraded to Emacs 24.0.91.1 on Windows -- not sure if the
  problem appeared directly after, or a little bit before.

- I began suspecting work that I could have done in a branch, and mixed
  versions that way -- as I'm not yet familiar with git and switching between
  branches.

- I've deleted all my Org directory, and cloned a fresh one

But it still occurs.

Though:

- Requiring org-compat does cure the problem.

- I see calls to org-compat in every crucial Org file -- I don't understand
  where it could be missing.

- I still must try to dissecate my .emacs, or use a minimal Emacs config file
  to see if it's reproducible that way.

But I currently really have no time for spending more time on it. I hope to be
able to do so in one week or two.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[shelagh Manton]

On Wed, 07 Dec 2011 09:34:21 +0100, Sebastien Vauban wrote:

> Hi all,
> 
> Nick Dokos wrote:
>> Shelagh Manton <shelagh.manton@gmail.com>
>> wrote:
>>> On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:
>>>> Shelagh Manton
>>>> <shelagh.manton@gmail.com> wrote:
>>>>> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
>>>>>> On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban I am getting the
>>>>>> same message here upon calling various org-functions (e.g.:
>>>>>> org-drill, org-submit-bug-report), since I have compiled org-mode
>>>>>> from git, but I am not sure where exactly the error was introduced.
>>>>>>
>>>>>>> Explicitly Loading `org-compat' does cure this problem...
>>>>>>
>>>>>> Requiring org-compat does not fix that here. Can you tell me where
>>>>>> exactly you loaded org-compat?
>>>>>>
>>>>>> Org-mode version 7.7 (release_7.7.617.gb1f2) GNU Emacs 24.0.50.1
>>>>>> (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0) of 2011-09-29
>>>>>>
>>>>>>> In conditions which I consider unchanged (I speak of my emacs
>>>>>>> config file), with the latest Org-mode version, I now have the
>>>>>>> message:
>>>>>>>
>>>>>>>    let*: Symbol's function definition is void:
>>>>>>>    org-pop-to-buffer-same-window
>>>>>>>
>>>>>>> when doing, for example, `C-c C-x C-j' to jump on the currently
>>>>>>> clocked item.
>>>>>>>
>>>>>>> Explicitly Loading `org-compat' does cure this problem... But we
>>>>>>> must miss a `require' somewhere, but where?  In `org.el' itself?
>>>>>
>>>>> I've just been bitten by this as well. requiring org-compat manually
>>>>> did nothing. My config files have not changed, just pulled latest
>>>>> org-mode, did a make clean and make. Suddenly my org-drill sessions
>>>>> don't work.
>>>>
>>>> Did you restart emacs?
>>>
>>> Yes. I did just then and same thing.
>>
>> Do you get the error with org-drill only or do you get it in the
>> instances that Seb and Kenny Meyer report? If the former, it may be a
>> bug with org-drill. Otherwise, I throw up my hands: I certainly cannot
>> reproduce it.
> 
> FYI:
> 
> - I don't use .elc files.
> 
> - I've recently upgraded to Emacs 24.0.91.1 on Windows -- not sure if
> the
>   problem appeared directly after, or a little bit before.
> 
> - I began suspecting work that I could have done in a branch, and mixed
>   versions that way -- as I'm not yet familiar with git and switching
>   between branches.
> 
> - I've deleted all my Org directory, and cloned a fresh one
> 
> But it still occurs.
> 
> Though:
> 
> - Requiring org-compat does cure the problem.
> 
> - I see calls to org-compat in every crucial Org file -- I don't
> understand
>   where it could be missing.
> 
> - I still must try to dissecate my .emacs, or use a minimal Emacs config
> file
>   to see if it's reproducible that way.
> 
> But I currently really have no time for spending more time on it. I hope
> to be able to do so in one week or two.
> 
> Best regards,
>   Seb

In the end I just found the function and pasted it into my dotemacs file. 
I really need to get rid of my org-mode cruft. I have so many snippets 
and configs in separate files that probably should just be done in 
customize. I just don't have time to work out where all the problems are 
coming from unless they are showstoppers like this one.

Cheers
Shelagh

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Sebastien Vauban]

Hi all,

"Sebastien Vauban" wrote:
> Nick Dokos wrote:
>> Shelagh Manton <shelagh.manton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:
>>>> Shelagh Manton <shelagh.manton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
>>>>>> On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
>>>>>>> In conditions which I consider unchanged (I speak of my emacs config
>>>>>>> file), with the latest Org-mode version, I now have the message:

There was the original mistake: conditions were changed!

>>>>>>>   let*: Symbol's function definition is void:
>>>>>>>   org-pop-to-buffer-same-window
>>>>>>>
>>>>>>> when doing, for example, `C-c C-x C-j' to jump on the currently
>>>>>>> clocked item.
>>>>>>>
>>>>>>> Explicitly Loading `org-compat' does cure this problem... But we
>>>>>>> must miss a `require' somewhere, but where?  In `org.el' itself?
>>>>>
>>>>> I've just been bitten by this as well. requiring org-compat manually did
>>>>> nothing. My config files have not changed, just pulled latest org-mode,
>>>>> did a make clean and make. Suddenly my org-drill sessions don't work.
>>>>
>>>> Did you restart emacs?
>>>
>>> Yes. I did just then and same thing.
>>
>> Do you get the error with org-drill only or do you get it in the instances
>> that Seb and Kenny Meyer report? If the former, it may be a bug with
>> org-drill. Otherwise, I throw up my hands: I certainly cannot reproduce it.
>
> FYI:
>
> - I don't use .elc files.
>
> - I've recently upgraded to Emacs 24.0.91.1 on Windows -- not sure if the
>   problem appeared directly after, or a little bit before.
>
> - I began suspecting work that I could have done in a branch, and mixed
>   versions that way -- as I'm not yet familiar with git and switching between
>   branches.
>
> - I've deleted all my Org directory, and cloned a fresh one
>
> But it still occurs.
>
> Though:
>
> - Requiring org-compat does cure the problem.
>
> - I see calls to org-compat in every crucial Org file -- I don't understand
>   where it could be missing.
>
> - I still must try to dissecate my .emacs, or use a minimal Emacs config file
>   to see if it's reproducible that way.

So, what was the problem in my case?  I've been trying to use the "starter
kit" approach, and have a "2-file" system:

- ~/.emacs

- ~/emacs/site-lisp/seb-conf.el (tangled from its .txt equivalent)
  which contains "add-to-load-path" calls for all packages (Org, Gnus, etc.)
  and all my customization.

In ~/.emacs, I've replaced my previous:

    (require 'seb-conf)

by

    (defun starter-kit-load ...)
    (defun starter-kit-compile ...)
    (starter-kit-load "emacs/site-lisp/seb-conf.txt")

Doing so, as it now calls `org-babel-load-file' (in `starter-kit-load'), and
as that function is autoloaded in Emacs 24, Emacs was loading the Org version
bundled with Emacs 24.0.91.1 -- that is, not the latest one, not the one in my
Git working copy.

This is very tricky to spot, IMHO, as all the checks done after Emacs has been
started up will give partially false answers:

    (locate-library "org-compat") shows my git version

as the load-path has been updated at the very beginning of loading `seb-conf'.

In summary:

- this is explained, and due to a mistake of mine;
- this is quite tricky to detect;
- this is a mix of different Org versions which causes the reported symptom.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Gustav Wikström]

[-- Attachment #1: Type: text/plain, Size: 4466 bytes --]

Just wanted to add a line here. I also encountered this problem when
upgrading to Emacs 24.0.92 on windows and started using ELPA to install the
newest release of Org.

Sebastiens comments were helpful in finding the reason for this. It seems
to relate to the fact that everything handled by ELPA doesn't load until
after the init file. Org (from ELPA) is auto-loaded first when called by
the user but the settings done in the init file still remains from the
default org-mode installation causing problems as this.

I solved it by adding the function (package-initialize) to my init file
before calling org to do things for me. I don't know if this has any bad
side-effects yet.. But please point at a better solution if one comes to
mind.

Regards
Gustav

On Wed, Dec 7, 2011 at 9:45 PM, Sebastien Vauban <wxhgmqzgwmuf@spammotel.com
> wrote:

> Hi all,
>
> "Sebastien Vauban" wrote:
> > Nick Dokos wrote:
> >> Shelagh Manton <shelagh.manton@gmail.com> wrote:
> >>> On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:
> >>>> Shelagh Manton <shelagh.manton@gmail.com> wrote:
> >>>>> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
> >>>>>> On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
> >>>>>>> In conditions which I consider unchanged (I speak of my emacs
> config
> >>>>>>> file), with the latest Org-mode version, I now have the message:
>
> There was the original mistake: conditions were changed!
>
> >>>>>>>   let*: Symbol's function definition is void:
> >>>>>>>   org-pop-to-buffer-same-window
> >>>>>>>
> >>>>>>> when doing, for example, `C-c C-x C-j' to jump on the currently
> >>>>>>> clocked item.
> >>>>>>>
> >>>>>>> Explicitly Loading `org-compat' does cure this problem... But we
> >>>>>>> must miss a `require' somewhere, but where?  In `org.el' itself?
> >>>>>
> >>>>> I've just been bitten by this as well. requiring org-compat manually
> did
> >>>>> nothing. My config files have not changed, just pulled latest
> org-mode,
> >>>>> did a make clean and make. Suddenly my org-drill sessions don't work.
> >>>>
> >>>> Did you restart emacs?
> >>>
> >>> Yes. I did just then and same thing.
> >>
> >> Do you get the error with org-drill only or do you get it in the
> instances
> >> that Seb and Kenny Meyer report? If the former, it may be a bug with
> >> org-drill. Otherwise, I throw up my hands: I certainly cannot reproduce
> it.
> >
> > FYI:
> >
> > - I don't use .elc files.
> >
> > - I've recently upgraded to Emacs 24.0.91.1 on Windows -- not sure if the
> >   problem appeared directly after, or a little bit before.
> >
> > - I began suspecting work that I could have done in a branch, and mixed
> >   versions that way -- as I'm not yet familiar with git and switching
> between
> >   branches.
> >
> > - I've deleted all my Org directory, and cloned a fresh one
> >
> > But it still occurs.
> >
> > Though:
> >
> > - Requiring org-compat does cure the problem.
> >
> > - I see calls to org-compat in every crucial Org file -- I don't
> understand
> >   where it could be missing.
> >
> > - I still must try to dissecate my .emacs, or use a minimal Emacs config
> file
> >   to see if it's reproducible that way.
>
> So, what was the problem in my case?  I've been trying to use the "starter
> kit" approach, and have a "2-file" system:
>
> - ~/.emacs
>
> - ~/emacs/site-lisp/seb-conf.el (tangled from its .txt equivalent)
>  which contains "add-to-load-path" calls for all packages (Org, Gnus, etc.)
>  and all my customization.
>
> In ~/.emacs, I've replaced my previous:
>
>    (require 'seb-conf)
>
> by
>
>    (defun starter-kit-load ...)
>    (defun starter-kit-compile ...)
>    (starter-kit-load "emacs/site-lisp/seb-conf.txt")
>
> Doing so, as it now calls `org-babel-load-file' (in `starter-kit-load'),
> and
> as that function is autoloaded in Emacs 24, Emacs was loading the Org
> version
> bundled with Emacs 24.0.91.1 -- that is, not the latest one, not the one
> in my
> Git working copy.
>
> This is very tricky to spot, IMHO, as all the checks done after Emacs has
> been
> started up will give partially false answers:
>
>    (locate-library "org-compat") shows my git version
>
> as the load-path has been updated at the very beginning of loading
> `seb-conf'.
>
> In summary:
>
> - this is explained, and due to a mistake of mine;
> - this is quite tricky to detect;
> - this is a mix of different Org versions which causes the reported
> symptom.
>
> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>

[-- Attachment #2: Type: text/html, Size: 5947 bytes --]

[OT] Current website not very attractive

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

Hey list,

Don't want to be negative, but doesn't anyone else also think the current
design is kind of amateurish and not very attractive? I also did not like
the screenshot used, I preferred the previous one, it showed more org
capabilities, and the colors and indentation looked better.

My two cents and food for thought,

- Marcelo.

[-- Attachment #2: Type: text/html, Size: 435 bytes --]

Re: [OT] Current website not very attractive

[Jude DaShiell]

Good, that probably means it's one of the more accessible and usable web 
sites on the internet.

On Thu, 9 Aug 2012, Marcelo de Moraes Serpa wrote:

> Hey list,
> 
> Don't want to be negative, but doesn't anyone else also think the current
> design is kind of amateurish and not very attractive? I also did not like
> the screenshot used, I preferred the previous one, it showed more org
> capabilities, and the colors and indentation looked better.
> 
> My two cents and food for thought,
> 
> - Marcelo.
> 

Support
your local
church or
synagogue,
worship at
Bank Of
America!
----------------------------------------------------------------

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

Re: [OT] Current website not very attractive

[Sankalp]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

I'm inclined to agree with Marcelo.
--
Sankalp

*******************************************************
If humans could mate with software, I'd have org-mode's
babies.
                          --- Chris League on Twitter.
               http://orgmode.org/worg/org-quotes.html
*******************************************************


On 10 August 2012 04:44, Jude DaShiell <jdashiel@shellworld.net> wrote:

> Good, that probably means it's one of the more accessible and usable web
> sites on the internet.
>
> On Thu, 9 Aug 2012, Marcelo de Moraes Serpa wrote:
>
> > Hey list,
> >
> > Don't want to be negative, but doesn't anyone else also think the current
> > design is kind of amateurish and not very attractive? I also did not like
> > the screenshot used, I preferred the previous one, it showed more org
> > capabilities, and the colors and indentation looked better.
> >
> > My two cents and food for thought,
> >
> > - Marcelo.
> >
>
> Support
> your local
> church or
> synagogue,
> worship at
> Bank Of
> America!
> ----------------------------------------------------------------
>
> Jude <jdashiel-at-shellworld-dot-net>
> <http://www.shellworld.net/~jdashiel/nj.html>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2076 bytes --]

Re: [OT] Current website not very attractive

[Ista Zahn]

I love the orgmode website. If you want to see amateurish and not
attractive, take a look at http://www.r-project.org/ (I love R too,
but the website could use an update)

-Ista

On Thu, Aug 9, 2012 at 5:45 PM, Marcelo de Moraes Serpa
<celoserpa@gmail.com> wrote:
> Hey list,
>
> Don't want to be negative, but doesn't anyone else also think the current
> design is kind of amateurish and not very attractive? I also did not like
> the screenshot used, I preferred the previous one, it showed more org
> capabilities, and the colors and indentation looked better.
>
> My two cents and food for thought,
>
> - Marcelo.
>

Re: [OT] Current website not very attractive

[Nick Dokos]

Sankalp <sankalpkhare@gmail.com> wrote:

> --f46d044401de1e3ad604c6de28a7
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I'm inclined to agree with Marcelo.
> --
> Sankalp
> 
> *******************************************************
> If humans could mate with software, I'd have org-mode's
> babies.
>                           --- Chris League on Twitter.
>                http://orgmode.org/worg/org-quotes.html
> *******************************************************
> 
> 
> On 10 August 2012 04:44, Jude DaShiell <jdashiel@shellworld.net> wrote:
> 
> > Good, that probably means it's one of the more accessible and usable web
> > sites on the internet.
> >
> > On Thu, 9 Aug 2012, Marcelo de Moraes Serpa wrote:
> >
> > > Hey list,
> > >
> > > Don't want to be negative, but doesn't anyone else also think the current
> > > design is kind of amateurish and not very attractive? I also did not like
> > > the screenshot used, I preferred the previous one, it showed more org
> > > capabilities, and the colors and indentation looked better.
> > >
> > > My two cents and food for thought,
> > >

Talk is cheap: how would you improve it? And I don't mean generalities: build
a website as you think it should be and then invite us over to take a look.
And  as Jude suggests, don't forget to keep accessibility/usability issues
in mind as you design.

Nick

Re: [OT] Current website not very attractive

[Jambunathan K]

> how would you improve it? 

I will probably make Worg Wikipedia-like 
  1. Quick navigation to one side.
  2. TOC on top and bounded.
  3. A header bar, maybe.
  4. A bigger font.

One can start with pedia.css provided by Emacswiki.  

I have followed this trail - Org as a Wiki and a personal information
portal - a bit for last few weeks.

If Wiki-like style is not agreeable one can go with a style like this:
http://mah.everybody.org/books/.  There is some simple understated
elegance to that page that is quite appealing.  It is the presence of
margins on either side that makes the page look solemn and respectable.
-- 

Re: [OT] Current website not very attractive

[Nick Dokos]

Nick Dokos <nicholas.dokos@hp.com> wrote:

> Sankalp <sankalpkhare@gmail.com> wrote:
> 
> > --f46d044401de1e3ad604c6de28a7
> > Content-Type: text/plain; charset=ISO-8859-1
> > 
> > I'm inclined to agree with Marcelo.
> > --
> > Sankalp
> > 
> > *******************************************************
> > If humans could mate with software, I'd have org-mode's
> > babies.
> >                           --- Chris League on Twitter.
> >                http://orgmode.org/worg/org-quotes.html
> > *******************************************************
> > 
> > 
> > On 10 August 2012 04:44, Jude DaShiell <jdashiel@shellworld.net> wrote:
> > 
> > > Good, that probably means it's one of the more accessible and usable web
> > > sites on the internet.
> > >
> > > On Thu, 9 Aug 2012, Marcelo de Moraes Serpa wrote:
> > >
> > > > Hey list,
> > > >
> > > > Don't want to be negative, but doesn't anyone else also think the current
> > > > design is kind of amateurish and not very attractive? I also did not like
> > > > the screenshot used, I preferred the previous one, it showed more org
> > > > capabilities, and the colors and indentation looked better.
> > > >
> > > > My two cents and food for thought,
> > > >
> 
> Talk is cheap: how would you improve it? And I don't mean generalities: build
> a website as you think it should be and then invite us over to take a look.
> And  as Jude suggests, don't forget to keep accessibility/usability issues
> in mind as you design.
> 
> Nick
> 

It has been pointed out to me that my comments might be taken as
"overbearing".  Not my intent, but I will take back the "talk is
cheap" part (or repeat it to myself as the target this time) and
apologize for it: I should have reread the mail before hitting send.

But the larger point is still there: "I don't like it" is a legitimate
response, but is not nearly as helpful as giving a list of reasons
of *why* you don't like it. And providing something you *like* is even
better. E.g. would the current design with the previous screen shot be
OK? Or are there deeper problems?

Nick

[Contest] Redesign orgmode.org by the end of august (was: [OT] Current website not very attractive)

[Bastien]

Hi all,

Yes, we can improve the website.

I suggest we organize a contest and vote for the design we want.

Here are the rules:

- The "new design" refers both to http://orgmode.org/ and to
  http://orgmode.org/worg/.

- The new design will be applicable as a set of patches against the
  current git repository.  If you don't know how to use git, please
  ask a friend.  You can clone the repo like this:

  ~$ git clone git://orgmode.org/worg.git

- Participants will host a demo of their proposal online.

- Participants will send their demo by August, 25th, midnight.

- People will then vote on the Org mailing list for the best demo.

- Only one demo per participant can be part of the vote.

- Only one vote per subscriber of the mailing list.

- The current design will be among the ones we can vote for.

- The vote will happen between August, 26th and 31st.

- If two or more designs are top-voted with the same number of votes, 
  I will choose one.

Let the dice roll,

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august (was: [OT] Current website not very attractive)

[John Hendy]

On Fri, Aug 10, 2012 at 2:05 AM, Bastien <bzg@gnu.org> wrote:
> Hi all,
>
> Yes, we can improve the website.
>
> I suggest we organize a contest and vote for the design we want.

I love this. No bike shedding. Build your own, paint it, and let the
votes speak for themselves :)

John

Re: [Contest] Redesign orgmode.org by the end of august

[Rémi Letot]

Bastien <bzg@gnu.org> writes:

> Hi all,
>
> Yes, we can improve the website.
>
> I suggest we organize a contest and vote for the design we want.

good idea, but maybe postpone the dates by one month so that people can
get back from hollidays ?

HTH,
-- 
Rémi

Re: [OT] Current website not very attractive

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

Hey guys,

Didn't mean to start any kind of flame.

@Nick: I'm not a designer, more of a hybrid coder with some design
foundations, but I'm definitely willing to help. I don't like the current
layout because of it's overuse of shadows and its "web1"-style layout.
Also, typography could use some improvement, and we could also use a better
screenshot, to give a better first impression.

- Marcelo.

On Fri, Aug 10, 2012 at 1:30 AM, Nick Dokos <nicholas.dokos@hp.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> wrote:
>
> > Sankalp <sankalpkhare@gmail.com> wrote:
> >
> > > --f46d044401de1e3ad604c6de28a7
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > I'm inclined to agree with Marcelo.
> > > --
> > > Sankalp
> > >
> > > *******************************************************
> > > If humans could mate with software, I'd have org-mode's
> > > babies.
> > >                           --- Chris League on Twitter.
> > >                http://orgmode.org/worg/org-quotes.html
> > > *******************************************************
> > >
> > >
> > > On 10 August 2012 04:44, Jude DaShiell <jdashiel@shellworld.net>
> wrote:
> > >
> > > > Good, that probably means it's one of the more accessible and usable
> web
> > > > sites on the internet.
> > > >
> > > > On Thu, 9 Aug 2012, Marcelo de Moraes Serpa wrote:
> > > >
> > > > > Hey list,
> > > > >
> > > > > Don't want to be negative, but doesn't anyone else also think the
> current
> > > > > design is kind of amateurish and not very attractive? I also did
> not like
> > > > > the screenshot used, I preferred the previous one, it showed more
> org
> > > > > capabilities, and the colors and indentation looked better.
> > > > >
> > > > > My two cents and food for thought,
> > > > >
> >
> > Talk is cheap: how would you improve it? And I don't mean generalities:
> build
> > a website as you think it should be and then invite us over to take a
> look.
> > And  as Jude suggests, don't forget to keep accessibility/usability
> issues
> > in mind as you design.
> >
> > Nick
> >
>
> It has been pointed out to me that my comments might be taken as
> "overbearing".  Not my intent, but I will take back the "talk is
> cheap" part (or repeat it to myself as the target this time) and
> apologize for it: I should have reread the mail before hitting send.
>
> But the larger point is still there: "I don't like it" is a legitimate
> response, but is not nearly as helpful as giving a list of reasons
> of *why* you don't like it. And providing something you *like* is even
> better. E.g. would the current design with the previous screen shot be
> OK? Or are there deeper problems?
>
> Nick
>
>

[-- Attachment #2: Type: text/html, Size: 3873 bytes --]

Re: [Contest] Redesign orgmode.org by the end of august

[Thomas S. Dye]

John Hendy <jw.hendy@gmail.com> writes:

> On Fri, Aug 10, 2012 at 2:05 AM, Bastien <bzg@gnu.org> wrote:
>> Hi all,
>>
>> Yes, we can improve the website.
>>
>> I suggest we organize a contest and vote for the design we want.
>
> I love this. No bike shedding. Build your own, paint it, and let the
> votes speak for themselves :)
>
> John
>
>

Me too.  Could the "losers" end up on Worg, too?  I've often felt the
need for a good CSS tailored to Org mode and it would be sweet to have
more choices.

Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [OT] Current website not very attractive

[Nick Dokos]

Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote:

> Hey guys,
> 
> Didn't mean to start any kind of flame.
> 

You did not. I didn't mean to either but my comment could be taken as
inflammatory, hence my apology.

> @Nick: I'm not a designer, more of a hybrid coder with some design
> foundations, but I'm definitely willing to help. I don't like the
> current layout because of it's overuse of shadows and its "web1"-style
> layout. Also, typography could use some improvement, and we could also
> use a better screenshot, to give a better first impression. 

Neither am I: I generally am happy when I can get to the information I
need - I don't care how the page looks but I realize I'm very much in
the minority here. FWIW, I'm happy with the website as it is.

Perhaps a useful distinction is between content and appearance (the
latter to be taken care of by CSS mostly). The shadows and typography
are appearance only - the screenshot is more content-like (and btw,
there are multiple screenshots so you can reload the page and get
another view of org's capabilities - there is no visible indication of
that however). 

Another goal should be ease of maintenance of the website: I'm sure
neither Bastien nor Jason have infinite time to tweak things.

Nick

Re: [Contest] Redesign orgmode.org by the end of august

[Suvayu Ali]

On Fri, Aug 10, 2012 at 06:43:18AM -1000, Thomas S. Dye wrote:
> 
> Me too.  Could the "losers" end up on Worg, too?  I've often felt the
> need for a good CSS tailored to Org mode and it would be sweet to have
> more choices.
> 

Well said Tom.  The "losers" would a great addition for Worg.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [OT] Current website not very attractive

[brian powell]

[-- Attachment #1: Type: text/plain, Size: 3704 bytes --]

* The site looks great as it is.

** Its supposed to be simple and simple-looking:

*** Go to: http://orgmode.org =>

Read the top line: "Org: Your Life in Plain Text"

*** Go to: http://doc.norang.ca/org-mode.html =>

Read the top line: "Org Mode - Organize Your Life In Plain Text!"

* Simplicity and portability is a huge part of the point of OrgMode right!?

* EMACS and TeX and Texinfo, etc. are great (partially) because they have
been ported to all platforms.

** So, if you make any changes, you should be able to convert the end
webpages to Texinfo
so they are readable and printable on all computers and printers.

--I just hope that whoever "wins the contest" creates web pages that are
"501 compliant" and everyone can read on any computer using any operating
system and browser and those webpages are as printable as a Texinfo
document.



On Fri, Aug 10, 2012 at 12:43 PM, Marcelo de Moraes Serpa <
celoserpa@gmail.com> wrote:

> Hey guys,
>
> Didn't mean to start any kind of flame.
>
> @Nick: I'm not a designer, more of a hybrid coder with some design
> foundations, but I'm definitely willing to help. I don't like the current
> layout because of it's overuse of shadows and its "web1"-style layout.
> Also, typography could use some improvement, and we could also use a better
> screenshot, to give a better first impression.
>
> - Marcelo.
>
> On Fri, Aug 10, 2012 at 1:30 AM, Nick Dokos <nicholas.dokos@hp.com> wrote:
>
>> Nick Dokos <nicholas.dokos@hp.com> wrote:
>>
>> > Sankalp <sankalpkhare@gmail.com> wrote:
>> >
>> > > --f46d044401de1e3ad604c6de28a7
>> > > Content-Type: text/plain; charset=ISO-8859-1
>> > >
>> > > I'm inclined to agree with Marcelo.
>> > > --
>> > > Sankalp
>> > >
>> > > *******************************************************
>> > > If humans could mate with software, I'd have org-mode's
>> > > babies.
>> > >                           --- Chris League on Twitter.
>> > >                http://orgmode.org/worg/org-quotes.html
>> > > *******************************************************
>> > >
>> > >
>> > > On 10 August 2012 04:44, Jude DaShiell <jdashiel@shellworld.net>
>> wrote:
>> > >
>> > > > Good, that probably means it's one of the more accessible and
>> usable web
>> > > > sites on the internet.
>> > > >
>> > > > On Thu, 9 Aug 2012, Marcelo de Moraes Serpa wrote:
>> > > >
>> > > > > Hey list,
>> > > > >
>> > > > > Don't want to be negative, but doesn't anyone else also think the
>> current
>> > > > > design is kind of amateurish and not very attractive? I also did
>> not like
>> > > > > the screenshot used, I preferred the previous one, it showed more
>> org
>> > > > > capabilities, and the colors and indentation looked better.
>> > > > >
>> > > > > My two cents and food for thought,
>> > > > >
>> >
>> > Talk is cheap: how would you improve it? And I don't mean generalities:
>> build
>> > a website as you think it should be and then invite us over to take a
>> look.
>> > And  as Jude suggests, don't forget to keep accessibility/usability
>> issues
>> > in mind as you design.
>> >
>> > Nick
>> >
>>
>> It has been pointed out to me that my comments might be taken as
>> "overbearing".  Not my intent, but I will take back the "talk is
>> cheap" part (or repeat it to myself as the target this time) and
>> apologize for it: I should have reread the mail before hitting send.
>>
>> But the larger point is still there: "I don't like it" is a legitimate
>> response, but is not nearly as helpful as giving a list of reasons
>> of *why* you don't like it. And providing something you *like* is even
>> better. E.g. would the current design with the previous screen shot be
>> OK? Or are there deeper problems?
>>
>> Nick
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5462 bytes --]

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Hi Rémi Letot,

hobbes@poukram.net (Rémi Letot) writes:

> Bastien <bzg@gnu.org> writes:
>
>> Hi all,
>>
>> Yes, we can improve the website.
>>
>> I suggest we organize a contest and vote for the design we want.
>
> good idea, but maybe postpone the dates by one month so that people can
> get back from hollidays ?

I prefer not to.

Vacations are either a bad time or a good time for coding -- depends on
everyone's vacations and day work, I guess.

But running a contest for the next design does not mean that this design
will last forever.  If a better one comes up after the contest, we can
always switch to it.

-- 
 Bastien

Re: [OT] Current website not very attractive

[Bastien]

Hi Marcelo,

Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:

> @Nick: I'm not a designer, more of a hybrid coder with some design
> foundations, but I'm definitely willing to help. I don't like the
> current layout because of it's overuse of shadows and its
> "web1"-style layout. Also, typography could use some improvement, and
> we could also use a better screenshot, to give a better first
> impression. 

If you have good ideas but no HTML/css skills, maybe you can find a
HTML/css who has no good ideas and work with him for the contest.

Best,

-- 
 Bastien

Re: [OT] Current website not very attractive

[Bastien]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Another goal should be ease of maintenance of the website: I'm sure
> neither Bastien nor Jason have infinite time to tweak things.

I confirm I don't have infinite time, but I do have ~infinite patience
for this kind of stuff.

-- 
 Bastien

Re: [OT] Current website not very attractive

[Bastien]

brian powell <briangpowellms@gmail.com> writes:

> --I just hope that whoever "wins the contest" creates web pages that
> are "501 compliant" and everyone can read on any computer using any
> operating system and browser and those webpages are as printable as a
> Texinfo document.

Even better: as the website is based on .org files, and as a new TeXinfo
exporter will soon be in contrib/lisp/, you will be able to export each
page of the website into a TeXinfo document.

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Hi Tom,

tsd@tsdye.com (Thomas S. Dye) writes:

> Could the "losers" end up on Worg, too?  I've often felt the
> need for a good CSS tailored to Org mode and it would be sweet to have
> more choices.

Quoting the "rules":

- The "new design" refers both to http://orgmode.org/ and to
  http://orgmode.org/worg/.

So the plan is to refresh both the main website and Worg.

Of course, if there are several very good designs beside the 
one we pick up, we can use them as alternative css, either on
orgmode.org or on orgmode.org/worg/

Best,

-- 
 Bastien

[ANN] Letter modes in the Groff exporter

[Luis Anaya]

Hi:

This is probably the last major feature to be implemented in the Groff
exporter. 

This is to announce that support for the letter building
macros (WA/WE/IA/IE/LO and LT) are now available in the Groff
exporter. This feature allows you to write business communications in
standard format which are provided by the means of new document classes,
namely: block, semiblock, full block, and simplified. It also
allows the use of cover sheets to build custom letter heads. 

Org will present a consistent mechanism for letter writing regardless of
the underlying macro calls. The objective during development was to hide 
as much as possible much of the implementation nuances in Groff. 

Samples are available at: 

https://www.box.com/s/578d9a22c890ddcea8bd

(I am using box instead of the pogoplug share because it was more convenient
to upload the files... call me lazy. :P )

Luis


-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: [ANN] Letter modes in the Groff exporter

[Suvayu Ali]

Hi Luis,

On Sat, Aug 11, 2012 at 06:46:05AM -0400, Luis Anaya wrote:
> Hi:
> 
> This is probably the last major feature to be implemented in the Groff
> exporter. 
> 
> This is to announce that support for the letter building
> macros (WA/WE/IA/IE/LO and LT) are now available in the Groff
> exporter. This feature allows you to write business communications in
> standard format which are provided by the means of new document classes,
> namely: block, semiblock, full block, and simplified. It also
> allows the use of cover sheets to build custom letter heads. 
> 
> Org will present a consistent mechanism for letter writing regardless of
> the underlying macro calls. The objective during development was to hide 
> as much as possible much of the implementation nuances in Groff. 
> 
> Samples are available at: 
> 
> https://www.box.com/s/578d9a22c890ddcea8bd
> 

This looks absolutely fantastic!  I had a quick look through the Worg
documentation, but I could not find any of the beautiful examples you
have posted on the list over the last few months.  It might be a nice
idea to include the those example files and the output pdfs on Worg as a
showcase (this could be a headline in the doc page).

I believe the policy is, binary files go in Worg/images and the source
files can be anywhere in the directory tree where it is contextually
relevant; in this case it could be a org-e-groff-examples subdirectory
in Worg/org-tutorials.

Thanks for the great work; I'm pretty sure I'll be using the letter
export a lot.  :)

> 
> Luis
> 

-- 
Suvayu

Open source is the future. It sets us free.

Re: [ANN] Letter modes in the Groff exporter

[Luis Anaya]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

>
> This looks absolutely fantastic!  I had a quick look through the Worg
> documentation, but I could not find any of the beautiful examples you
[chomp]

I can load them there, there are still in the Pogo Cloud thinguie. It
just did not occurred to me to do it.

> Thanks for the great work; I'm pretty sure I'll be using the letter
> export a lot.  :)

I hope that they'll be of use to you. :) I have honestly thought that I was
going to be the only person using any of this. 

Luis

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: [ANN] Letter modes in the Groff exporter

[Bastien]

Hi Luis,

thanks for all the hard work!  I'm quite excited to test all this
thoroughly (and to see your latest commits pushed to org-mode.git).

Luis Anaya <papoanaya@hotmail.com> writes:

>> This looks absolutely fantastic!  I had a quick look through the Worg
>> documentation, but I could not find any of the beautiful examples you
> [chomp]
>
> I can load them there, there are still in the Pogo Cloud thinguie. It
> just did not occurred to me to do it.

In general, it's better to images and pdfs stored on your own server, 
then to create a link to orgmode.org.  

>> Thanks for the great work; I'm pretty sure I'll be using the letter
>> export a lot.  :)
>
> I hope that they'll be of use to you. :) I have honestly thought that I was
> going to be the only person using any of this. 

There is a particular look'n feel in those Groff PDFs, I love it.

Best,

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Thomas S. Dye]

Hi Bastien,

Bastien <bzg@gnu.org> writes:

> Hi Tom,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> Could the "losers" end up on Worg, too?  I've often felt the
>> need for a good CSS tailored to Org mode and it would be sweet to have
>> more choices.
>
> Quoting the "rules":
>
> - The "new design" refers both to http://orgmode.org/ and to
>   http://orgmode.org/worg/.
>
> So the plan is to refresh both the main website and Worg.
>
> Of course, if there are several very good designs beside the 
> one we pick up, we can use them as alternative css, either on
> orgmode.org or on orgmode.org/worg/
>
> Best,

I'm hoping for a repository of Org mode aware CSS "designs," regardless of
what ends up powering orgmode.org and worg.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

tsd@tsdye.com (Thomas S. Dye) writes:

> I'm hoping for a repository of Org mode aware CSS "designs," regardless of
> what ends up powering orgmode.org and worg.

Good idea!  Hopefully there will be at least one or two new CSS via the
contest...  crossing fingers.

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Bastien <bzg@gnu.org> writes:

> Yes, we can improve the website.
>
> - Participants will send their demo by August, 25th, midnight.

I received approximately ~0 redesign proposal(s).

I also feel like the website needs to be revamped,
but I don't have that much time for this right now.

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Bastien <bzg@gnu.org> writes:
> 
> > Yes, we can improve the website.
> >
> > - Participants will send their demo by August, 25th, midnight.
> 
> I received approximately ~0 redesign proposal(s).
> 
> I also feel like the website needs to be revamped,
> but I don't have that much time for this right now.
> 

IIRC, Jambunathan posted some concrete suggestions for improvements in
this thread. When you (or somebody) get some time to redesign, those
suggestions can be revisited.

Nick

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Hi all,

Bastien <bzg@gnu.org> writes:

> Yes, we can improve the website.

I gave a shot at this.

Check the new website here: http://orgmode.org

I'm afraid it still looks amateurish but I tried to make it sober and
informative.

I introduced a "features" page with highlights on some important
features:

  http://localhost/org-mode/features.html

If you miss something from the previous website, please let me know.

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Bastien <bzg@altern.org> writes:

> I gave a shot at this.

If your browser reports a 404 error, please empty your 
cache before reloading.

Also, I could not do this refresh without removing the
translations -- so this english-only for now.  

But the new website should be easier to translate, less
useless talk.

If you want to help:

  ~$ git clone git://orgmode.org/orgweb.git

then send me a patch against master, using e.g. /fr/ as a 
new directory for the french translation.

Thanks!

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Giovanni Ridolfi]

Da: Bastien <bzg@altern.org>
Inviato: Lunedì 10 Settembre 2012 13:00

>   http://localhost/org-mode/features.html

http://orgmode.org/features.html

chers,
Giovanni

Re: [Contest] Redesign orgmode.org by the end of august

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi all,
> 
> Bastien <bzg@gnu.org> writes:
> 
> > Yes, we can improve the website.
> 
> I gave a shot at this.
> 
> Check the new website here: http://orgmode.org
> 

I get 404s on every navigation link except Home and More.

> I'm afraid it still looks amateurish but I tried to make it sober and
> informative.
> 
> I introduced a "features" page with highlights on some important
> features:
> 
>   http://localhost/org-mode/features.html
> 

Ahem :-) And even after changing localhost to orgmode.org, I get a 404
here too.

Nick

Re: [Contest] Redesign orgmode.org by the end of august

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Bastien <bzg@altern.org> writes:
> 
> > I gave a shot at this.
> 
> If your browser reports a 404 error, please empty your 
> cache before reloading.
> 

D'oh - OK.

Nick

> Also, I could not do this refresh without removing the
> translations -- so this english-only for now.  
> 
> But the new website should be easier to translate, less
> useless talk.
> 
> If you want to help:
> 
>   ~$ git clone git://orgmode.org/orgweb.git
> 
> then send me a patch against master, using e.g. /fr/ as a 
> new directory for the french translation.
> 
> Thanks!
> 
> -- 
>  Bastien
> 

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> I get 404s on every navigation link except Home and More.

You most probably need to empty your cache.

Going directly to this link should do:

http://orgmode.org/index.html

HTH,

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Takaaki ISHIKAWA]

Hi Bastien,

I copied index.org into ./ja directory with Japanese translation (not completed yet).
The translation will be finished until this week end.

I made a branch "ja" in the orgweb repository for translation work.
If this is not good for you and all, please let me know.

By the way, do you have any solution to check the translated result in a browser (through HTTP)?
HTML export from org files is a solution, but I'm not sure the layout and visual quality is correct.
And also internal links between pages should be checked before pushing them into orgweb repository.


Best,
Takaaki Ishikawa

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Hi Takaaki,

Takaaki ISHIKAWA <takaxp@ieee.org> writes:

> I copied index.org into ./ja directory with Japanese translation (not completed yet).
> The translation will be finished until this week end.

Great -- I added links to the translated versions of the website in the
top left corner (under the logo).

> I made a branch "ja" in the orgweb repository for translation work.
> If this is not good for you and all, please let me know.

It's perfectly fine, but public branches are more when several people
are likely to work on it.  Now you can make your changes directly on 
master, they will be published immediately.

> By the way, do you have any solution to check the translated result in a browser (through HTTP)?
> HTML export from org files is a solution, but I'm not sure the layout and visual quality is correct.
> And also internal links between pages should be checked before pushing them into orgweb repository.

Please have a look at the french translation for the internal links.

Otherwise, I don't think there is a quick way for this -- just be 
bold and go ahead, we can fix things later on.

Thanks for your work on this!

-- 
 Bastien

Re: [OT] Current website not very attractive

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

Bastien et al,

Congrats on the new site! I really liked the minimalist concept, the colors
and the typography! It's much cleaner and much more attractive :)

- Marcelo.

On Sat, Aug 11, 2012 at 4:30 AM, Bastien <bzg@gnu.org> wrote:

> brian powell <briangpowellms@gmail.com> writes:
>
> > --I just hope that whoever "wins the contest" creates web pages that
> > are "501 compliant" and everyone can read on any computer using any
> > operating system and browser and those webpages are as printable as a
> > Texinfo document.
>
> Even better: as the website is based on .org files, and as a new TeXinfo
> exporter will soon be in contrib/lisp/, you will be able to export each
> page of the website into a TeXinfo document.
>
> --
>  Bastien
>

[-- Attachment #2: Type: text/html, Size: 1238 bytes --]

Re: [OT] Current website not very attractive

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

I think the new design is more appealing to not-very-technical-people like
graphic designers and other "knowledge-workers" that might not be
coding-savvy, by the way.

On Thu, Sep 13, 2012 at 3:19 PM, Marcelo de Moraes Serpa <
celoserpa@gmail.com> wrote:

> Bastien et al,
>
> Congrats on the new site! I really liked the minimalist concept, the
> colors and the typography! It's much cleaner and much more attractive :)
>
> - Marcelo.
>
> On Sat, Aug 11, 2012 at 4:30 AM, Bastien <bzg@gnu.org> wrote:
>
>> brian powell <briangpowellms@gmail.com> writes:
>>
>> > --I just hope that whoever "wins the contest" creates web pages that
>> > are "501 compliant" and everyone can read on any computer using any
>> > operating system and browser and those webpages are as printable as a
>> > Texinfo document.
>>
>> Even better: as the website is based on .org files, and as a new TeXinfo
>> exporter will soon be in contrib/lisp/, you will be able to export each
>> page of the website into a TeXinfo document.
>>
>> --
>>  Bastien
>>
>
>

[-- Attachment #2: Type: text/html, Size: 1858 bytes --]

Re: [OT] Current website not very attractive

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

I can help with the Spanish and Portuguese versions, by the way.

On Thu, Sep 13, 2012 at 3:21 PM, Marcelo de Moraes Serpa <
celoserpa@gmail.com> wrote:

> I think the new design is more appealing to not-very-technical-people like
> graphic designers and other "knowledge-workers" that might not be
> coding-savvy, by the way.
>
> On Thu, Sep 13, 2012 at 3:19 PM, Marcelo de Moraes Serpa <
> celoserpa@gmail.com> wrote:
>
>> Bastien et al,
>>
>> Congrats on the new site! I really liked the minimalist concept, the
>> colors and the typography! It's much cleaner and much more attractive :)
>>
>> - Marcelo.
>>
>> On Sat, Aug 11, 2012 at 4:30 AM, Bastien <bzg@gnu.org> wrote:
>>
>>> brian powell <briangpowellms@gmail.com> writes:
>>>
>>> > --I just hope that whoever "wins the contest" creates web pages that
>>> > are "501 compliant" and everyone can read on any computer using any
>>> > operating system and browser and those webpages are as printable as a
>>> > Texinfo document.
>>>
>>> Even better: as the website is based on .org files, and as a new TeXinfo
>>> exporter will soon be in contrib/lisp/, you will be able to export each
>>> page of the website into a TeXinfo document.
>>>
>>> --
>>>  Bastien
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2274 bytes --]

Re: [OT] Current website not very attractive

[Bastien]

Hi Marcelo,

glad you like the new website!  It's important to keep Org open
to non-developers, it is good if the website somehow advertizes
this attitude.

Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:

> I can help with the Spanish and Portuguese versions, by the way.

Great!  

~$ git clone git://orgmode.org/orgweb.git
~$ cd orgweb/
~$ git branch orgweb-es
~$ mkdir es/
~$ cp *org es/

[translate the es/*org files]

~$ git commit -m "Yeah! "es" translation done!"
~$ git format-patch master

... then send me the patch(es).

Should be one-hour max of work.

Thanks in advance :)

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Brian van den Broek]

On 10 September 2012 07:00, Bastien <bzg@altern.org> wrote:
> Hi all,
>
> Bastien <bzg@gnu.org> writes:
>
>> Yes, we can improve the website.
>
> I gave a shot at this.
>
> Check the new website here: http://orgmode.org

<snip>

> If you miss something from the previous website, please let me know.

Hi Bastien,

I went looking for the full manual on a single HTML page today, and I
could not find it. I'd understand if this was left out on purpose out
of concern for bandwidth, but if it was just an oversight, it'd be
lovely if it could be restored.

Thanks and best,

Brian vdB

Re: [Contest] Redesign orgmode.org by the end of august

[Bastien]

Hi Brian,

Brian van den Broek <brian.van.den.broek@gmail.com> writes:

> I went looking for the full manual on a single HTML page today, and I
> could not find it. 

It did not move: http://orgmode.org/org.html

> I'd understand if this was left out on purpose out
> of concern for bandwidth, but if it was just an oversight, it'd be
> lovely if it could be restored.

It's advertized in this section:

  http://orgmode.org/#docs

HTH,

-- 
 Bastien

Re: [Contest] Redesign orgmode.org by the end of august

[Brian van den Broek]

On 21 September 2012 03:24, Bastien <bzg@altern.org> wrote:
> Hi Brian,
>
> Brian van den Broek <brian.van.den.broek@gmail.com> writes:
>
>> I went looking for the full manual on a single HTML page today, and I
>> could not find it.

<snip>

> It's advertized in this section:
>
>   http://orgmode.org/#docs

And so it unambiguously is. I coulda sworn ....

I knew I wasn't getting enough sleep these days, but I guess the
problem is worse than I thought. Sorry for the noise.

Best,

Brian vdB

Re: [OT] Current website not very attractive

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

Bastien,

I can't clone the orgweb repo:

git clone git://orgmode.org/orgweb.git
Cloning into 'orgweb'...
fatal: The remote end hung up unexpectedly

Is the server is down?

- Marcelo.

On Fri, Sep 14, 2012 at 12:41 AM, Bastien <bzg@altern.org> wrote:

> Hi Marcelo,
>
> glad you like the new website!  It's important to keep Org open
> to non-developers, it is good if the website somehow advertizes
> this attitude.
>
> Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
>
> > I can help with the Spanish and Portuguese versions, by the way.
>
> Great!
>
> ~$ git clone git://orgmode.org/orgweb.git
> ~$ cd orgweb/
> ~$ git branch orgweb-es
> ~$ mkdir es/
> ~$ cp *org es/
>
> [translate the es/*org files]
>
> ~$ git commit -m "Yeah! "es" translation done!"
> ~$ git format-patch master
>
> ... then send me the patch(es).
>
> Should be one-hour max of work.
>
> Thanks in advance :)
>
> --
>  Bastien
>

[-- Attachment #2: Type: text/html, Size: 1649 bytes --]

Re: [OT] Current website not very attractive

[Nick Dokos]

Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote:

> Bastien,
> 
> I can't clone the orgweb repo:
> 
> git clone git://orgmode.org/orgweb.git
> Cloning into 'orgweb'...
> fatal: The remote end hung up unexpectedly
> 
> Is the server is down?
> 

I can't get to it either, but I am behind a firewall and have had
problems with the socks proxy I usually use. After I switched proxies,
I *was* able to do a git pull on the emacs repository though, so I
suspect the fault is at orgmode.org's end.

Nick

> - Marcelo.
> 
> On Fri, Sep 14, 2012 at 12:41 AM, Bastien <bzg@altern.org> wrote:
> 
>     Hi Marcelo,
>    
>     glad you like the new website!  It's important to keep Org open
>     to non-developers, it is good if the website somehow advertizes
>     this attitude.
>    
>     Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
>    
>     > I can help with the Spanish and Portuguese versions, by the way.
>    
>     Great!
>    
>     ~$ git clone git://orgmode.org/orgweb.git
>     ~$ cd orgweb/
>     ~$ git branch orgweb-es
>     ~$ mkdir es/
>     ~$ cp *org es/
>    
>     [translate the es/*org files]
>    
>     ~$ git commit -m "Yeah! "es" translation done!"
>     ~$ git format-patch master
>    
>     ... then send me the patch(es).
>    
>     Should be one-hour max of work.
>    
>     Thanks in advance :)
>    
>     --
>      Bastien
> 
> 
> ----------------------------------------------------
> Alternatives:
> 
> ----------------------------------------------------

Re: [OT] Current website not very attractive

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote:
>
>> Bastien,
>> 
>> I can't clone the orgweb repo:
>> 
>> git clone git://orgmode.org/orgweb.git
>> Cloning into 'orgweb'...
>> fatal: The remote end hung up unexpectedly
>> 
>> Is the server is down?
>> 
>
> I can't get to it either, but I am behind a firewall and have had
> problems with the socks proxy I usually use. After I switched proxies,
> I *was* able to do a git pull on the emacs repository though, so I
> suspect the fault is at orgmode.org's end.
>


orgmode.org was recently moved to a new machine, so you will have to
update any tools which check MAC addresses for things like man in the
middle attacks.  I did have to update my ~/.ssh/known_hosts this morning
to remove the old key.

I've since been using the git repo on the orgmode server without
problem.

Hope this helps,

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

Re: [OT] Current website not very attractive

[Nick Dokos]

Eric Schulte <eric.schulte@gmx.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote:
> >
> >> Bastien,
> >> 
> >> I can't clone the orgweb repo:
> >> 
> >> git clone git://orgmode.org/orgweb.git
> >> Cloning into 'orgweb'...
> >> fatal: The remote end hung up unexpectedly
> >> 
> >> Is the server is down?
> >> 
> >
> > I can't get to it either, but I am behind a firewall and have had
> > problems with the socks proxy I usually use. After I switched proxies,
> > I *was* able to do a git pull on the emacs repository though, so I
> > suspect the fault is at orgmode.org's end.
> >
> 
> 
> orgmode.org was recently moved to a new machine, so you will have to
> update any tools which check MAC addresses for things like man in the
> middle attacks.  I did have to update my ~/.ssh/known_hosts this morning
> to remove the old key.
> 

I don't think that I have anything like that. The IP address resolves to

,----
| $ host orgmode.org
| orgmode.org has address 198.101.246.4
| orgmode.org mail is handled by 0 deathroller.dunsmor.com.
`----

and I can get to http://orgmode.org, I just can't get to it through git:

,----
| $ tsocks git clone git://orgmode.org/org-mode.git
| Cloning into org-mode...
| fatal: The remote end hung up unexpectedly
`----


> I've since been using the git repo on the orgmode server without
> problem.
> 

Presumably through ssh? If so, port 22 is open. I wonder if there is some
restriction on the git port (9418 by default) though.

Nick

Re: [OT] Current website not very attractive

[Nick Dokos]

Nick Dokos <nicholas.dokos@hp.com> wrote:

> Eric Schulte <eric.schulte@gmx.com> wrote:
> 
> > Nick Dokos <nicholas.dokos@hp.com> writes:
> > 
> > > Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote:
> > >
> > >> Bastien,
> > >> 
> > >> I can't clone the orgweb repo:
> > >> 
> > >> git clone git://orgmode.org/orgweb.git
> > >> Cloning into 'orgweb'...
> > >> fatal: The remote end hung up unexpectedly
> > >> 
> > >> Is the server is down?
> > >> 
> > >
> > > I can't get to it either, but I am behind a firewall and have had
> > > problems with the socks proxy I usually use. After I switched proxies,
> > > I *was* able to do a git pull on the emacs repository though, so I
> > > suspect the fault is at orgmode.org's end.
> > >
> > 
> > 
> > orgmode.org was recently moved to a new machine, so you will have to
> > update any tools which check MAC addresses for things like man in the
> > middle attacks.  I did have to update my ~/.ssh/known_hosts this morning
> > to remove the old key.
> > 
> 
> I don't think that I have anything like that. The IP address resolves to
> 
> ,----
> | $ host orgmode.org
> | orgmode.org has address 198.101.246.4
> | orgmode.org mail is handled by 0 deathroller.dunsmor.com.
> `----
> 
> and I can get to http://orgmode.org, I just can't get to it through git:
> 
> ,----
> | $ tsocks git clone git://orgmode.org/org-mode.git
> | Cloning into org-mode...
> | fatal: The remote end hung up unexpectedly
> `----
> 
> 
> > I've since been using the git repo on the orgmode server without
> > problem.
> > 
> 
> Presumably through ssh? If so, port 22 is open. I wonder if there is some
> restriction on the git port (9418 by default) though.
> 
> Nick
> 

One other data point: if I change the protocol to http in .git/config,
things are working - changing it back to git breaks it again:

,----
| $ git pull
| From http://orgmode.org/org-mode
|    ac9ed2a..5083790  maint      -> origin/maint
|    23b30cd..34db1c2  master     -> origin/master
| Updating 23b30cd..34db1c2
| Fast-forward
|  contrib/lisp/org-wikinodes.el |    6 +++---
|  doc/org.texi                  |   23 ++++++++++++++++++++---
|  lisp/Makefile                 |   13 +++++++++++--
|  lisp/org-agenda.el            |    2 +-
|  lisp/org-clock.el             |    3 ++-
|  lisp/org.el                   |    1 +
|  mk/targets.mk                 |    9 +--------
|  7 files changed, 39 insertions(+), 18 deletions(-)
| 
| # change it back to git:
| git pull
| fatal: The remote end hung up unexpectedly
`----

So it seems to me that either the git daemon is not running or the port
is unreachable.

Nick

Re: [OT] Current website not very attractive

[Bastien]

Yes, there is a problem here: only users with push access can 
clone for now (and pull and push.)

I think Jason is not online this week-end, so we will have to
live with it.

I've created clones of org-mode.git and orgweb.git on github:

  https://github.com/bzg/org-mode
  https://github.com/bzg/orgweb

HTH,

-- 
 Bastien

Re: [OT] Current website not very attractive

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Yes, there is a problem here: only users with push access can 
> clone for now (and pull and push.)
> 
> I think Jason is not online this week-end, so we will have to
> live with it.
> 
> I've created clones of org-mode.git and orgweb.git on github:
> 
>   https://github.com/bzg/org-mode
>   https://github.com/bzg/orgweb
> 

Just tell people to use http: instead of git: for now.

Nick

Re: [OT] Current website not very attractive

[Bastien]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Just tell people to use http: instead of git: for now.

All right, you just did so.  Thanks,

-- 
 Bastien

Re: [OT] Current website not very attractive

[John Hendy]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

For firewalls (im behind one too) see if theres an https alternative. I
guess you solved this, but some might not be able to futz with proxies (or
shouldn't) at work :)
On Sep 21, 2012 5:50 PM, "Nick Dokos" <nicholas.dokos@hp.com> wrote:

> Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote:
>
> > Bastien,
> >
> > I can't clone the orgweb repo:
> >
> > git clone git://orgmode.org/orgweb.git
> > Cloning into 'orgweb'...
> > fatal: The remote end hung up unexpectedly
> >
> > Is the server is down?
> >
>
> I can't get to it either, but I am behind a firewall and have had
> problems with the socks proxy I usually use. After I switched proxies,
> I *was* able to do a git pull on the emacs repository though, so I
> suspect the fault is at orgmode.org's end.
>
> Nick
>
> > - Marcelo.
> >
> > On Fri, Sep 14, 2012 at 12:41 AM, Bastien <bzg@altern.org> wrote:
> >
> >     Hi Marcelo,
> >
> >     glad you like the new website!  It's important to keep Org open
> >     to non-developers, it is good if the website somehow advertizes
> >     this attitude.
> >
> >     Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
> >
> >     > I can help with the Spanish and Portuguese versions, by the way.
> >
> >     Great!
> >
> >     ~$ git clone git://orgmode.org/orgweb.git
> >     ~$ cd orgweb/
> >     ~$ git branch orgweb-es
> >     ~$ mkdir es/
> >     ~$ cp *org es/
> >
> >     [translate the es/*org files]
> >
> >     ~$ git commit -m "Yeah! "es" translation done!"
> >     ~$ git format-patch master
> >
> >     ... then send me the patch(es).
> >
> >     Should be one-hour max of work.
> >
> >     Thanks in advance :)
> >
> >     --
> >      Bastien
> >
> >
> > ----------------------------------------------------
> > Alternatives:
> >
> > ----------------------------------------------------
>
>

[-- Attachment #2: Type: text/html, Size: 2800 bytes --]

Re: [OT] Current website not very attractive

[Achim Gratz]

Bastien writes:
> I think Jason is not online this week-end, so we will have to
> live with it.

He has just fixed it and it works again with my old configuration.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Logging of work no longer working with emcas24

[Im Exil]

Hi,

after I've decided to use emacs24 I found out that logging of work
does no lpnge work. All I get after typing:  "C-c C-x C-i" all I get
is an empty

CLOCK:

and the message:
byte-code: Symbol's function definition is void: org-get-effort

Any idea what I'm missing? I'm using the git version tag release_7.9.3
as ELPA did not really work well.

Thanks,
Dietmar

Re: Logging of work no longer working with emcas24

[Nick Dokos]

Im Exil <imexil@gmx.de> wrote:

> Hi,
> 
> after I've decided to use emacs24 I found out that logging of work
> does no lpnge work. All I get after typing:  "C-c C-x C-i" all I get
> is an empty
> 
> CLOCK:
> 
> and the message:
> byte-code: Symbol's function definition is void: org-get-effort
> 
> Any idea what I'm missing? I'm using the git version tag release_7.9.3
> as ELPA did not really work well.
> 

You probably have a mixed installation, where some bits are loaded from
release_7.9.3 and some are loaded from the older org that comes with
emacs: org-get-effort was deleted as part of commit
c4d4bf3833ecdfffd603aa7555eca2cea45aff6e.

Make sure that you follow the instructions in section 1.2,
"Installation", of the manual to the letter and also make sure that you
set the load-path in your .emacs (or other init file as
applicable) *before any piece of org is loaded* - you seem to be loading
org.el before resetting the load-path, so you end up getting the org.el
from the emacs distribution.

Nick

Re: Logging of work no longer working with emcas24

[Im Exil]

OK there seems indeed to be a problem of the initialisation. I got it
to work using a minimal init.el file. Thanks I think I can now start
investigating further.


On Tue, Jan 15, 2013 at 11:27 AM, Nick Dokos <nicholas.dokos@hp.com> wrote:
>
> Im Exil <imexil@gmx.de> wrote:
>
> > Hi,
> >
> > after I've decided to use emacs24 I found out that logging of work
> > does no lpnge work. All I get after typing:  "C-c C-x C-i" all I get
> > is an empty
> >
> > CLOCK:
> >
> > and the message:
> > byte-code: Symbol's function definition is void: org-get-effort
> >
> > Any idea what I'm missing? I'm using the git version tag release_7.9.3
> > as ELPA did not really work well.
> >
>
> You probably have a mixed installation, where some bits are loaded from
> release_7.9.3 and some are loaded from the older org that comes with
> emacs: org-get-effort was deleted as part of commit
> c4d4bf3833ecdfffd603aa7555eca2cea45aff6e.
>
> Make sure that you follow the instructions in section 1.2,
> "Installation", of the manual to the letter and also make sure that you
> set the load-path in your .emacs (or other init file as
> applicable) *before any piece of org is loaded* - you seem to be loading
> org.el before resetting the load-path, so you end up getting the org.el
> from the emacs distribution.
>
> Nick

Re: Logging of work no longer working with emcas24

[Nick Dokos]

Nick Dokos <nicholas.dokos@hp.com> wrote:

> Im Exil <imexil@gmx.de> wrote:
> 
> > Hi,
> > 
> > after I've decided to use emacs24 I found out that logging of work
> > does no lpnge work. All I get after typing:  "C-c C-x C-i" all I get
> > is an empty
> > 
> > CLOCK:
> > 
> > and the message:
> > byte-code: Symbol's function definition is void: org-get-effort
> > 
> > Any idea what I'm missing? I'm using the git version tag release_7.9.3
> > as ELPA did not really work well.
> > 
>
> ... 
> set the load-path in your .emacs (or other init file as
> applicable) *before any piece of org is loaded* - you seem to be loading
> org.el before resetting the load-path, so you end up getting the org.el
> from the emacs distribution.
> 

Uhhh, that's not right - I should have said: you seem to be getting
org-clock.el (or whoever used to use org-get-effort) from the emacs
distribution, but org.el (which does not define org-get-effort any more)
from the git clone.

Sorry for misleading,
Nick

Re: Logging of work no longer working with emcas24

[Im Exil]

OK so I could narrow it down to the following:

in my init.el I had this:

;; org-mode
(add-to-list 'load-path "~/.emacs.d/plugins/org-mode/lisp")
;; make contrib modules available
(add-to-list 'load-path "~/.emacs.d/plugins/org-mode/contrib/lisp" t)
(setq org-directory "~/ORGA/GTD/org")
;;(add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-ca" 'org-agenda)
(global-set-key "\C-cb" 'org-iswitchb)
(global-set-key "\C-ct" 'org-toggle-timestamp-type)
(setq org-default-notes-file (concat org-directory "/notes.org"))
(define-key global-map "\C-cr" 'org-remember)

Which works perfectly fine. In addition i have the following line
right below the above:

(find-file "/home/dietmarw/ORGA/GTD/org/mygtd.org")

This breaks the logging funktionality. If I don't auto load the file I
can open it and everything works fine. But I still like to keep it the
way that my org-mode file comes up after launching emacs. Is there
another way to do that that won't break org-mode time logging?

/Dietmar/

Re: Logging of work no longer working with emcas24

[Achim Gratz]

Im Exil writes:
> Which works perfectly fine. In addition i have the following line
> right below the above:
>
> (find-file "/home/dietmarw/ORGA/GTD/org/mygtd.org")
>
> This breaks the logging funktionality. If I don't auto load the file I
> can open it and everything works fine. But I still like to keep it the
> way that my org-mode file comes up after launching emacs. Is there
> another way to do that that won't break org-mode time logging?

This is to be expected, put any stuff that needs to happen after
initialization into `after-init-hook´.  But in this particular case you
really should simply define an alias that simply loads the file into
Emacs.

alias mygtd 'emacs /home/dietmarw/ORGA/GTD/org/mygtd.org'


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Logging of work no longer working with emcas24

[Im Exil]

Achim,

On Tue, Jan 15, 2013 at 8:10 PM, Achim Gratz <Stromeko@nexgo.de> wrote:
> alias mygtd 'emacs /home/dietmarw/ORGA/GTD/org/mygtd.org'

of course ... some things just are too simple to see it. Thanks for this!

/Dietmar/