Arch Linux

These are just minor problems, so I don't see any reason why should we use an old Electron. Old Electron comes with old Chromium, which contains many vulnerabilities, thus insecure to use:
http://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/Google-Chrome.html

I think that upstream developers should support the latest releases of electron. If you found any problems, then bother upstream to fix it.

These vulnerabilities are important for a browser. Not so much for a code editor.

I also think that the upstream supported Electron version should be used. There are too many incompatibilities between major releases of Electron (most of which due to V8), upgrades are not as simple as a version bump, and it's naive to think that everything will just work with a newer major release than the officially supported and tested one.

In my case Atom from this package does not even start, and I strongly suspect this to be the cause.

well security its not that simple. atom is meant to be extended where you pull in potentially untrusted javascript... plus you may also open untrusted files with a code editor. Of cause its less compared to browsing the webm but saying its not so important is simply wrong.

before blindly guessing into the wild, could you try to rebuild a older version of electron yourself and test if that works?
Electron itself should be kept up-to-date so if this gets decided, it would basically mean to maintain an additional legacy version -,-

> before blindly guessing into the wild, could you try to rebuild a older version of electron yourself and test if that works?

Not for a few days. But I get this in dmesg each time I try to start Atom:

> [ 2539.736730] traps: electron[4719] trap invalid opcode ip:18a4291 sp:7ffdf6f06850 error:0 in electron[400000+3b8b000]

> Electron itself should be kept up-to-date so if this gets decided, it would basically mean to maintain an additional legacy version -,-

Not necessarily as a separate package, could be part of this package's build. Just like e.g. nodejs builds its own V8.

Electron is an application framework, and there is a web browser which uses it:
https://aur.archlinux.org/packages/min

So I think we have the following options:
1. Fix the autocomplete-plus plugin ASAP.
2. Remove the autocomplete-plus plugin from the package until it gets fixed.
3. Drop Atom from the official repositories, because it's unsupported by upstream.

I don't like the idea to bundle an old Electron release with Atom. If you want this, then you can download the pre-built packages from https://atom.io/ .

@onestone: are you using a 32 bit system? Please open a new task for this issue.

> @onestone: are you using a 32 bit system? Please open a new task for this issue.

No, my arch is x86_64 (with Multilib enabled).

>So I think we have the following options:
>1. Fix the autocomplete-plus plugin ASAP.

I doubt this will be the only issue caused by using an incompatible Electron version.

> 2. Remove the autocomplete-plus plugin from the package until it gets fixed.

Unacceptable, autocomplete-plus is an essential plugin, nearly all supported languages use it. Atom would be crippled without it.

> I don't like the idea to bundle an old Electron release with Atom. If you want this, then you can download the pre-built packages from https://atom.io/ .

There are two good AUR packages which bundle a compatible Electron release - atom-editor and atom-editor-bin. I've had good experience with both of them.

Is there any specific reason to not like this idea btw? It's not a precedent. E.g. nodejs does the same (it also demands a specific V8 version).

as György already pointed out, security is a pretty good point and just because the pre-built or ancient bundled versions in AUR work, doesn't mean it makes sense.

Your issue why its not starting is because electron was built with native mtune and uses AVX instruction sets while your CPU does not seem to support such. Thats a bug in electron and a ticket should be opened accordingly that it respects mtune=generic from /etc/makepkg.conf CFLAGS/LDFLAGS and does not override it:
> objdump -d ./usr/lib/electron/electron|grep -i vbro
70d020: c4 e2 7d 1a 25 f7 56 vbroadcastf128 0x3ce56f7(%rip),%ymm4 # 43f2720 <_ZN20TtsPlatformImplLinux21current_notification_E@@Ba
...
70e922: c4 e2 7d 18 ed vbroadcastss %xmm5,%ymm5
...

> as György already pointed out, security is a pretty good point

Extensions already have the power to break anything in $HOME. Regarding opening untrusted files, the danger is pretty small, as these files are only parsed, not executed. I'm not saying security is not important, but it's less important in a code editor than in a web browser. Correctness can (and IMHO should) be prioritized here.

> just because the pre-built or ancient bundled versions in AUR work, doesn't mean it makes sense

This is misrepresenting the issue. Let me try to summarize it again:

- Major Electron releases are not completely backwards compatible. This is often caused not only by Electron itself, but also by its own dependencies - V8 and Node.js. V8 in particular introduces breaking API changes quite often.

- Upgrading to a newer Electron major release is not trivial. It's not enough to just bump the version, it also takes extensive testing and fixing what has been broken. Atom periodically upgrades its Electron dependency, but not with every release, as it is a time-consuming task. Please see this comment from an Atom developer: https://github.com/atom/atom/issues/11967#issuecomment-225974781 (relevant quote: "So we will move to new versions of Electron as we can, when it makes sense, when we can guarantee a certain level of stability for all users of Atom, when we can work with our package authors (who we feel are a significant part of Atom's success) to ensure that their hard work isn't broken or at least they have fair warning, and when the benefits outweigh the downsides. We won't commit to a timeline because every new version of Electron brings with it new challenges. Some take longer and some are easier.").

