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

Mon Jul 7 16:57:03 PDT 2014

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) 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); frame at daube.ch; 
> 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
>
> ------------------------------------------------------------------------
>
> From: Syed.Hosain at aeris.net <mailto:Syed.Hosain at aeris.net>
> To: docudoc at hotmail.com <mailto:docudoc at hotmail.com>; frame at daube.ch 
> <mailto:frame at daube.ch>; framers at lists.frameusers.com 
> <mailto:framers at lists.frameusers.com>
> Date: Mon, 7 Jul 2014 09:10:33 -0700
> Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl)
>
> Hi, Fred.
>
> Hmmm ... I understand your point, but am not sure I would /entirely/ 
> agree with the reasoning.
>
> Yes, FrameMaker (and other programs like Word) do put in additional 
> information besides the EOP glyph itself.
>
>
> But, this is a relatively commonly used/desired function -- certainly 
> in simple text editors -- to replace an EOP with other characters 
> (perhaps including an EOP). For example, to "join" multiple lines 
> together, or to do what Klaus mentions.
>
> Yes, FM is /not/ just a simple text editor, which is why I see your 
> reasoning to not call it a bug.
>
> But I think it would be good to define exactly what regular expression 
> matching is supposed to do with EOP markers then (or have a special 
> mechanism to identify /and/ use an EOP more effectively perhaps?)
>
> Z
>
> *From:*framers-bounces at lists.frameusers.com 
> <mailto:framers-bounces at lists.frameusers.com> 
> [mailto:framers-bounces at lists.frameusers.com] *On Behalf Of *Fred Ridder
> *Sent:* Monday, July 07, 2014 8:02 AM
> *To:* 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)
>
> No, I don't think it is a bug.
> And end-of-paragraph mark is not a simple glyph; it has properties and 
> attributes associated with it (e.g. a paragraph tag, the formatting 
> associated with that paragraph tag, and any overrides to the standard 
> formatting for the tag).
> You can find an EOP as if it were a simple glyph because they do have 
> a common fundamental property (i.e. denoting the end of a paragraph).
> But you cannot effectively insert a new EOP in a replace string 
> because there is no way to associate any of the other properties with 
> the new mark.
> Finding an EOP and replacing it with itself, on the other hand, is a 
> valid operation because the found mark has a full complement of 
> paragraph properties.
>
> -Fred Ridder
>
> > From: frame at daube.ch <mailto:frame at daube.ch>
> > To: framers at lists.frameusers.com <mailto:framers at lists.frameusers.com>
> > Date: Mon, 7 Jul 2014 15:48:17 +0200
> > Subject: FM12: Quirks in Find/replace using RegEx (Perl)
> >
> > Friends of FramMaker, please judge.
> >
> > I want to find incorrectly ended paragraphs (missing punctuation).
> > For example the following 4 lines are paragraphs, the first 2 correct,
> > the next two incorrect:
> >
> > This is the first paragraph!
> > And this is the second one.
> > And here a third
> > And a fourth one:
> >
> > RegEx Find/Replace with these settings:
> > Find: ([^\.!?])\n
> > Repl: $1.\n
> > Result: find is correct, replacement is n instead of paragraph end
> > With repl = $1.\r replacement is a forced newline; correct, but not 
> wanted.
> >
> > Find: ([^\.!?])(\n)
> > Repl: $1.$2
> > This creates a correct replacement!
> >
> > IMHO the behaviour of not honoring \n as an 'end of paragraph' for 
> the replacement is
> > a bug. Do You agree?
> >
> > Klaus Daube
>
>
>
> _______________________________________________
>
>
> You are currently subscribed to framers as sp10 at leximation.com.
>
> Send list messages to framers at lists.frameusers.com.
>
> To unsubscribe send a blank email to
> framers-unsubscribe at lists.frameusers.com
> or visit http://lists.frameusers.com/mailman/options/framers/sp10%40leximation.com
>
> Send administrative questions to listadmin at frameusers.com. Visit
> http://www.frameusers.com/ for more resources and info.

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