`set-variable' should use :set

`set-variable' should use :set

[Drew Adams]

`set-variable' is in most respects a shortcut for using Customize to change an
option's value (for the current session - it does not save the value).  For
example, it uses the proper `interactive' spec and forces user input to be of
the correct defcustom :type.

However, it does not respect a defcustom :set.  I'm thinking that it should, so
that using `set-variable' would indeed be a proper shortcut for setting an
option value.

Am I missing something?  Is there some fundamental reason why we do not want to
do this or we should not do it?  Or is it just that we have never bothered to do
it?

If there is no special reason why we don't do it, then I think we should.  A
user should not encounter surprises due to :set not being invoked when using
`set-variable' and thus (perhaps important) value-change actions not being
carried out.

If we cannot, or for some reason should not, make such an enhancement, shouldn't
we at least warn the user that :set will not be invoked?  And perhaps require
confirmation after such a warning, before just setting the value?

WDOT?

Re: `set-variable' should use :set

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> However, it does not respect a defcustom :set.  I'm thinking that it should, so
> that using `set-variable' would indeed be a proper shortcut for setting an
> option value.

Sounds reasonable to me....

-miles

-- 
Vote, v. The instrument and symbol of a freeman's power to make a fool of
himself and a wreck of his country.

Re: `set-variable' should use :set

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
>> However, it does not respect a defcustom :set.  I'm thinking that it should, so
>> that using `set-variable' would indeed be a proper shortcut for setting an
>> option value.
>
> Sounds reasonable to me....

BTW, my vague impression is that `set-variable' is pretty lightly used,
maybe because it's not that much more convenient than just "M-: (setq..."

Making this change might make it a much more useful command...

-Miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

RE: `set-variable' should use :set

[Drew Adams]

> Sounds reasonable to me....
> 
> BTW, my vague impression is that `set-variable' is pretty 
> lightly used, maybe because it's not that much more convenient
> than just "M-: (setq..."
> 
> Making this change might make it a much more useful command...

That's also my vague impression.
And I agree that this might help.

However, I disagree that it is not that much more convenient than setq.  For one
thing, it respects the defcustom :type spec.  For another, it uses a proper
interactive spec.  The type-checking in particular is a win, IMO.

(FWIW, I use it often.)

RE: `set-variable' should use :set

[Stephen J. Turnbull]

Drew Adams writes:

 > However, I disagree that [set-variable] is not that much more
 > convenient than setq.  For one thing, it respects the defcustom
 > :type spec.  For another, it uses a proper interactive spec.  The
 > type-checking in particular is a win, IMO.

I don't find either of those noticable.  Except when type-checking
conflicts with the lack of :set support, which can be confusing.

 > (FWIW, I use it often.)

I'm curious, what are your use cases?  When I find myself using
set-variable (more likely, setq), it's invariably a symptom of a
defect in my environment: a command is missing an argument, an
initialization function is DT wrong T.  In fact, I often do

M-: (setq foovar barval) RET
;; experiment
M-: C-p C-a C-k C-g
M-x find-function RET foo RET <mouse-2> C-j

which makes "M-: (setq ..." an effective, rather than annoying, idiom.

RE: `set-variable' should use :set

[Drew Adams]

>  > However, I disagree that [set-variable] is not that much more
>  > convenient than setq.  For one thing, it respects the defcustom
>  > :type spec.  For another, it uses a proper interactive spec.  The
>  > type-checking in particular is a win, IMO.
> 
> I don't find either of those noticable.

1. Type-checking is noticeable in that you cannot enter a value whose type
conflicts with the defcustom type.  With `setq' you can.  (The type mismatch
error message should be more helpful, however, instead of just saying "Value
`VAL' does not match type choice of OPTION".)

But I'm not trying to convince anyone to use `set-variable'.
It's fine if you don't find it useful.


