The issue here is as follows:
The old code was not merging a the paragraph terminator when content was added.
This left an extra terminator which caused all kinds of problems with the table
code (I do not remember the details.) It’s also questionable whether it’s a
good idea to preserve formatt
Nope. That only works at the end of the last paragraph. When inserting at the
end of an intermediate paragraph, the second span gets added to the beginning
of the next paragraph.
On Sep 19, 2015, at 10:54 PM, Harbs wrote:
> Hi Mihai,
>
> I think I just fixed it in commit 96a959d1b943630e68a82
Yeah, changing FalconJX to handle window as a special case would work too.
It would make things easier on other tools, like externc and dts2as. As a
bonus, while it's a simple string that we wanted to avoid, it's actually
valid JS, so it wouldn't have as much potential for conflict. I think I
like
Inline as well, gotta scroll way down for my latest proposal.
On 9/19/15, 9:01 AM, "Josh Tynjala" wrote:
>Responses inline.
>
>- Josh
>
>On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui wrote:
>
>>
>> Hmm. Maybe, but what does that sort of import really do? Why not just
>> create a global subclass
Hi Mihai,
I think I just fixed it in commit 96a959d1b943630e68a826a1cf1fc804c73e8b95.
Please confirm.
On Sep 19, 2015, at 10:19 PM, Harbs wrote:
> Thanks for the reminder.
>
> I will try to look at this tomorrow.
>
> Harbs
>
> On Sep 19, 2015, at 10:07 PM, Mihai Chira wrote:
>
>> bump
>>
Thanks for the reminder.
I will try to look at this tomorrow.
Harbs
On Sep 19, 2015, at 10:07 PM, Mihai Chira wrote:
> bump
> On 9 Sep 2015 18:37, "Mihai Chira" wrote:
>
>> Hey guys (addressed to Piotr and Harbs),
>>
>> if you have time to take a look at this, it would really help. I have
>
bump
On 9 Sep 2015 18:37, "Mihai Chira" wrote:
> Hey guys (addressed to Piotr and Harbs),
>
> if you have time to take a look at this, it would really help. I have
> a feeling you'd have much better ideas on how to go forward with the
> fix.
>
> Many thanks!
>
>
> -- Forwarded message ---
Responses inline.
- Josh
On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui wrote:
>
> Hmm. Maybe, but what does that sort of import really do? Why not just
> create a global subclass of goog.events.Event?
>
A global subclass would work only if you were creating all instances. If
you need to use th
On 9/19/15, 7:43 AM, "Josh Tynjala" wrote:
>I think that making it possible to reference a class in the global
>package,
>even when another class with the same name is imported, is a good
>improvement. Probably easiest to implement.
>
>Along the same lines as an unimport, what if we could do so
Yeah, I vaguely remember something about the methods not being stored on
the prototype too. It makes sense if you consider that stuff we had to add
for event listeners to keep the right scope.
Regardless, even if it's not on the prototype, it's still accessible like
obj["identifierName"], so that'
I think that making it possible to reference a class in the global package,
even when another class with the same name is imported, is a good
improvement. Probably easiest to implement.
Along the same lines as an unimport, what if we could do something like
this to remove ambiguity:
import GoogEv
11 matches
Mail list logo
