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

Re: rendering PCDATA in xml documents

Expand Messages
  • Peter Heslin
    ... Yes, and presumably the same kind of escaping/un-escaping could be done when widening/narrowing, if you wanted to implement it that way. Peter
    Message 1 of 18 , Jul 28, 2004
    • 0 Attachment
      On 2004-07-28, Vincent Lefevre <vincent@...> wrote:
      > The advantage is that some form of decoding can be performed before
      > yanking it to a temporary buffer, making the text more readable. And
      > after editing, reencoding can be performed before the text is put
      > back to the original buffer. This would be a bit like po files are
      > edited.

      Yes, and presumably the same kind of escaping/un-escaping could be
      done when widening/narrowing, if you wanted to implement it that way.

      Peter
    • drkm
      ... Yes. It s what I mean when I wrote that switching points are privileged place to perform some tasks. More generaly, I think it s also more easy to
      Message 2 of 18 , Jul 28, 2004
      • 0 Attachment
        Vincent Lefevre <vincent@...> writes:

        > On 2004-07-28 19:38:46 +0200, drkm wrote:

        >> The first one, corresponding to nxml-script if I didn't
        >> misunderstand Peter, is to switch explicitely between the two modes.
        >> And eventually warrow to the submode region, or yank it to a temporary
        >> buffer.

        > The advantage is that some form of decoding can be performed before
        > yanking it to a temporary buffer, making the text more readable. And
        > after editing, reencoding can be performed before the text is put
        > back to the original buffer.

        Yes. It's what I mean when I wrote that switching points are
        privileged place to perform some tasks. More generaly, I think it's
        also more easy to setting up the context of the submode mode
        precisely, in a clean way.

        > This would be a bit like po files are
        > edited.

        PO files. Mmm ... It's related to gettext, it isn't ? I don't
        know how they are edited. I tried open a "test.po" file, but the mode
        was text-mode. I didn't find any po-mode or gette* functions. What
        do you mean, when you speak about PO files ?

        --drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
      • Vincent Lefevre
        ... There s a po mode in Debian, provided by the gettext-el package. When a po file is edited, it is in fact marked as read-only, and the user can make a
        Message 3 of 18 , Jul 28, 2004
        • 0 Attachment
          On 2004-07-28 23:22:53 +0200, drkm wrote:
          > PO files. Mmm ... It's related to gettext, it isn't ? I don't
          > know how they are edited. I tried open a "test.po" file, but the mode
          > was text-mode. I didn't find any po-mode or gette* functions. What
          > do you mean, when you speak about PO files ?

          There's a po mode in Debian, provided by the gettext-el package.
          When a po file is edited, it is in fact marked as read-only, and
          the user can make a change / new translation by typing [Return]:
          this opens a new Emacs window below the main one in fundamental
          mode. When there is a double quote (") in a message, it must be
          escaped with a backslash, as shown in the main window. But in
          the temporary buffer, the message appears decoded: the double
          quote isn't escaped. Ditto for tab characters (encoded as \t in
          the po file). When the user has finished editing the message,
          he types C-c C-c to return to the main window, and Emacs encodes
          the double quote and tab characters as expected.

          Something similar could be done for scripts embedded in XML, where
          some characters must be encoded / escaped.

          --
          Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.org/>
          100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
          Championnat International des Jeux Mathématiques et Logiques, etc.
          Work: CR INRIA - computer arithmetic / SPACES project at LORIA
        • drkm
          ... Yes, I think is a lack in Emacs. But as I said, I think adding it to Emacs would be a non trivial task, and would require modifications in the emacs/lisp
          Message 4 of 18 , Jul 28, 2004
          • 0 Attachment
            Peter Heslin <usenet@...> writes:

            > On 2004-07-28, drkm <darkman_spam@...> wrote:

            >> So we will have two ways. One requiring switching between modes,
            >> but probably more robust. The other more intuitive and usable, but
            >> IMHO not so robust as can be the other way. The user will use
            >> normally the second way, but can use the first one if he have some
            >> trouble.

            >> Peter, can you verify I didn't say errors about nxml-script ? And
            >> maybe precise some points.

            > What you said is correct, and I agree with your assessment entirely.
            > It would be better if we had an mmm-mode style implementation. The
            > only problem is that this functionality is not currently supported in
            > the official Emacs distribution.

            Yes, I think is a lack in Emacs. But as I said, I think adding it
            to Emacs would be a non trivial task, and would require modifications
            in the emacs/lisp directory ... I don't read the Emacs devel ML. I
            don't know if someone work on this.

            > The only real advantage of narrowing/widening the buffer and switching
            > major-modes is that it can be done pretty easily and robustly (I am
            > supposing).

            I think too.

            > I agree that the UI is not as nice.

            Well, it's not a lot of work to switch to submodes. And with a
            alternate binding to a function key, for example, it could be very
            simple to use.

            > That's why I said
            > that the UI may depend on what it is possible to implement cleanly.

            I think it's why we have to do two things. A clean way, like
            nxml-script, and writing MMM classes (because MMM Mode provide enough
            functionalities to be useable, I think).

            --drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
          • drkm
            ... Yes. Using a temporary buffer or narrow/wide are fundamentaly equivalent. I mean they require a trigger (an interactive function). This trigger can use a
            Message 5 of 18 , Jul 28, 2004
            • 0 Attachment
              Peter Heslin <usenet@...> writes:

              > On 2004-07-28, Vincent Lefevre <vincent@...> wrote:

              >> The advantage is that some form of decoding can be performed before
              >> yanking it to a temporary buffer, making the text more readable. And
              >> after editing, reencoding can be performed before the text is put
              >> back to the original buffer. This would be a bit like po files are
              >> edited.

              > Yes, and presumably the same kind of escaping/un-escaping could be
              > done when widening/narrowing, if you wanted to implement it that way.

              Yes. Using a temporary buffer or narrow/wide are fundamentaly
              equivalent. I mean they require a trigger (an interactive function).
              This trigger can use a temporary buffer, narrow, decoding, etc.

              --drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
            • drkm
              Vincent Lefevre writes: [about editing PO files] Ok. It s what I thought about. ... BTW, more than provide an easy way to do
              Message 6 of 18 , Jul 28, 2004
              • 0 Attachment
                Vincent Lefevre <vincent@...> writes:

                [about editing PO files]

                Ok. It's what I thought about.

                > Something similar could be done for scripts embedded in XML, where
                > some characters must be encoded / escaped.

                BTW, more than provide an easy way to do {en,de}coding, this way (as
                opposite to the MMM Mode way) make it clear to {en,de}code. In the
                MMM Mode way, it's not so clear to do or not. In MMM Mode way, you
                always see the entire XML document, so it may be confusing to decode
                "<" and co., IMHO.

                --drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
              Your message has been successfully submitted and would be delivered to recipients shortly.