2. The interactive reading of a value by `set-variable' depends on the variable
having a `variable-interactive' property.  I use that property in my own code,
but vanilla Emacs does not anymore.  (There are exactly 3 variables left in all
of the vanilla Lisp sources that have this property: `tags-file-name',
`sgml-transformation-function', and `skeleton-transformation-function'.)  So I'm
not surprised that you don't find it noticeable. ;-)

Try, for instance, `M-x set-variable tags-file-name' and compare the behavior
with that of `M-x set-variable custom-file'.  The former gives you file-name
completion.  The latter gives you nada.  That's a noticeable difference.

So yes, I would also BTW suggest that we use property `variable-interactive'
more.  Or better yet make Customize automatically DTRT, at least in the simple
cases (e.g. automatically set that property, or provide the behavior in some
other way), so that `set-variable' is helpful with the values of most user
options (not just 3!).

Even many defcustom `choice' types could be made accessible using completion.
Obviously `const' choices could, and even a type like `function' could, allowing
completion against known function names.  (The completion would be non-strict,
letting you enter a lambda form etc.)  `set-variable' could at least be made to
offer the degree of interactive help (e.g. completion) that is provided for
value-editing in Customize.

I never understood why this feature was abandoned.  The doc (`(elisp) Defining
Variables') says:

"If a user option variable has a `variable-interactive' property, the
`set-variable' command uses that value to control reading the new value
for the variable.  The property's value is used as if it were specified
in `interactive' (*note Using Interactive::).  However, this feature is
largely obsoleted by `defcustom' (*note Customization::)."

That last part is a bit presumptuous, IMHO.  Perhaps it means to say only that
`set-variable' is largely obsolete (although I don't see why it would be - it is
quick; Customize is not).  ("Obsolete" is not a verb BTW (e.g. "obsoleted"),
although it is true that you can verb any noun.)

But it seems to also be suggesting that Customize replaces `set-variable's
reading of a value according to an `interactive' spec, which it does not.

Customize sometimes lets you use completion when editing an option value,
granted.  But if you have to enter the jungle of Customize and survive to come
out the other side in order to get the benefit of an `interactive' spec (editing
the value) then I'd say that some of that benefit has been lost.  Just an
opinion.  One person's loss is another person's obsolete. ;-)

(Tomorrow morning some earnest soul will no doubt remove those 3 vestigial
`variable-interactive' properties in a cleanup sweep to purge the code once and
for all...)

>  > (FWIW, I use it often.)
> 
> I'm curious, what are your use cases?

As I said before, more or less the same use cases as using Customize to set a
value (without saving it):

 `M-x customize-option'
 Edit value or choose value using menu.
 Click `Set for this session'.
 `q'

When might one use Customize instead of setq?  I do it when I want to test
things that involve various option menu values, or when the option value is
somewhat complex.  Sometimes I'll keep a particular Customize buffer open in a
separate frame and make various value changes while testing things.

And setting a value using Customize instead of setq can help when I don't recall
the exact structure of the value (the custom :type).

`set-variable' is quicker for this than Customize.  It offers some of what
Customize offers but is as quick as setq.  However, it helps with the value
reading only if propery `variable-interactive' is set.  And again, it would help
more with the type if the mismatch error were more informative.

Let me be clear: by "often" I don't mean that I use `set-variable' every 3
minutes.  But I do use it fairly often instead of entering Customize or using
setq.

