Loading ...
Sorry, an error occurred while loading the content.
 

[jasspa] Re: numbers <-> bullets -- regexp bug/question

Expand Messages
  • Thomas Hundt
    Detlef s got some good ideas here. I was messing around, trying to extend the concept, when I discovered the following weird behavior. - When you use the
    Message 1 of 3 , Oct 11, 1999
      Detlef's got some good ideas here. I was messing around, trying to extend the concept, when I discovered the following weird behavior.

      - When you use the regexp [0-9]+ in &xequal, it doesn't work at all.
      - When you use [0-9]*, it works like [0-9]+, not matching the empty string but matching a string of digits.
      - When you use these in query-replace-string, they work "correctly," i.e., '+' matches one or more of a char, '*' matches empty strings and any number of a char.

      Here's my example. (The commented-out regexp is supposed to match lines like
      " 13. Reinstall Windows again". The one left in matches lines like "123" only.)

      define-macro renumber
      set-alpha-mark "z"
      backward-line
      ; !if &xsequal @wl " *[0-9]+\..*" ; <--- what I want to do
      !if &xsequal @wl "[0-9]*" ; <-- works like [0-9]+
      set-variable #l0 &add 0 @wl
      ml-write &spr "* found number %d" #l0
      !endif
      goto-alpha-mark "z"
      !emacro
      !force global-bind-key renumber "C-x n"


      Any ideas?

      -Th


      p.s. While we're discussing regexps, why are the \h, \l etc. functions not supported? These would be useful. My (admittedly limited) Unix in a Nutshell book documents these as being part of GNU regexp (they make letters/words uppercase/lowercase).
    • Steven Phillips,,,
      ... This is a user error. As with most systems there are 2 types of regex , the complex gnu regex used by search and replace which is what you think &xseq
      Message 2 of 3 , Oct 12, 1999
        > - When you use the regexp [0-9]+ in &xequal, it doesn't work at all.
        > - When you use [0-9]*, it works like [0-9]+, not matching the empty string but matching a string of digits.
        > - When you use these in query-replace-string, they work "correctly," i.e., '+' matches one or more of a char, '*' matches empty strings and any number of a char.
        >

        This is a user error. As with most systems there are 2 types of 'regex', the
        complex gnu regex used by search and replace which is what you think &xseq is,
        and the file-system regex where '*' is any number of any character (i.e. ".*"
        in gnu regex) and '?' is any char. Which is why [0-9]* appears to work and
        [0-9]+ doesn't.

        Having said that, when I implemented the &xse regexcmp function I did not have
        access to a simple interface to a gnu-regex style engine. I now do, so I'm
        tempted to move everything over to gnu-regex. This means that variables like
        $spell-word, $buffer-names, $command-names etc will be gnu-regex compliant.
        Can anyone see any reason why I shouldn't?

        > p.s. While we're discussing regexps, why are the \h, \l etc. functions not
        > supported? These would be useful. My (admittedly limited) Unix in a Nutshell
        > book documents these as being part of GNU regexp (they make letters/words
        > uppercase/lowercase).

        I'm afraid they are not gnu Emacs regex compliant, only \b (word boundary) and
        \w (word char) are strictly gnu, there are also "\s " and \s- for a white
        space and \sw for a word char. I also added the posix style character classes,
        i.e. [[:upper:]] or [^[:upper:][:lower:]] (horrible I know but they are the
        standard.

        We could add the \h & \l (what others are missing??), after all, this is not
        gnu Emacs. But I am concerned that they will conflict with existing \?
        characters, such as \n or \t etc. So which ones are missing? And does anyone
        object to adding them?

        Steve
      Your message has been successfully submitted and would be delivered to recipients shortly.