Malformed interactive spec in replace.el

Malformed interactive spec in replace.el

[Juanma Barranquero]

In query-replace-regexp-eval:
replace.el:289:4:Warning: malformed interactive spec: (interactive
    (barf-if-buffer-read-only) (let* ((from (let
    ((query-replace-to-history-variable nil)) (query-replace-read-from "Query
    replace regexp" t))) (to (list (read-from-minibuffer (format "Query
    replace regexp %s with eval: " (query-replace-descr from)) nil nil t
    query-replace-to-history-variable from t)))) (replace-match-string-symbols
    to) (list from (car to) current-prefix-arg (if (and transient-mark-mode
    mark-active) (region-beginning)) (if (and transient-mark-mode mark-active)
    (region-end)))))
Wrote c:/bin/emacs/HEAD/lisp/replace.elc

                                                                Juanma

Re: Malformed interactive spec in replace.el

[David Kastrup]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> In query-replace-regexp-eval:
> replace.el:289:4:Warning: malformed interactive spec: (interactive
>     (barf-if-buffer-read-only) (let* ((from (let
>     ((query-replace-to-history-variable nil)) (query-replace-read-from "Query
>     replace regexp" t))) (to (list (read-from-minibuffer (format "Query
>     replace regexp %s with eval: " (query-replace-descr from)) nil nil t
>     query-replace-to-history-variable from t)))) (replace-match-string-symbols
>     to) (list from (car to) current-prefix-arg (if (and transient-mark-mode
>     mark-active) (region-beginning)) (if (and transient-mark-mode mark-active)
>     (region-end)))))
> Wrote c:/bin/emacs/HEAD/lisp/replace.elc

That's a result of the recent disruptive changes of Stefan that were
seemingly checked in without discussion.

Could we restrict ourselves to changes that conceivably work towards
getting into a consistent state for the release?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Juanma Barranquero]

On 06 Jul 2004 10:35:45 +0200
David Kastrup <dak@gnu.org> wrote:

> That's a result of the recent disruptive changes of Stefan that were
> seemingly checked in without discussion.

I don't know about "disruptive changes".  I think in this case the
problem is something trivial, like a missing `progn'.

> Could we restrict ourselves to changes that conceivably work towards
> getting into a consistent state for the release?

This is an experiment: we're now trying to see whether we can "restrict
ourselves" into working to get a release out.  Perhaps we can (and more
power to us), and perhaps we cannot, and then, other models (like
branching for a release and leaving the trunk open for people who wants
to do new stuff) would be better.  It's a matter of group dynamics, and
much, I think, depends on the size and cohesion of the group.

But in any case I see no point in getting angry about the outcome :)


                                                                Juanma

Re: Malformed interactive spec in replace.el

[David Kastrup]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On 06 Jul 2004 10:35:45 +0200
> David Kastrup <dak@gnu.org> wrote:
> 
> > That's a result of the recent disruptive changes of Stefan that were
> > seemingly checked in without discussion.
> 
> I don't know about "disruptive changes".  I think in this case the
> problem is something trivial, like a missing `progn'.
> 
> > Could we restrict ourselves to changes that conceivably work towards
> > getting into a consistent state for the release?
> 
> This is an experiment: we're now trying to see whether we can "restrict
> ourselves" into working to get a release out.

And the way to do that is checking in completely new functionality
that changes existing APIs, replaces existing functionality by
something different without apparent need or discussion, and needs
additional work to get it documented, tried out, compared to the
behavior it replaces, and even just to work?

It is my opinion that such changes should at the very least be only
attempted if there is some consensus that they are unambiguously
desirable for the next release.  Our policy is feature freeze right
now.  "Policy" does not mean that exceptions are impossible, but then
we should have some consensus about them.

> Perhaps we can (and more power to us), and perhaps we cannot, and
> then, other models (like branching for a release and leaving the
> trunk open for people who wants to do new stuff) would be better.

So you claim this is just Stefan's way of suggesting he thinks we
should not concentrate on the release?

> It's a matter of group dynamics, and much, I think, depends on the
> size and cohesion of the group.
> 
> But in any case I see no point in getting angry about the outcome :)

I fail to see those changes as an "outcome" to an "experiment" trying
to see whether we can "restrict outselves into working to get a
release out".

It's like eating a cake as an experiment for checking whether one can
keep one's diet.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Juanma Barranquero]

