External viewers; Select-by-Copy
Mark T. B. Carroll
* If I select text in a message, only that text is quoted when I reply.
* If an external viewer is launched for a message attachment or URL or
whatever, I can't quit Emacs without it killing the viewer.
Does there happen to be some easy way that I've missed to correct these?
Mark
Ted Zlatanov
MTBC> Two things that Gnus does that really annoy me are:
MTBC> * If I select text in a message, only that text is quoted when I reply.
That's a feature, I'm not sure why it should be changed. Why is it harmful?
MTBC> * If an external viewer is launched for a message attachment or URL or
MTBC> whatever, I can't quit Emacs without it killing the viewer.
I think to correct that, the child process needs to disassociate itself
from Emacs as its parent and that's pretty complicated (requires C calls
that are not available in ELisp AFAIK). I last did this 15+ years ago
so maybe someone else with more current knowledge can comment.
Ted
Mark T. B. Carroll
> On Tue, 24 Nov 2009 18:04:08 -0500 "Mark T. B. Carroll" <mt...@ixod.org> wrote:
>
> MTBC> Two things that Gnus does that really annoy me are:
> MTBC> * If I select text in a message, only that text is quoted when I reply.
>
> That's a feature, I'm not sure why it should be changed. Why is it
> harmful?
Featurism is in the eye of the beholder. Some applications, in my view,
get steadily worse in the development that happens after the initial
mature versions! This particular `feature' is never what I want. I copy
and paste fragments of articles in checking them out in other
applications, taking notes, etc. But then the selection has happened so
when I get to replying, it just quotes a little bit of the article, so I
have to undo the selection first, whether by going to some other article
then back to that one, or using M-u to mark it unread, quit the group
altogether, reenter it and go back to the article, or whatever. Maybe
there's an easier way to get rid of the selection, but a high fraction
of my selecting has nothing to do with what I might want to quote in
reply, so having to undo it just causes me extra work for no gain.
(nip)
> I think to correct that, the child process needs to disassociate itself
> from Emacs as its parent and that's pretty complicated (requires C calls
> that are not available in ELisp AFAIK).
Oh, that's a bit unfortunate! What happens is it starts up a web
browser, say, then I get reminded of or linked to other things I want to
check out, and in the same session after a while I'm now looking at
things that are nothing to do with what I originally launched from
emacs. This is especially bad with things like web browers, Acrobat
Reader, etc., where, when I view different things from outside emacs,
those attempts to view things attach to the existing emacs-spawned
process instead of spawning a new viewer, and then they want to die with
an application that never had anything to do with them.
Mark
Anders Wirzenius
> Ted Zlatanov <t...@lifelogs.com> writes:
>
>> On Tue, 24 Nov 2009 18:04:08 -0500 "Mark T. B. Carroll" <mt...@ixod.org> wrote:
>>
>> MTBC> Two things that Gnus does that really annoy me are:
>> MTBC> * If I select text in a message, only that text is quoted when I reply.
>>
>> That's a feature, I'm not sure why it should be changed. Why is it
>> harmful?
>
> Featurism is in the eye of the beholder. Some applications, in my view,
> get steadily worse in the development that happens after the initial
> mature versions! This particular `feature' is never what I want. I copy
> and paste fragments of articles in checking them out in other
> applications, taking notes, etc. But then the selection has happened so
> when I get to replying, it just quotes a little bit of the article, so I
> have to undo the selection first, whether by going to some other article
> then back to that one, or using M-u to mark it unread, quit the group
> altogether, reenter it and go back to the article, or whatever. Maybe
> there's an easier way to get rid of the selection, but a high fraction
> of my selecting has nothing to do with what I might want to quote in
> reply, so having to undo it just causes me extra work for no gain.
>
Try C-g before you reply.
--
Anders
Mark T. B. Carroll
> Try C-g before you reply.
Ah, cool, that works better and makes it, from my point of view, a
smaller bug! (-: I'm getting the impression that there's no variable
I've missed to just turn it off, then.
(Some other kind soul suggested to me by e-mail that `S W' to reply
might help, at least until this feature infects that too.)
Mark
Ted Zlatanov
>> That's a feature, I'm not sure why it should be changed. Why is it
>> harmful?
MTBC> I copy and paste fragments of articles in checking them out in
MTBC> other applications, taking notes, etc. But then the selection has
MTBC> happened so when I get to replying, it just quotes a little bit of
MTBC> the article, so I have to undo the selection first, whether by
MTBC> going to some other article then back to that one, or using M-u to
MTBC> mark it unread, quit the group altogether, reenter it and go back
MTBC> to the article, or whatever. Maybe there's an easier way to get
MTBC> rid of the selection, but a high fraction of my selecting has
MTBC> nothing to do with what I might want to quote in reply, so having
MTBC> to undo it just causes me extra work for no gain.
On Wed, 02 Dec 2009 08:58:06 -0500 "Mark T. B. Carroll" <mt...@ixod.org> wrote:
MTBC> Anders Wirzenius <anders.w...@netikka.fi> writes:
>> Try C-g before you reply.
MTBC> Ah, cool, that works better and makes it, from my point of view, a
MTBC> smaller bug! (-: I'm getting the impression that there's no variable
MTBC> I've missed to just turn it off, then.
MTBC> (Some other kind soul suggested to me by e-mail that `S W' to reply
MTBC> might help, at least until this feature infects that too.)
Sorry, I thought you knew how to clear the selection. I really don't
think it needs to be turned off or that it's a bug from anyone's point
of view. If you feel strongly about it, perhaps you or someone else can
produce a patch to disable the feature on demand. It should be fairly
easy.
>> I think to correct that, the child process needs to disassociate itself
>> from Emacs as its parent and that's pretty complicated (requires C calls
>> that are not available in ELisp AFAIK).
MTBC> Oh, that's a bit unfortunate! What happens is it starts up a web
MTBC> browser, say, then I get reminded of or linked to other things I want to
MTBC> check out, and in the same session after a while I'm now looking at
MTBC> things that are nothing to do with what I originally launched from
MTBC> emacs. This is especially bad with things like web browers, Acrobat
MTBC> Reader, etc., where, when I view different things from outside emacs,
MTBC> those attempts to view things attach to the existing emacs-spawned
MTBC> process instead of spawning a new viewer, and then they want to die with
MTBC> an application that never had anything to do with them.
Yeah, that's annoying. You can do the disassociation in a
shell/Perl/etc. script. Also there are programs to launch the URL or
file in the OS's default URL handler, e.g. in Ubuntu there's a way to do
it. When you launch the URL or file that way, the handler won't be
associated with Emacs. With temporary files from a message attachment,
however, this won't work because they get deleted after the external
viewer is done. I personally use and prefer w3m so I don't experience
this issue.
Ted
Mark T. B. Carroll
(snip)
> Sorry, I thought you knew how to clear the selection. I really don't
> think it needs to be turned off or that it's a bug from anyone's point
> of view.
Now I think about it further, I think it unsettles me partly because
it's the first application I've used that breaks a rule I'd previously
internalized: that what I select to copy into the paste buffer isn't per
se input to any application I didn't paste it into. I'll get used to it,
I just didn't want to miss an easy way not to have to.
> You can do the disassociation in a shell/Perl/etc. script. Also there
> are programs to launch the URL or file in the OS's default URL
> handler, e.g. in Ubuntu there's a way to do it. When you launch the
> URL or file that way, the handler won't be associated with Emacs.
Ah, thank you, I just need an intermediate handler of some kind that can
do the disassociation. That might actually be worth to getting around
to. Some applications can remember what state they were in when they
were killed and then restore it, but things like Adobe Reader don't.
Mark
Ted Zlatanov
MTBC> Ted Zlatanov <t...@lifelogs.com> writes:
>> You can do the disassociation in a shell/Perl/etc. script. Also there
>> are programs to launch the URL or file in the OS's default URL
>> handler, e.g. in Ubuntu there's a way to do it. When you launch the
>> URL or file that way, the handler won't be associated with Emacs.
MTBC> Ah, thank you, I just need an intermediate handler of some kind that can
MTBC> do the disassociation. That might actually be worth to getting around
MTBC> to. Some applications can remember what state they were in when they
MTBC> were killed and then restore it, but things like Adobe Reader don't.
On Ubuntu you can install the `daemon' command (look at the man page to
see how complicated the process is, and you probably want it with the
-foreground option). There's a `detach' program to do a similar task as
well on other Unix systems.
Remember to copy the file in your script. The original temporary file
will be deleted when your script launches the child and exits. Here's
a 100% untested version:
#!/usr/bin/perl
use strict;
use warnings;
use File::Copy;
my $tf = "/tmp/temporary-$$";
copy($ARGV[0],$tf) or die "Copy of $ARGV[0] to $tf failed: $!";
# note the => is effectively a comma that quotes the left side
exec (daemon => -f => "your command here" => "argument1" => "argument2" => $tf);
Ted