* [sup-talk] [PATCH] Add new :crypto_default configuration option.
@ 2009-09-28 22:57 Carl Worth
2009-10-01 17:07 ` William Morgan
0 siblings, 1 reply; 4+ messages in thread
From: Carl Worth @ 2009-09-28 22:57 UTC (permalink / raw)
For example, users that want to sign all outgoing messages by default
can set:
:crypto_default: :sign
in ~/.sup/config.yaml. Configuring an invalid value will cause a list
of the valid values to be logged at the "error" level.
---
lib/sup/horizontal-selector.rb | 8 +++++++-
lib/sup/modes/edit-message-mode.rb | 7 ++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/sup/horizontal-selector.rb b/lib/sup/horizontal-selector.rb
index aef16d4..13c63ed 100644
--- a/lib/sup/horizontal-selector.rb
+++ b/lib/sup/horizontal-selector.rb
@@ -12,7 +12,13 @@ class HorizontalSelector
@selection = 0
end
- def set_to val; @selection = @vals.index(val) end
+ def set_to val
+ if @vals.index(val)
+ @selection = @vals.index(val)
+ else
+ error "Invalid option ", val.inspect, " (valid options: ", @vals.inspect, ")"
+ end
+ end
def val; @vals[@selection] end
diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
index 8da316f..3449503 100644
--- a/lib/sup/modes/edit-message-mode.rb
+++ b/lib/sup/modes/edit-message-mode.rb
@@ -89,7 +89,12 @@ EOS
if CryptoManager.have_crypto?
HorizontalSelector.new "Crypto:", [:none] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.keys, ["None"] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.values
end
- add_selector @crypto_selector if @crypto_selector
+ if @crypto_selector
+ if !$config[:crypto_default].nil?
+ @crypto_selector.set_to $config[:crypto_default]
+ end
+ add_selector @crypto_selector
+ end
HookManager.run "before-edit", :header => @header, :body => @body
--
1.6.4.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090928/cc5a4c98/attachment.bin>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [sup-talk] [PATCH] Add new :crypto_default configuration option.
2009-09-28 22:57 [sup-talk] [PATCH] Add new :crypto_default configuration option Carl Worth
@ 2009-10-01 17:07 ` William Morgan
2009-10-01 17:31 ` Carl Worth
0 siblings, 1 reply; 4+ messages in thread
From: William Morgan @ 2009-10-01 17:07 UTC (permalink / raw)
I like the idea, but how about a hook instead? I think the reply-mode
hook is exactly equivalent to this. (Which maybe I will one day rename
to default-reply-mode.)
I have a strong aversion to adding configuration options.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [sup-talk] [PATCH] Add new :crypto_default configuration option.
2009-10-01 17:07 ` William Morgan
@ 2009-10-01 17:31 ` Carl Worth
2009-10-06 17:16 ` William Morgan
0 siblings, 1 reply; 4+ messages in thread
From: Carl Worth @ 2009-10-01 17:31 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu Oct 01 10:07:20 -0700 2009:
> I like the idea, but how about a hook instead? I think the reply-mode
> hook is exactly equivalent to this. (Which maybe I will one day rename
> to default-reply-mode.)
>
> I have a strong aversion to adding configuration options.
I'm intrigued.
What makes a hook preferable over a configuration option?
I've been getting concerned watching the number of hooks in sup grow
as each creates a maintenance burden. Either:
1. All hooks are supported forever with consistent
arguments/semantics, (which may make it more difficult to make
changes in sup than it would be otherwise)
OR:
2. Hooks are not supported forever, in which case users may find that
things just start working when upgrading.
Neither of those seem options look nice to me, and both seem easy to
avoid with configuration options.
If the plan is to go with (1) I'm concerned that I don't see sup
shipping documentation for the current possible hooks. (This applies
to configuration options too though. I think the maintainer should
reject patches that add either without also adding documentation to
the standard list.[*])
[*] Assuming the pre-condition of such documentation existing of
course.
On the other hand, I also dislike configuration options (and hooks,
equally), to the extent that they might be used as an excuse to avoid
putting the most sane and useful default functionality into sup
itself. Obviously, this can be complicated by some people not agreeing
on what the most sane and useful behavior is.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/55fc7ab2/attachment.bin>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [sup-talk] [PATCH] Add new :crypto_default configuration option.
2009-10-01 17:31 ` Carl Worth
@ 2009-10-06 17:16 ` William Morgan
0 siblings, 0 replies; 4+ messages in thread
From: William Morgan @ 2009-10-06 17:16 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Carl Worth's message of 2009-10-01:
> What makes a hook preferable over a configuration option?
I would like to support everyone's crazy desires, and a hook is worth a
thousand configuration options.
In this case, I'm sure it's only a matter of time before someone wants
to automatically determine the crypto setting based on the recipient, or
based on the message body. A hook would allow that.
> 2. Hooks are not supported forever, in which case users may find that
> things just start working when upgrading.
I am fine with this. Users be damned! (Or at least, required to read the
changelog.)
> Neither of those seem options look nice to me, and both seem easy to
> avoid with configuration options.
How so? Configuration options can change just as easily.
> If the plan is to go with (1) I'm concerned that I don't see sup
> shipping documentation for the current possible hooks. (This applies
> to configuration options too though. I think the maintainer should
> reject patches that add either without also adding documentation to
> the standard list.[*])
sup -l is supposed to produce all the hook documentation you'd need,
assuming a reasonable knowledge of Ruby.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-10-06 17:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-28 22:57 [sup-talk] [PATCH] Add new :crypto_default configuration option Carl Worth
2009-10-01 17:07 ` William Morgan
2009-10-01 17:31 ` Carl Worth
2009-10-06 17:16 ` William Morgan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox