Any function calls that occur on the same line as a => gets colored as a function definition. This actually extends outward to the left; nested calls are all colored, unless an outer call occurs on a separate line.

Also note the weird indentation--though I think that's JunoLab/Atom.jl#62, which has been addressed.

The package.json file says MIT, but could always be more explicit about it.

Should ask for permission on reused code from the previous package, just in case.

Everything after is ends up being highlighted as if it was a string. So in that example the closing brace would be highlighted the same colour as the brace between the quotes.

t("(")

This seems to of been caused by the latest update too by the way

Normal transposes, e.g. x' are colored normally, but adding the transpose after ) makes things a little funky:

@spencerlyon2 do you have any objections to this? I invited you to that organization.

It appears exp.(x) isn't highlighted at all, whereas the exp is highlighted in exp(x).

I noticed that usually functions (kind a orange) that are typed get the type brace colored yellowish,
which I think is nice. However, this does not happen for typed operators, as the following screenshot illustrates.

Is that intentional? I think it would be nicer to have a typed operator also embraced with a yellowish type bracket

Assuming we're replacing the existing language-julia package, I think we need a higher version number. Right now, my (heavily modified local install of) Atom prompts me to upgrade this package to the old package that we're replacing.

Consider this code:

f(g("($A)"))
f(g("($B)"))
f(g("($C)"))

The highlighting it produces is broken (closing parenthesis is matched inside the string):

continue! is a valid identifier

Only a small thing, but this doesn't auto-indent the cursor on newline:

@time foo begin

It seem to treat them as single quotes only.

example:

"""Contains " quote " characters"""

Enabling the plugin fails with error: Uncaught Error: spawn julia ENOENT (events.js).

The Julia style guide prefers 4 spaces, but currently the default tab spacing in atom is 2 spaces.

Not sure if this is a problem in this package or somewhere else, but when I try tab-completions of submodules the parent module gets consumed. Eg. - if I'm using Gadfly and type Coord., I get a list of completions, select Cartesian and hit <tab>, then instead of Coord.Cartesian I end up with just Cartesian

The following code breaks the highlighting logic:

edit_magic_help(magic::AbstractString, args::AbstractString) = md"""
    An analogue of IPython's `%edit` magic is provided by
    the `edit` function and the `@edit` macro in Julia, as
    described [in the Julia manual](http://docs.julialang.org/en/latest/stdlib/base/#Base.edit).

    For example, instead of `%edit -n line 'filename'"` in IPython, you would do
    `edit("filename", line)` followed by `include("filename")` if you
    want to execute the file when you are done editing.  The analogue
    of `%edit` (which creates a temporary file) is `n=tempname(); edit(n)`
    followed by `include(n)`.

    If you have a function `foo()`, then `%edit foo` in IPython opens
    the file where `foo` was defined.  The analogue of this in Julia is
    to do `@edit foo()`   Note that you need to supply sample arguments
    to `foo` (which is not actually called), so that Julia knows *which*
    method of `foo` you want to edit.

    If `s` is a string variable, IPython's `%edit s` loads its contents
    into an editor.  In Julia, you would have to explicitly write
    to a temporary file with `n=tempname(); write(n, s); edit(n)` followed
    by `include(n)` to execute it."""

# any subsequent code is highlighted as if it were part of a string!!

sorry for posting a question here instead of an issue - but if I wanted to move to atom-language-julia from language-julia, how would I do it?

(Perhaps something in README.md?)

Hi all,

Sorry - didn't know where else to put this, but it would be great to have something that integrates with atom-linter.

I have just installed Juno-atom on my windows 7 64bit Pro PC. Julia version is 0.4.5 and it runs OK in its own window. I cannot get Juno to recognize the path "C:\Users\Eagle\AppData\Local\Julia-0.4.5\bin\julia.exe" I have tried "//", "", "", everything I can think of. It will not recognize the path.

What am I doing wrong?

Thank,

Tom Eagle

Highlighting every other of the following is worse than no highlighting at all:

x = [Int, Bool, Vector, Array, Integer, FloatingPoint, DataArray, DataFrame]

Seems like consistent options are:

• Highlight every type exported from Base
• Go farther highlighting everything that's proven to be a type by syntax (e.g. x = Union{...............})
• Both of the above
• Remove 'storage.type.julia'

I think the latter is the cleanest and means the least distracting false alarms, but I wouldn't be that surprised if others like the second option.

Thoughts?

It would be nice to be able to code fold the docstrings.

edit: looks like this is a limitation in atom itself atom/first-mate#48

From JunoLab/atom-ink#42

Whenever it type doc<Tab>, the docstring snippet from language-julia is inserted.

So that we can use the "go to symbol" functionality.

If you evaluate the whole script via Shift+Enter, the script will run but the plots won't display. Example code:

using Gadfly
x = 0:.01:2
y = rand(length(x))
println(y)
plot(layer(x=x,y=y,Geom.line))

If you Shift+Enter, it prints y but does not display the plot. If you then click to the line for the plot and do Ctrl+Enter it will display the plot.