P.S. Thank you for diagnosing my issue. Strange, my CPU is Sandy Bridge and it supports AVX.

There are only 2 right ways to fix it:

1) Bundle 'atom' package with an appropriate Electron version, just like 'atom-editor' from AUR does (and just like Node.js is shipped with appropriate V8 version).
2) Create a separate package, electron0.37.8, and change Atom's dep accordingly – but I found that way a lot less nice, especially because Atom's Electron version changes often.

We can't just fix 'autocomplete-plus' plugin and believe that no more bugs will appear – as Peter said, newer Electron versions breaks and deprecates a lot of API, and upgrading Atom to it is a non-trivial task (I mentioned a link to related issue in head post).

Peter, you mentioned an error in dmesg. By chance are you using linux-lts? Another user had a problem with it (https://github.com/tensor5/arch-atom/issues/34).

The incompatibilities between atom and the latest version of electron have a trivial fix the vast majority of the times, and if they are not fixable right away I delay upgrading electron. The issue with autocomplete-plus also have a trivial fix, thanks for reporting it.

> Peter, you mentioned an error in dmesg. By chance are you using linux-lts? Another user had a problem with it (https://github.com/tensor5/arch-atom/issues/34).

Yes. I also responded on the GitHub issue you linked, let's continue the discussion about this there.

I just uploaded a new release that fixes the autocomplete-plus issue.

I get "Error: Path must be a string. Received null" when try to open any js-file in atom with installed 'linter-eslint' package. Have no errors with bundled electron.

Vasyl, I opened a PR just now https://github.com/AtomLinter/linter-eslint/pull/673. Meantime you can fix it manually by applying the changes in the PR to your ~/.atom/packages/linter-eslint.

This also causes this bug:
https://github.com/atom/atom/issues/12534

NicoHood, I fixed it in 1.9.9-3. Please try it and let me not if there is any side-effect to my patch.

Thanks a lot! That seems to work :)

Fresh install on a new arch system: The editor window is entirely black, there is no welcome screen, no tree view, etc...

Hi Geoffrey,
I tried to reproduce your problem by removing .atom and .config/Atom. It starts regularly with welcome page and welcome guide.
Can you try and launch electron alone, and electron --app=/usr/lib/atom, and see if you get some some error message on the terminal.

After deleting ~/.atom/ and ~/.config/Atom (I think I forgot to try this one yesterday), it works well. That's strange because I"m sure it didn't work at the very first start. Thanks

> Vasyl, I opened a PR just now https://github.com/AtomLinter/linter-eslint/pull/673.
Thanks, it works after release 7.3.0.

I have another one "Path must be a string" error when trying to open new file (Ctrl+N). The cause is the 'react' package:
https://github.com/orktes/atom-react/blob/master/lib/atom-react.coffee#L126

https://github.com/orktes/atom-react/pull/196

Since the latest update of Node.js to 7.0.0, apm has stopped to work completely. I reported this upstream (https://github.com/atom/apm/issues/635), but the devs say that Atom must be bundled with the appropriate version of Electron.

Now, I can only use apm if I downgrade Node :(

@cle1109 and @laurybueno, apm 1.14.0-2.

@tensor5 thank you so much for the great work!

@tensor5 thanks a lot, great work!

I currently have 2 problems with atom:
Sometimes the scrol bar is not shown when the windows is in full screen. This also sometimes happens with splitted view where one of both views does not work.

I always get the welcome message when I open atom. Annoying but acceptable for now.

Another reason to package the official release is documented here: https://github.com/atom/tabs/issues/395

Thanks for reporting.

@NicoHood, I noticed the scrollbar issue and I'll look into it. I don't have the welcome message problem.

@Chais, that's another "path must be a string" type of problem, I'll fix it soon.

Fortunately starting from v1.12 Atom will use a much more updated version of Electron (1.3), so I expect that the rate of this kind of bugs will decrease dramatically.

@Chais, the Ctrl-N thing should be fixed in atom-1.12.

> https://github.com/orktes/atom-react/pull/196
@Nicola Ctrl-N works without this fix in atom-1.12. Thank you anyway for your time.

I'm highly in favour of bundling the specific Electron version, as this introduces subtle bugs and general annoyances. It's not worth to save a few megs but introducing potential problems. For example, in my cases I have issues with mit HiDPI setup due to a too new version of Electron. An Atom dev explicitly said to bundle the specific Electron version.

https://github.com/atom/atom/issues/13331#issuecomment-263067273

I think this discussion goes nowhere. Upstream developers have wrong design decisions. Someone should fill an issue or send a pull request to change their minds:
https://github.com/atom/design-decisions/blob/master/unofficial-atom-distributions.md

I think it's reasonable to package the latest electron, and use it with all electron applications. So I'm closing this task soon.

I agree. Moreover Atom is fully functional with the latest version of Electron, and there are no bugs that are related to this.