I also use other, non-vanilla commands to increment a numerical option, toggle
any binary option (not just custom-type `boolean'), and so on.

I use this kind of thing more than some people perhaps because I use Emacs to
develop and test Emacs-Lisp code more than I use Emacs for other things.  (The
only thing Emacs is good for is Emacs...but that's a lot.)

Also, I don't necessarily treat user options as things to be set once in a blue
moon and persist.  I don't mind commands that change option values, even
incrementally/dynamically.  Even if an option were never persisted its typing
would still be a useful feature.  I take advantage of both the typing and the
persistence of Emacs options without always treating them as statically as
others do.

I even proposed that Emacs allow for (i.e., optionally) typing non-option vars.
That suggestion was summarily dismissed by you - the sole responder, with the
single word "YAGNI".
http://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html

We have different views of Emacs and its features.  That's OK.  YAGNI.  But IUI.
 

RE: `set-variable' should use :set

[Stephen J. Turnbull]

Drew Adams writes:

 > That last part is a bit presumptuous, IMHO.  Perhaps it means to
 > say only that `set-variable' is largely obsolete (although I don't
 > see why it would be - it is quick; Customize is not).

You've simply identified an optimization that isn't premature.
Congratulations!

OK, point made.  But I don't really understand why customize-variable
needs to be any slower than set-variable.

 > ("Obsolete" is not a verb BTW (e.g. "obsoleted"), although it is
 > true that you can verb any noun.)

Don't tell me that, submit a patch. ;-)

 > > I'm curious, what are your use cases?
 > 
 > As I said before, more or less the same use cases as using Customize to set a
 > value (without saving it):

That's not a use case.  Which variables?  As I wrote, I don't see a
need for this, but maybe I just don't mess with the same variables
that you do.

 > Also, I don't necessarily treat user options as things to be set
 > once in a blue moon and persist.

Well, neither do I.  For example, I might toggle debug-on-error or
debug-on-signal a dozen times in a session.  But since I do, those
toggles live on C-c D E and C-c D S respectively, along with a number
of other debugging utilities I use frequently in the C-c D keymap.
set-variable kind of pales in comparision.

OTOH, if I do something infrequently enough that I'd forget the key
sequence I bound it to, customize-variable would do the trick.

So it sounds to me like you must do a lot of experimenting with
various options, and in that context I can see where set-variable
would hit a sweet spot.  I have no objection to you writing -- and
maintaining -- variable-interactive declarations for any variables you
care to, but I ain't gonna do it myself unless there's a lot more
support for it from typical users.

 > I even proposed that Emacs allow for (i.e., optionally) typing
 > non-option vars.  That suggestion was summarily dismissed by you -
 > the sole responder, with the single word "YAGNI".
 > http://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html
 > 
 > We have different views of Emacs and its features.  That's OK.
 > YAGNI.  But IUI.

That's not true, though.  Maybe YWUI, but you admitted in that post
that you have no implementation and don't intend to create one, and
evidently even less intention to maintain a few thousand
variable-interactive or type declarations.  And that's the rub.

If (as you suggest) set-variable could be made to use Customize
descriptions without losing its speed, that would be reasonable.  But
duplicating the effort makes no sense.  Similarly, the typing code
clashes with the (alleged) intent of Emacs Lisp to be lightweight (at
least compared to Common Lisp).  So while your suggestions have merit
in themselves, I don't see them fitting with Emacs philosophy very
well.

Re: `set-variable' should use :set

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 21 Oct 2010 18:11:34 -0700
> Cc: 'Emacs-Devel devel' <emacs-devel@gnu.org>
> 
> However, I disagree that it is not that much more convenient than setq.  For one
> thing, it respects the defcustom :type spec.  For another, it uses a proper
> interactive spec.  The type-checking in particular is a win, IMO.

To say nothing of the fact that set-variable provides completion,
while M-: does not.

Re: `set-variable' should use :set

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 22 Oct 2010 11:20:57 +0900
> Cc: 'Emacs-Devel devel' <emacs-devel@gnu.org>, 'Miles Bader' <miles@gnu.org>
> 
>  > (FWIW, I use it often.)
> 
> I'm curious, what are your use cases?

Random testing.  E.g., someone reports a certain behavior with a
non-default setting, or I learn about a new option and want to try it
for a while, then revert back if I don't like it.  Also, some unusual
situations that I don't expect to repeat too often, like a file with
unusually long lines that defeats line-number-mode.

Re: `set-variable' should use :set

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > To say nothing of the fact that set-variable provides completion,
 > while M-: does not.

M-TAB works for me.

Re: `set-variable' should use :set

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Drew Adams writes:
>
>  > That last part is a bit presumptuous, IMHO.  Perhaps it means to
>  > say only that `set-variable' is largely obsolete (although I don't
>  > see why it would be - it is quick; Customize is not).
>
> You've simply identified an optimization that isn't premature.
> Congratulations!
>
> OK, point made.  But I don't really understand why customize-variable
> needs to be any slower than set-variable.
>
>  > ("Obsolete" is not a verb BTW (e.g. "obsoleted"), although it is
>  > true that you can verb any noun.)
>
> Don't tell me that, submit a patch. ;-)

<URL:http://www.merriam-webster.com/dictionary/obsolete>


2obsolete
vt
obsolet·ed obsolet·ing
Definition of OBSOLETE
: to make obsolete
First Known Use of OBSOLETE
1640

-- 
David Kastrup

Re: `set-variable' should use :set

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Drew Adams <drew.adams@oracle.com>,
>     emacs-devel@gnu.org,
>     miles@gnu.org
> Date: Fri, 22 Oct 2010 17:16:27 +0900
> 
> Eli Zaretskii writes:
> 
>  > To say nothing of the fact that set-variable provides completion,
>  > while M-: does not.
> 
> M-TAB works for me.

M-TAB is taken by the window manager.  (And no, I don't want to remap
it.)  And ESC-TAB is too inconvenient.

Re: `set-variable' should use :set

[Juanma Barranquero]

On Fri, Oct 22, 2010 at 06:34, Drew Adams <drew.adams@oracle.com> wrote:

>  ("Obsolete" is not a verb BTW (e.g. "obsoleted"),

It is, according at least to

- Free Merriam-Webster: http://mw1.m-w.com/dictionary/obsoleted
- Webster's Revised Unabridged Dictionary:
http://machaut.uchicago.edu/?resource=Webster%27s&word=obsolete

Note that the second one is a reference from the 1913 edition, so it
is not even new. The Recency Illusion
(http://en.wikipedia.org/wiki/Recency_illusion) may be in play here.

    Juanma

RE: `set-variable' should use :set

[Drew Adams]

> >  ("Obsolete" is not a verb BTW (e.g. "obsoleted"),
> 
> It is, according at least to
> 
> - Free Merriam-Webster: http://mw1.m-w.com/dictionary/obsoleted
> - Webster's Revised Unabridged Dictionary:
> http://machaut.uchicago.edu/?resource=Webster%27s&word=obsolete

Oh, fun.

The first of those URLs claims that as a verb it is (only) transitive ("You
obsoleted the bike"). The second of those claims that as a verb it is (only)
intransitive ("You obsoleted, but the bike obsoleted first").

It is not an intransitive verb according to the first URL, and it is not a
transitive verb according to the second.  Abracadabra, by Web dictionary
addition it is neither transitive nor intransitive - call it "interesting". ;-)

Anyway, if you're happy with "obsoleted" in the doc it's A OK by me.  My remark
was parenthetical and qualified with a "BTW".  IOW, it's beside the point.

And as I said (quite earnestly), you _can_ verb any noun.  There is no Academie
Anglaise[*]; we take a different view of language (and dictionaries).

So please, manual any words you like, whether or not they can be successfully
dictionaried.  A dictionary does not a word make - we make em.
http://www.socialmeteor.com/2009/09/02/facebook-a-verb-thats-whats-happenin/,
http://www.guardian.co.uk/books/2008/jul/05/saturdayreviewsfeatres.guardianrevie
w, etc.

Most important is clarity, and I find "However, this feature is largely
obsoleted by `defcustom'" quite clear as far as it goes (it doesn't say why or
how).

My objection to it was a disagreement with what it claims, not how it makes the
claim.  And I was clear that even that objection is minor - I find it only "a
bit" presumptuous to pretend that Customize replaces `set-variable'.

Customize obsoletes `set-variable' the same way stalking and killing your own
deer, cleaning it, transporting it, and stewing it obsoletes just grabbing a
bowl of venison stew at the hunting lodge.  Customize is an adventure;
`set-variable' is sans drama.

But at least we've escaped the proposal, and without ever needing to proposal
the escape. ;-)

