headers
Stefan Monnier | 1 Sep 2009 01:32
Picon

Re: turning on minor modes from hooks

>>> A call with no arguments, as in (auto-save-mode), naturally ought to
>>> toggle the mode or turn it on.
>> Care to explain why?
> Note that he said "or turn it on"; I think the point was to distinguish
> those possibilities from "unconditionally turn it off".

Toggling is just wrong for it.  I understand why it's like this right
now, but from an Lisp point of view, it's just not the right choice, and
there's no need here to distinguish a nil arg from the absence of an arg.

        Stefan
Permalink | Reply | 1 comment |
headers
Stefan Monnier | 1 Sep 2009 01:43
Picon

Re: turning on minor modes from hooks

>> Stephen has long advocated that non-interactive invocation of mode
>> commands should always turn on the mode instead of toggling.
> Isn't magically changing behavior between the interactive and
> non-interactive cases a Bad Thing?

There's no magic involved: if you call (call-interactively 'foo-mode)
it will toggle just fine, but you have no reason to presume that this is
equivalent to (foo-mode).  And indeed it's not.

        Stefan
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Sep 2009 01:47
Picon

Re: using libmagic in Emacs?

> No one has yet explained why we shouldn't deal with such failures by
> simply fixing Emacs' file detection, instead of relying on libmagic or

Because we don't want to keep reinventing the wheel, do we?

        Stefan
Permalink | Reply | 2 comments |
headers
Stefan Monnier | 1 Sep 2009 01:49
Picon

Re: [Emacs-diffs] emacs/lisp image.el

>> Then we should perhaps obsolete `image-jpeg-p' (which is not used
>> anymore in the sources).
>> 
>> Currently it does what its docstring says, but there's some of a
>> mismatch with the name (which seems to imply more generality); also it
>> is not clear what purpose does serve a function to detect just
>> JFIF/Exif JPEGs. And generalizing it would turn it into a trivial
>> two-liner.

> Gerd, do you remember the original rationale for image-jpeg-p?

I have a the vague impression that it's linked to the long discussion we
had about safety and other such things linked to the use of magic-* in
preference to auto-mode-alist, so we wanted to avoid false positives.

        Stefan
Permalink | Reply | 1 comment |
headers
Stefan Monnier | 1 Sep 2009 01:56
Picon

Re: interactive-p and called-interactively-p

>       `interactive-p' has the advantage that it existed for a *very*
>     long time, whereas called-interactively-p is a new comer.

> It has existed only 5 years,

Yes, and during this time, compatibility to Emacs-21 and XEmacs was
still fairly important for unbundled packages, so it hasn't seen much
use outside of Emacs itself.

> but I think the important point is that its name fits its meaning.
> The name interactive-p does not correspond to its meaning, and users
> very often guess wrong about what it does.

This is clearly true, but while confusion has been common, it hasn't
been an actual problem either.  And in any case, as I mentioned, we
should rather encourage programmers to stay avoid from both of
those functions.

>> Perhaps we should make the name `interactive-p' obsolete and make
>> a new name, `from-user-input-p'.  This will eliminate the
>> confusion completely.

>     Even such a new name isn't very clear.  The only clear solution is to
>     use an additional argument passed from the interactive spec.
> In what sense is that the only clear solution?  I do not follow you here.

