From: Barry Margolin <barmar@alum.mit.edu>
To: help-gnu-emacs@gnu.org
Subject: Re: Why do replace commands sometimes not work?
Date: Fri, 25 May 2012 11:36:38 -0400 [thread overview]
Message-ID: <barmar-57717E.11363825052012@news.eternal-september.org> (raw)
In-Reply-To: 5O-dnbLCNdm5bCPSnZ2dnUVZ5rmdnZ2d@giganews.com
In article <5O-dnbLCNdm5bCPSnZ2dnUVZ5rmdnZ2d@giganews.com>,
"B. T. Raven" <nihil@nihilo.net> wrote:
> Die Thu May 24 2012 18:15:40 GMT-0500 (Central Daylight Time) MBR
> <mbr@arlsoft.com> scripsit:
>
> > There's a problem I've encountered with Emacs for many years. I never
> > reported it because I've been running Emacs 21.3 under Windows, and I
> > figured that Emacs users on Windows are probably a very small percentage
> > of Emacs users, and that 21.3 is so old that it nobody would be
> > interested in debugging the problem.
> >
> > But then I encountered the same problem with Emacs 23.2.1 running under
> > Linux. And a few days ago I finally installed Windows Emacs 23.4.1, and
> > it's got the same problem.
> >
> > The problem: the replace commands, M-x replace-string and M-x
> > replace-regexp, sometimes work and sometimes don't. When it doesn't
> > work, it often will work if I retype exactly the same command a few times.
> >
> > My reaction when I first encountered the problem was that I must have
> > mistyped the command the first time. But I've encountered it for so
> > many years that whenever it fails to work the first time, it's become
> > habit for me to be extremely careful in my typing the second and
> > subsequent times, and it often fails on those tries too, but eventually
> > succeeds.
> >
> > I particularly notice it when I'm defining a macro [ delimited by C-x (
> > and C-x ) ]. And frequently I have the buffer narrowed to a small
> > subset of text that I want to operate on. But I don't know for certain
> > that defining a macro or having the buffer narrowed are what cause the
> > problem to manifest.
> >
> > I now have a concrete example of this that proves that it's not due to
> > my mistyping. There's a point in the macro where the buffer has been
> > narrowed to a portion that contains a symbol in CamelCase.
> >
> > Note: In case you're unfamiliar with CamelCase, it's a convention
> > for variable names originally popularized by the X Window System.
> > Earlier conventions for C and C++ used "_" as a word delimiter
> > within variable names. Lisp used "-" instead of "_". CamelCase,
> > so-called because the capital letters in the middle of the word form
> > humps like those on a camel's back, uses capital letters to indicate
> > the beginning of a new word. So, the C-style variable name
> > find_char_in_string, or Lisp-style variable name
> > find-char-in-string, in CamelCase is findCharInString.
> >
> > The purpose of this part of the macro is to turn CamelCase into
> > space-separated words.
> >
> > M-< ;; Go to beginning of narrowed buffer
> > M-x replace-regexp RET
> > [A-Z] RET ;; Find any capital letter
> > C-q SPC \& RET ;; Replace it with a space followed by itself
> > M-< ;; Go to beginning of narrowed buffer
> > C-d ;; Delete the unwanted space before the
> > first letter
> >
> > So, if the narrowed portion of the buffer contains:
> >
> > "JohnJacobJingleheimerschmidt"
> >
> > after running this portion of the macro, it should contain:
> >
> > "John Jacob Jingleheimerschmidt"
> >
> > Instead, when run in Emacs 23, the result is:
> >
> > "ohnJacobJingleheimerschmidt"
> >
> > which is exactly what you'd expect if the M-x replace-regexp failed to
> > do the replacement that it should have. But since I know that sometimes
> > a replace command works the second time after failing to work the first
> > time, I modified that portion of the macro to do the replace twice:
> >
> > M-< ;; Go to beginning of narrowed buffer
> > M-x replace-regexp RET
> > [A-Z] RET ;; Find any capital letter
> > C-q SPC \& RET ;; Replace it with a space followed by itself
> > M-< ;; Go to beginning of narrowed buffer
> > M-x replace-regexp RET
> > [A-Z] RET ;; Find any capital letter
> > C-q SPC \& RET ;; Replace it with a space followed by itself
> > M-< ;; Go to beginning of narrowed buffer
> > C-d ;; Delete the unwanted space before the
> > first letter
> >
> > Now, if the replace were working the first time, applying it again would
> > produce the undesired result:
> >
> > " John Jacob Jingleheimerschmidt"
> >
> > Instead, it produces:
> >
> > "John Jacob Jingleheimerschmidt"
> >
> > Does anybody here have any idea what's going wrong here?
> >
> > Mark Rosenthal
> > mbr@arlsoft.com <mailto:mbr@arlsoft.com>
> >
> > P.S. - One further clue: In the older version of Emacs (21.3) I've
> > noticed that at those times when the replace fails to work, if I repeat
> > the replace command with C-x ESC ESC, the minibuffer shows:
> >
> > (replace-regexp "[A-Z]" " \\&" nil sss eee)
> >
> > where sss and eee are integers that are supposed to indicate the
> > beginning and end characters of the region to operate on, but when the
> > replace has failed, sss and eee specify a small subset of the region.
> >
>
>
> I can't reproduce that misbehavior on w32 ver 23.1
> Both in *scratch* (lisp mode) and a junk file in text mode I get:
>
> John Jacob Jingleheimerschmidt
> " John Jacob Jingleheimerschmidt"
> " John Jacob Jingleheimerschmidt"
> John Jacob Jingleheimerschmidt
> John Jacob Jingleheimerschmidt
>
> where the second and third lines were originally camel-case in quotes.
> I did assign the macro to a keychord with C-xC-kb
I think the clue is in his P.S. If you have transient-mark-mode
enabled, the replace commands restrict themselves to the active region.
When I run M-ESC ESC in Emacs 22.2, it doesn't show explicit buffer
positions, it show things like (if (and transient-mark-mode mark-active)
(region-beginning)). But maybe in the older version it just put the
buffer positions in the history.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
next prev parent reply other threads:[~2012-05-25 15:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1636.1337901354.855.help-gnu-emacs@gnu.org>
[not found] ` <5O-dnbLCNdm5bCPSnZ2dnUVZ5rmdnZ2d@giganews.com>
2012-05-25 3:01 ` Why do replace commands sometimes not work? MBR
2012-05-25 12:25 ` Ludwig, Mark
2012-05-25 3:19 ` Can't respond to B. T. Raven <nihil@nihilo.net> MBR
2012-05-25 9:03 ` Peter Dyballa
[not found] ` <mailman.1656.1337936620.855.help-gnu-emacs@gnu.org>
2012-05-25 12:52 ` B. T. Raven
2012-05-25 15:36 ` Barry Margolin [this message]
2012-05-24 23:15 Why do replace commands sometimes not work? MBR
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=barmar-57717E.11363825052012@news.eternal-september.org \
--to=barmar@alum.mit.edu \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.