• CLARIFICATION [Re: Confused first time Kate user]

    From Richard Owlett@21:1/5 to Richard Owlett on Wed Jul 3 05:57:39 2024
    On 07/02/2024 09:40 AM, Richard Owlett wrote:
    I have a Debian machine with Kate Version 16.08.3 .

    I wish to do a search & replace using regular expressions.
    The "Help" menu has led to https://docs.kde.org/stable5/en/kate/katepart/regular-expressions.html
    and
    https://docs.kde.org/stable5/en/kate/katepart/regex-patterns.html

    I have strings of the form "XYZn" where n is one to three digits
    representing values of from 1 to 299. I wish to replace all occurrences
    with "abc".

    The documents give essentially no examples.

    Help please.
    TIA


    The first paragraph of the first reference explicitly warns:
    This Appendix contains a brief but hopefully sufficient and
    covering introduction to the world of regular
    expressions. It documents regular expressions in the form
    available within KatePart, which is not compatible with the regular expressions of perl, nor with those of for example
    grep.

    Please note the phrasing "... which is not compatible ...".
    This is a personal project. I started searching the web for information
    on regular expressions. Circumstances require I use this particular
    machine with its current software ] no updates ;[

    My formal background is limited to a single introductory programming
    course I took as a freshman E.E. student in '61. I learned by doing.

    My web reading and a discussion in another forum has may has made me
    aware that there is more than one way to handle regular expressions.

    This time I asked on a "editor" focused group and specified the specific
    editor I'm using.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Richard Owlett on Fri Jul 5 01:05:08 2024
    On Wed, 3 Jul 2024 05:57:39 -0500, Richard Owlett wrote:

    My web reading and a discussion in another forum has may has made me
    aware that there is more than one way to handle regular expressions.

    The Perl style seems to have become something of a de-facto standard.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Lawrence D'Oliveiro on Fri Jul 5 04:00:01 2024
    On 05.07.2024 03:05, Lawrence D'Oliveiro wrote:
    On Wed, 3 Jul 2024 05:57:39 -0500, Richard Owlett wrote:

    My web reading and a discussion in another forum has may has made me
    aware that there is more than one way to handle regular expressions.

    I'm not quite sure what you mean by "handle" REs. There's tools
    with different syntax and that support more or less functions,
    even sometimes exceeding the class of a Regular grammar (at a
    given cost). - I suppose you meant this?


    The Perl style seems to have become something of a de-facto standard.

    Hardly. First, there's differences on the functional level; Perl
    supports with their regexp library functions that are not part
    of the Regular Expression grammar class, they exceed that class.
    The consequence is that for that subset there's no O(N) (linear)
    complexity guaranteed any more.
    Second, there's syntactical differences between tools, that are
    necessary to handle meta-characters in their specific language
    context; in one tool meta-characters need, e.g., to be escaped
    where in another context that's not necessary. How can something
    be a standard when (standard-)tools do not support that.
    Then there's sometimes syntactical convenience shortcuts in use
    (here I'm thinking of Perl's escaped classes of common entities
    and their negated forms); these are very handy especially where
    these expressions get more complex.

    Moreover, when speaking about [de facto] "standards"; what would
    that mean in the light of existing (real) standards, like POSIX,
    that define behavior of tools and the supported RE implementation
    (BRE, ERE).
    And finally shells (like Kornshell) that had since 1988 version
    an own syntax (not comparable with BRE, ERE, Perl's, syntax), an
    extension of the "wildcard" patterns. Also back-references, one
    extension that doesn't guaranteed O(N) any more, had been added
    later. Only later version supported the ERE syntax in addition
    to the original Ksh-"patterns".

    It's know that fans of specific products often use terms like
    de-facto standard. Readers should be careful when spotting such
    phrases, they are often nothing but marketing talk.

    Usually you have requirements and have to make yourself familiar
    with what the allowed tool chest supports (including the Regexp
    facilities). Granted, getting familiar is harder than following
    marketing suggestions. But there's (real) standards (as opposed
    to "de-facto" standards), so if you're learning the standards
    (RE oder otherwise) you may apply these in a broader context.

    And if you have the time and the tools that support these "Perl
    regexps", yet better, since they make some things appear tidier
    and add convenient functional extensions. Note that Perl regexps
    also follow (and extend) the basic syntax of the other standard
    Regexps mentioned (BRE, ERE), so learning the basics first can
    never be wrong.

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Janis Papanagnou on Fri Jul 5 03:58:00 2024
    On Fri, 5 Jul 2024 04:00:01 +0200, Janis Papanagnou wrote:

    On 05.07.2024 03:05, Lawrence D'Oliveiro wrote:

    The Perl style seems to have become something of a de-facto standard.

    Hardly. First, there's differences on the functional level; Perl
    supports with their regexp library functions that are not part of the
    Regular Expression grammar class, they exceed that class. The
    consequence is that for that subset there's no O(N) (linear) complexity guaranteed any more.

    Precisely. Many users of REs seem to feel it is useful to at least
    have the option of such extensions, and they are willing to pay that
    price.

    Second, there's syntactical differences between tools, that are
    necessary to handle meta-characters in their specific language
    context; in one tool meta-characters need, e.g., to be escaped where
    in another context that's not necessary. How can something be a
    standard when (standard-)tools do not support that.

    Surely they do it the way that Perl does. Hence “Perl style”.

    Moreover, when speaking about [de facto] "standards"; what would
    that mean in the light of existing (real) standards ...

    It means there is a standard library (actually a whole bunch of them)
    you can link against to immediately support that style of regular
    expression.

    <https://packages.debian.org/search?keywords=pcre&searchon=names&suite=stable&section=all>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Lawrence D'Oliveiro on Sat Jul 6 02:53:07 2024
    On 05.07.2024 05:58, Lawrence D'Oliveiro wrote:
    On Fri, 5 Jul 2024 04:00:01 +0200, Janis Papanagnou wrote:

    [...] First, there's differences on the functional level; Perl
    supports with their regexp library functions that are not part of the
    Regular Expression grammar class, they exceed that class. The
    consequence is that for that subset there's no O(N) (linear) complexity
    guaranteed any more.

    Precisely. Many users of REs seem to feel it is useful to at least
    have the option of such extensions, and they are willing to pay that
    price.

    There's two problems; one related to the Perl user, and one related
    to the Perl implementor - if they're not aware about the line drawn
    between regular and non-regular grammars. - The Perl user should be
    informed about the complexities they buy with certain constructs
    so that they are really "willing to pay" and not "pay a price that
    they just did not expect". The implementor shall be aware that the
    mechanism implemented should well differentiate between the two
    domains of complexity for the respective functions, otherwise (as
    happened in the past!) a common mechanism is implemented that even
    for ordinary O(N) Regular Expressions non-linear complexities have
    to be payed (unintentionally!) in certain, even simple, cases.

    Note that this caveat is not Perl-specific; all pattern matchers
    that support such functions, like e.g. back-references, should be
    aware of that.

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)