[* At least there was not an Acadamie Anglaise until this summer.
http://www.macmillandictionaryblog.com/lacademie-anglaise.  Leave it to the
royals to stand up straight for such silliness - Rule Britannia!  On n'arrete
pas le progres.]

Re: `set-variable' should use :set

[Stefan Monnier]

I'm surprised that this discussion compares customize-variable and
set-variable: obviously set-variable has a completely different UI which
means that customize-variable cannot replace it.

But there is also customize-set-variable, which is what we should
compare it against.  So I think Drew wants set-variable and
customize-set-variable to be made more similar.  I would agree and
I think we should merge them.
I would also suggest that it's a good opportunity to obsolete
variable-interactive.


        Stefan

Re: `set-variable' should use :set

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> >  ("Obsolete" is not a verb BTW (e.g. "obsoleted"),
>> 
>> It is, according at least to
>> 
>> - Free Merriam-Webster: http://mw1.m-w.com/dictionary/obsoleted
>> - Webster's Revised Unabridged Dictionary:
>> http://machaut.uchicago.edu/?resource=Webster%27s&word=obsolete
>
> Oh, fun.
>
> The first of those URLs claims that as a verb it is (only) transitive ("You
> obsoleted the bike"). The second of those claims that as a verb it is (only)
> intransitive ("You obsoleted, but the bike obsoleted first").

The second is from 1913.  The first is current.  Since Emacs 19.13 has
been obsolete for quite a while, I'd go with the latter, namely the
first.

> Customize obsoletes `set-variable' the same way stalking and killing
> your own deer, cleaning it, transporting it, and stewing it obsoletes
> just grabbing a bowl of venison stew at the hunting lodge.  Customize
> is an adventure; `set-variable' is sans drama.

Until you picked up the slack.

-- 
David Kastrup

RE: `set-variable' should use :set

[Drew Adams]

> I think Drew wants set-variable and customize-set-variable
> to be made more similar.  I would agree and I think we should
> merge them.  I would also suggest that it's a good opportunity
> to obsolete variable-interactive.

Yes, that all sounds good to me.

But the last part would hopefully entail automatically getting the equivalent of
`variable-interactive' from the custom type (e.g. along the lines I suggested).

And hopefully the type-checking would give you a better error message than the
generic "Value does not match number type".

And there is potential synergy between those two.
If, for example the :type is:

(alist
  :key-type (string :tag "Sort order")
  :value-type (choice :tag "Type"
               (const    :tag "None (do not sort)" nil)
               (function :tag "Sorting predicate")
               (list     :tag "Sorting multi-predicate"
                (repeat (function :tag "Component pred"))
                (choice :tag "Final predicate?"
                 (const    :tag "None" nil)
                 (function :tag "Predicate")))))

Then the interactive spec could allow completion or other appropriate input
methods (e.g. reading a number) for each of the parts in turn, type-checking it
individually.  If tags are present they could be used in the prompts.  Example:

1. "Sort order: "      no completion (string)

2. "Type: "            completion with candidates:
                        `None (do not sort)'
                        `Sorting predicate'
                        `Sorting multi-predicate'

3. Supposing `Sorting multi-predicate' was chosen:

   "Component pred: "  lax completion on fboundp symbols
   "Component pred: "  ... until empty input (for example)
   
4. "Final predicate? " completion with candidates:
                        `None', `Predicate'

5. Supposing `Predicate' was chosen:

   "Predicate: "       lax completion on fboundp symbols

If a tag is not provided, then the immediate type name would be used in its
place - e.g. "function: " if there were no tag "Sorting predicate".

This could go a long way toward helping, including dealing with typing mistakes
(in both senses of the word).  Currently, you're on your own coming up with a
proper Lisp sexp that fits the custom type - e.g. (("My Sort 1" (info-cp gnus-cp
file-cp) alpha-p)).  Currently the prompt just punts: "[alist] Set customized
value for ___ to: ".

Yes, use of such a `(customize-)set-variable' command would obviously be better
for simple custom types than for complex ones like this.  If the type is quite
complex then it can be easier/clearer to enter Customize and deal with it there.

The example is meant to show that _even_ complex types could be handled in a
relatively straightforward way.  Users might well prefer to enter Customize for
such a type rather than answer a series of voice-mail-hell-like prompts.  But
for simpler types avoiding Customize would be a worthwhile.

Essentially, the idea is that `(customize-)set-variable' would offer a (helpful)
minibuffer UI as an alternative to entering Customize in order change an option
value.

The point is that we could do better than just prompt for a complete "[alist] "
value in one shot.  We could offer a reasonable way to input each of the value
components, providing completion as appropriate.  Each part would be
type-checked on its own, letting users know just where they go wrong when
inputting.

And for times when you really want to input a fancy sexp and you prefer using
such a command to using setq (so you get type-checking), we could let `C-u' give
you the all-or-nothing "[alist] " prompt offered today.

Re: `set-variable' should use :set

[Juanma Barranquero]

On Fri, Oct 22, 2010 at 15:40, Drew Adams <drew.adams@oracle.com> wrote:

> The first of those URLs claims that as a verb it is (only) transitive ("You
> obsoleted the bike"). The second of those claims that as a verb it is (only)
> intransitive ("You obsoleted, but the bike obsoleted first").

First one is more modern.

> And as I said (quite earnestly), you _can_ verb any noun.  There is no Academie
> Anglaise[*]; we take a different view of language (and dictionaries).

I know.

> Most important is clarity, and I find "However, this feature is largely
> obsoleted by `defcustom'" quite clear as far as it goes (it doesn't say why or
> how).

I find it quite clear too.

    Juanma

Re: `set-variable' should use :set

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > > Most important is clarity, and I find "However, this feature is
 > > largely obsoleted by `defcustom'" quite clear as far as it goes
 > > (it doesn't say why or how).
 > 
 > I find it quite clear too.

Clear, yes.  I personally think it's ugly and awkward, the kind of
usage a tasteless engineer[1] would invent.  I would hope that Emacs
aspires to a higher, more literary standard.  That's why I suggested
Drew contribute a patch, not as an indirect way of asking him to shut
up.  (The smiley was because I expected the response he produced: a
few hundred words on emacs-devel and no patch.)

I don't think that clarity is sufficiently important that we should
say "if it's clear, ship it."  Precision in natural language is as
important as precision in formal languages.  I don't have an issue
with efficient use of one's time; if you happen to be a tasteless
engineer, your contribution will be in elegant code, not elegant
docs.  Clarity is the sine qua non, and that's what you should aim for
if getting even that is a struggle.

But a superior application will have elegant docs, which the user will
appreciate far more than elegant code.  (Of course neither holds a
candle to elegant UI.)

Footnotes: 
[1]  The adjective is not redundant.

RE: `set-variable' should use :set

[Drew Adams]

> > > quite clear as far as it goes (it doesn't say why or how).
> >
> > I find it quite clear too.
> 
> Clear, yes.  I personally think it's ugly and awkward, the kind of
> usage a tasteless engineer[1] would invent.  I would hope that Emacs
> aspires to a higher, more literary standard.

Good to hear.  Patch welcome. ;-)

(But higher yes, more literary, no.  It's not about being literary - depending
on what is meant by that term.  No, don't bother to send dictionary citations.
;-))

> That's why I suggested Drew contribute a patch

Ditto.  Your patch is welcome, to raise Emacs to a higher standard.

But it seems we both prefer, at least in some such trivial cases, to teach
fishing rather than grab the pole and pull an already caught fish on board.  I
placed the fish firmly on the hook this time.  It's really not difficult to reel
it in.

What's missing is the will to do so, which apparently depends on agreement that
this fish is a worthy one.  Or even a that it is truly a fish!  Submitting
patches does no more good here than pointing out clearly what is wrong.  Believe
me (or not).

> I don't think that clarity is sufficiently important that we should
> say "if it's clear, ship it."  Precision in natural language is as
> important as precision in formal languages.

Clarity goes hand in hand with preciseness (and completeness and
correctness...), but yes, there are degrees.  We agree about their importance, I
believe.  Clarity is about understanding, but understanding something that was
not expressed precisely can mean misunderstanding what was meant.

> But a superior application will have elegant docs, which the user will
> appreciate far more than elegant code.  (Of course neither holds a
> candle to elegant UI.)

Agreed again.  Elegant UI can reduce or even eliminate the need for docs,
elegant or otherwise.  And BTW, "UI" here includes APIs (e.g. names of packages,
routines, and parameters), for users who are developers.

But we are now far afield of "`set-variable' should use :set".
It should, BTW. ;-)

Re: `set-variable' should use :set

[Juanma Barranquero]

On Sat, Oct 23, 2010 at 18:13, Drew Adams <drew.adams@oracle.com> wrote:

> But it seems we both prefer, at least in some such trivial cases, to teach
> fishing rather than grab the pole and pull an already caught fish on board.  I
> placed the fish firmly on the hook this time.  It's really not difficult to reel
> it in.
>
> What's missing is the will to do so, which apparently depends on agreement that
> this fish is a worthy one.  Or even a that it is truly a fish!  Submitting
> patches does no more good here than pointing out clearly what is wrong.  Believe
> me (or not).
>

I'm really interested in knowing whether I'm the only one who finds
this comment quite patronizing...

(I'm not offended, so this is not a request for apologies, but a
genuine question.)

    Juanma

Re: `set-variable' should use :set

[Glenn Morris]

Juanma Barranquero wrote:

> I'm really interested in knowing whether I'm the only one who finds
> this comment quite patronizing...

patronizing and much else besides.

By the way, this entire thread is just a low signal-to-noise duplicate
of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6578.

At least I can read that one without feeling nauseous.

Re: `set-variable' should use :set

[Jambunathan K]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Oct 23, 2010 at 18:13, Drew Adams <drew.adams@oracle.com> wrote:
>
>> But it seems we both prefer, at least in some such trivial cases, to teach
>> fishing rather than grab the pole and pull an already caught fish on board.  I
>> placed the fish firmly on the hook this time.  It's really not difficult to reel
>> it in.
>>
>> What's missing is the will to do so, which apparently depends on agreement that
>> this fish is a worthy one.  Or even a that it is truly a fish!  Submitting
>> patches does no more good here than pointing out clearly what is wrong.  Believe
>> me (or not).
>>
>
> I'm really interested in knowing whether I'm the only one who finds
> this comment quite patronizing...
>

I find the discussion unquestionably amusing and entertaining. Being new
to the list, I am overwhelmed (at times) by it's ground realities.

> (I'm not offended, so this is not a request for apologies, but a
> genuine question.)
>
>     Juanma

A disillusioned visitor,
Jambunathan K.

Re: `set-variable' should use :set

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Oct 23, 2010 at 18:13, Drew Adams <drew.adams@oracle.com> wrote:
>
>> But it seems we both prefer, at least in some such trivial cases, to
>> teach fishing rather than grab the pole and pull an already caught
>> fish on board.
>
> I'm really interested in knowing whether I'm the only one who finds
> this comment quite patronizing...

The fishing analogy is hopelessly shopworn, anyway.  I much prefer Terry
Pratchet's version: "set a man on fire, and he is warm for the rest of
his life."