[ wildly merged quotes from 3 mails. I hope you don't mind.] Per Olofsson schrob: > Thanks. There's a problem though. xdg-email is meant specifically for > GUI programs. That means there's no tty available in general. So you > can't simply run mutt - you need to run it in a terminal window.
/usr/lib/mutt/mailto-mutt already does that (in addition to parsing mailto: links). And it shouldn't be too hard to prevent it from spawning an x-terminal-emulator if already in a terminal. In fact: > I wonder if the X issue can be solved similarly to BROWSER. I'm not > even sure how it's solved with BROWSER. What if the user doesn't want > a graphical browser? That's me! And I seem to have success with | #!/bin/sh | ELINKS=/some/where/elinks | local L | if L="`tput lines`" && [ "$L"0 -gt "1"0 ] ; then | exec $ELINKS "$@" | else | exec x-terminal-emulator -e $ELINKS "$@" | fi and pointing BROWSER to that. Still new and in trial, but so far works for xdg-open in the linux console, in an x-terminal-emulator, and under X outside of a terminal emulator. Opens an x-terminal-emulator exactly in the last case. Should be probably factored into "run-in-terminal.sh" and used as BROWSER='run-in-terminal.sh /some/where/elinks' > There's also the question of the user setting for example MAILER=alpine. She should set MAILER='run-in-terminal.sh alpine' instead. :) > Then xdg-email will have to recognize that it's not an X app and also > launch it in a terminal. How will it know that? I guess that doesn't > work with BROWSER either at the moment. Correct, xdg-email can't know if $MAILER is an X app. The user has to supply that information, by not prefixing withrun-in-terminal.sh . (Unless she knows she'll never use xdg-email from inside a native X application, then she could guarantee alpine always has a terminal. Ha! Not what you expected she'd do to your GUI-helper. ;) > Thirdly, your patch always uses the MAILER variable if it's defined, > even when running under a DE. I'm not sure that's the correct thing to do. No problem, I am sure. :D Having set the environment variable is an explicit statement of the form "I demand mutt as my mua!". Using a DE, in contrast, is more along the line of "I generally like what GNOME is doing", it's much less specific about my email preferences. And if we make xdg-email prefer the DE's idea over MAILER, I can't even unset GNOME's email preferences, I have to explicitly configure GNOME to use mutt. And I have to configure KDE to use mutt, if I occasionally use KDE too, for whatever reason. And I have to re-configure MAILER, GNOME and KDE if I decide to switch to mutt-ng. Note I also can't configure GNOME/KDE to use xdg-email, because that'd be a cycle. If we make xdg-email prefer MAILER over the DE's idea, on the other hand, I can still set MAILER to mutt. When I then use GNOME/KDE/XFCE, I can, once, say "use xdg-email as a mailto handler", and everything will follow MAILER around to mutt-ng, or alpine, or whatever. Alternatively, I can set just KDE to stick with kmail(?), and it will. And, best of all, if I don't care about that funky MAILER stuff for people who use non-DE software or multiple DEs, I don't have to: it will never be set, and never get in my way. > > [1] Anyone know of a good documentation for BROWSER/EDITOR/VISUAL/PAGER? > http://catb.org/~esr/BROWSER/ Thanks. And I guess that EDITOR/VISUAL/PAGER never supported X or the colon-fallthough-scheme, but just assume they're running in a terminal? > [MAILER and colon-fallthrough] We could simply copy the code that > parses $BROWSER (it's in upstream but not the Debian package) Nice, +1. cheers, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
signature.asc
Description: Digital signature
