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.
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:[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
------------------------------------------------------------------------
From: [email protected] <mailto:[email protected]>
To: [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>
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:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *Fred Ridder
*Sent:* Monday, July 07, 2014 8:02 AM
*To:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*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: [email protected] <mailto:[email protected]>
> To: [email protected] <mailto:[email protected]>
> 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 [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/sp10%40leximation.com
Send administrative questions to [email protected]. Visit
http://www.frameusers.com/ for more resources and info.
_______________________________________________
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.
