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

A possible enhancement for the next release: regions

Expand Messages
  • Giuseppe Bilotta
    Hello, the idea behind this proposal is that with certain file types one can have different part of the same file having very different requirements (e.g.
    Message 1 of 8 , Nov 24, 2002
    • 0 Attachment
      Hello,

      the idea behind this proposal is that with certain file types one
      can have different part of the same file having very different
      requirements (e.g. different text width and text wrap settings,
      and/or different highlight requirements, or different mappings,
      and/or different indent expressions/functions)

      There are several examples of this; for example in HTML text stuff
      between <pre> tags should not be wrapped; or, when editing tables,
      (in any kind of text-based format, like plain text, HTML, TeX,
      etc), text should wrap differently, and there could be mapping
      (active only in such a textblock) to "move to next row/column"; etc.

      Regions are already used in syntax highlighting. My proposal is to
      extend region management at a higher level. This way, the region
      concept would insert an extra granularity level in defining
      options, mappings, movements, etc. Regional settings would
      "cascade" (i.e. be inherited by nested regions unless overruled);
      many predefined objects could be much better defined in terms of
      regions: buffers themselves could be considered regions (starting at
      line 1 and ending with the last line), and also paragraphs, or
      other blocks (possibly).

      Regarding region definition, I think the safest thing to do is defining
      them linewise. My guess is that defining them characterwise would
      be too complex, even if it would allow very nice things
      (generalizations of the 'blocks' concept for selection purpouses,
      for example; etc). If we limit definitions to linewise regions, we
      could define region-based folding (could this be done with
      characterwise regions?)

      Another problem would be on how to make this feature accessible;
      for movement commands we could simply have
      ar a region
      ir inner region (i.e. region without the begin/end pair)
      to define regions, we could probably use a syntax similar to that
      of region syntax highlight.

      Does this idea sound viable?

      --
      Giuseppe "Oblomov" Bilotta
    • Paul Moore
      ... [...] ... I ve no idea how viable it is in terms of implementation (it sounds hard!) but I, for one, would find something like this immensely valuable. I
      Message 2 of 8 , Nov 24, 2002
      • 0 Attachment
        Giuseppe Bilotta <gip.bilotta@...> writes:

        > the idea behind this proposal is that with certain file types one
        > can have different part of the same file having very different
        > requirements (e.g. different text width and text wrap settings,
        > and/or different highlight requirements, or different mappings,
        > and/or different indent expressions/functions)

        [...]

        > Does this idea sound viable?

        I've no idea how viable it is in terms of implementation (it sounds
        hard!) but I, for one, would find something like this immensely
        valuable. I regularly work with Windows Script files (VBScript and
        JavaScript embedded in XML) and Oracle SQL*Plus (PL/SQL langage, SQL
        statements and SQL*Plus commands all intermixed). I'd imagine this
        could also be useful for shell scripts ("Here documents") and HTML
        (embedded JavaScript).

        I'm all in favour of this. I know of no "big features" outstanding and
        Vim development currently seems to be in a "stable" state (there are
        lots of patches for 6.1, which itself was a bugfix release to 6.0),
        and maybe a feature like this would be useful to give "the next
        direction" for Vim.

        Paul.
        --
        This signature intentionally left blank
      • Benji Fisher
        ... I agree that this is a nice idea. For a long time, I have wished that I could have a different setting for the textwidth option in tex files depending
        Message 3 of 8 , Nov 24, 2002
        • 0 Attachment
          Paul Moore wrote:
          >
          > Giuseppe Bilotta <gip.bilotta@...> writes:
          >
          > > the idea behind this proposal is that with certain file types one
          > > can have different part of the same file having very different
          > > requirements (e.g. different text width and text wrap settings,
          > > and/or different highlight requirements, or different mappings,
          > > and/or different indent expressions/functions)
          >
          > [...]
          >
          > > Does this idea sound viable?
          >
          > I've no idea how viable it is in terms of implementation (it sounds
          > hard!) but I, for one, would find something like this immensely
          > valuable. I regularly work with Windows Script files (VBScript and
          > JavaScript embedded in XML) and Oracle SQL*Plus (PL/SQL langage, SQL
          > statements and SQL*Plus commands all intermixed). I'd imagine this
          > could also be useful for shell scripts ("Here documents") and HTML
          > (embedded JavaScript).
          >
          > I'm all in favour of this. I know of no "big features" outstanding and
          > Vim development currently seems to be in a "stable" state (there are
          > lots of patches for 6.1, which itself was a bugfix release to 6.0),
          > and maybe a feature like this would be useful to give "the next
          > direction" for Vim.

          I agree that this is a nice idea. For a long time, I have wished
          that I could have a different setting for the 'textwidth' option in tex
          files depending on whether I am typing ordinary text or mathematical
          equations.

          In some situations, it is already possible to get this sort of
          behavior. For example, an indent script can check the value of the
          current syntax region, and return a value appropriate for the embedded
          file type. I think there are already some scripts that work this way,
          but maybe not yet any in the standard distribution.

          This approach relies on the syntax files to determine the embedded
          file types. This is probably A Good Thing.

          :help synID()

          HTH --Benji Fisher
        • Giuseppe Bilotta
          ... I m not much an expert about syntax highlighting ... is it possible to define syntax regions without actually highlighting them? In either case, I think
          Message 4 of 8 , Nov 24, 2002
          • 0 Attachment
            On Sunday, November 24, 2002 Benji Fisher wrote:

            > In some situations, it is already possible to get this sort of
            > behavior. For example, an indent script can check the value of the
            > current syntax region, and return a value appropriate for the embedded
            > file type. I think there are already some scripts that work this way,
            > but maybe not yet any in the standard distribution.

            > This approach relies on the syntax files to determine the embedded
            > file types. This is probably A Good Thing.

            > :help synID()

            I'm not much an expert about syntax highlighting ... is it
            possible to define syntax regions without actually 'highlighting'
            them?

            In either case, I think the regions thing should come "before"
            syntax highlight. We can make the two things cooperate by:
            (1) allowing syntax highlight groups to be defined based on
            regions
            (2) allowing syntax groups definitions to automatically define
            regions [sort of like folds being defined by indents]

            --
            Giuseppe "Oblomov" Bilotta
          • Brett Pershing Stahlman
            ... From: Giuseppe Bilotta To: Benji Fisher Cc: Sent: Sunday, November 24, 2002 5:13 PM Subject:
            Message 5 of 8 , Dec 2, 2002
            • 0 Attachment
              ----- Original Message -----
              From: Giuseppe Bilotta <gip.bilotta@...>
              To: Benji Fisher <fisherbb@...>
              Cc: <vim-dev@...>
              Sent: Sunday, November 24, 2002 5:13 PM
              Subject: Re[2]: A possible enhancement for the next release: regions


              > On Sunday, November 24, 2002 Benji Fisher wrote:
              >
              > > In some situations, it is already possible to get this sort of
              > > behavior. For example, an indent script can check the value of the
              > > current syntax region, and return a value appropriate for the embedded
              > > file type. I think there are already some scripts that work this way,
              > > but maybe not yet any in the standard distribution.
              >
              > > This approach relies on the syntax files to determine the embedded
              > > file types. This is probably A Good Thing.
              >
              > > :help synID()
              >
              > I'm not much an expert about syntax highlighting ... is it
              > possible to define syntax regions without actually 'highlighting'
              > them?
              Yes. You simply do not link the region to one of the predefined regions that
              have highlighting defined for them (e.g., Comment, String, Error, etc...).
              Alternatively, you can define a region as transparent, to ensure that the
              highlighting of the containing region shows through.

              >
              > In either case, I think the regions thing should come "before"
              > syntax highlight. We can make the two things cooperate by:
              > (1) allowing syntax highlight groups to be defined based on
              > regions
              > (2) allowing syntax groups definitions to automatically define
              > regions [sort of like folds being defined by indents]

              In my opinion, folding would be more useful if it could be made to act in a
              non-linewise manner. Not allowing 2 different folds to exist on the same
              line seems to me to be an artificial limitation, given the fact that many
              useful programming languages are not line-oriented. I realize, of course,
              that allowing characterwise fold definitions would greatly complicate the
              implementation. Just wondering if anyone else has found this to be a
              limitation...

              Brett S.
              >
              > --
              > Giuseppe "Oblomov" Bilotta
              >
            • Giuseppe Bilotta
              ... I really can t think of a way characterwise folding could be implemented ... would you simply remove the collapsed chars (which might span a few lines)
              Message 6 of 8 , Dec 2, 2002
              • 0 Attachment
                On Monday, December 2, 2002 Brett Pershing Stahlman wrote:

                > In my opinion, folding would be more useful if it could be made to act in a
                > non-linewise manner. Not allowing 2 different folds to exist on the same
                > line seems to me to be an artificial limitation, given the fact that many
                > useful programming languages are not line-oriented. I realize, of course,
                > that allowing characterwise fold definitions would greatly complicate the
                > implementation. Just wondering if anyone else has found this to be a
                > limitation...

                I really can't think of a way characterwise folding could be
                implemented ... would you simply remove the "collapsed" chars
                (which might span a few lines) and virtually substitute them with
                a (possibly visible but one-char-wide-only) mark?

                --
                Giuseppe "Oblomov" Bilotta
              • Vince Negri
                ... Rather like the conceal patch... Vince Legal Disclaimer: Any views expressed by the sender of this message are not necessarily those of Application
                Message 7 of 8 , Dec 2, 2002
                • 0 Attachment
                  > I really can't think of a way characterwise folding could be
                  > implemented ... would you simply remove the "collapsed" chars
                  > (which might span a few lines) and virtually substitute them with
                  > a (possibly visible but one-char-wide-only) mark?

                  Rather like the 'conceal' patch...

                  Vince
                  Legal Disclaimer: Any views expressed by the sender of this message are
                  not necessarily those of Application Solutions Ltd. Information in this
                  e-mail may be confidential and is for the use of the intended recipient
                  only, no mistake in transmission is intended to waive or compromise such
                  privilege. Please advise the sender if you receive this e-mail by mistake.
                • Brett Pershing Stahlman
                  ... From: Vince Negri To: Giuseppe Bilotta ; Brett Pershing Stahlman Cc:
                  Message 8 of 8 , Dec 2, 2002
                  • 0 Attachment
                    ----- Original Message -----
                    From: Vince Negri <vnegri@...>
                    To: 'Giuseppe Bilotta' <gip.bilotta@...>; Brett Pershing Stahlman
                    <brett.stahlman@...>
                    Cc: <vim-dev@...>
                    Sent: Monday, December 02, 2002 9:23 AM
                    Subject: RE: Re[4]: A possible enhancement for the next release: regions


                    > > I really can't think of a way characterwise folding could be
                    > > implemented ... would you simply remove the "collapsed" chars
                    > > (which might span a few lines) and virtually substitute them with
                    > > a (possibly visible but one-char-wide-only) mark?
                    >
                    > Rather like the 'conceal' patch...
                    I have not tried the conceal patch, but yes, a one-character-wide glyph of
                    some sort was what I had in mind. Perhaps some descriptive text for the
                    fold, embedded within special delimiters in the original file, could be
                    hidden along with the folded text, and shown only when requested with a
                    special fold command.

                    Brett S.
                    >
                    > Vince
                    > Legal Disclaimer: Any views expressed by the sender of this message are
                    > not necessarily those of Application Solutions Ltd. Information in this
                    > e-mail may be confidential and is for the use of the intended recipient
                    > only, no mistake in transmission is intended to waive or compromise such
                    > privilege. Please advise the sender if you receive this e-mail by mistake.
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.