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: [email protected] To: [email protected] 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 ([email protected]) wrote: Yeah … I have to admit that I can’t argue with you on this too much. J Because, 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:[email protected]] Sent: Monday, July 07, 2014 10:18 AM To: Syed Zaeem Hosain ([email protected]); [email protected]; [email protected] 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
_______________________________________________ You are currently subscribed to framers as [email protected]. Send list messages to [email protected]. To unsubscribe send a blank email to [email protected] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [email protected]. Visit http://www.frameusers.com/ for more resources and info.
