FM12: Quirks in Find/replace using RegEx (Perl)

[Scott Prentice]

There's no reason the plain-text replacement can't add EOPs .. just need 
a code to do that. You can do that with a regular search/replace by 
searching on "\p" and replacing with "\p\p". The "\n" is a forced return 
in the non-regex UI. It should at least do the same .. not an "n".

...scott


On 7/7/14 6:07 PM, Fred Ridder wrote:
> But if there is no practical way for a plain text-oriented tool to 
> insert a *proper* EOP, the only way to make Frame's overall 
> Find/Replace behavior consistent would be to forbid searching for 
> EOPs. And that would be a *real* shortcoming IMO. Kind of like 
> throwing out the baby with the bathwater...
>
> -Fred
>
> ------------------------------------------------------------------------
> Date: Mon, 7 Jul 2014 16:57:03 -0700
> From: sp10 at leximation.com
> To: framers at lists.frameusers.com
> Subject: Re: FM12: Quirks in Find/replace using RegEx (Perl)
>
> I dunno. I just don't like the fact that "\n" will match on a line end 
> (of some type), while it replaces as an "n" .. that's not right.
>
> ...scott
>
> On 7/7/14 4:52 PM, Syed Zaeem Hosain (Syed.Hosain at aeris.net 
> <mailto:Syed.Hosain at aeris.net>) wrote:
>
>     Yeah … I have to admit that I can’t argue with you on this too
>     much. JBecause, there isn’t a simple “this is the right way” to do
>     the EOP insertions.
>
>     Although … /maybe/ … Word stands a slightly better chance because
>     of its “Normal” paragraph that /could/ get applied by default. Of
>     course, as you note, this could cause a mess with documents whose
>     paragraphs have already been changed to some other paragraph
>     format, etc.
>
>     Z
>
>     *From:*Fred Ridder [mailto:docudoc at hotmail.com]
>     *Sent:* Monday, July 07, 2014 10:18 AM
>     *To:* Syed Zaeem Hosain (Syed.Hosain at aeris.net
>     <mailto:Syed.Hosain at aeris.net>); frame at daube.ch
>     <mailto:frame at daube.ch>; framers at lists.frameusers.com
>     <mailto:framers at lists.frameusers.com>
>     *Subject:* RE: FM12: Quirks in Find/replace using RegEx (Perl)
>
>     Don't get me wrong. I'm not saying that it wouldn't be *useful* to
>     be able to insert a new EOP. But the reality is that in either
>     Word or FrameMaker (and I assume in other word processing
>     applications) it is problematic because EOP is not a simple
>     character. Regular expressions are designed to work with arbitrary
>     strings of simple characters. They were never intended to handle
>     characters that have formatting or page layout properties embedded
>     in them. If a regular expression *were* able to insert a new EOP,
>     what formatting should apply to it? Since regular expressions
>     don't know about formatting, the only practical answer is the
>     lowest level default formatting. But in any properly designed word
>     processor document (i.e., one that uses styles) that default is
>     going to be *wrong* in >99% of cases and require further, manual
>     attention from the author, which really defeats the benefit of
>     being able to use a regular expression replacement. A simple text
>     editor is a completely different situation because there really is
>     nothing special about an EOP.
>
>     I think the real point is that in Klaus' case the analysis of the
>     task was slightly flawed. To fix his punctuation issue, what he
>     really wants to do is insert a period (full stop) between the
>     current unpunctuated text and the existing EOP, which is exactly
>     what his second regular expression does. There really is no reason
>     to delete the existing EOP (and all the "magic" embedded in it)
>     and replace it with a brand-new, untagged EOP that would require
>     his manual attention to tag and/or format. FrameMaker's behavior
>     of not allowing this saves the user from having to do a lot of
>     after-the-fact cleanup.
>
>     FrameMaker's regular expressions let you find EOPs without issue,
>     and lets you reuse them. What they don't let you do is try to
>     create a new one where there is insufficient information in the
>     found text string(s) to do that operation without making a mess.
>
>     -Fred
>
>     ------------------------------------------------------------------------
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20140707/6cbe8687/attachment.htm>