Because it makes it clear that you're distinguishing different notions
of "interactivity" (one of them being just "called via
call-interactively", the other being "directly called from the keyboard
rather than via a macro or some batch invocation").
(Continue reading)

Permalink | Reply | 12 comments |
headers
Juanma Barranquero | 1 Sep 2009 02:05
Picon
Gravatar

Re: [Emacs-diffs] emacs/lisp image.el

On Tue, Sep 1, 2009 at 01:49, Stefan Monnier<monnier <at> iro.umontreal.ca> wrote:

> I have a the vague impression that it's linked to the long discussion we
> had about safety and other such things linked to the use of magic-* in
> preference to auto-mode-alist, so we wanted to avoid false positives.

But image-jpeg-p exists, and has been used in image-type-regexps, since 2001:

2001-08-08  Gerd Moellmann  <gerd <at> gnu.org>

        * image.el (image-type-regexps): Allow predicates.  Change the way
        JPEG images are recognized.
        (image-jpeg-p): New function.
        (image-type-from-data): Handle predicates in image-type-regexps.

It was, apparently, never intended to be anything but a helper for
image-type-regexps.

The discussion you're talking about is much more recent, isn't? (2005
or 2006, I think.)

    Juanma
Permalink | Reply | 0 comments |
headers
Miles Bader | 1 Sep 2009 02:17
Picon
Gravatar

Re: turning on minor modes from hooks

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>> A call with no arguments, as in (auto-save-mode), naturally ought to
>>>> toggle the mode or turn it on.
>>> Care to explain why?
>>
>> Note that he said "or turn it on"; I think the point was to distinguish
>> those possibilities from "unconditionally turn it off".
>
> Toggling is just wrong for it.

Right, but the second possibility, "turn it on" (and I interpreted that
to mean "unconditionally turn it on"), is right, and he _did_ say
"or"...

> I understand why it's like this right now, but from an Lisp point of
> view, it's just not the right choice, and there's no need here to
> distinguish a nil arg from the absence of an arg.

I agree that toggling is wrong for the elisp interface, but I disagree
with the rest of that -- as a programmer, (foo) and (foo nil) _do_ look
like entirely different things; the fact that they're conflated in elisp
seems like an implementation detail, not a design choice; it's generally
harmless, but on occasion can result in annoyingly counter-intuitive
interfaces.

In the case of mode functions, ideally I _could_ use (foo-mode) _or_
(foo-mode t) to turn on foo mode, and (foo-mode nil) to turn it off.
Those usages seem like the natural ones to me, given no implementation
constraints.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 Sep 2009 03:58
Favicon

Re: interactive-p and called-interactively-p

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> but I think the important point is that its name fits its meaning.
>> The name interactive-p does not correspond to its meaning, and users
>> very often guess wrong about what it does.
>
> This is clearly true, but while confusion has been common, it hasn't
> been an actual problem either.  And in any case, as I mentioned, we
> should rather encourage programmers to stay avoid from both of
> those functions.

I think the status quo is acceptable.  We already state, in the
doc-string of called-interactively-p, that you can do the same thing
with an interactive spec.  Further tinkering is just noise.
Permalink | Reply | 11 comments |
headers
Stephen J. Turnbull | 1 Sep 2009 04:07
Picon
Favicon

Re: turning on minor modes from hooks

Daniel Colascione writes:

 > Isn't magically changing behavior between the interactive and
 > non-interactive cases a Bad Thing?

No.  XEmacs inverts the (boolean) prefix arg in some cases where
experience shows that interactive usage by far favored the prefixed
version.  This was hotly opposed in theory, in practice everybody
loved it immediately.  It turned out that C-e and M-: (end-of-line) RET
are not aliases in our minds (YMMV), but rather synonyms, and we don't
have trouble making the subtle semantic distinction.  (NB, the command
in question isn't `end-of-line', but I don't remember which it is and
a quick grep shows that "invert" isn't the word used in the docstring.)

 > What about some kind of enable-minor-mode function?

If you mean a generic function that can enable specific minor modes,
that will just cause proliferation of definitions like

(defun turn-on-auto-fill () (enable-minor-mode 'auto-fill-mode))
(defun turn-off-auto-fill () (disable-minor-mode 'auto-fill-mode))
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Sep 2009 05:16
Picon

Re: using libmagic in Emacs?

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Mon, 31 Aug 2009 19:47:14 -0400
> Cc: juri <at> jurta.org, Eli Zaretskii <eliz <at> gnu.org>, rms <at> gnu.org, joakim <at> verona.se,
> 	emacs-devel <at> gnu.org
> 
> > No one has yet explained why we shouldn't deal with such failures by
> > simply fixing Emacs' file detection, instead of relying on libmagic or
> 
> Because we don't want to keep reinventing the wheel, do we?

What wheel is that?  Emacs has been consulting various internal
databases since time immemoriam.  We do the same with Unicode
databases as well.
Permalink | Reply | 1 comment |

Gmane