The following two snippets should be interpreted identically.

x::UInt8
x   ::   UInt8

When you have a function or type constructor which takes lots of arguments, such that you break them up into multiple lines, it is nice to be able to align them. :)

function doit(
        firstarg :: Int
        second   :: UInt
        third    :: Bool
        forth    :: AbstractArray)

   # function body
end

Or, if they are kwargs...

function doit(;
        firstarg ::           Int = -45
        second   ::          UInt = 247
        third    ::          Bool = true
        forth    :: AbstractArray = [])

   # function body
end

See screenshot:

It would be great to have the emacs and REPL functionality for replacing LaTeX commands with the right unicode symbols here, as well.

It would be helpful for me.

For example, I type this:

for i in 1:3

hit Enter and get this:

for i in 1:condition ? if_true : if_false

So I have to hit Esc, then Enter. Really?

Meanwhile, maybe there's a workaround that can be used?

The current regex to increase indentation level is

^(\\s*|.*=\\s*|.*@\\w*\\s*)(if|while|for|function|stagedfunction|macro|immutable|type|let|quote|try|begin|.*\\)\\s*do|else|elseif|catch|finally)\\b(?!.*\\bend\\b[^\\]]*$).*$

Pasting that into http://regexpal.com/ highlights an extra closing paren. I'm not familiar enough with what this regex is supposed to do, but I'm guessing that might be causing some trouble.

This thing breaks highlighting on atom-language-julia 0.2.0:

 f("\"")
 f("\"")

ref JunoLab/uber-juno#7

If I have the following @doc string

"""
    myFunction() computes something based on the reference
> My Paper I Would like to quote
> Further quote...
"""

The editor gets confused in its markup and does not recognize the closing """. Everything until the end of the document is marked as if it was code in (colorwise).

However as noted by @spencerlyon2 here adding an empty line direktly after the last line starting with > fixes the markup, i.e.

"""
    myFunction() computes something based on the reference
> My Paper I Would like to quote
> Further quote...

"""

yields a correct color markup and the same if even theres more text following the quote, it only colors the code following correctly if theres a blank line after the blockquote.

e.g. :type.

This docstring makes highlighting go funky:

"""
    @switch isa(x, _) begin
      Integer; "x is an integer!"
      FloatingPoint; "x is a float!"
      "x is something else!"
    end

Where `_` is replaced by the value for testing in each case. The final
"""
macro switch(args...)

The _ seems to start an italic section despite being in a code block, and this doesn't happen without the ). Also, for some reason the final """ isn't closing off the docstring either.

Highlighting top-level strings as markdown is a great idea, but maybe it would then be good to remove the string scope so that the default colour isn't yellow. It'd also be pretty cool if we could highlight indent code blocks as Julia by default.

There's some confusion in the spec as to what really constitutes a symbol, and in turn how we check for and handle the keyword.other, storage.modifier and keyword.control categories.

At the moment, we tokenize general symbols (e.g. :foo) with a negative look behind checking for a :. The colon here matches another representation, which is the keyword.operator.range.julia category (previously operator.ternary) and what follows becomes constant.other.symbol.julia.

Thus, we have two different colours highlighting one thing, and in the back end we get this complication that symbols are actually somehow also a range. The probable fix for this would be drop the negative look behind for symbols, but add a negative look ahead on the range.

The second point, which is where I feel some confusion comes in inside the spec are the checks for these three categories I listed above. Each have a test that matches scopes exactly the same as the symbols, so whilst they currently pass, it looks as though these tests are incomplete. In addition to that, storage.modifier's test looks for :using, but using isn't even in storage.modifier, it has its own category keyword.control.using.julia.

What I think needs to happen here is actually drop the : in front of each of the tests for these three categories. Why are we testing for symbols of these keywords anyway? I may be missing something here, but it seems to make more sense without the colons. Then the tests can be matched against the proper scopes.

If this gets sorted out, I'd say that #75 should also be inherently (or at least easily) solved.

I think I can fix these issues pretty quickly, but some feedback on my thoughts would be appreciated.

In

xs[i]

we would have that xs is scoped as a type. I can think of a few instances where we want this to be a type:

• Float64[] -- creating an empty, typed array
• Float64[1, 2, 3] -- creating a non-empty, typed array
• Float64[f(i) for i in x]-- typed comprehension

Not sure how we separate case 2 and indexing...

Maybe we just wait until when (if?) Jeff wins and we moved the type for typed comprehensions/arrays to the end (e.g. [...]T instead of the current T[...])

The highlighting of '(transpose) is mistakenly recognized as '' when using cascaded subscripts:

Currently, a workaround is to use brackets, but I hope this can be fixed. Thanks!

If you make a plot in Gadfly but then want to split the plot to a new screen, you get the following error. I was able to reproduce it on 3 computers: 2 Windows, 1 Linux.

