* Re: replacing endline
2006-04-20 14:43 ` Fredrik Bulow
@ 2006-04-20 16:11 ` Lennart Borgman
2006-04-20 18:16 ` Eli Zaretskii
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Lennart Borgman @ 2006-04-20 16:11 UTC (permalink / raw)
Cc: help-gnu-emacs, Emacs Devel
Fredrik Bulow wrote:
>>> I don't see why this behavior shouldn't be labeled as a bug.
>>>
>> if you label that behavior as a bug, then you have introduced two
>> "bugs", not just one. the first bug is in your mental model of how
>> emacs should work, and the second, the one labeled as suggested. if
>> you pre-emptively fix the first bug, perhaps the second bug will, as a
>> result, vanish as well.
>>
>> applying the above thought process to various behaviors, you may
>> be able to find and remove many bugs in the future. good luck!
>>
>> thi
>>
>
> Thanks for that totally uncalled for insult.
If thi thinks there are two bugs then I think there are three now since
I agree with Fredrik. Or should it maybe be four thi, if perhaps you are
a bit wrong too?;-)
>
> So once again, what is the good reason that (query-replace "\n" "#")
> behave differenty than calling the same function with its keybinding
> and providing it interactively with the same arguments?
>
I also have difficulties understanding the prompting in cases like this.
I have nothing against the "C-q C-j" solution but it is not the first I
think of. Is there any reason not to just convert the input as needed so
that it in the interactive case works as Fredrik and I expect it to do?
This would make it easier at least for relative beginners. Could it be
done in such a way that it is still easy for those who are accustomed to
the current behaviour?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: replacing endline
2006-04-20 14:43 ` Fredrik Bulow
2006-04-20 16:11 ` Lennart Borgman
@ 2006-04-20 18:16 ` Eli Zaretskii
[not found] ` <mailman.650.1145549499.9609.help-gnu-emacs@gnu.org>
2006-04-20 23:38 ` B. T. Raven
3 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2006-04-20 18:16 UTC (permalink / raw)
> From: Fredrik Bulow <kaliumfredrik@gmail.com>
> Date: Fri, 21 Apr 2006 00:43:46 +1000
>
> So once again, what is the good reason that (query-replace "\n" "#")
> behave differenty than calling the same function with its keybinding
> and providing it interactively with the same arguments?
Is that an honest question, meaning that you _really_ don't know why
typing literally 2 characters `\' and `n' at the Emacs prompt doesn't
produce a newline, while the string "\n" does? Or do you know that,
but are suggesting that the former is a misfeature?
I'm sorry, but with all the fancy talk in this thread, one can no
longer no who sincerely wants to know and who is merely being
facetious.
^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <mailman.650.1145549499.9609.help-gnu-emacs@gnu.org>]
* Re: replacing endline
[not found] ` <mailman.650.1145549499.9609.help-gnu-emacs@gnu.org>
@ 2006-04-20 19:25 ` Harald Hanche-Olsen
2006-04-20 22:19 ` Lennart Borgman
[not found] ` <mailman.671.1145571606.9609.help-gnu-emacs@gnu.org>
2006-04-21 0:53 ` Thien-Thi Nguyen
1 sibling, 2 replies; 18+ messages in thread
From: Harald Hanche-Olsen @ 2006-04-20 19:25 UTC (permalink / raw)
+ Lennart Borgman <lennart.borgman.073@student.lu.se>:
| Fredrik Bulow wrote:
|> So once again, what is the good reason that (query-replace "\n" "#")
|> behave differenty than calling the same function with its keybinding
|> and providing it interactively with the same arguments?
|>
| I also have difficulties understanding the prompting in cases like
| this. I have nothing against the "C-q C-j" solution but it is not
| the first I think of. Is there any reason not to just convert the
| input as needed so that it in the interactive case works as Fredrik
| and I expect it to do?
Uh. You would like to be able to type M-x query-replace RET \n RET #
RET and have that \n behave like it was typed between quotes in a lisp
expression? That, to me, is very unintuitive behaviour. The \n
syntax is a special escape for the convenience of programmers. It
should not be allowed to pollute interactive commands. The difficulty
here comes from the very fact that entering a string in a program, and
supplying one to an interactive command, are two very different
things, and they need different escape conventions to enter special
characters like the newline. Once you understand that, the difficulty
should indeed evaporate. You might of course disagree with the choice
of escape conventions, but I think it would confuse people more to use
the backslash as an escape character in the interactive setting.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: replacing endline
2006-04-20 19:25 ` Harald Hanche-Olsen
@ 2006-04-20 22:19 ` Lennart Borgman
2006-04-21 7:38 ` Eli Zaretskii
[not found] ` <mailman.671.1145571606.9609.help-gnu-emacs@gnu.org>
1 sibling, 1 reply; 18+ messages in thread
From: Lennart Borgman @ 2006-04-20 22:19 UTC (permalink / raw)
Cc: help-gnu-emacs
Harald Hanche-Olsen wrote:
> Uh. You would like to be able to type M-x query-replace RET \n RET #
> RET and have that \n behave like it was typed between quotes in a lisp
> expression? That, to me, is very unintuitive behaviour. The \n
> syntax is a special escape for the convenience of programmers. It
> should not be allowed to pollute interactive commands. The difficulty
> here comes from the very fact that entering a string in a program, and
> supplying one to an interactive command, are two very different
> things, and they need different escape conventions to enter special
> characters like the newline. Once you understand that, the difficulty
> should indeed evaporate. You might of course disagree with the choice
> of escape conventions, but I think it would confuse people more to use
> the backslash as an escape character in the interactive setting.
>
AFAICS the same escape syntax that are used for strings in elisp could
be used for strings read in the minibuffer. In princip I mean, not now
of course. To me it is not unnatural at all. But maybe it is very
inconvenient? Could you please explain what you mean from that point of
view?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: replacing endline
2006-04-20 22:19 ` Lennart Borgman
@ 2006-04-21 7:38 ` Eli Zaretskii
0 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2006-04-21 7:38 UTC (permalink / raw)
> Date: Fri, 21 Apr 2006 00:19:57 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: help-gnu-emacs@gnu.org
>
> AFAICS the same escape syntax that are used for strings in elisp could
> be used for strings read in the minibuffer.
Aha, and then wouldn't Windows users complain that they cannot type
file names with backslashes when Emacs prompts them?
Also, if I need to search for the literal string \n, what would I need
to do?
^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <mailman.671.1145571606.9609.help-gnu-emacs@gnu.org>]
* Re: replacing endline
[not found] ` <mailman.671.1145571606.9609.help-gnu-emacs@gnu.org>
@ 2006-04-21 6:52 ` Harald Hanche-Olsen
0 siblings, 0 replies; 18+ messages in thread
From: Harald Hanche-Olsen @ 2006-04-21 6:52 UTC (permalink / raw)
+ Lennart Borgman <lennart.borgman.073@student.lu.se>:
| AFAICS the same escape syntax that are used for strings in elisp
| could be used for strings read in the minibuffer. In princip I mean,
| not now of course.
Sure, in principle you could choose any escape convention you please.
| To me it is not unnatural at all. But maybe it is very inconvenient?
| Could you please explain what you mean from that point of view?
Well, if backslash was an escape character in string reads in the
minibuffer, any latex user who wants to replace \foo by \bar would
have to type those strings as \\foo and \\bar. That would confuse
newbies, and be inconvenient to more experienced folk. It gets worse
if you need to use query-replace-regexp, which also uses backslashes
for an escape convention, so you might end up having to type a
quadruple backslash in place of a single one. Ouch!
Besides, the C-q escape convention is not only for the minibuffer.
It's for every kind of buffer! Once you realise that there is nothing
that special about the minibuffer - it's just an ordinary buffer with
a peculiar mode - you will see that this is very logical indeed.
(I think I am going to bow out of this discussion now. I have said
all I have to say on the topic, and can't think of a way to state it
more clearly.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: replacing endline
[not found] ` <mailman.650.1145549499.9609.help-gnu-emacs@gnu.org>
2006-04-20 19:25 ` Harald Hanche-Olsen
@ 2006-04-21 0:53 ` Thien-Thi Nguyen
1 sibling, 0 replies; 18+ messages in thread
From: Thien-Thi Nguyen @ 2006-04-21 0:53 UTC (permalink / raw)
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> If thi thinks there are two bugs then I think there are three now
> since I agree with Fredrik. Or should it maybe be four thi, if perhaps
> you are a bit wrong too?;-)
agreement and understanding are orthogonal. whether or not i am wrong
plays no part in emacs' behavior or in OP's self-directed growth -- only
OP's understanding of how expectation and reality (mis-)map matters.
anyway, i'm never a bit wrong (word {m}alignment, you see ;-).
thi
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: replacing endline
2006-04-20 14:43 ` Fredrik Bulow
` (2 preceding siblings ...)
[not found] ` <mailman.650.1145549499.9609.help-gnu-emacs@gnu.org>
@ 2006-04-20 23:38 ` B. T. Raven
3 siblings, 0 replies; 18+ messages in thread
From: B. T. Raven @ 2006-04-20 23:38 UTC (permalink / raw)
"Fredrik Bulow" <kaliumfredrik@gmail.com> wrote in message
news:87acagux25.fsf@gmail.com...
> >> I don't see why this behavior shouldn't be labeled as a bug.
> >
> >if you label that behavior as a bug, then you have introduced two
> >"bugs", not just one. the first bug is in your mental model of how
> >emacs should work, and the second, the one labeled as suggested. if
> >you pre-emptively fix the first bug, perhaps the second bug will, as a
> >result, vanish as well.
> >
> >applying the above thought process to various behaviors, you may
> >be able to find and remove many bugs in the future. good luck!
> >
> >thi
>
> Thanks for that totally uncalled for insult. Of course, any bug can be
> removed by changing your expectations on how a program should behave
> to the way a program actually behaves. "It's not a bug that something
> crashes, it is suppose to crash, and how do I know that? Well, I tried
> and it crashed!." Usually, if something behaves in an unexpected way I
> think it is a bug unless there is a good reason why the current
> behaviour makes more sense than what I expected. I was kind of hoping
> that someone would give me the good reason why there should be two
> different behaviours.
>
> So once again, what is the good reason that (query-replace "\n" "#")
> behave differenty than calling the same function with its keybinding
> and providing it interactively with the same arguments?
>
> /Fredrik
This is one of those wonderful instances where both you and Thi are right.
It is difficult for those far up on the mountainside to see what things
look like down here in the valley. Try playing around with C-q C-j and
just C-j in *scratch* and in a text-mode buffer.
In
(query-replace "\n" "*")
the "/n" works the same way as it does in
printf ("Hello World!\n");
It is one of two arguments of type string to the query-replace function
If you put the lines below into *scratch* and then evaluate the form, it
will find the invisible newlines rather than the characters ", \, n, "
M-% will only find those literal characters unless you input a newline as
C-q C-j. Press the n key instead of the space bar to inhibit replacement
with "*". After you play around with this for a while you will agree with
Thi, sort of, which is good enough.
(query-replace "\n" "*")
\n
"\n"
'("\n")
p.s. Remember M-x top-level and C-x n w. It's easy to get lost while
fooling around with C-j in an interactive lisp buffer. Its behaviour
depends on whether or not there are matched parentheses above the point
where it is invoked. I am pretty sure that C-q C-j is a synonym for the
Enter-Return key just about anywhere except inside interactive functions
like M-% and C-M-% where it produces an actual newline in the minibuffer..
("
")
Ed.
^ permalink raw reply [flat|nested] 18+ messages in thread