Re: Why do replace commands sometimes not work?

Re: Why do replace commands sometimes not work?

[MBR]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On 5/24/2012 10:41 PM, B. T. Raven wrote:
> 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
>
> Ed
I'm not surprised that you can't reproduce it.  It's so unpredictable 
that it reminds me of an assembly language bug I diagnosed many years 
ago where the code turned out to be making a critical decision based on 
data it fetched from an uninitialized memory location.  In the case of 
this bug, the state of memory could depend on every keystroke I've typed 
since I started Emacs, the contents of every file it's opened, etc.

The example I gave was to illustrate the sort of problem I'm running 
into, to see if anyone else has encountered the same problem.  I'd be 
thrilled if I could come up with a reproducible example, but I've had no 
luck on that front so far.

    Mark


[-- Attachment #2: Type: text/html, Size: 1540 bytes --]

Can't respond to B. T. Raven <nihil@nihilo.net>

[MBR]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

Sorry to bother the whole list with this, but it's the only way I can 
get a message through to "B. T. Raven" <nihil@nihilo.net>.

"B. T. Raven" <nihil@nihilo.net> responded on this list to my question 
about Emacs replace functions sometimes not working.  But when I tried 
to respond to his email, my response bounced with:

        This message was created automatically by mail delivery software.

        A message that you sent could not be delivered to one or more of its
        recipients. This is a permanent error. The following address(es) failed:

           nihil@nihilo.net
             SMTP error from remote mail server after RCPT TO:<nihil@nihilo.net>:
             host mailserver.nihilo.net [213.171.216.114]:
             550<nihil@nihilo.net>: Recipient address rejected:
             User unknown in virtual mailbox table

In case nihil@nihilo.net is reading this list, do you have any idea why 
your mailserver is rejecting emails addressed to you?  Is there an 
alternate email address I can mail you at?

        Mark Rosenthal
        mbr@arlsoft.com <mailto:mbr@arlsoft.com>



[-- Attachment #2: Type: text/html, Size: 1891 bytes --]

Re: Can't respond to B. T. Raven <nihil@nihilo.net>

[Peter Dyballa]

Am 25.05.2012 um 05:19 schrieb MBR:

> Sorry to bother the whole list with this, but it's the only way I can get a message through to "B. T. Raven"

I think on this list we are supposed to respond to all, to the whole list and to the author of the referenced eMail.

--
Greetings

  Pete

How many Microsoft engineers does it take to screw in a light-bulb?
None.
They just redefine "dark" as the new standard.

RE: Why do replace commands sometimes not work?

[Ludwig, Mark]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

I assume something like Valgrind has been applied to Emacs ... and it's clean.

Cheers,
Mark

From: help-gnu-emacs-bounces+ludwig.mark=siemens.com@gnu.org [mailto:help-gnu-emacs-bounces+ludwig.mark=siemens.com@gnu.org] On Behalf Of MBR
Sent: Thursday, May 24, 2012 10:01 PM
To: B. T. Raven
Cc: help-gnu-emacs@gnu.org
Subject: Re: Why do replace commands sometimes not work?

On 5/24/2012 10:41 PM, B. T. Raven wrote:

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



Ed
I'm not surprised that you can't reproduce it.  It's so unpredictable that it reminds me of an assembly language bug I diagnosed many years ago where the code turned out to be making a critical decision based on data it fetched from an uninitialized memory location.  In the case of this bug, the state of memory could depend on every keystroke I've typed since I started Emacs, the contents of every file it's opened, etc.

The example I gave was to illustrate the sort of problem I'm running into, to see if anyone else has encountered the same problem.  I'd be thrilled if I could come up with a reproducible example, but I've had no luck on that front so far.
Mark

[-- Attachment #2: Type: text/html, Size: 5319 bytes --]

Re: Can't respond to B. T. Raven <nihil@nihilo.net>

[B. T. Raven]

Sorry, mbr and Pete. I'm a little paranoid about usenet. I've sent mbr
my real email.

Ed

> 
> Am 25.05.2012 um 05:19 schrieb MBR:
> 
>> Sorry to bother the whole list with this, but it's the only way I can get a message through to "B. T. Raven"
> 
> I think on this list we are supposed to respond to all, to the whole list and to the author of the referenced eMail.
> 
> --
> Greetings
> 
>   Pete
> 
> How many Microsoft engineers does it take to screw in a light-bulb?
> None.
> They just redefine "dark" as the new standard.
> 
> 

Re: Why do replace commands sometimes not work?

[Barry Margolin]

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 ***