Uncaught Error: The workspace can only contain one instance of item [object Object]
/usr/share/atom/resources/app.asar/src/item-registry.js:11
Hide Stack Trace
Error: The workspace can only contain one instance of item [object Object]
at ItemRegistry.module.exports.ItemRegistry.addItem (/usr/share/atom/resources/app.asar/src/item-registry.js:11:15)
at PaneContainer.module.exports.PaneContainer.addedPaneItem (/usr/share/atom/resources/app.asar/src/pane-container.js:374:25)
at /usr/share/atom/resources/app.asar/src/pane-container.js:353:19
at /usr/share/atom/resources/app.asar/src/pane-container.js:97:16
at Function.module.exports.Emitter.simpleDispatch (/usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:25:14)
at Emitter.module.exports.Emitter.emit (/usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:125:28)
at PaneContainer.module.exports.PaneContainer.didAddPane (/usr/share/atom/resources/app.asar/src/pane-container.js:293:27)
at Pane.module.exports.Pane.setContainer (/usr/share/atom/resources/app.asar/src/pane.js:98:26)
at PaneAxis.module.exports.PaneAxis.addChild (/usr/share/atom/resources/app.asar/src/pane-axis.js:144:13)
at PaneAxis.module.exports.PaneAxis.insertChildAfter (/usr/share/atom/resources/app.asar/src/pane-axis.js:216:19)
at Pane.module.exports.Pane.split (/usr/share/atom/resources/app.asar/src/pane.js:710:23)
at Pane.module.exports.Pane.splitRight (/usr/share/atom/resources/app.asar/src/pane.js:672:19)
at atom-tabs.TabBarView.splitTab (/usr/share/atom/resources/app.asar/node_modules/tabs/lib/tab-bar-view.js:392:31)
at Object.addElementCommands.tabs:split-right (/usr/share/atom/resources/app.asar/node_modules/tabs/lib/tab-bar-view.js:127:26)
at atom-tabs.commandsWithPropagationStopped.(anonymous function) (/usr/share/atom/resources/app.asar/node_modules/tabs/lib/tab-bar-view.js:78:36)
at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app.asar/src/command-registry.js:260:29)
at CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app.asar/src/command-registry.js:3:61)
at CommandRegistry.module.exports.CommandRegistry.dispatch (/usr/share/atom/resources/app.asar/src/command-registry.js:160:19)
at AtomEnvironment.module.exports.AtomEnvironment.dispatchContextMenuCommand (/usr/share/atom/resources/app.asar/src/atom-environment.js:1019:28)
at emitTwo (events.js:87:13)
at EventEmitter.emit (events.js:172:7)
at EventEmitter.ipc.sendSync (/usr/share/atom/resources/atom.asar/renderer/api/lib/ipc.js:21:31)
at BrowserWindow.RemoteMemberFunction as emit
at ContextMenuManager.module.exports.ContextMenuManager.showForEvent (/usr/share/atom/resources/app.asar/src/context-menu-manager.js:156:33)
at WindowEventHandler.module.exports.WindowEventHandler.handleDocumentContextmenu (/usr/share/atom/resources/app.asar/src/window-event-handler.js:250:47)
at HTMLDocument. (/usr/share/atom/resources/app.asar/src/window-event-handler.js:3:61)
The error was thrown from the tabs package. This issue has already been reported.

Regular variables like foo are not highlighted any more specifically than source.julia. I don't know what the standard is for variables but if we could label them as identifier or variable or something that would be really useful.

The reason being that secret plugins, which may or may not exist, might want to highlight variables differently depending on whether they are defined or not.

I think it would be helpful if the default highlighting for symbols was different from type annotations, functions, etc. As it stands, if you use some symbols, your whole code turns the same color (as seen in the picture).

e.g.

Base.map(+, 4:-1:2) # 'Base.' is highlighted as part of the function
Base.@time(1 + 1) # 'Base.' is not

I'd prefer not highlighting as part of the function, as it would leave Base. highlighted consistently with Base.CONST, import Base, etc.

Thoughts?

I don't have admin rights to this repo, so I can't flip the switch.

@johnmyleswhite, can you flip travis on for the repo?

Here is the issue:

in

# TODO do a thing

The TODO should be highlighted. It it not. By comparison with

#=
TODO do a thing
=#

where it is. TODO and a few others are part of language-todo, which is standard in atom.

Atom v1.1.0 now officially supports ligatures. When this package is active, not all ligatures are displaying.

An example: The left frame has a Julia file and the right an untitled document. The untitled document has != and <= ligatures working, although once saved into a .lj and syntax highlighted, the ligatures are no longer visible.

Not all ligatures are removed, for example -> still works. The problem doesn't occur in other file types (for example a .cpp or .hs file, which aren't syntax highlighted via this package), and I've tested this with most of the ligature enabled fonts: no changes there either.

Similar to how you can have open brackets match with close brackets, it'd be cool to be able to match the closing end with the corresponding begin, for, or while block starter.

since the release of 0.9.0, atom seems to be extremely confused about which package to install, this one, or the one created by tpoisot.

Could you please tag 0.9.1, just so atom can distinguish the two packages again.