Multe-line strings about language-powershell HOT 9 CLOSED

Thanks for taking the time to let me know and put together an issue! After some digging, though, it appears the grammar handles multi-line strings correctly and plain quotes don't delineate a multi-line string.

From this post, it looks like multi-line strings are bookended by @" and "@ and not just plain quotes.

Using the example from that page in the language grammar tool you showed seems to indicate that everything's fine.

That's a very nice tool! i've seen it before but appreciate the reminder 😄

from language-powershell.

PowerShell grammar allows such strings. You can try it in powershell_ise:

The one that you refered are known as "here docs strings". They purpose is to eliminate need in escaping quotes (useful for code-snippets and docs).

Sergei Vorobev
Windows PowerShell team

from language-powershell.

Ah, you're right! Thanks for being patient with me, i'll look into fixing it soon.

Sergei Vorobev
Windows PowerShell team

haha, i guess i should know who i'm disagreeing with, huh? 😊

from language-powershell.

Yeah, pushing with authority :P

I sent you message on twitter about https://github.com/SublimeText/PowerShell
I think we should collaborate and work on grammar together: there is no point to redo same work in two different places and solve same problems. Atom and SublimeText uses compatible grammars descriptions to describe the syntax.

from language-powershell.

Sorry if I sounded offensive, didn't mean that.
A little tired at the end of the week.

from language-powershell.

ah, i didn't see those twitter messages until now, i usually catch them earlier.

Sorry if I sounded offensive, didn't mean that.

i didn't think it sounded offensive, or take any offense 😉

I think we should collaborate and work on grammar together

i'd be very happy to cooperate! i didn't know you were working on that sublime grammar. When i originally saw your issue, i planned to try converting over that package to see if it did a better job than what i already have in place... i guess i'll be doing that more often soon!

Where do you think we should start?

from language-powershell.

It makes sense to have the same grammar (physically same files) in both places in the long run. It can be done with pulling grammar to the separate module and including it as a sub-module, merging two repos, or some other way that I cannot think of right now. But it's a pretty ambitious project and I would not suggest to start with it.

We can start small and make our grammar files the same manually, without enforcing it on the source control level. In sublime text we can convert between three forms of grammar files: plist / xml, json, yml. We use xml as a master file for grammar, because sublime consume it, but we edit grammar in yml, because it's easier.

As far as I see, atom use cson which is pretty much json, right? I looked up atom highlighting for our test file and there are few problem. You can open the file in atom and easily identify them. For instance, something is broken in here-doc-strings, so the whole end of the file is treated as a string.

My suggestion:

1. I want you to try our grammar in your test cases and maybe some manual test cases, if you have them. If you need help with converting xml to cson, let me know.
2. If you find some problems, please let me know. I will open issues in our bug tracker.
3. I will investigate your grammar to identify any cases that you covered, but we missed.
4. Once we have this sense of projects, we can think about a strategy to align grammars.

Does it make sense?

from language-powershell.

i think that makes sense... i'll see how implementing some of these ideas goes in the near future. i'm hoping that i can use apm's textmate grammar conversions to get from your stuff to a cson grammar file that atom will use.

As far as I see, atom use cson which is pretty much json, right?

Yup, right.

Thanks for the test file. i'm not sure what this grammar will have that yours doesn't, though.

from language-powershell.

i did a first pass at vendoring the PowerShell grammar into this one. So far so good! Take a deeper look at #36 😄

from language-powershell.