Re: FM12: Quirks in Find/replace using RegEx (Perl)
I work with on a windows environment and write Perl scripts regularly to adjust HTML, MIF, XML and other UTF-8 files using RegEx. Sometimes its a single file other times a folder structure of files. IF you need a small perl script I be glad to donate to this group. Ed Nodland sddat.com On Tue, Jul 8, 2014 at 3:01 AM, Steve Rickaby < srick...@wordmongers.demon.co.uk> wrote: > Klaus and others > > I admit that I have not been following this thread too closely, although > I've had similar issues with EOLs in FrameMaker in the past. > > However, where regexp work is concerned, there is an alternative, which > might be practical if what's required is a batch on-off cleanup: work on > the MIF and parse it with a stream editor. Users of FrameMaker on Unix and > Mac have access to apps like sed: you would have to grok a bit of MIF > grammar, but it offers a completely different approach to FrameMaker's > native regexp find/replace. > > Of course, you'd have to learn regexps all over again for sed :-( > > -- > Steve > ___ > > > You are currently subscribed to framers as enodl...@gmail.com. > > Send list messages to framers@lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscr...@lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/enodland%40gmail.com > > Send administrative questions to listad...@frameusers.com. Visit > http://www.frameusers.com/ for more resources and info. > ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: FM12: Quirks in Find/replace using RegEx (Perl)
Klaus and others I admit that I have not been following this thread too closely, although I've had similar issues with EOLs in FrameMaker in the past. However, where regexp work is concerned, there is an alternative, which might be practical if what's required is a batch on-off cleanup: work on the MIF and parse it with a stream editor. Users of FrameMaker on Unix and Mac have access to apps like sed: you would have to grok a bit of MIF grammar, but it offers a completely different approach to FrameMaker's native regexp find/replace. Of course, you'd have to learn regexps all over again for sed :-( -- Steve ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: FM12: Quirks in Find/replace using RegEx (Perl)
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: s...@leximation.com To: framers@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.hos...@aeris.net <mailto:syed.hos...@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:docu...@hotmail.com] *Sent:* Monday, July 07, 2014 10:18 AM *To:* Syed Zaeem Hosain (syed.hos...@aeris.net <mailto:syed.hos...@aeris.net>); fr...@daube.ch <mailto:fr...@daube.ch>; framers@lists.frameusers.com <mailto:framers@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 ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: FM12: Quirks in Find/replace using RegEx (Perl)
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: s...@leximation.com
To: framers@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.hos...@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:docu...@hotmail.com]
Sent: Monday, July 07, 2014 10:18 AM
To: Syed Zaeem Hosain (syed.hos...@aeris.net);
fr...@daube.ch; framers@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 ___
You are currently subscribed to framers as arch...@mail-archive.com.
Send list messages to framers@lists.frameusers.com.
To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.
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.hos...@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:docu...@hotmail.com] *Sent:* Monday, July 07, 2014 10:18 AM *To:* Syed Zaeem Hosain (syed.hos...@aeris.net); fr...@daube.ch; framers@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.hos...@aeris.net <mailto:syed.hos...@aeris.net> To: docu...@hotmail.com <mailto:docu...@hotmail.com>; fr...@daube.ch <mailto:fr...@daube.ch>; framers@lists.frameusers.com <mailto:framers@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-boun...@lists.frameusers.com <mailto:framers-boun...@lists.frameusers.com> [mailto:framers-boun...@lists.frameusers.com] *On Behalf Of *Fred Ridder *Sent:* Monday, July 07, 2014 8:02 AM *To:* fr...@daube.ch <mailto:fr...@daube.ch>; framers@lists.frameusers.com <mailto:framers@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
RE: FM12: Quirks in Find/replace using RegEx (Perl)
Yeah ... I have to admit that I can't argue with you on this too much. :) 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:docu...@hotmail.com] Sent: Monday, July 07, 2014 10:18 AM To: Syed Zaeem Hosain (syed.hos...@aeris.net); fr...@daube.ch; framers@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.hos...@aeris.net<mailto:syed.hos...@aeris.net> To: docu...@hotmail.com<mailto:docu...@hotmail.com>; fr...@daube.ch<mailto:fr...@daube.ch>; framers@lists.frameusers.com<mailto:framers@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-boun...@lists.frameusers.com<mailto:framers-boun...@lists.frameusers.com> [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Ridder Sent: Monday, July 07, 2014 8:02 AM To: fr...@daube.ch<mailto:fr...@daube.ch>; framers@lists.frameusers.com<mailto:framers@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:
Re: FM12: Quirks in Find/replace using RegEx (Perl)
On 7 Jul 2014 at 11:02, Fred Ridder wrote: > 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). > ... Thank You Fred for Your reasoning! After that I agree with you that the second method of my replacement is the only correct one - and according to the design of RegExes. I was thinking in the plain text editor mode ... Klaus Daube ~~ Docu + Design Daube; Schäracher 11; CH-8053 Zürich Technical documentation & consultancy; On-line and paper F: +41-44-422 86 25 E: d...@daube.ch W: www.daube.ch ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
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.hos...@aeris.net To: docu...@hotmail.com; fr...@daube.ch; framers@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-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Ridder Sent: Monday, July 07, 2014 8:02 AM To: fr...@daube.ch; framers@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: fr...@daube.ch > To: framers@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
Re: FM12: Quirks in Find/replace using RegEx (Perl)
Hi Klaus... Definitely a bug in that the handling of "\n" is inconsistent. But I'd wonder what "\n" is really matching on, and what type of "end of line" is it? Will this match on a forced return (SHIFT+ENTER) as well as an end of paragraph? And what about the end of flow? I'd feel better if "\n" didn't match on anything since I don't know that this really applies in a FM document. What about trying "$" to indicate an end of line? Definitely a bug though. ...scott On 7/7/14 6:48 AM, Klaus Daube wrote: 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.\rreplacement 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 ~~ Docu + Design Daube; Schäracher 11; CH-8053 Zürich Technical documentation & consultancy; On-line and paper F: +41-44-422 86 25 E: d...@daube.ch W: www.daube.ch ___ ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
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-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Ridder Sent: Monday, July 07, 2014 8:02 AM To: fr...@daube.ch; framers@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: fr...@daube.ch<mailto:fr...@daube.ch> > To: framers@lists.frameusers.com<mailto:framers@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 arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
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: fr...@daube.ch > To: framers@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.\rreplacement 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 arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
