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

[Fred Ridder]

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)
      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: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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20140707/447e61ac/attachment.htm>