We could and that's the approach we use in the formatter but we can't use
it generally because it would break stuff like keyword lists (as the first
element is now a tuple __block__ and no longer an atom).
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R
On Wed,
One thing that comes to mind for "simple value" cases like this: we could
use the existing :__block__ ast node with a single child as nodes for
simple values which have metadata attributes. AFAIK __block__ ast nodes now
always have > 1 child.
This works:
iex(7)> {:__block__, [], [:a]} |>
Thanks José,
This is indeed a topic of interest to me. Actually, part of my talk in
Prague coming tuesday will be about this. I'll let it simmer for now and
maybe we can have a chat during the conference!
cheers, Arjan
On Wednesday, April 3, 2019 at 9:07:24 PM UTC+2, José Valim wrote:
>
> Hi
Hi Arjan,
I don't believe there was any progress here. Storing it in the AST would be
hard because some nodes have no metadata slot, so it would be tricky in
situations like this:
# Let's return just an atom for now
:foo
However, we do have the ability to return comments from tokenizer and the
Hi Steve, just stumbled on this, do you know if anything ever happened to
this?
On Sunday, September 23, 2018 at 1:10:38 AM UTC+2, Steve Morin wrote:
>
> Tried on Slack but I'll try freenode next
>
> On Fri, Sep 21, 2018 at 10:47 AM OvermindDL1 > wrote:
>
>> #elixir-lang on freenode for note*
Thanks for that.
On Wednesday, April 3, 2019 at 9:33:13 PM UTC+4, José Valim wrote:
>
> Generally speaking, the project .gitignore should only have contents
> specific to your project.
>
> Files that are generated by your editors or .DS_STORE, which is specific
> to your OS, should be in your
Generally speaking, the project .gitignore should only have contents
specific to your project.
Files that are generated by your editors or .DS_STORE, which is specific to
your OS, should be in your global gitignore:
https://help.github.com/en/articles/ignoring-files#create-a-global-gitignore
would it hurt to add .DS_Store to the .gitignore of new mix projects :/
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
On Wednesday, April 3, 2019 at 9:50:31 AM UTC-3, Norbert Melzer wrote:
>
> You said, you haven't elaborated on tree-parsers benefits, as you think
> the linked page did a better job than you could.
>
> But the web page tells me about nothing.
>
> On the first paragraph it looks like if it wants
> On Apr 3, 2019, at 3:12 AM, João Paulo Silva de Souza
> wrote:
>
> What exactly are those effects that could pose issues?
> Nested macro blocks inside of another macro?
> Ambiguous syntax due to macro usage?
Sorry, but if I had had a real effect to suggest, I would have done so.
I simply
I don't see this as something core wants to take on, but it would be great
if there were a group of people dedicated to editor support. The closest
thing to that right now is: https://github.com/elixir-lsp
Allen Madsen
http://www.allenmadsen.com
On Wed, Apr 3, 2019 at 8:50 AM Norbert Melzer
You said, you haven't elaborated on tree-parsers benefits, as you think the
linked page did a better job than you could.
But the web page tells me about nothing.
On the first paragraph it looks like if it wants to be a modern replacement
for YACC/BISON, not even telling us, what language it can
Hi Rich
I am new to this whole ecosystem, and don't use BBEdit,
but regarding development tools, have you had a look at
CodeRunner and their language setup:
They use textmate language grammar which seems to be regular expression
based
https://macromates.com/manual/en/language_grammars
This
I should also mention that Tree-Sitter still isn't as wide as the makers
intend it to be (e.g. it doesn't handle gracefully many megabytes of code
in a single file
What exactly are those effects that could pose issues? Nested macro blocks
inside of another macro? Ambiguous syntax due to macro usage?
IMO Tree-Sitter will be at least as correct as current RegExp syntaxes,
while being faster, with the upside of potentially turning out much better.
The worst
Writing regexes to parse programming languages is painful at best
and impossible at worst. (I looked into trying to improve BBEdit's
rules for Elixir and backed away quickly :-/). So, I'm glad to see
a Real Parser (TM) being applied to the problem of code parsing in
text editors.
That said, I
Ben, thank you for the attention. I held myself off elaborating further
because the introductory content in the project's page does a much better
job.
Tree-Sitter parses code and builds an AST out of the nodes. That same tree
can then be smartly updated continuously by providing the locations
17 matches
Mail list logo