On 06 Jul 2004 11:26:41 +0200
David Kastrup <dak@gnu.org> wrote:

> And the way to do that is checking in completely new functionality
> that changes existing APIs, replaces existing functionality by
> something different without apparent need or discussion, and needs
> additional work to get it documented, tried out, compared to the
> behavior it replaces, and even just to work?

No, of course not.

> Our policy is feature freeze right
> now.  "Policy" does not mean that exceptions are impossible, but then
> we should have some consensus about them.

I know.

> So you claim this is just Stefan's way of suggesting he thinks we
> should not concentrate on the release?

No.  What I "claim", if I do claim anything at all, is that in many
projects, the line between "bugfix" and "little feature" is vague and
that often people finds difficult to restrain themselves to what
everyone would unambiguously call "bugfixes".  (Of course, my comments
are *very emphatically* not referring to Stefan or anyone else in
particular.)

> I fail to see those changes as an "outcome" to an "experiment" trying
> to see whether we can "restrict outselves into working to get a
> release out".

I'm not talking about those changes.  I'm saying that, in the two or
three months we've been on pre-release mode, there's been quite a few
comments (mostly by RMS and you, IIRC) about the need to focus on the
release.  That would suggest that people is (at least, on your and RMS'
eyes) not doing it.  Doesn't that mean anything?

The only reason that I would put forth for advocating the development
trunk/release branch model is that we're just a bunch of people on
voluntary work.  That doesn't mean we cannot concentrate on releasing. 
But it's hard (if ever posible, or desirable) to push people one way or
other.

                                                                Juanma

Re: Malformed interactive spec in replace.el

[David Kastrup]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On 06 Jul 2004 11:26:41 +0200
> David Kastrup <dak@gnu.org> wrote:
> 
> > Our policy is feature freeze right now.  "Policy" does not mean
> > that exceptions are impossible, but then we should have some
> > consensus about them.
> 
> I know.
> 
> > So you claim this is just Stefan's way of suggesting he thinks we
> > should not concentrate on the release?
> 
> No.  What I "claim", if I do claim anything at all, is that in many
> projects, the line between "bugfix" and "little feature" is vague

It wasn't here as far as I was able to discern.

> > I fail to see those changes as an "outcome" to an "experiment" trying
> > to see whether we can "restrict outselves into working to get a
> > release out".
> 
> I'm not talking about those changes.  I'm saying that, in the two or
> three months we've been on pre-release mode, there's been quite a
> few comments (mostly by RMS and you, IIRC) about the need to focus
> on the release.  That would suggest that people is (at least, on
> your and RMS' eyes) not doing it.  Doesn't that mean anything?

You mean that when a team trainer or team mate is telling his players
to try harder, the conclusion should be that they all stop trying
because it appears it would take an effort to succeed?

> But it's hard (if ever posible, or desirable) to push people one way
> or other.

Reminding people of things we all agreed on is not "pushing" in my
book.  I know that I am responsible for a lot of recent post-freeze
movement of replace.el, and I start being sorry for it.  Not because
it was a bad idea to rather implement sensible additional semantics
in the normal replacement commands than document the more awkward
query-replace-regexp-eval, but because this has escalated from
implementing \, in the interactive regexp reader to adding \? as a
replacement for documenting the non-satisfactory \,(read-string) idea.

If I had not already documented all of this in the manual, I'd be
sorely tempted to rip everything except the basic \, out again since
it would appear that I have been setting a bad example, even though I
tried to reach consensus on the list about the immediate desirability
of those changes before checking them in.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Juanma Barranquero]

On 06 Jul 2004 12:31:31 +0200
David Kastrup <dak@gnu.org> wrote:

> It wasn't here as far as I was able to discern.

I've not followed the replace thread (my message was just to report a
tiny bug which caused a miscompilation), so I don't have an opinion
about that.

> You mean that when a team trainer or team mate is telling his players
> to try harder, the conclusion should be that they all stop trying
> because it appears it would take an effort to succeed?

No.  I mean what it would be good to know whether the team players are
all interested in playing the same game, at the same time, with the same
motivation :)

> Reminding people of things we all agreed on is not "pushing" in my
> book.

Perhaps I read this kind of things differently.  Every time I see a post
saying (with gentler wording, of course) "OK, I get what you're doing,
but, BTW, shouldn't you be doing such and such other thing" I feel the
pushing.

