Actually, the possibility of multi line __MSG_ substitutions probably makes the hunking process necessary as well, so I guess I'm +1 on Ihab's proposal.
~Kevin On Jan 18, 2008 4:04 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > With the introduction of multiple content sections, plus the fact you've > already mentioned that messages and other substitution can lead to line > number modification (and certainly column modification), I actually like > the > List<Hunk> idea. > > This will be especially so once we support some mechanism for inclusion of > one content section in another. > > --John > > On Fri, Jan 18, 2008 at 3:56 PM, <[EMAIL PROTECTED]> wrote: > > > On Jan 18, 2008 3:11 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > From what I can tell right now, we're probably going to only wind up > > with 1 > > > "Hunk" anyway, since the inlining of the other files will wind up > > happening > > > in the cajoling process rather than in shindig itself. > > > > Okay, so we assume then that the only change you are making to the > > content is message substitution, and that this does not substantially > > affect file positions (i.e., it does not affect *line* number)? If so, > > then you're right, we only need 1 hunk. > > > > If so, then the information we need is the start position for the > > [one] hunk, right? And we don't need the inline annotations, right? So > > we end up with -- > > > > GadgetContentRewriter.rewriteContent( > > ..., > > FilePosition start, > > Readable content, > > ...); > > > > Does this look okay then? Does everyone -- Shindig and Caja -- like > > this better? What are the limitations? > > > > Ihab > > > > -- > > Ihab A.B. Awad, Palo Alto, CA > > >
