Re: ODT export --> opening in Okular?

Re: ODT export --> opening in Okular?

[James Harkins]

---- On Tue, 11 Dec 2018 01:00:15 +0800 <emacs-orgmode-request@gnu.org> wrote ---- 
> Check your ~/.mailcap and/or /etc/mailcap file as well: there are indeed 
> many twisty passages through org-open-file, so you may end up calling 
> whatever the system has set up (correctly or not). 
> Nick 

Aha, that was the answer. Apparently installing Okular adds this bit of silliness into /etc/mailcap:

application/vnd.oasis.opendocument.text; okular %s --icon okular -caption Okular; test=test -n "$DISPLAY"

... which I find now has also been reported to Debian as a bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857443

I still think it's insane, but at least now it's clear where the insanity lies: with Okular's inflated sense of self-importance :D

But, what I still don't understand is, after adding an ODT entry to org-file-apps, why did org revert to querying mailcap...?

Value: ((auto-mode . emacs)
 ("\\.mm\\'" . default)
 ("\\.x?html?\\'" . "/usr/bin/firefox %s")
 ("\\.odt\\'" . "/usr/bin/libreoffice6.0 %s")
 ("\\.pdf\\'" . "/usr/bin/okular %s"))

Original value was 
((auto-mode . emacs)
 ("\\.mm\\'" . default)
 ("\\.x?html?\\'" . default)
 ("\\.pdf\\'" . default))

... this has exactly zero effect. Org ignores the odt line here, where I would expect an org-specific preference setting to override the system default.

hjh

ODT export --> opening in Okular?

[James Harkins]

Hi,

I realize I'm running an older version of org-mode (8.3.3), but things are working for me generally and I'm not in a position to monkey around with my environment right now.

Anyway, something strange. A few months ago, I was able to export to ODT and the file would open in LibreOffice. But, just now, emacs insists on issuing a command to open it in okular.

Creating ODT file...
Running zip -mX0 project-notes.odt mimetype
Running zip -rmTq project-notes.odt .
Created /blah/blah/project-notes.odt
Parsing archive file...done.
Running okular /blah/blah/project-notes.odt --icon okular -caption Okular...done

Okular? That makes no sense at all.

I tried adding an entry to org-file-apps to force it to use libreoffice6.0 to open ODT files, but this is having no effect.

 '(org-file-apps
   (quote
    ((auto-mode . emacs)
     ("\\.mm\\'" . default)
     ("\\.x?html?\\'" . "/usr/bin/firefox %s")
     ("\\.pdf\\'" . "/usr/bin/okular %s")
     ("\\.odt\\'" . "libreoffice6.0 %s"))))

I can find no hard coded reference to Okular anywhere in the org source code.

This is quite mysterious to me. If it's using a particular app to open this type of file, I should be able to find some settings or some instruction somewhere. But I can't.

How to fix this?

hjh

Re: ODT export --> opening in Okular?

[briangpowell]

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

* Suggest you try changing this:

 ("\\.odt\\'" . "libreoffice6.0 %s"))))

* To this instead:

 ("\\.odt\\'" . "libreoffice %s"))))

--since "libreoffice6.0" is a specific link that is subject to change--not
only by you but by your chosen operating system package manager

Unless of course, you intentionally run several versions of libreoffice,
which is possible but seems pointless



On Sun, Dec 9, 2018 at 6:07 PM James Harkins <jamshark70@zoho.com> wrote:

> Hi,
>
> I realize I'm running an older version of org-mode (8.3.3), but things are
> working for me generally and I'm not in a position to monkey around with my
> environment right now.
>
> Anyway, something strange. A few months ago, I was able to export to ODT
> and the file would open in LibreOffice. But, just now, emacs insists on
> issuing a command to open it in okular.
>
> Creating ODT file...
> Running zip -mX0 project-notes.odt mimetype
> Running zip -rmTq project-notes.odt .
> Created /blah/blah/project-notes.odt
> Parsing archive file...done.
> Running okular /blah/blah/project-notes.odt --icon okular -caption
> Okular...done
>
> Okular? That makes no sense at all.
>
> I tried adding an entry to org-file-apps to force it to use libreoffice6.0
> to open ODT files, but this is having no effect.
>
>  '(org-file-apps
>    (quote
>     ((auto-mode . emacs)
>      ("\\.mm\\'" . default)
>      ("\\.x?html?\\'" . "/usr/bin/firefox %s")
>      ("\\.pdf\\'" . "/usr/bin/okular %s")
>      ("\\.odt\\'" . "libreoffice6.0 %s"))))
>
> I can find no hard coded reference to Okular anywhere in the org source
> code.
>
> This is quite mysterious to me. If it's using a particular app to open
> this type of file, I should be able to find some settings or some
> instruction somewhere. But I can't.
>
> How to fix this?
>
> hjh
>
>
>

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

Re: ODT export --> opening in Okular?

[James Harkins]

---- On Mon, 10 Dec 2018 07:25:13 +0800 briangpowell <briangpowellms@gmail.com> wrote ---- 
> * Suggest you try changing this:
> 
>  ("\\.odt\\'" . "libreoffice6.0 %s"))))
> * To this instead:
> 
>  ("\\.odt\\'" . "libreoffice %s"))))
> --since "libreoffice6.0" is a specific link that is subject to change--not only by you but by your chosen operating system package manager

Nope.

$ libreoffice --help
The program 'libreoffice' is currently not installed.

(I installed libreoffice by downloading from their website, not using Ubuntu packages -- because I had some issues with it a while back and the advice from their user community is always, don't use system-bundled packages because they are out of date.)

In any case, it doesn't make a difference: org still insists on issuing the command for okular.

I also tried the full path to the binary /usr/bin/libreoffice6.0 -- still exports to Okular.

As a final test, I deleted both the PDF and ODT entries from org-file-apps -- so that there is absolutely no reference in any org code file or variable to okular -- and it is *still* opening the exported ODT in okular! Which strikes me as insane.

org-open-file seems to be a rather complex function. I can't make heads or tails of it. If I had to guess, I would suppose that it has some fallback position that doesn't depend on org configuration variables.

Anyway, the solution for now, as I'm under some time pressure, is to declare that ODT export is broken on my system until I can scrape together some time to upgrade org. PDF export is actually OK for now (and working fine).

hjh

Re: ODT export --> opening in Okular?

[Ken Mankoff]

On 2018-12-09 at 17:45 -0800, James Harkins <jamshark70@zoho.com> wrote:
> Anyway, the solution for now, as I'm under some time pressure, is to
> declare that ODT export is broken on my system until I can scrape
> together some time to upgrade org. PDF export is actually OK for now
> (and working fine).

But export is not the same as opening. Export should work.

  -k.

Re: ODT export --> opening in Okular?

[Eric S Fraga]

On Sunday,  9 Dec 2018 at 18:20, Ken Mankoff wrote:
> On 2018-12-09 at 17:45 -0800, James Harkins <jamshark70@zoho.com> wrote:
>> Anyway, the solution for now, as I'm under some time pressure, is to
>> declare that ODT export is broken on my system until I can scrape
>> together some time to upgrade org. PDF export is actually OK for now
>> (and working fine).
>
> But export is not the same as opening. Export should work.

James might be invoking "expoert & open".

For James, your problem may have been caused by changes outside emacs,
e.g. mailcap and mime.types although obviously it should work when you
specify the file apps in emacs.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.13-894-gf79545

Re: ODT export --> opening in Okular?

[Nick Dokos]

James Harkins <jamshark70@zoho.com> writes:

> ...
> As a final test, I deleted both the PDF and ODT entries from
> org-file-apps -- so that there is absolutely no reference in any org
> code file or variable to okular -- and it is *still* opening the
> exported ODT in okular! Which strikes me as insane.
>
> org-open-file seems to be a rather complex function. I can't make
> heads or tails of it. If I had to guess, I would suppose that it has
> some fallback position that doesn't depend on org configuration
> variables.
>

Check your ~/.mailcap and/or /etc/mailcap file as well: there are indeed
many twisty passages through org-open-file, so you may end up calling
whatever the system has set up (correctly or not).

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler