how do i set evince as the default. right now xpdf is, but if i remove it, following a link to a pdf file produces nothing. i'm using gnome and evince is the default there (eg through nautilus), so somehow it seems that orgmode has decided to make xpdf the default instead. -- in friendship, prad
Prad,
On Sun, Mar 11, 2012 at 1:31 PM, prad <prad@towardsfreedom.com> wrote:
> how do i set evince as the default.
>
> right now xpdf is, but if i remove it, following a link to a pdf file
> produces nothing.
>
> i'm using gnome and evince is the default there (eg through nautilus),
> so somehow it seems that orgmode has decided to make xpdf the default
> instead.
Customize the variable `org-file-apps'. Look at documentation of the
variable, for an example and options available.
--
Puneeth
Puneeth Chaganti <punchagan@gmail.com> writes:
> On Sun, Mar 11, 2012 at 1:31 PM, prad <prad@towardsfreedom.com> wrote:
>> how do i set evince as the default.
>>
>> right now xpdf is, but if i remove it, following a link to a pdf file
>> produces nothing.
>>
>> i'm using gnome and evince is the default there (eg through nautilus),
>> so somehow it seems that orgmode has decided to make xpdf the default
>> instead.
>
> Customize the variable `org-file-apps'. Look at documentation of the
> variable, for an example and options available.
>
thx Puneeth! that's what i was looking for!
strange thing is that it was already set to default so i thought evince
would come up. then i changed it to system and xpdf still opened it.
anyway, i altered it to
evince -p %1 %s
and all is well.
--
in friendship,
prad
[-- Attachment #1: Type: text/plain, Size: 975 bytes --] I much prefer OKULAR over EVINCE On Sun, Mar 11, 2012 at 1:15 PM, prad <prad@towardsfreedom.com> wrote: > Puneeth Chaganti <punchagan@gmail.com> writes: > > > On Sun, Mar 11, 2012 at 1:31 PM, prad <prad@towardsfreedom.com> wrote: > >> how do i set evince as the default. > >> > >> right now xpdf is, but if i remove it, following a link to a pdf file > >> produces nothing. > >> > >> i'm using gnome and evince is the default there (eg through nautilus), > >> so somehow it seems that orgmode has decided to make xpdf the default > >> instead. > > > > Customize the variable `org-file-apps'. Look at documentation of the > > variable, for an example and options available. > > > thx Puneeth! that's what i was looking for! > strange thing is that it was already set to default so i thought evince > would come up. then i changed it to system and xpdf still opened it. > > anyway, i altered it to > evince -p %1 %s > > and all is well. > > -- > in friendship, > prad > > > [-- Attachment #2: Type: text/html, Size: 1532 bytes --]
prad <prad@towardsfreedom.com> wrote:
> how do i set evince as the default.
>
> right now xpdf is, but if i remove it, following a link to a pdf file
> produces nothing.
>
> i'm using gnome and evince is the default there (eg through nautilus),
> so somehow it seems that orgmode has decided to make xpdf the default
> instead.
>
But why is org using xpdf, if the system default is evince?
What OS are you running? At least on unix/linux-y systems, you shouldn't
have to customize org-file-apps: just check ~/.mailcap (and/or
/etc/mailcap).
IMO, changing mailcap has the advantage that *all* mailcap-enabled
applications will do the right thing, whereas customizing org-file-apps
just fixes org (I'm assuming of course that you always want evince, not
sometimes one and sometimes the other.)
Nick
Nick Dokos <nicholas.dokos@hp.com> writes: > prad <prad@towardsfreedom.com> wrote: > >> how do i set evince as the default. >> >> right now xpdf is, but if i remove it, following a link to a pdf file >> produces nothing. >> >> i'm using gnome and evince is the default there (eg through nautilus), >> so somehow it seems that orgmode has decided to make xpdf the default >> instead. >> > > But why is org using xpdf, if the system default is evince? > that's what i can't figure out - but admittedly i haven't looked too deeply into this. > What OS are you running? At least on unix/linux-y systems, you shouldn't > have to customize org-file-apps: just check ~/.mailcap (and/or > /etc/mailcap). > i'm on debian squeeze. here's what i found in /etc/mailcap application/pdf; /usr/bin/xpdf '%s'; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf application/x-pdf; /usr/bin/xpdf '%s'; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf application/pdf; evince '%s'; test=test -n "$DISPLAY"; nametemplate=%s.pdf however, i'm not sure how to interpret this. > IMO, changing mailcap has the advantage that *all* mailcap-enabled > applications will do the right thing, whereas customizing org-file-apps > just fixes org (I'm assuming of course that you always want evince, not > sometimes one and sometimes the other.) > ya that would be good! since it is consistency that i'm after, i'd prefer to have emacs run evince because it is the system default rather than because i've changed the variable. -- in friendship, prad
prad <prad@towardsfreedom.com> wrote:
> here's what i found in /etc/mailcap
>
> application/pdf; /usr/bin/xpdf '%s'; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf
>
> application/x-pdf; /usr/bin/xpdf '%s'; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf
>
> application/pdf; evince '%s'; test=test -n "$DISPLAY"; nametemplate=%s.pdf
>
> however, i'm not sure how to interpret this.
>
I'm no expert but I believe that the first entry that matches wins: for
"application/pdf" e.g. in this case, if /usr/bin/xpdf is present and
executable and the display test succeeeds, xpdf will be used. Otherwise
it's going to search further: if evince is present and the display test
succeeds, evince will be used.
You probably want to experiment by adding entries to ~/.mailcap, so that
you don't mess up the system one: entries in ~/.mailcap override. I just
have the bare minimum in mine:
application/pdf; xpdf -q %s
Next question: since xpdf is available and /etc/mailcap prefers it, why
is nautilus using evince? Doesn't it use mailcap? I guess not, although
I don't know for sure[fn:1], but it wouldn't surprise me if it did its
own thing: there are way too many cooks in this kitchen.
Nick
Footnotes:
[fn:1] as you might guess, I don't use nautilus: I have emacs - why would
I use anything else?
On Mon, Mar 12 2012, Nick Dokos wrote:
> prad <prad@towardsfreedom.com> wrote:
>
>
>> here's what i found in /etc/mailcap
>>
>> application/pdf; /usr/bin/xpdf '%s'; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf
>>
>> application/x-pdf; /usr/bin/xpdf '%s'; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf
>>
>> application/pdf; evince '%s'; test=test -n "$DISPLAY"; nametemplate=%s.pdf
>>
>> however, i'm not sure how to interpret this.
>>
>
> I'm no expert but I believe that the first entry that matches wins: for
> "application/pdf" e.g. in this case, if /usr/bin/xpdf is present and
> executable and the display test succeeeds, xpdf will be used. Otherwise
> it's going to search further: if evince is present and the display test
> succeeds, evince will be used.
>
> You probably want to experiment by adding entries to ~/.mailcap, so that
> you don't mess up the system one: entries in ~/.mailcap override. I just
> have the bare minimum in mine:
>
> application/pdf; xpdf -q %s
>
> Next question: since xpdf is available and /etc/mailcap prefers it, why
> is nautilus using evince? Doesn't it use mailcap? I guess not, although
> I don't know for sure[fn:1], but it wouldn't surprise me if it did its
> own thing: there are way too many cooks in this kitchen.
I think most linux desktop environments use something like xdg-open or
gnome-open to determine defaults applications, all my defaults seem to
live in /usr/local/share/applications, which can be overridden in the
home directory. Nautilus ought to use gnome-open. I've tweaked most of
my "open-in-external-blah" functions (in dired and gnus, for example) to
use xdg-open, so the same defaults are used in all my applications,
including emacs.
--
GNU Emacs 24.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
of 2012-03-06 on pellet
Org-mode version 7.8.03 (release_7.8.03.573.g86131)
[OT warning: no org content here, just gnome/mailcap.]
Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> > Next question: since xpdf is available and /etc/mailcap prefers it, why
> > is nautilus using evince? Doesn't it use mailcap? I guess not, although
> > I don't know for sure[fn:1], but it wouldn't surprise me if it did its
> > own thing: there are way too many cooks in this kitchen.
>
> I think most linux desktop environments use something like xdg-open or
> gnome-open to determine defaults applications, all my defaults seem to
> live in /usr/local/share/applications, which can be overridden in the
> home directory. Nautilus ought to use gnome-open. I've tweaked most of
> my "open-in-external-blah" functions (in dired and gnus, for example) to
> use xdg-open, so the same defaults are used in all my applications,
> including emacs.
>
Thanks! That was useful.
Part of my frustration with these things (gnome things in particular) is
the sparse-to-non-existent documentation, so I really appreciate these
pointers. Or maybe I've given up too easily: is there good documentation
somewhere on the web e.g. of gconftool? Not just the syntax but an
enumeration of possibilities. My impression is that things like this are
hidden, (and in some cases, as time goes on, even if they exist, they
are taken away, so there is some motivation to keep them hidden,
although I'm not thinking conspiracy: it's just that documenting things
is hard.) I've usually fumbled in the dark with things under ~/.gconf
(or .gnome2 or .gnome) until I've found something plausible. Just to
make my problem concrete: what is the invocation of gconftool that would
change the default pdf viewer to xpdf?
The other way that I eventually figured out to do that is to open some
application, e.g. nautilus, select some PDF file, click on Properties
and change the default application: I find that counterintuitive,
changing the properties of a class through a single instance (and to all
applications that use the mechanism, even though I'm just using
nautilus: I can't help but find this method somewhat distasteful.) And I
like editing files rather than clicking buttons, but that's me.
To get back to your post: my problem with xdg-open with its switch
blades (kde-open, gnome-open, etc) is that each of those has its own
customization methods. So if I ever want to switch from kde to gnome, I
have to redo the customizations (and I have to find out how to do all
that for the new environment).
I'd rather have them all use mailcap for preferred application choice.
And if mailcap does not provide all the capabilities needed by them, I'd
rather they cooperated and came up with a common mechanism that would
serve *all* their needs (plus provide thorough documentation!) But
that's a fight that's been fought and lost many times - many more times
than it's been won.
Enough venting: I've veered off-topic quite a bit here. Apologies for
the length of the (possibly uninformed) rant. If I've got things wrong,
I'd love to be corrected, but I don't want to exercise the patience of
the regulars too much. But I hope that the discussion, however
tangential, is useful.
Thanks,
Nick
On Tue, Mar 13 2012, Nick Dokos wrote: > [OT warning: no org content here, just gnome/mailcap.] > > Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > >> > Next question: since xpdf is available and /etc/mailcap prefers it, why >> > is nautilus using evince? Doesn't it use mailcap? I guess not, although >> > I don't know for sure[fn:1], but it wouldn't surprise me if it did its >> > own thing: there are way too many cooks in this kitchen. >> >> I think most linux desktop environments use something like xdg-open or >> gnome-open to determine defaults applications, all my defaults seem to >> live in /usr/local/share/applications, which can be overridden in the >> home directory. Nautilus ought to use gnome-open. I've tweaked most of >> my "open-in-external-blah" functions (in dired and gnus, for example) to >> use xdg-open, so the same defaults are used in all my applications, >> including emacs. >> > > Thanks! That was useful. > > Part of my frustration with these things (gnome things in particular) is > the sparse-to-non-existent documentation, so I really appreciate these > pointers. Or maybe I've given up too easily: is there good documentation > somewhere on the web e.g. of gconftool? Not just the syntax but an > enumeration of possibilities. My impression is that things like this are > hidden, (and in some cases, as time goes on, even if they exist, they > are taken away, so there is some motivation to keep them hidden, > although I'm not thinking conspiracy: it's just that documenting things > is hard.) I've usually fumbled in the dark with things under ~/.gconf > (or .gnome2 or .gnome) until I've found something plausible. Just to > make my problem concrete: what is the invocation of gconftool that would > change the default pdf viewer to xpdf? I don't use gnome anymore, but back when I did the gconf stuff was absolutely its most obscure aspect. I get the feeling that gnome is still trying to be the Linux Desktop for Dummies, and while gconftool is there if you need it, no one is trying to make it any easier to use. I don't think I ever once invoked gconftool, so I'm afraid I don't know… > The other way that I eventually figured out to do that is to open some > application, e.g. nautilus, select some PDF file, click on Properties > and change the default application: I find that counterintuitive, > changing the properties of a class through a single instance (and to all > applications that use the mechanism, even though I'm just using > nautilus: I can't help but find this method somewhat distasteful.) And I > like editing files rather than clicking buttons, but that's me. One of the nice things with the Mac is that it gives you two options in the contextual menu: you can open a file with a specific application, or you can tell it "use this application for all files of this type". That at least made it clearer what was going on. > To get back to your post: my problem with xdg-open with its switch > blades (kde-open, gnome-open, etc) is that each of those has its own > customization methods. So if I ever want to switch from kde to gnome, I > have to redo the customizations (and I have to find out how to do all > that for the new environment). > > I'd rather have them all use mailcap for preferred application choice. > And if mailcap does not provide all the capabilities needed by them, I'd > rather they cooperated and came up with a common mechanism that would > serve *all* their needs (plus provide thorough documentation!) But > that's a fight that's been fought and lost many times - many more times > than it's been won. Since moving from Ubuntu to a home-rolled Arch/XFCE/Stumpwm mix, I've definitely become aware that, of all the aspects of a Linux installation, the functionality that falls under the "desktop environment" category is at once the most underdocumented, and also most key to user experience. This seems to be the dark under-plumbing of the Linux GUI experience, the unlovely tangle that no one wants to expose to the user. When I went spelunking, I got the impression that mailcap predates all this XXX-open malarkey, but that most of the apps I use prefer that over mailcap. Like you, I would be very, very surprised if anyone ever put any thought into helping user customizations survive a transition from one DE to another. I still think you'll have most luck messing with files under ~/.local/share/applications, though it probably won't be as simple as that. Sorry, that's not helpful at all! > Enough venting: I've veered off-topic quite a bit here. Apologies for > the length of the (possibly uninformed) rant. If I've got things wrong, > I'd love to be corrected, but I don't want to exercise the patience of > the regulars too much. But I hope that the discussion, however > tangential, is useful. > > Thanks, > Nick > > -- GNU Emacs 24.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-03-06 on pellet Org-mode version 7.8.03 (release_7.8.03.581.g5cb80)
Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> ...
> Sorry, that's not helpful at all!
>
Au contraire! It adds some validity to my prejudices :-)
Thanks,
Nick
Nick Dokos <nicholas.dokos@hp.com> writes: > Or maybe I've given up too easily: is there good documentation > somewhere on the web e.g. of gconftool? As they said in the old times: the documentation is in the files with the suffix .c (ducks :-). > To get back to your post: my problem with xdg-open with its switch > blades (kde-open, gnome-open, etc) is that each of those has its own > customization methods. So if I ever want to switch from kde to gnome, I > have to redo the customizations (and I have to find out how to do all > that for the new environment). Yup, one of those dislikable things they copied from Windows, it's called vendor-lock-in. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Nick Dokos <nicholas.dokos@hp.com> writes: > Part of my frustration with these things (gnome things in particular) is > the sparse-to-non-existent documentation, But Nick, the GUI is everything now. Who needs documentation! ? :-( Anecdote. A big, complex translation system was demonstrated to a few governmental possible buyers, who were taking it a bit from above. At the end of the demo, the technician decided to leave printed copies of the documentation. One of the receiving guy said: "What? You mean that your users actually have to *learn* how to use your system?" Sorry! But am i? I did not even want to resist :-). > that's a fight that's been fought and lost many times - many more times > than it's been won. On the Linux system, I seem just unable to find everything that needs to be changed to prevent Nautilus from ever getting started. In particular, "xdg-open DIRECTORY" required that I patch the program rather setting parameters. It is very possible that I might have done it all wrong, but for me at least, it *is* frustrating. > Enough venting: I've veered off-topic quite a bit here. [...] But I > hope that the discussion, however tangential, is useful. Well, you allowed me to release some steam. Thanks! :-) François