faq.texi

faq.texi

[Richard M. Stallman]

Is anyone maintaining faq.texi?

Re: faq.texi

[Romain Francoise]

"Richard M. Stallman" <rms@gnu.org> writes:

> Is anyone maintaining faq.texi?

The MAINTAINERS file lists Eli as maintainer for this file, but the last
major update was done by me.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: faq.texi

[Richard M. Stallman]

Could you please put your name in as the maintainer?
Is the file up to date?

Re: faq.texi

[Romain Francoise]

"Richard M. Stallman" <rms@gnu.org> writes:

> Could you please put your name in as the maintainer?

If Eli is okay with that, sure.

> Is the file up to date?

I updated it in prevision of the release, but I'm not sure if it really
reflects the questions that people ask nowadays...  (I don't follow the
user support channels much.)

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: faq.texi

[Eli Zaretskii]

> From: Romain Francoise <romain@orebokech.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Sun, 05 Feb 2006 14:07:31 +0100
> 
> "Richard M. Stallman" <rms@gnu.org> writes:
> 
> > Could you please put your name in as the maintainer?
> 
> If Eli is okay with that, sure.

Of course I'm okay with that.  Thanks!

Re: faq.texi

[Richard M. Stallman]

    > Could you please put your name in as the maintainer?

    If Eli is okay with that, sure.

If you are the one actually updating it, your name should be in it.

    I updated it in prevision of the release, but I'm not sure if it really
    reflects the questions that people ask nowadays...  (I don't follow the
    user support channels much.)

Could you start doing that, so you can see what questions to add?

Re: faq.texi

[Romain Francoise]

"Richard M. Stallman" <rms@gnu.org> writes:

> Could you start doing that, so you can see what questions to add?

Ok.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: faq.texi

[Frank Schmitt]

Romain Francoise <romain@orebokech.com> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>> Could you start doing that, so you can see what questions to add?
>
> Ok.

Two questions I've been several times are:

"When I type C-s to search, I can't paste via Shift+Insert (or yank via
C-y). Why and what to do against it?"

"How does query-replace across line borders work?" or on a similiar topic
"How to prefix every line with text a"

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: faq.texi

[Romain Francoise]

Hi Frank,

Thanks for your input!

Frank Schmitt <ich@frank-schmitt.net> writes:

> Two questions I've been several times are:

> "When I type C-s to search, I can't paste via Shift+Insert (or yank
> via C-y). Why and what to do against it?"

Er, I'm not sure what that means.  You mean paste whilst being in
isearch?

> "How does query-replace across line borders work?"

Hmm, yeah, the manual explains that one must use C-q C-j to match
newlines, but not in a very straightforward way.  Or did you have
something different in mind?

> or on a similiar topic "How to prefix every line with text a"

This one is covered already:

(info "(efaq)Inserting > at the beginning of each line")

Though it could be made more general.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

(efaq)Inserting > at the beginning of each line (was: faq.texi)

[Reiner Steib]

On Tue, Feb 07 2006, Romain Francoise wrote:

> (info "(efaq)Inserting > at the beginning of each line")
>
> Though it could be made more general.

,----[ (info "(efaq)Inserting > at the beginning of each line") ]
|    If you are trying to prefix a yanked mail message with `>', you
| might want to set the variable `mail-yank-prefix'.  Better yet, use the
| Supercite package (*note Supercite::), which provides flexible citation
| for yanked mail and news messages; it is included in Emacs since
| version 19.20.  *Note Changing the included text prefix::, for
| additional information.
`----

In `message-mode' you can simply use `M-;' (`comment-region' [1]).  In
`mail-mode' you need to specify the comment syntax.  Maybe it should
be added to `mail-mode' as well.

Bye, Reiner.

[1] From `message.el':

  (when message-yank-prefix
    (set (make-local-variable 'comment-start) message-yank-prefix)
    (set (make-local-variable 'comment-start-skip)
	 (concat "^" (regexp-quote message-yank-prefix) "[ \t]*")))
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: (efaq)Inserting > at the beginning of each line

[Romain Francoise]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> In `message-mode' you can simply use `M-;' (`comment-region' [1]).  In
> `mail-mode' you need to specify the comment syntax.  Maybe it should
> be added to `mail-mode' as well.

Yeah, not that I want to reopen old wounds, but having two
very-but-not-quite similar mail composition packages is a pain.

The FAQ now mentions M-; in Message mode to cite messages, thanks for
the suggestion,

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: (efaq)Inserting > at the beginning of each line

[Richard M. Stallman]

    Yeah, not that I want to reopen old wounds, but having two
    very-but-not-quite similar mail composition packages is a pain.

The Gnus developers should have consulted with me about upgrading
Mail mode before they developed an alternative to it.  That kind
of divergence is what makes for an incoherent system.

Re: faq.texi

[Kevin Rodgers]

Romain Francoise wrote:
> Hi Frank,
> 
> Thanks for your input!
> 
> Frank Schmitt <ich@frank-schmitt.net> writes:
> 
> 
>>Two questions I've been several times are:
> 
> 
>>"When I type C-s to search, I can't paste via Shift+Insert (or yank
>>via C-y). Why and what to do against it?"
> 
> 
> Er, I'm not sure what that means.  You mean paste whilst being in
> isearch?

Probably he does.  The Incremental Search node of the Emacs manual says:

    The character `M-y' copies text from the kill ring into the search
string.  It uses the same text that `C-y' as a command would yank.
`Mouse-2' in the echo area does the same.  *Note Yanking::.

>>"How does query-replace across line borders work?"
> 
> 
> Hmm, yeah, the manual explains that one must use C-q C-j to match
> newlines, but not in a very straightforward way.  Or did you have
> something different in mind?

I would suggest using query-replace-regexp instead of query-replace,
so that typing SPC while entering the regexp matches newlines as well
via search-whitespace-regexp (assuming the buffer has a sane syntax
table).

>>or on a similiar topic "How to prefix every line with text a"
> 
> 
> This one is covered already:
> 
> (info "(efaq)Inserting > at the beginning of each line")
> 
> Though it could be made more general.

-- 
Kevin Rodgers

Re: faq.texi

[Frank Schmitt]

Romain Francoise <romain@orebokech.com> writes:

> Hi Frank,
>
> Thanks for your input!
>
> Frank Schmitt <ich@frank-schmitt.net> writes:
>
>> Two questions I've been several times are:
>
>> "When I type C-s to search, I can't paste via Shift+Insert (or yank
>> via C-y). Why and what to do against it?"
>
> Er, I'm not sure what that means.  You mean paste whilst being in
> isearch?

Yes. Often if people want to search for a ReallyComplicatedAndLongWord
they are too lazy too type it in isearch, so they copy it to the
clipboard from some application, type C-s to start a search and then hit
Shift+Insert to insert it at the minibuffer prompt. This doesn't work,
which isn't really intuitive.

>> "How does query-replace across line borders work?"
>
> Hmm, yeah, the manual explains that one must use C-q C-j to match
> newlines, but not in a very straightforward way.  Or did you have
> something different in mind?

No, exactly this.

>> or on a similiar topic "How to prefix every line with text a"
>
> This one is covered already:
>
> (info "(efaq)Inserting > at the beginning of each line")
>
> Though it could be made more general.

I think it's ok. However I think we have included some more user
friendly command for this during development of Emacs 23 but I can't
remember it's name...

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: faq.texi

[Eli Zaretskii]

> From: Frank Schmitt <ich@frank-schmitt.net>
> Date: Tue, 07 Feb 2006 22:06:06 +0100
> 
> > Er, I'm not sure what that means.  You mean paste whilst being in
> > isearch?
> 
> Yes. Often if people want to search for a ReallyComplicatedAndLongWord
> they are too lazy too type it in isearch, so they copy it to the
> clipboard from some application, type C-s to start a search and then hit
> Shift+Insert to insert it at the minibuffer prompt. This doesn't work,
> which isn't really intuitive.

Is there anything that prevents us from binding S-insert in
isearch-mode-map?  If that's what people expect, maybe it's simpler to
behave according to their expectations than provide lengthy
explanation why we don't.

Re: faq.texi

[Romain Francoise]

Eli Zaretskii <eliz@gnu.org> writes:

> Is there anything that prevents us from binding S-insert in
> isearch-mode-map?

Yes: C-y in isearch does not run `yank', and people expect C-y and
S-insert to do the same thing.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: faq.texi

[Eli Zaretskii]

> From: Romain Francoise <romain@orebokech.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 Feb 2006 21:38:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is there anything that prevents us from binding S-insert in
> > isearch-mode-map?
> 
> Yes: C-y in isearch does not run `yank', and people expect C-y and
> S-insert to do the same thing.

I was talking about binding S-insert to do the same thing as C-y.  Is
there a problem doing that?

Re: faq.texi

[Romain Francoise]

Eli Zaretskii <eliz@gnu.org> writes:

> I was talking about binding S-insert to do the same thing as C-y.  Is
> there a problem doing that?

Hmm...  Why not.  cI have no strong feelings about that.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: faq.texi

[Juri Linkov]

>> > Is there anything that prevents us from binding S-insert in
>> > isearch-mode-map?
>> 
>> Yes: C-y in isearch does not run `yank', and people expect C-y and
>> S-insert to do the same thing.
>
> I was talking about binding S-insert to do the same thing as C-y.
> Is there a problem doing that?

Do you mean the same thing as C-y does in isearch mode or not?

If you mean binding S-insert to the same thing as C-y in isearch mode
(i.e. `isearch-yank-line') then I think it is a bad idea to bind a useful
key S-insert to `isearch-yank-line' just for consistency.  Moreover,
I think C-y was a bad choice for a keybinding to `isearch-yank-line'.
I hope at some time `isearch-yank-kill' in isearch will be bound to
more natural C-y, and `isearch-yank-line' to some other key, but not to M-y.
Yanking in isearch has another nuisance: there is no key to replace text
just yanked into the search string with earlier kills, i.e. what M-y
normally does.

If you mean binding S-insert to `isearch-yank-kill' this would be useful
only for novices who don't know about M-y (`isearch-yank-kill'), but not
for all other users.  Since now it is not possible to exit isearch and yank
with the same key M-y, currently S-insert is the only key that can do this,
i.e. it is more convenient to type only one key S-insert with automalically
existing isearch than typing two keys `RET C-y'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: romain@orebokech.com, emacs-devel@gnu.org
> Date: Thu, 09 Feb 2006 19:31:44 +0200
> 
> > I was talking about binding S-insert to do the same thing as C-y.
> > Is there a problem doing that?
> 
> Do you mean the same thing as C-y does in isearch mode or not?

The same as C-y does in isearch.

> If you mean binding S-insert to the same thing as C-y in isearch mode
> (i.e. `isearch-yank-line') then I think it is a bad idea to bind a useful
> key S-insert to `isearch-yank-line' just for consistency.  Moreover,
> I think C-y was a bad choice for a keybinding to `isearch-yank-line'.

Well, if you oppose to the C-y binding in isearch, then I think you
should disqualify yourself from arguing about an identical binding for
S-insert, since it's clear that you will dislike them both on the same
grounds.  I suggested the S-insert binding for consistency.

Re: faq.texi

[Juri Linkov]

> Well, if you oppose to the C-y binding in isearch, then I think you
> should disqualify yourself from arguing about an identical binding for
> S-insert, since it's clear that you will dislike them both on the same
> grounds.  I suggested the S-insert binding for consistency.

There is no inconsistency in my wishes.  I wish:

- one key to bind to isearch-yank-line (not C-y)
- one key to exit isearch and yank (S-insert)
- one key to bind to isearch-yank-pop (M-y, like yank-pop)
- one key to bind to isearch-yank-kill (C-y)
- one key to bind them all in the darkness :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: romain@orebokech.com, emacs-devel@gnu.org
> Date: Thu, 09 Feb 2006 23:48:34 +0200
> 
> > Well, if you oppose to the C-y binding in isearch, then I think you
> > should disqualify yourself from arguing about an identical binding for
> > S-insert, since it's clear that you will dislike them both on the same
> > grounds.  I suggested the S-insert binding for consistency.
> 
> There is no inconsistency in my wishes.  I wish:
> 
> - one key to bind to isearch-yank-line (not C-y)
> - one key to exit isearch and yank (S-insert)

Yeah, like I said: you ``consistently'' dislike both C-y and S-Ins in
this context.  By contrast, what I said is if C-y does something,
S-Ins should do the same.

Re: faq.texi

[Juri Linkov]

>> - one key to bind to isearch-yank-line (not C-y)
>> - one key to exit isearch and yank (S-insert)
>
> Yeah, like I said: you ``consistently'' dislike both C-y and S-Ins in
> this context.  By contrast, what I said is if C-y does something,
> S-Ins should do the same.

The consistency I meant is for C-y and M-y to have the same non-isearch
meaning in isearch mode: for C-y to yank last killed text into the search
string, and for M-y to yank earlier kills into the search string.

But not all consistencies are equally good.  C-y is a bad keybinding for
isearch-yank-line, and making S-Insert consistent with a bad keybinding
makes things worse: it doesn't do what beginners expect (the initial
request was exactly about this, i.e. "I can't paste via Shift+Insert
or yank via C-y") and also it takes away a good keybinding from other
users to exit isearch and to yank with one key.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> The consistency I meant is for C-y and M-y to have the same non-isearch
> meaning in isearch mode: for C-y to yank last killed text into the search
> string, and for M-y to yank earlier kills into the search string.

Yeah; I know it's a contentious issue, but it seems to me like
ultimately the best solution would be to bite the bullet and change the
default binding of C-y (and M-y) in isearch to better match what people
expect (and add some other bi nding for the "grab rest of line").  The
traditional isearch bindings have been a consistent point of confusion
as long as I can remember (not just among newbies either).

I say this because I think the isearch meanings of C-y (etc), while
certainly not obscure, are in general less used than other bindings, and
more problematic in their current form, so it's thinkable to change them.

-miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: faq.texi

[Richard M. Stallman]

    The consistency I meant is for C-y and M-y to have the same non-isearch
    meaning in isearch mode: for C-y to yank last killed text into the search
    string, and for M-y to yank earlier kills into the search string.

I'd rather turn off the special meaning of C-y in a search.
Too many characters have been given special meanings in isearch,
and that means you can't use them normally when you're in a search.

Re: faq.texi

[Juri Linkov]

>     The consistency I meant is for C-y and M-y to have the same non-isearch
>     meaning in isearch mode: for C-y to yank last killed text into the search
>     string, and for M-y to yank earlier kills into the search string.
>
> I'd rather turn off the special meaning of C-y in a search.
> Too many characters have been given special meanings in isearch,
> and that means you can't use them normally when you're in a search.

Either way we should find a replacement keybinding for isearch-yank-line,
and this is not easy.

One way to reduce the isearch controversy is to pick up only one key and
to use it as a prefix key for all isearch commands.  All other keys should
exit the search.  Let's say such a key is `M-s'.  Then possible keybindings:

`M-s C-y' - isearch-yank-kill
`M-s C-e' - isearch-yank-line
`M-s C-f' - isearch-yank-char
`M-s M-f' - isearch-yank-word
`M-s M-f M-f M-f ...' - yank successive words

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Richard M. Stallman]

    Either way we should find a replacement keybinding for isearch-yank-line,
    and this is not easy.

Is it really useful?  C-w in a search is definitely useful, but I have
never seen a use for C-y.  In general, a whole line of text is more
than one needs to search for.

    One way to reduce the isearch controversy is to pick up only one key and
    to use it as a prefix key for all isearch commands.

That is an interesting idea.  I think that putting ALL of the special
search characters into a prefix would be going too far; C-w needs
to be typed repeatedly, for instance.  However, there may be several
that could usefully be put into a prefix character.

    `M-s C-y' - isearch-yank-kill
    `M-s C-e' - isearch-yank-line
    `M-s C-f' - isearch-yank-char
    `M-s M-f' - isearch-yank-word
    `M-s M-f M-f M-f ...' - yank successive words

That is an interesting idea too.  I somewhat worry about the
idea of repetition after M-s, since that makes it like a mode.
(I think we have overused that approach in recent years.)
But the rest seems worth considering.

However, I think we should consider it after the release.

Re: faq.texi

[Miles Bader]

On 2/15/06, Richard M. Stallman <rms@gnu.org> wrote:
>     Either way we should find a replacement keybinding for isearch-yank-line,
>     and this is not easy.
>
> Is it really useful?  C-w in a search is definitely useful, but I have
> never seen a use for C-y.  In general, a whole line of text is more
> than one needs to search for.

Maybe I'm weird, but I do tend to use C-y reasonably often in a
specific circumstance:  when i want to see how well two regions of
text match, I go to the beginning of one, and hit C-y until the search
fails; this could be done with C-w too but it's a lot more tedious for
big regions.

-Miles
--
Do not taunt Happy Fun Ball.

Re: faq.texi

[Alan Mackenzie]

On Wed, 15 Feb 2006, Miles Bader wrote:

>On 2/15/06, Richard M. Stallman <rms@gnu.org> wrote:
>>     Either way we should find a replacement keybinding for isearch-yank-line,
>>     and this is not easy.

>> Is it really useful?  C-w in a search is definitely useful, but I have
>> never seen a use for C-y.  In general, a whole line of text is more
>> than one needs to search for.

>Maybe I'm weird, but I do tend to use C-y reasonably often in a
>specific circumstance:  when i want to see how well two regions of
>text match, I go to the beginning of one, and hit C-y until the search
>fails; this could be done with C-w too but it's a lot more tedious for
>big regions.

Maybe I'm also wierd, because I do this, too - more precisely, C-y through
one region until the regexp highlighting stops on the other.

>-Miles

-- 
Alan Mackenzie (Munich, Germany)

RE: faq.texi

[Drew Adams]

    >Maybe I'm weird, but I do tend to use C-y reasonably often in a
    >specific circumstance:  when i want to see how well two regions of
    >text match, I go to the beginning of one, and hit C-y until the search
    >fails; this could be done with C-w too but it's a lot more tedious for
    >big regions.

    I do this, too - more precisely, C-y through
    one region until the regexp highlighting stops on the other.

Is this mostly (only?) useful for different areas of the same buffer (since
you mention isearch highlighting other areas)? I assume you didn't literally
mean "region" here, but just "section" of text, no?

For comparing text sections in two different buffers, I usually select them,
`C-x n n', and use ediff on them. For sections in the same buffer, I
sometimes paste one section into a new buffer and do the same.

Maybe your technique would be handier (quicker) in that case, at least to
find a first difference. But IIUC, the two sections would need to be visible
simultaneously - e.g. near each other or in different windows.

RE: faq.texi

[Alan Mackenzie]

Hi, Drew!

On Wed, 15 Feb 2006, Drew Adams wrote:

>    >Maybe I'm weird, but I do tend to use C-y reasonably often in a
>    >specific circumstance:  when i want to see how well two regions of
>    >text match, I go to the beginning of one, and hit C-y until the search
>    >fails; this could be done with C-w too but it's a lot more tedious for
>    >big regions.

>    I do this, too - more precisely, C-y through
>    one region until the regexp highlighting stops on the other.

>Is this mostly (only?) useful for different areas of the same buffer (since
>you mention isearch highlighting other areas)? I assume you didn't literally
>mean "region" here, but just "section" of text, no?

>For comparing text sections in two different buffers, I usually select them,
>`C-x n n', and use ediff on them. For sections in the same buffer, I
>sometimes paste one section into a new buffer and do the same.

>Maybe your technique would be handier (quicker) in that case, at least to
>find a first difference. But IIUC, the two sections would need to be visible
>simultaneously - e.g. near each other or in different windows.

I often use it in files.diff, when I just can't see what's different
between the two versions.  Often it's things like a space at EOL, or a
leading TAB becoming TAB + 2 spaces, and suchlike.  C-y in isearch is
good for this.

-- 
Alan Mackenzie (Munich, Germany)

Re: faq.texi

[Miles Bader]

On 2/16/06, Drew Adams <drew.adams@oracle.com> wrote:
> I assume you didn't literally
> mean "region" here, but just "section" of text, no?

Yes

> For comparing text sections in two different buffers, I usually select them,
> `C-x n n', and use ediff on them. For sections in the same buffer, I
> sometimes paste one section into a new buffer and do the same.

ediff is the "obvious" method, but it's far too heavyweight, clunky,
and awkward for many cases (to tell the truth, I think ediff is too
clunky and awkward even for comparing files most of the time).  It
would be great to have a simple function that compared two sections of
a buffer and maybe added overlays highlighting the equal/different
bits; perhaps such a function could share some ediff code.

-Miles
--
Do not taunt Happy Fun Ball.

RE: faq.texi

[Drew Adams]

    > For comparing text sections in two different buffers, I
    > usually select them, `C-x n n', and use ediff on them. For
    > sections in the same buffer, I sometimes paste one section
    > into a new buffer and do the same.

    ediff is the "obvious" method, but it's far too heavyweight, clunky,
    and awkward for many cases (to tell the truth, I think ediff is too
    clunky and awkward even for comparing files most of the time).

I agree, but I often find that even though I start out doing a simple
comparison that doesn't need the heavy lifting of ediff, I can end up
appreciating the fact that I'm using it.

    It would be great to have a simple function that compared two
    sections of a buffer and maybe added overlays highlighting the
    equal/different bits; perhaps such a function could share some
    ediff code.

Yes, that could be good. It might be as simple as providing a different
interface (or two) to ediff. It's the narrow-to-region, set-up stuff that
represents overhead, for me. I don't find ediff too heavy once I'm in it.
(OK, then there's needing to exit...)

After using ediff as is for decades, I finally threw together a simple
case-sensitivity toggle for it (similar to whitespace sensitivity via ##). I
now use that toggle all the time, and I wonder how I ever got by without it
before. It's amazing how we can get used to doing stuff a particular way,
even if it might be simple to make a useful improvement.

Once, when I was younger and poorer, I had only one pair of shoes, which
gradually wore out. The sole of the left shoe became completely loose from
the toe back to about the middle. Well, I had gradually gotten used to
walking with those shoes, and I didn't even realize that my gait had adapted
to minimize the flopping of the left sole. When I finally bought some new
shoes, I was amazed that I had (a little) difficulty walking: it was awkward
to get by with a *good* user interface, because I had become so maladapted
to the previous bad one. It was a good lesson (but I still don't change buy
new shoes often).

BTW, there is also `compare-windows', which can be handy at times. But it is
limited and has no highlighting. Your use of C-s C-y reminds me of what
`compare-windows' does.

Re: faq.texi

[Richard M. Stallman]

    Maybe I'm also wierd, because I do this, too - more precisely, C-y through
    one region until the regexp highlighting stops on the other.

Wouldn't M-x compare-windows do that more easily?

Re: faq.texi

[Miles Bader]

"Richard M. Stallman" <rms@gnu.org> writes:
>     Maybe I'm also wierd, because I do this, too - more precisely, C-y through
>     one region until the regexp highlighting stops on the other.
>
> Wouldn't M-x compare-windows do that more easily?

Didn't know about compare-windows before...  I just tried it, and while
it's possibly the right tool (after getting used to it), it does seem a
bit terse -- one thing I like about using isearch is the friendly
highlighting.

Perhaps a wrapper around compare-windows (which would repeatedly invoke
it and leave a "trail" of overlays to highlight its progress) would be
useful.

-Miels

-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: faq.texi

[Richard M. Stallman]

    Didn't know about compare-windows before...  I just tried it, and while
    it's possibly the right tool (after getting used to it), it does seem a
    bit terse

I am not really sure what that means; could you be more specific
about what change you would like?

    Perhaps a wrapper around compare-windows (which would repeatedly invoke
    it and leave a "trail" of overlays to highlight its progress) would be
    useful.

Are you saying you wish it would highlight the matching text that it
finds each time?

Re: faq.texi

[Miles Bader]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Didn't know about compare-windows before...  I just tried it, and while
>     it's possibly the right tool (after getting used to it), it does seem a
>     bit terse
>
> I am not really sure what that means; could you be more specific
> about what change you would like?

I'm not entirely sure, as I'm still getting used to compare-windows, but ...

Currently the point moves to show you where matching has stopped.  To check
where the corresponding point is in the other window, you have to switch
windows, which is a bit cumbersome; it would be nice to see at a glance.

[Nonetheless I'm glad you mentioned this function; I've already found it
very useful.]

> Are you saying you wish it would highlight the matching text that it
> finds each time?

Something like that; given that it already has support for an overlay to
indicate where it skipped over non-matching text, I'm imagining an
extension of that functionality where it would (1) highlight matching text
too (in a different color), and (2) not immediately delete the overlays
(currently the overlay appears to be strictly temporary).

I'm not sure the best way to delete the overlays though, if they were made
longer-lasting.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: faq.texi

[Juri Linkov]

>> Are you saying you wish it would highlight the matching text that it
>> finds each time?
>
> Something like that; given that it already has support for an overlay to
> indicate where it skipped over non-matching text, I'm imagining an
> extension of that functionality where it would (1) highlight matching text
> too (in a different color), and (2) not immediately delete the overlays
> (currently the overlay appears to be strictly temporary).
>
> I'm not sure the best way to delete the overlays though, if they were made
> longer-lasting.

I believe the patch below is a good way to do this.  When the value of
`compare-windows-highlight' is `persistent', it requires calling
`compare-windows-dehighlight' (which can be bound to a separate key)
to delete all overlays.

Index: lisp/compare-w.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/compare-w.el,v
retrieving revision 1.33
diff -c -r1.33 compare-w.el
*** lisp/compare-w.el	6 Feb 2006 14:33:32 -0000	1.33
--- lisp/compare-w.el	17 Feb 2006 21:54:57 -0000
***************
*** 117,124 ****
    :version "22.1")
  
  (defcustom compare-windows-highlight t
!   "*Non-nil means compare-windows highlights the differences."
!   :type 'boolean
    :group 'compare-w
    :version "22.1")
  
--- 117,130 ----
    :version "22.1")
  
  (defcustom compare-windows-highlight t
!   "*Non-nil means compare-windows highlights the differences.
! The value t removes highlighting immediately after invoking a command
! other than `compare-windows'.
! The value `persistent' leaves all highlighted differences.  You can clear
! out all highlighting later with the command `compare-windows-dehighlight'."
!   :type '(choice (const :tag "No highlighting" nil)
! 		 (const :tag "Persistent highlighting" persistent)
! 		 (other :tag "Highlight until next command" t))
    :group 'compare-w
    :version "22.1")
  
***************
*** 130,135 ****
--- 136,143 ----
  
  (defvar compare-windows-overlay1 nil)
  (defvar compare-windows-overlay2 nil)
+ (defvar compare-windows-overlays1 nil)
+ (defvar compare-windows-overlays2 nil)
  (defvar compare-windows-sync-point nil)
  
  ;;;###autoload
***************
*** 351,363 ****
        (overlay-put compare-windows-overlay2 'face 'compare-windows)
        (overlay-put compare-windows-overlay2 'priority 1000))
      (overlay-put compare-windows-overlay2 'window w2)
!     ;; Remove highlighting before next command is executed
!     (add-hook 'pre-command-hook 'compare-windows-dehighlight)))
  
  (defun compare-windows-dehighlight ()
    "Remove highlighting created by `compare-windows-highlight'."
    (interactive)
    (remove-hook 'pre-command-hook 'compare-windows-dehighlight)
    (and compare-windows-overlay1 (delete-overlay compare-windows-overlay1))
    (and compare-windows-overlay2 (delete-overlay compare-windows-overlay2)))
  
--- 381,402 ----
        (overlay-put compare-windows-overlay2 'face 'compare-windows)
        (overlay-put compare-windows-overlay2 'priority 1000))
      (overlay-put compare-windows-overlay2 'window w2)
!     (if (not (eq compare-windows-highlight 'persistent))
! 	;; Remove highlighting before next command is executed
! 	(add-hook 'pre-command-hook 'compare-windows-dehighlight)
!       (when compare-windows-overlay1
! 	(push (copy-overlay compare-windows-overlay1) compare-windows-overlays1)
! 	(delete-overlay compare-windows-overlay1))
!       (when compare-windows-overlay2
! 	(push (copy-overlay compare-windows-overlay2) compare-windows-overlays2)
! 	(delete-overlay compare-windows-overlay2)))))
  
  (defun compare-windows-dehighlight ()
    "Remove highlighting created by `compare-windows-highlight'."
    (interactive)
    (remove-hook 'pre-command-hook 'compare-windows-dehighlight)
+   (mapc 'delete-overlay compare-windows-overlays1)
+   (mapc 'delete-overlay compare-windows-overlays2)
    (and compare-windows-overlay1 (delete-overlay compare-windows-overlay1))
    (and compare-windows-overlay2 (delete-overlay compare-windows-overlay2)))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Richard M. Stallman]

This is such a small change
that you can install it now if other people like it.

Re: faq.texi

[Richard M. Stallman]

    Currently the point moves to show you where matching has stopped.  To check
    where the corresponding point is in the other window, you have to switch
    windows, which is a bit cumbersome; it would be nice to see at a glance.

Normally there is a cursor in every window, except on a tty.
On a tty, it could set up some sort of highlighting to show this.

    Something like that; given that it already has support for an overlay to
    indicate where it skipped over non-matching text, I'm imagining an
    extension of that functionality where it would (1) highlight matching text
    too (in a different color), and (2) not immediately delete the overlays
    (currently the overlay appears to be strictly temporary).

    I'm not sure the best way to delete the overlays though, if they were made
    longer-lasting.

Would you like to work on implementing something that you find
convenient?  Later, after the release, we could install it.

Re: faq.texi

[Alan Mackenzie]

On Wed, 15 Feb 2006, Richard M. Stallman wrote:

>    Maybe I'm also wierd, because I do this, too - more precisely, C-y through
>    one region until the regexp highlighting stops on the other.

>Wouldn't M-x compare-windows do that more easily?

Hey, I didn't know about that!  That could be pretty good, but I'd have
to bind it to some key sequence first - C-c c, perhaps.  I doubt it would
be so good on files.diff, because then I'd have to first C-x 2 and set
point in each window.  But then, it could be convenient for large diff
chunks which are taller than half the frame.

But whatever, I still wouldn't want to lose C-y from within searches.
Sometimes C-y followed by M-e and a few backspaces is more convenient
than repeated C-w.

-- 
Alan.

RE: faq.texi

[Drew Adams]

    >Wouldn't M-x compare-windows do that more easily?

    That could be pretty good, but I'd have
    to bind it to some key sequence first - C-c c, perhaps.

FWIW, I've always used C-= as a prefix for comparisons. These are the only
ones I have, but other people might know and use other comparison commands.

 C-= b  ediff-buffers
 C-= d  diff
 C-= e  ediff-files
 C-= f  ediff-files
 C-= w  compare-windows

Perhaps such a comparison prefix would be useful for Emacs generally.

Re: faq.texi

[Juri Linkov]

>     >Wouldn't M-x compare-windows do that more easily?
>
>     That could be pretty good, but I'd have
>     to bind it to some key sequence first - C-c c, perhaps.
>
> FWIW, I've always used C-= as a prefix for comparisons. These are the only
> ones I have, but other people might know and use other comparison commands.
>
>  C-= b  ediff-buffers
>  C-= d  diff
>  C-= e  ediff-files
>  C-= f  ediff-files
>  C-= w  compare-windows
>
> Perhaps such a comparison prefix would be useful for Emacs generally.

C-= is not available on xterms, but this is a minor problem.

For a keybinding for `compare-windows' to be useful it should be one key,
because it requires repeated keystrokes to advance to the next differences.
So I suggest to bind `compare-windows' to C-= available on graphical displays.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: faq.texi

[Drew Adams]

    > I've always used C-= as a prefix for comparisons. These
    > are the only ones I have, but other people might know and use
    > other comparison commands.
    >
    >  C-= b  ediff-buffers
    >  C-= d  diff
    >  C-= e  ediff-files
    >  C-= f  ediff-files
    >  C-= w  compare-windows
    >
    > Perhaps such a comparison prefix would be useful for Emacs generally.

    C-= is not available on xterms, but this is a minor problem.

Yes.

    For a keybinding for `compare-windows' to be useful it should
    be one key, because it requires repeated keystrokes to advance
    to the next differences.

Not necessarily. C-x z z z z z... works just fine for that. In fact, it's
easier to repeatedly hit `z' than `C-='.

    So I suggest to bind `compare-windows' to C-= available on
    graphical displays.

There are multiple comparison commands. Why pick one in particular for C-=?

If we did have to pick only one, then you're right that the other commands I
mentioned don't need to be repeated in the way that `compare-windows' does,
so `compare-windows' is not a bad choice. But I still think it would be good
to use C-= as a prefix key reserved for comparison commands of all sorts.

To me, the advantage of `C-=' is its mnemonic character, not the fact that
it requires only a single keystroke. As I say, `C-x z' works well here. As a
prefix, `C-= C-h' lets you know all the bindings of comparison functions.

Re: faq.texi

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> But whatever, I still wouldn't want to lose C-y from within searches.
> Sometimes C-y followed by M-e and a few backspaces is more convenient
> than repeated C-w.

I second that.  I'm also using C-y in isearch quite often.  Another
application for it on diffs is to do C-s C-y on a context line, then
change to the file that this diff is based on and do C-s C-s to find the
context line here.  That's still faster than copying the line from the
diff and using C-s M-y.  C-s C-y is very fast to type on a German
keyboard. :-)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: faq.texi

[Juri Linkov]

>> But whatever, I still wouldn't want to lose C-y from within searches.
>> Sometimes C-y followed by M-e and a few backspaces is more convenient
>> than repeated C-w.
>
> I second that.  I'm also using C-y in isearch quite often.  Another
> application for it on diffs is to do C-s C-y on a context line, then
> change to the file that this diff is based on and do C-s C-s to find
> the context line here.

This is one of the typical examples when I use C-y in isearch too.
Another one is to check two multi-line sections of the same buffer
(such duplicate sections can appear after merge conflicts or after
copying from different sources) and to find the first different line.

But this doesn't mean that I like C-y as a keybinding.  I need only
its function isearch-yank-line, and would accept any other keybinding.

BTW, there is one problem with multi-line lazy highlighting: isearch
doesn't highlight partially visible matches, i.e. when a match begins
before (window-end) and ends after it.  This is due to the meaning of the
argument `limit' of `search-forward' which specifies the lower bound of
the search, i.e. (match-end 0).  Without an ability to specify the
upper bound of the search, isearch lazy highlighting can't highlight
partially visible matches whose (match-beginning 0) is before (window-end),
and (match-end 0) is after (window-end).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> But this doesn't mean that I like C-y as a keybinding.  I need only
> its function isearch-yank-line, and would accept any other keybinding.

The important thing about the current C-y bindings is that it should be
easy to repeat; it would be much more annoying as a binding that
required multiple keystrokes.

-miles
-- 
We live, as we dream -- alone....

Re: faq.texi

[Richard M. Stallman]

      I doubt it would
    be so good on files.diff, because then I'd have to first C-x 2 and set
    point in each window.

No matter what method you might use to compare two parts of a buffer,
you will surely have to identify where they start.

Re: faq.texi

[Miles Bader]

"Richard M. Stallman" <rms@gnu.org> writes:
>     I doubt it would be so good on files.diff, because then I'd have
>     to first C-x 2 and set point in each window.
>
> No matter what method you might use to compare two parts of a buffer,
> you will surely have to identify where they start.

Actually with the "isearch + C-y" method, you _don't_ -- the
highlight-other-matches function of isearch simply highlights everything
visible that matches the string you're searching for.  (and then stops
when you C-y past the point where the regions don't match anymore)

-Miles
-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: faq.texi

[Robert J. Chassell]

Miles Bader <miles@gnu.org> wrote,

   Maybe I'm weird, but I do tend to use C-y reasonably often in a
   specific circumstance ...

You are not weird.  It makes perfect sense in some situations.  I use
it, too.

Re: faq.texi

[Juri Linkov]

>     `M-s C-y' - isearch-yank-kill
>     `M-s C-e' - isearch-yank-line
>     `M-s C-f' - isearch-yank-char
>     `M-s M-f' - isearch-yank-word
>     `M-s M-f M-f M-f ...' - yank successive words
>
> That is an interesting idea too.  I somewhat worry about the
> idea of repetition after M-s, since that makes it like a mode.

I think different isearch modes are not necessarily bad.  There are
already a few: isearch case-sensitivity mode toggled by M-c, regexp mode
toggled by M-r, search string editing mode entered by M-e.

So a new mode toggled by M-s would be useful too.  In this mode
many normal keys should be interpreted specially in isearch context:
all point movement keys C-f/C-b/C-n/C-p, C-a/C-e, M-f/M-b should change the
search string according to the original buffer and the new point location,
i.e. after every point movement set the search string to the buffer's
contents between isearch-other-end and point.

Note that this is a different idea than using `M-s' as a prefix key
like I proposed earlier.  I think `M-s' as a key to toggle special mode
is more convenient.  It makes easier to type some yanking keys repeatedly.
One disadvantage of this mode is that fewer keys will exit the search.
But its advantages outweigh this disadvantage: in the default isearch mode
we could turn off the special meanings of M-y, C-y, C-w, and in the new
isearch mode use more natural keys for isearch commands.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Richard M. Stallman]

    > That is an interesting idea too.  I somewhat worry about the
    > idea of repetition after M-s, since that makes it like a mode.

    I think different isearch modes are not necessarily bad.  There are
    already a few: isearch case-sensitivity mode toggled by M-c, regexp mode
    toggled by M-r, search string editing mode entered by M-e.

We are failing to communicate--you're talking about different kinds of
modes.

Re: faq.texi

[Richard M. Stallman]

    Well, if you oppose to the C-y binding in isearch, then I think you
    should disqualify yourself from arguing about an identical binding for
    S-insert, since it's clear that you will dislike them both on the same
    grounds.

Since I am in charge of Emacs development, there is no decision from
which I am "disqualified".  There are some I don't have an opinion
about.

Re: faq.texi

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: juri@jurta.org, romain@orebokech.com, emacs-devel@gnu.org
> Date: Fri, 10 Feb 2006 18:02:26 -0500
> 
>     Well, if you oppose to the C-y binding in isearch, then I think you
>     should disqualify yourself from arguing about an identical binding for
>     S-insert, since it's clear that you will dislike them both on the same
>     grounds.
> 
> Since I am in charge of Emacs development, there is no decision from
> which I am "disqualified".

Richard, please re-read my message: I wasn't talking to you, I was
talking to Jury.  You weren't even in the list of addressees.  It's
unfair to accuse me of such blatant rudeness based only on partial
reading of the text I sent.

Re: faq.texi

[Richard M. Stallman]

    >     Well, if you oppose to the C-y binding in isearch, then I think you
    >     should disqualify yourself from arguing about an identical binding for
    >     S-insert, since it's clear that you will dislike them both on the same
    >     grounds.

    Richard, please re-read my message: I wasn't talking to you, I was
    talking to Jury.

I apologize for the misunderstanding, but there was a reason for it.
Since I do oppose the C-y binding in Isearch, I thought the first
sentence was a general statement that would apply to me.  Also, when I saw

    > Do you mean the same thing as C-y does in isearch mode or not?

I thought it was something I had said.  (I did say something
along the same lines).

Re: faq.texi

[Kevin Rodgers]

Eli Zaretskii wrote:
>>From: Romain Francoise <romain@orebokech.com>
>>Cc: emacs-devel@gnu.org
>>Date: Wed, 08 Feb 2006 21:38:53 +0100
>>
>>Eli Zaretskii <eliz@gnu.org> writes:
>>
>>
>>>Is there anything that prevents us from binding S-insert in
>>>isearch-mode-map?
>>
>>Yes: C-y in isearch does not run `yank', and people expect C-y and
>>S-insert to do the same thing.

Really?  Not being a Shift-Insert user, I have no expectations.  But
it sounds to me like a Windows shortcut, and the basis of the original
question is that C-s S-insert does not search for the selected text:
http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg00307.html

> I was talking about binding S-insert to do the same thing as C-y.  Is
> there a problem doing that?

I was sure you meant binding S-insert in isearch-mode-map to the same
thing as M-y (isearch-yank-kill).

-- 
Kevin Rodgers

Re: faq.texi

[Eli Zaretskii]

> From: Kevin Rodgers <ihs_4664@yahoo.com>
> Date: Thu, 09 Feb 2006 12:04:22 -0700
> 
> >>Yes: C-y in isearch does not run `yank', and people expect C-y and
> >>S-insert to do the same thing.
> 
> Really?  Not being a Shift-Insert user, I have no expectations.  But
> it sounds to me like a Windows shortcut

It's not a Windows shortcut, it's a CUA shortcut, and is also
supported by Motif/Lesstif and similar environments.

> > I was talking about binding S-insert to do the same thing as C-y.  Is
> > there a problem doing that?
> 
> I was sure you meant binding S-insert in isearch-mode-map to the same
> thing as M-y (isearch-yank-kill).

S-insert generally does the same as C-y, so it should be compatible in
this case as well, IMO.

Re: faq.texi

[Richard M. Stallman]

    I was talking about binding S-insert to do the same thing as C-y.  Is
    there a problem doing that?

You mean, snarf the rest of the current line into the search?
That is what C-y does in I-search.

Re: faq.texi

[Romain Francoise]

Frank Schmitt <ich@frank-schmitt.net> writes:

> Yes. Often if people want to search for a ReallyComplicatedAndLongWord
> they are too lazy too type it in isearch, so they copy it to the
> clipboard from some application, type C-s to start a search and then
> hit Shift+Insert to insert it at the minibuffer prompt. This doesn't
> work, which isn't really intuitive.

Okay.  The manual is very clear about this, but I've added an entry to
the FAQ about it nonetheless, pointing people to the relevant node in
the manual.

>> Hmm, yeah, the manual explains that one must use C-q C-j to match
>> newlines, but not in a very straightforward way.  Or did you have
>> something different in mind?

> No, exactly this.

OK, same here.

> I think it's ok. However I think we have included some more user
> friendly command for this during development of Emacs 23 but I can't
> remember it's name...

There's been a discussion in October about adding a function named
`prefix-region' but it never made it into the code.

Thanks,

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: faq.texi

[Juri Linkov]

> Okay.  The manual is very clear about this, but I've added an entry to
> the FAQ about it nonetheless, pointing people to the relevant node in
> the manual.

Actually there is already a special node in FAQ that describes how to use
C-q C-j to match newlines: (info "(efaq)Working with unprintable characters")
with the title:

5.10 How do I search for, delete, or replace unprintable (eight-bit or control) characters?

So the new node `Searching for/replacing newlines' duplicates it.

BTW, the node `Working with unprintable characters' says:

   * You don't need to quote <TAB> with either isearch or typing
     something in the minibuffer.

But I think it's better to suggest to always quote <TAB> because in
the minibuffer its behavior depends on `indent-tabs-mode', and in
isearch mode it is bound to completion.

I also looked briefly at other parts of the FAQ and noticed other
inaccuracies and omissions:

1. The Top node says:

  If you find any errors, or have any suggestions, please use `M-x
  report-emacs-bug' to report them.

This is correct, but the node (info "(efaq)Reporting bugs")
doesn't mention `M-x report-emacs-bug' at all, and has no xref
to (info "(emacs)Bugs").

2. A xref from (info "(efaq)Highlighting a region")
to (info "(efaq)Turning on syntax highlighting") seems
inappropriate to me.  Region highlighting and syntax highlighting
are different things.

3. The node (info "(efaq)Replacing highlighted text") could be placed
just after (info "(efaq)Highlighting a region") in the menu.

4. I propose to merge nodes (info "(efaq)Turning on auto-fill by default")
and (info "(efaq)Wrapping words automatically").  And also to merge nodes
(info "(efaq)Repeating commands") and
(info "(efaq)Repeating a command as many times as possible")

5. I think (info "(efaq)Horizontal scrolling") should mention
`truncate-partial-width-windows'.

6. (info "(efaq)Forcing the cursor to remain in the same column")
should mention `track-eol', `C-x C-n' and `C-u C-x C-n' and have
a xref to (info "(emacs)Moving Point").

7. (info "(efaq)Inserting text at the beginning of each line")
could have a xref to (info "(efaq)Changing the included text prefix").

8. The node (info "(efaq)Newsgroup archives") could also
contain a link to `http://gmane.org/'.  And the node
(info "(efaq)Packages that do not come with Emacs") could have
a reference to the file `etc/MORE.STUFF'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: faq.texi

[Romain Francoise]

Juri Linkov <juri@jurta.org> writes:

> [...] I also looked briefly at other parts of the FAQ and noticed
> other inaccuracies and omissions [...]

I haven't had to opportunity to fix those over the past weeks and I see
now that you fixed them yourself.  Thanks!

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: faq.texi

[Eli Zaretskii]

> From: Frank Schmitt <ich@frank-schmitt.net>
> Date: Mon, 06 Feb 2006 15:18:10 +0100
> 
> Two questions I've been several times are:
> 
> "When I type C-s to search, I can't paste via Shift+Insert (or yank via
> C-y). Why and what to do against it?"
> 
> "How does query-replace across line borders work?" or on a similiar topic
> "How to prefix every line with text a"

They sound like good additions, but I think we need to verify that the
relevant features are described in the manual and indexed to ease the
search for them.  People are used to go to the FAQ as their first
resort, but we are trying to educate them to look in the manual before
they do.  So I think the FAQ should never describe anything that isn't
in the manual, except if the issue is too obscure or too technical or
doesn't belong in the manual (like URLs of useful resources).

Re: faq.texi

[Richard M. Stallman]

    They sound like good additions, but I think we need to verify that the
    relevant features are described in the manual and indexed to ease the
    search for them.  People are used to go to the FAQ as their first
    resort, but we are trying to educate them to look in the manual before
    they do.

I think the way to do that is to put xrefs to the manual into the FAQ.

Re: faq.texi

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Wed, 08 Feb 2006 14:04:43 -0500
> Cc: ich@frank-schmitt.net, emacs-devel@gnu.org
> 
>     They sound like good additions, but I think we need to verify that the
>     relevant features are described in the manual and indexed to ease the
>     search for them.  People are used to go to the FAQ as their first
>     resort, but we are trying to educate them to look in the manual before
>     they do.
> 
> I think the way to do that is to put xrefs to the manual into the FAQ.

Sure, but I suggested first to make sure they _are_ in the manual.

Re: faq.texi

[Richard M. Stallman]

    > I think the way to do that is to put xrefs to the manual into the FAQ.

    Sure, but I suggested first to make sure they _are_ in the manual.

Indeed, if something is important to users but missing from the manual,
let's document it in the manual.