> If I had not already documented all of this in the manual, I'd be
> sorely tempted to rip everything except the basic \, out again since
> it would appear that I have been setting a bad example, even though I
> tried to reach consensus on the list about the immediate desirability
> of those changes before checking them in.

I don't think you've set a bad or good example.  More like you've done
what most of us are doing: concentrate on the release, but finding a bit
of trouble leaving aside our own pet projects or improvements.  But
that's only how I interpret it, of course.

                                                                Juanma

Re: Malformed interactive spec in replace.el

[David Kastrup]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On 06 Jul 2004 12:31:31 +0200
> David Kastrup <dak@gnu.org> wrote:
> 
> > If I had not already documented all of this in the manual, I'd be
> > sorely tempted to rip everything except the basic \, out again
> > since it would appear that I have been setting a bad example, even
> > though I tried to reach consensus on the list about the immediate
> > desirability of those changes before checking them in.
> 
> I don't think you've set a bad or good example.  More like you've
> done what most of us are doing: concentrate on the release, but
> finding a bit of trouble leaving aside our own pet projects or
> improvements.  But that's only how I interpret it, of course.

And it is not how I interpret it, since the changes were proposed and
implemented in the course of a discussion about whether
query-replace-regexp-eval is suitable at all for inclusion into the
manual which needed updating for the release.  My "own pet project"
was simply an attempt to make existing functionality accessible in a
form which would not be an embarrassment and awkwardness to document.
\? was more intrusive, but it was again an attempt of avoiding to
document basically useful, but completely awkward techniques (using
read-string in an evalled replacement expression asks at a completely
unconvenient time, and in an inconvenient manner).

And I tried to get people's opinion about those changes and patches
before installing them.  And cleaned up a number of bugs in the
process as well.  My "pet project" is a releasable state of Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Stefan]

> That's a result of the recent disruptive changes of Stefan that were
> seemingly checked in without discussion.

The "default Q&R to the same as last Q&R" was discussed thank you.
The "use regexp Q-R if M-% is hit while in regexp isearch" was discussed
thank you.
The "revert `initial'" was discussed thank you.

So please complain more constructively by telling me which part of my
changes is a disruptive change that was not discussed.  It might simply be
a bug I introduced, like the barf-if-buffer-read-only thingy.



        Stefan

Re: Malformed interactive spec in replace.el

[Juanma Barranquero]

On 06 Jul 2004 13:42:34 +0200
David Kastrup <dak@gnu.org> wrote:

> My "pet project" is a releasable state of Emacs.

OK.

                                                                Juanma

Re: Malformed interactive spec in replace.el

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

> > That's a result of the recent disruptive changes of Stefan that were
> > seemingly checked in without discussion.
> 
> The "default Q&R to the same as last Q&R" was discussed thank you.

Actually when I saw stuff like

+	      (read-from-minibuffer
+	       (if (and lastto lastfrom)
+		   (format "%s (default %s -> %s): " string
+			   (query-replace-descr lastfrom)
+			   (query-replace-descr lastto))
+		 (format "%s: " string))

I had dedicated that this was implementing the "use -> for shorthand
entry proposals" which it doesn't.  I was probably led astray by the
total amount of correlated changes that factor out
query-replace-read-args into different routines and similar.

> So please complain more constructively by telling me which part of
> my changes is a disruptive change that was not discussed.  It might
> simply be a bug I introduced, like the barf-if-buffer-read-only
> thingy.

Which would definitely count as "getting into releasable state".  So
it appears that I owe you an apology and/or a beverage of your choice.

I am probably too touchy about this issue because I increasingly get
the feeling that it was my involvement with replace.el that tempts
everybody to tack features onto it.  I hate feeling like pandora.  At
least that was the impression I gathered from the talks, and I only
checked very superficially what had happened in the actual code after
a bug report in the area "replace.el does not work anymore" came
through for which I felt responsible.

Sorry for that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Stefan]

> Which would definitely count as "getting into releasable state".  So
> it appears that I owe you an apology and/or a beverage of your choice.

There were some bug fixes in the changes I installed, but the "default to
foo -> bar" is definitely a "new feature" rather than a "bug fix".


        Stefan

Re: Malformed interactive spec in replace.el

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

> > Which would definitely count as "getting into releasable state".  So
> > it appears that I owe you an apology and/or a beverage of your choice.
> 
> There were some bug fixes in the changes I installed, but the "default to
> foo -> bar" is definitely a "new feature" rather than a "bug fix".

Well, there was discussion over it over the weekend while I was away.
Anyway, I don't think I want the query-replace prompt to take up four
staggered lines in case that my last replacement happened to be a
multi-line one.  Putting the stuff in some history where it will
appear on-demand is fine, but cluttering the prompt into 5 lines
because of some replacement I did hours ago does not feel like a good
idea to me.  And there is little point in displaying long things I
can't change, anyhow.  So either we should have a rather short
"(default to last)", or we should just rely on the user taking the
history to task.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Stefan <monnier@iro.umontreal.ca> writes:
> 
> > > Which would definitely count as "getting into releasable state".  So
> > > it appears that I owe you an apology and/or a beverage of your choice.
> > 
> > There were some bug fixes in the changes I installed, but the "default to
> > foo -> bar" is definitely a "new feature" rather than a "bug fix".
> 
> Well, there was discussion over it over the weekend while I was away.
> Anyway, I don't think I want the query-replace prompt to take up four
> staggered lines in case that my last replacement happened to be a
> multi-line one.  Putting the stuff in some history where it will
> appear on-demand is fine, but cluttering the prompt into 5 lines
> because of some replacement I did hours ago does not feel like a good
> idea to me.  And there is little point in displaying long things I
> can't change, anyhow.  So either we should have a rather short
> "(default to last)", or we should just rely on the user taking the
> history to task.

P.S.: taking a look at the code I noticed that you quote control
characters.  I still don't want large replacements from hours ago
appearing in my prompt.  Prompted defaults are for reasonable
guesses, like the current buffer, function, thing-at-point.  The last
replacement is not a reasonable guess.  If I wanted to continue the
last replacement unchanged, I would have used C-r in between and not
have exited the search.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Stefan]

> If I wanted to continue the last replacement unchanged, I would have used
> C-r in between and not have exited the search.

The "default to last" is completely unrelated to isearch.  C-s or C-r
wouldn't help one bit.


        Stefan

Re: Malformed interactive spec in replace.el

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

> > If I wanted to continue the last replacement unchanged, I would have used
> > C-r in between and not have exited the search.
> 
> The "default to last" is completely unrelated to isearch.  C-s or C-r
> wouldn't help one bit.

C-r is bound to recursive-edit in query-replace-map.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Stefan]

>> > If I wanted to continue the last replacement unchanged, I would have used
>> > C-r in between and not have exited the search.
>> 
>> The "default to last" is completely unrelated to isearch.  C-s or C-r
>> wouldn't help one bit.

> C-r is bound to recursive-edit in query-replace-map.

Oh, thanks for correcting me.  I now see what you meant.
But I don't think it's an option in my typical usage:

   M-% foo RET bar RET y y !
   ...do other things...
   M-% RET !
   ...do other things...
   M-% RET !

After I hit ! I don't get a chance to enter recursive edit.


        Stefan "who never used C-r in Q&R"

Re: Malformed interactive spec in replace.el

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

> >> > If I wanted to continue the last replacement unchanged, I would have used
> >> > C-r in between and not have exited the search.
> >> 
> >> The "default to last" is completely unrelated to isearch.  C-s or C-r
> >> wouldn't help one bit.
> 
> > C-r is bound to recursive-edit in query-replace-map.
> 
> Oh, thanks for correcting me.  I now see what you meant.
> But I don't think it's an option in my typical usage:
> 
>    M-% foo RET bar RET y y !
>    ...do other things...
>    M-% RET !

But where would any occurences of "foo" come from?  You replaced all
of them already.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Malformed interactive spec in replace.el

[Stefan]

>> M-% foo RET bar RET y y !
>> ...do other things...
>> M-% RET !

> But where would any occurences of "foo" come from?  You replaced all
> of them already.

Other buffer?  Other region? ...


        Stefan

Re: Malformed interactive spec in replace.el

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

> >> M-% foo RET bar RET y y !
> >> ...do other things...
> >> M-% RET !
> 
> > But where would any occurences of "foo" come from?  You replaced all
> > of them already.
> 
> Other buffer?  Other region? ...

C-x ESC ESC RET will work fine in those cases.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum