serious problems with org-8 under Xemacs-21.5.32

serious problems with org-8 under Xemacs-21.5.32

[Uwe Brauer]

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

Hello

In order to check whether org-8 works under Xemacs-21.5.32 Mule (and not
using my old org-7 setting), I did the following

    -  I started xemacs -vanilla (equivalent to GNU emacs -q)

    -  I loaded the following init file:


,----
| (push (expand-file-name "~/xemacs/site-lisp/packages/org-8.0.3/lisp/") load-path)
| (push (expand-file-name "~/xemacs/site-lisp/packages/org-8.0.3/contrib/lisp/") load-path)
| (push (expand-file-name "~/xemacs/site-lisp/packages/org-8.0.3/contrib/odt/etc/schema/") load-path)
| 
| (require 'org-compat)
| (require 'ox)
| (require 'org-install)
`----

I opened an org file. Observations

    -  the file was in *fundamental* mode!

    -  I turned on org-mode and received and error I attach.

    -  I tried to use org-preview-latex-fragment and received a
       different error (also attached)

    -  I tried to use org-submit-bug-report and received third error.

Any comments?

thanks

Uwe Brauer 

[-- Attachment #2: org-8-bug-submit-bug --]
[-- Type: application/octet-stream, Size: 4426 bytes --]

Debugger entered--Lisp error: (void-function call-process-shell-command)
  call-process-shell-command("command" nil nil nil "-v" "x11idle")
  byte-code("..." [window-system org-clock-x11idle-program-name current-load-list org-x11idle-exists-p default-boundp set-default x call-process-shell-command "command" nil "-v" 0] 9)
  load-internal("org-clock" nil require nil raw-text-unix)
  load("org-clock" nil require nil)
  apply(load ("org-clock" nil require nil))
  dired-handler-fn(load "org-clock" nil require nil)
  load("org-clock" nil require nil)
  require(org-clock)
  mapc(require (org-colview org-id org-remember org-table org-timer))
  org-require-autoloaded-modules()
  #<compiled-function (from org-submit-bug-report) nil "...(82)" [#:G7788 reporter-prompt-for-summary-p list require reporter org-load-modules-maybe org-require-autoloaded-modules "Bug report subject: " reporter-submit-bug-report "emacs-orgmode@gnu.org" org-version nil full current-window-configuration (...) org-pop-to-buffer-same-window get-buffer-create "*Warn about privacy*" delete-other-windows erase-buffer "You are about to submit a bug report to the Org-mode mailing list.\n\nWe would like to add your full Org-mode and Outline configuration to the\nbug report.  This greatly simplifies the work of the maintainer and\nother experts on the mailing list.\n\nHOWEVER, some variables you have customized may contain private\ninformation.  The names of customers, colleagues, or friends, might\nappear in the form of file names, tags, todo states, or search strings.\nIf you answer yes to the prompt, you might want to check and remove\nsuch private information before sending the email." add-text-properties (face org-warning) yes-or-no-p "Include your Org-mode configuration " mapatoms #<compiled-function (from "/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc") ... "...(53)" ... 4 0x14da> kill-buffer get-buffer "Remember to cover the basics, that is, what you expected to happen and\nwhat in fact did happen.  You don't know how to make a good report?  See\n\n     http://orgmode.org/manual/Feedback.html#Feedback\n\nYour bug report will be posted to the Org-mode mailing list.\n------------------------------------------------------------------------" re-search-backward "^\\(Subject: \\)Org-mode version \\(.*?\\);[ 	]*\\(.*\\)" t replace-match "\\1Bug: \\3 [\\2]"] 7 ("/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc" . 622704) nil 0x14db>()
  call-interactively(org-submit-bug-report)
  command-execute(org-submit-bug-report t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)
  recursive-edit()
  byte-code("..." [buffer-read-only noninteractive debugger-buffer middlestart debugger-args debugger-batch-max-lines pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n" message buffer-string kill-emacs debug backtrace-debug 3 t debugger-reenable "" nil recursive-edit standard-output] 3)
  debug(error (invalid-state "Autoloading failed to define function" outline-previous-heading))
  outline-previous-heading()
  org-cycle-show-empty-lines(overview)
  run-hook-with-args(org-cycle-show-empty-lines overview)
  org-cycle-internal-global()
  org-cycle((4))
  org-set-startup-visibility()
  #<compiled-function (from org-mode) nil "...(710)" [org-mode-syntax-table org-ellipsis org-mode-map org-display-table var value make-local-variable delay-mode-hooks t outline-mode org-mode "Org" mode-class put keymap-parent set-keymap-parents current-local-map derived-mode-merge-syntax-tables syntax-table use-local-map set-syntax-table boundp outline-mode-menu-heading easy-menu-remove org-load-modules-maybe easy-menu-add org-install-agenda-files-menu add-to-invisibility-spec (org-link) (org-cwidth) (org-hide-block . t) line-move-ignore-invisible outline-regexp outline-level org-outline-level left-to-right paragraph-start "\f\\|[ 	]*$\\|\\*+ " fboundp set-display-table-slot buffer-display-table make-glyph-code make-display-table 4 vconcat mapcar #<compiled-function (from "/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc") ... "...(10)" ... 3 0x121a> "..." org-set-regexps-and-options-for-tags org-set-regexps-and-options ...] 7 ("/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc" . 194853) nil 0x121b>()
  call-interactively(org-mode)
  command-execute(org-mode t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

[-- Attachment #3: org-8-bug-preview --]
[-- Type: application/octet-stream, Size: 2215 bytes --]

Debugger entered--Lisp error: (void-function face-at-point)
  face-at-point()
  org-format-latex("ltxpng/test" "/home/oub/xemacs/init/" overlays "Creating images for buffer...%s" nil forbuffer dvipng)
  org-preview-latex-fragment(nil)
  call-interactively(org-preview-latex-fragment)
  command-execute(org-preview-latex-fragment t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)
  recursive-edit()
  byte-code("..." [buffer-read-only noninteractive debugger-buffer middlestart debugger-args debugger-batch-max-lines pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n" message buffer-string kill-emacs debug backtrace-debug 3 t debugger-reenable "" nil recursive-edit standard-output] 3)
  debug(error (invalid-state "Autoloading failed to define function" outline-previous-heading))
  outline-previous-heading()
  org-cycle-show-empty-lines(overview)
  run-hook-with-args(org-cycle-show-empty-lines overview)
  org-cycle-internal-global()
  org-cycle((4))
  org-set-startup-visibility()
  #<compiled-function (from org-mode) nil "...(710)" [org-mode-syntax-table org-ellipsis org-mode-map org-display-table var value make-local-variable delay-mode-hooks t outline-mode org-mode "Org" mode-class put keymap-parent set-keymap-parents current-local-map derived-mode-merge-syntax-tables syntax-table use-local-map set-syntax-table boundp outline-mode-menu-heading easy-menu-remove org-load-modules-maybe easy-menu-add org-install-agenda-files-menu add-to-invisibility-spec (org-link) (org-cwidth) (org-hide-block . t) line-move-ignore-invisible outline-regexp outline-level org-outline-level left-to-right paragraph-start "\f\\|[ 	]*$\\|\\*+ " fboundp set-display-table-slot buffer-display-table make-glyph-code make-display-table 4 vconcat mapcar #<compiled-function (from "/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc") ... "...(10)" ... 3 0x121a> "..." org-set-regexps-and-options-for-tags org-set-regexps-and-options ...] 7 ("/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc" . 194853) nil 0x121b>()
  call-interactively(org-mode)
  command-execute(org-mode t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

[-- Attachment #4: org-8-bug --]
[-- Type: application/octet-stream, Size: 1491 bytes --]

Debugger entered--Lisp error: (invalid-state "Autoloading failed to define function" outline-previous-heading)
  outline-previous-heading()
  org-cycle-show-empty-lines(overview)
  run-hook-with-args(org-cycle-show-empty-lines overview)
  org-cycle-internal-global()
  org-cycle((4))
  org-set-startup-visibility()
  #<compiled-function (from org-mode) nil "...(710)" [org-mode-syntax-table org-ellipsis org-mode-map org-display-table var value make-local-variable delay-mode-hooks t outline-mode org-mode "Org" mode-class put keymap-parent set-keymap-parents current-local-map derived-mode-merge-syntax-tables syntax-table use-local-map set-syntax-table boundp outline-mode-menu-heading easy-menu-remove org-load-modules-maybe easy-menu-add org-install-agenda-files-menu add-to-invisibility-spec (org-link) (org-cwidth) (org-hide-block . t) line-move-ignore-invisible outline-regexp outline-level org-outline-level left-to-right paragraph-start "\f\\|[ 	]*$\\|\\*+ " fboundp set-display-table-slot buffer-display-table make-glyph-code make-display-table 4 vconcat mapcar #<compiled-function (from "/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc") ... "...(10)" ... 3 0x121a> "..." org-set-regexps-and-options-for-tags org-set-regexps-and-options ...] 7 ("/home/oub/xemacs/site-lisp/packages/org-8.0.3/lisp/org.elc" . 194853) nil 0x121b>()
  call-interactively(org-mode)
  command-execute(org-mode t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

Re: serious problems with org-8 under Xemacs-21.5.32

[Nick Dokos]

Uwe Brauer <oub@mat.ucm.es> writes:

> Hello
>
> In order to check whether org-8 works under Xemacs-21.5.32 Mule (and not
> using my old org-7 setting), I did the following
>
>     -  I started xemacs -vanilla (equivalent to GNU emacs -q)
>
>     -  I loaded the following init file:
>
>
> ,----
> | (push (expand-file-name
> | "~/xemacs/site-lisp/packages/org-8.0.3/lisp/") load-path)
> | (push (expand-file-name
> | "~/xemacs/site-lisp/packages/org-8.0.3/contrib/lisp/") load-path)
> | (push (expand-file-name
> | "~/xemacs/site-lisp/packages/org-8.0.3/contrib/odt/etc/schema/")
> | load-path)
> | 
> | (require 'org-compat)
> | (require 'ox)
> | (require 'org-install)
> `----
>
> I opened an org file. Observations
>
>     -  the file was in *fundamental* mode!
>

You need to set up auto-mode-alist in your init file:

(add-to-list 'auto-mode-alist   '("\\.org$" . org-mode))


>     -  I turned on org-mode and received and error I attach.
>

The error is[fn:1]:

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (invalid-state "Autoloading failed to define function" outline-previous-heading)
  outline-previous-heading()
  org-cycle-show-empty-lines(overview)
  run-hook-with-args(org-cycle-show-empty-lines overview)
  org-cycle-internal-global()
  org-cycle((4))
  org-set-startup-visibility()
  ...
  call-interactively(org-mode)
  command-execute(org-mode t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)
--8<---------------cut here---------------end--------------->8---

so xemacs found an outline.el that did not define
outline-previous-heading. Check which outline.el xemacs finds with M-x
locate-library RET outline RET. It's probably a compiled file, but the
corresponding outline.el should be in the same directory, or you might need to
get a source package with the xemacs .el files to find it. Check what version
it is, compare it with the emacs version, check whether it includes
outline-previous-heading (probably not, hence the error).

Crossing fingers and toes, you might try using the emacs outline.el but
unless you are really lucky, it's probably not going to work.
Which will mean that somebody will nees to port a recent outline.el from
emacs to xemacs. An xemacs specific mailing list seems the best bet for
that.

>     -  I tried to use org-preview-latex-fragment and received a
>        different error (also attached)
>

The error here:

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-function face-at-point)
  face-at-point()
--8<---------------cut here---------------end--------------->8---

Presumably xemacs does not have face-at-point.

>     -  I tried to use org-submit-bug-report and received third error.
>

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-function call-process-shell-command)
  call-process-shell-command("command" nil nil nil "-v" "x11idle")
--8<---------------cut here---------------end--------------->8---


and it does not seem to have call-process-shell-command. This is
a thin wrapper around call-process (which xemacs should have), so
this should be easy to port.

> Any comments?
>
> thanks
>
> Uwe Brauer 
>
>
>

Footnotes:

[fn:1] Can you please make sure that when you send attachments they are
typed properly? They are sent as "application/octet-stream" currently,
requiring two steps: saving them and then opening the saved file. For
backtraces, just use "text/plain" instead: emacs/gnus knows how to open
these directly.

-- 
Nick

face-at-point (was: serious problems with org-8 under Xemacs-21.5.32)

[Uwe Brauer]

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

>> "Nick" == Nick Dokos <ndokos@gmail.com> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> Hello
   >> 


   > You need to set up auto-mode-alist in your init file:

   > (add-to-list 'auto-mode-alist   '("\\.org$" . org-mode))

Ok, I did this 

   >> -  I turned on org-mode and received and error I attach.
   >> 

   > The error is[fn:1]:

I am sorry, this is also the fault of
gnus-dired-attach 

Which my default uses this type of attachment, I have to look into it,
how to change it on demand.


   >   command-execute(org-mode t)
   >   execute-extended-command(nil)
   >   call-interactively(execute-extended-command)

   > so xemacs found an outline.el that did not define
   > outline-previous-heading. Check which outline.el xemacs finds with M-x
   > locate-library RET outline RET. It's probably a compiled file, but the
   > corresponding outline.el should be in the same directory, or you might need to
   > get a source package with the xemacs .el files to find it. Check what version
   > it is, compare it with the emacs version, check whether it includes
   > outline-previous-heading (probably not, hence the error).

The issue is that org-7 shipped its own outline version for org mode
called noutline, I don't know why it disappear, so I simply copied
noutline into the org-8 directory added a 
(require 'noutline)
to org.el 

And run make again, now org, works, at least partially.
I will CC to xemacs-beta about the outline.el version, because the one
shipped in the pkg xemacs-base is very old. No I better open a new
thread there.


   >> -  I tried to use org-preview-latex-fragment and received a
   >> different error (also attached)
   >> 

   > The error here:

   > Debugger entered--Lisp error: (void-function face-at-point)
   >   face-at-point()

   > Presumably xemacs does not have face-at-point.

Yes and this is a problem. I presume this function is new in GNU emacs 24?

   >> -  I tried to use org-submit-bug-report and received third error.
   >> 

   > Debugger entered--Lisp error: (void-function call-process-shell-command)
   >   call-process-shell-command("command" nil nil nil "-v" "x11idle")


   > and it does not seem to have call-process-shell-command. This is
   > a thin wrapper around call-process (which xemacs should have), so
   > this should be easy to port.

Ok I ask in xemacs-beta

Thanks for your help.

Uwe 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: face-at-point

[Nick Dokos]

Uwe Brauer <oub@mat.ucm.es> writes:


>    > The error is[fn:1]:
>
> I am sorry, this is also the fault of
> gnus-dired-attach 
>
> Which by default uses this type of attachment, I have to look into it,
> how to change it on demand.
>
>

gnus-dired-attach uses mm-default-file-encoding to figure things out.
That in turn calls mailcap-extension-to-mime which uses your mailcap
file (see the mailcap man page) and the file extension. If you give your
backtrace files a .txt extension, chances are good that they will end up
with mime type "text/plain". Evaluate this to make sure:

--8<---------------cut here---------------start------------->8---
(mailcap-extension-to-mime "txt")
"text/plain"
--8<---------------cut here---------------end--------------->8---

Or look through your mailcap file and find a mime-type that is
appropriate and use whatever extension it needs.

-- 
Nick

Re: face-at-point

[Nick Dokos]

Nick Dokos <ndokos@gmail.com> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>
>
>>    > The error is[fn:1]:
>>
>> I am sorry, this is also the fault of
>> gnus-dired-attach 
>>
>> Which by default uses this type of attachment, I have to look into it,
>> how to change it on demand.
>>
>>
>
> gnus-dired-attach uses mm-default-file-encoding to figure things out.
> That in turn calls mailcap-extension-to-mime which uses your mailcap
> file (see the mailcap man page) and the file extension. If you give your
> backtrace files a .txt extension, chances are good that they will end up
> with mime type "text/plain". Evaluate this to make sure:
>
> (mailcap-extension-to-mime "txt")
> "text/plain"
>
> Or look through your mailcap file and find a mime-type that is
> appropriate and use whatever extension it needs.

Sorry - /etc/mime.types is the file that maps extensions to mime-types,
not mailcap.

-- 
Nick

Re: face-at-point

[Uwe Brauer]

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

>> "Nick" == Nick Dokos <ndokos@gmail.com> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> > The error is[fn:1]:
   >> 
   >> I am sorry, this is also the fault of
   >> gnus-dired-attach 
   >> 
   >> Which by default uses this type of attachment, I have to look into it,
   >> how to change it on demand.
   >> 
   >> 

   > gnus-dired-attach uses mm-default-file-encoding to figure things out.

I tried to generalize this function so that it optionally takes the type
as an argument. Too complicated.
   > That in turn calls mailcap-extension-to-mime which uses your mailcap
   > file (see the mailcap man page) and the file extension. If you give your
   > backtrace files a .txt extension, chances are good that they will end up
   > with mime type "text/plain". Evaluate this to make sure:

right, or even save it as .el would do the trick,


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: face-at-point

[Nick Dokos]

Uwe Brauer <oub@mat.ucm.es> writes:

>>> "Nick" == Nick Dokos <ndokos@gmail.com> writes:
>
>    > Uwe Brauer <oub@mat.ucm.es> writes:
>    >> > The error is[fn:1]:
>    >> 
>    >> I am sorry, this is also the fault of
>    >> gnus-dired-attach 
>    >> 
>    >> Which by default uses this type of attachment, I have to look into it,
>    >> how to change it on demand.
>    >> 
>    >> 
>
>    > gnus-dired-attach uses mm-default-file-encoding to figure things out.
>
> I tried to generalize this function so that it optionally takes the type
> as an argument. Too complicated.

Eric Fraga has been prolific in providing solutions to these problems
today. In addition to the client side solution ("Use v instead of t")
which solves the problem on the recipient's side, he provided another
solution (which I have used in the past, but I forgot all about it until
I saw Eric's reply to your question in the gnus mailing list) that
solves the problem on the sender's side: let gnus-dired-attach default
to whatever it bloody well pleases - the attachment cookie it inserts in
the mail you are composing is just text (until you hit C-c C-c and then
it becomes a "real" attachment), so if the type is not to your liking,
you can go ahead and edit it at will (I've stripped out parts of the
cookie, so it won't be mistaken as a real attachment - I'm not sure
how to quote it so that it won't be recognized):

... type="application/octet-stream" filename="~/Desktop/foo" disposition=attachment description=Hunoz>

to

... type="text/plain" filename="~/Desktop/foo" disposition=attachment description=Hunoz>

Another instance of the "Your life in plain text" principle.

I thought I'd post a note with Eric's solution here, just to close the
loop all the way. Here is a reference to his reply:

     http://thread.gmane.org/gmane.emacs.gnus.general/83319/focus=83320

Thanks, Eric!

-- 
Nick

Re: face-at-point

[Eric S Fraga]

Nick Dokos <ndokos@gmail.com> writes:
> Eric Fraga has been prolific in providing solutions to these problems
> today. 

Can you tell I didn't feel like doing any more work at some point in the
day (after an 8 hour meeting...)?  ;-)

> Thanks, Eric!

You're very welcome!

Now off to have a glass of wine and to read a novel.  Have a great
weekend everybody (on this and other lists)!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.3-239-gd316ec

Re: face-at-point

[Uwe Brauer]

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

>> "Nick" == Nick Dokos <ndokos@gmail.com> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:

   > Eric Fraga has been prolific in providing solutions to these problems
   > today. In addition to the client side solution ("Use v instead of t")
   > which solves the problem on the recipient's side, he provided another
   > solution (which I have used in the past, but I forgot all about it until
   > I saw Eric's reply to your question in the gnus mailing list) that
   > solves the problem on the sender's side: let gnus-dired-attach default
   > to whatever it bloody well pleases - the attachment cookie it inserts in
   > the mail you are composing is just text (until you hit C-c C-c and then
   > it becomes a "real" attachment), so if the type is not to your liking,
   > you can go ahead and edit it at will (I've stripped out parts of the
   > cookie, so it won't be mistaken as a real attachment - I'm not sure
   > how to quote it so that it won't be recognized):

   > ... type="application/octet-stream" filename="~/Desktop/foo"
   > disposition=attachment description=Hunoz>

   > to

   > ... type="text/plain" filename="~/Desktop/foo"
   > disposition=attachment description=Hunoz>
yes I have seen his answer, problem with this approach: you have to know
by heart which is hte correct type. 

I never can remember whether it is text/plain or plain/text

 mml-attach-file gives you a list of options.

Uwe Brauer 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: face-at-point

[Nick Dokos]

Uwe Brauer <oub@mat.ucm.es> writes:

>>> "Nick" == Nick Dokos <ndokos@gmail.com> writes:
>
>    > Uwe Brauer <oub@mat.ucm.es> writes:
>
>    > Eric Fraga has been prolific in providing solutions to these problems
>    > today. In addition to the client side solution ("Use v instead of t")
>    > which solves the problem on the recipient's side, he provided another
>    > solution (which I have used in the past, but I forgot all about it until
>    > I saw Eric's reply to your question in the gnus mailing list) that
>    > solves the problem on the sender's side: let gnus-dired-attach default
>    > to whatever it bloody well pleases - the attachment cookie it inserts in
>    > the mail you are composing is just text (until you hit C-c C-c and then
>    > it becomes a "real" attachment), so if the type is not to your liking,
>    > you can go ahead and edit it at will (I've stripped out parts of the
>    > cookie, so it won't be mistaken as a real attachment - I'm not sure
>    > how to quote it so that it won't be recognized):
>
>    > ... type="application/octet-stream" filename="~/Desktop/foo"
>    > disposition=attachment description=Hunoz>
>
>    > to
>
>    > ... type="text/plain" filename="~/Desktop/foo"
>    > disposition=attachment description=Hunoz>
> yes I have seen his answer, problem with this approach: you have to know
> by heart which is hte correct type. 
>
> I never can remember whether it is text/plain or plain/text
>
>  mml-attach-file gives you a list of options.
>

Ideally, the /etc/mime.types mapping will take care of things
automatically.  But this is a last-ditch opportunity to get it
right. You can always

        M-x grep RET plain /etc/mime.types RET

(or jpg, or jpeg, or pdf, or whatever) to verify the correct form.  Or
put it in a function and bind it to a key so you don't have to remember the
name of the file.

OTOH, if you send it out wrong, I now know how to open the attachment
correctly using Eric's other solution - the problem has almost vanished
and life is good...

-- 
Nick

Re: face-at-point

[Michael Sperber]

Uwe Brauer <oub@mat.ucm.es> writes:

> The issue is that org-7 shipped its own outline version for org mode
> called noutline, I don't know why it disappear, so I simply copied
> noutline into the org-8 directory added a 
> (require 'noutline)
> to org.el 

That's because XEmacs's outline.el is now what used to be noutline.el.
(It has been for about 3 years.)  So you can just require outline.el.

-- 
Regards,
Mike

[partically solved] (was: serious problems with org-8 under Xemacs-21.5.32)

[Uwe Brauer]

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

>> "Nick" == Nick Dokos <ndokos@gmail.com> writes:


   > so xemacs found an outline.el that did not define
   > outline-previous-heading. Check which outline.el xemacs
   > finds with M-x locate-library RET outline RET. It's probably
   > a compiled file, but the corresponding outline.el should be
   > in the same directory, or you might need to get a source
   > package with the xemacs .el files to find it. Check what
   > version it is, compare it with the emacs version, check
   > whether it includes outline-previous-heading (probably not,
   > hence the error).



    - Ok the issue is my xemacs-base pkg and therefore the
      corresponding outline.el was too old, after the upgrade,
      this problem disappeared.


    - I also just copied face face-at-point and the
      org-preview-latex-fr worked again.

It remains to look now for the shell-pro and the gnus compatibility
problem I face.

Uwe 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5554 bytes --]

Re: serious problems with org-8 under Xemacs-21.5.32

[Eric S Fraga]

Nick Dokos <ndokos@gmail.com> writes:

[...]

> [fn:1] Can you please make sure that when you send attachments they are
> typed properly? They are sent as "application/octet-stream" currently,
> requiring two steps: saving them and then opening the saved file. For
> backtraces, just use "text/plain" instead: emacs/gnus knows how to open
> these directly.

OT but: the easy way to open these attachments, when you know they are
meant to be text/plain, is to use 't' (gnus-mime-view-part-as-type) as
opposed to 'v' to view the attachment: you get asked for the mime type
and you then get the appropriate viewer.  Quite handy, especially when
interacting with users of certain brain-dead MUAs...  As usual, gnus has
a solution to most problems!  The trick is knowing these solutions. :-)

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.3-193-g334581

Re: serious problems with org-8 under Xemacs-21.5.32

[Nick Dokos]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
> [...]
>
>> [fn:1] Can you please make sure that when you send attachments they are
>> typed properly? They are sent as "application/octet-stream" currently,
>> requiring two steps: saving them and then opening the saved file. For
>> backtraces, just use "text/plain" instead: emacs/gnus knows how to open
>> these directly.
>
> OT but: the easy way to open these attachments, when you know they are
> meant to be text/plain, is to use 't' (gnus-mime-view-part-as-type) as
> opposed to 'v' to view the attachment: you get asked for the mime type
> and you then get the appropriate viewer.  Quite handy, especially when
> interacting with users of certain brain-dead MUAs...  As usual, gnus has
> a solution to most problems!  The trick is knowing these solutions. :-)

Ah, thanks! I recently switched to gnus and the culture shock is killing
me, but I'm determined to stick it out this time. This will make it a
bit easier.

-- 
Nick