* Re: Why do replace commands sometimes not work? [not found] ` <5O-dnbLCNdm5bCPSnZ2dnUVZ5rmdnZ2d@giganews.com> @ 2012-05-25 3:01 ` 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 15:36 ` Why do replace commands sometimes not work? Barry Margolin 2 siblings, 1 reply; 6+ messages in thread From: MBR @ 2012-05-25 3:01 UTC (permalink / raw) To: B. T. Raven; +Cc: help-gnu-emacs [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Why do replace commands sometimes not work? 2012-05-25 3:01 ` Why do replace commands sometimes not work? MBR @ 2012-05-25 12:25 ` Ludwig, Mark 0 siblings, 0 replies; 6+ messages in thread From: Ludwig, Mark @ 2012-05-25 12:25 UTC (permalink / raw) To: MBR, B. T. Raven; +Cc: help-gnu-emacs@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Can't respond to B. T. Raven <nihil@nihilo.net> [not found] ` <5O-dnbLCNdm5bCPSnZ2dnUVZ5rmdnZ2d@giganews.com> 2012-05-25 3:01 ` Why do replace commands sometimes not work? MBR @ 2012-05-25 3:19 ` MBR 2012-05-25 9:03 ` Peter Dyballa [not found] ` <mailman.1656.1337936620.855.help-gnu-emacs@gnu.org> 2012-05-25 15:36 ` Why do replace commands sometimes not work? Barry Margolin 2 siblings, 2 replies; 6+ messages in thread From: MBR @ 2012-05-25 3:19 UTC (permalink / raw) To: help-gnu-emacs [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can't respond to B. T. Raven <nihil@nihilo.net> 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> 1 sibling, 0 replies; 6+ messages in thread From: Peter Dyballa @ 2012-05-25 9:03 UTC (permalink / raw) To: MBR; +Cc: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <mailman.1656.1337936620.855.help-gnu-emacs@gnu.org>]
* Re: Can't respond to B. T. Raven <nihil@nihilo.net> [not found] ` <mailman.1656.1337936620.855.help-gnu-emacs@gnu.org> @ 2012-05-25 12:52 ` B. T. Raven 0 siblings, 0 replies; 6+ messages in thread From: B. T. Raven @ 2012-05-25 12:52 UTC (permalink / raw) To: help-gnu-emacs 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. > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why do replace commands sometimes not work? [not found] ` <5O-dnbLCNdm5bCPSnZ2dnUVZ5rmdnZ2d@giganews.com> 2012-05-25 3:01 ` Why do replace commands sometimes not work? MBR 2012-05-25 3:19 ` Can't respond to B. T. Raven <nihil@nihilo.net> MBR @ 2012-05-25 15:36 ` Barry Margolin 2 siblings, 0 replies; 6+ messages in thread From: Barry Margolin @ 2012-05-25 15:36 UTC (permalink / raw) To: help-gnu-emacs 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 *** ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-05-25 15:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [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 ` Why do replace commands sometimes not work? Barry Margolin
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.