Hyper: Atom integration

[amilajack]

Is it possible that this package could provide possible Atom integration?

[hharnisc]

OMG yes!

[BenoitAverty]

Or any electron app integration for that matter.

[zridouh-chwy]

This would actually be amazing.

[ghost]

Aside from other issues, one problem with trying to do this is that Atom is using an old version of electron v0.37.8 and hyperterm is using v1.2.5. And unfortunately the Atom devs apparently have no plans to move to v1.x in the near future since it's not a high priority issue.

[amilajack]

Possible naive solution could be to write a babel that could transform the api calls to an abstraction layer. Also here's a list of most of the api changes. Seems manageable.

[desmondmorris]

this would be 😍

[amilajack]

http://electron.atom.io/blog/2015/11/17/electron-api-changes

Doesnt seem like too many changes

[hultberg]

Update; There is a pull request from the atom devs to upgrade electron: atom/atom#12300

[tad-lispy]

And now it's merged :D

[zridouh-chwy]

Any progress on this now that Electron is updated in Atom?

[amilajack]

https://github.com/atom/atom/blob/master/package.json#L15

[nerdpad]

OMG it will be amazing!

[controversial]

Please?

[rumpelsepp]

Le's to some cross referencing; here is a topic in the forums:
https://discuss.atom.io/t/package-request-hyperterm-embedded-in-atom/31506

[amilajack]

I think it would be better if we wait for hyperterm's windows integration before integrating.

[controversial]

These two things aren't at all related.

On Sat, Nov 5, 2016 at 3:24 PM Amila Welihinda [email protected]
wrote:

I think it would be better if we wait for hyperterm's windows integration
before integrating.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zeit/hyper/issues/254#issuecomment-258634964, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ5Yr53C-2t98YpxSqQUszpBZ-9ZINhMks5q7NgHgaJpZM4JPAf6
.

[dimitrieh]

This would be awesome :)

@amilajack what about the other way around, spawning atom within hyper as if it was vim?

[amilajack]

From what I see, Atom is a much larger project. To me, it makes more sense to integrate a smaller project into a larger and not vice versa

[dimitrieh]

@amilajack to me implementation details shouldn't mess with UX. I don't say perse integrate atom, however think of it this way:

Hyper is finally a terminal that could do more than just a hacked on implementation of code editors.. it could integrate a real code editor with all the functionality that comes with it.

Most of the time you open your text editor from the command line, not the other way around.

why else is there is vim command?

[controversial]

I think spawning Hyper within Atom makes much more sense. It's far more practical. An embedded editor is way out of Hyper's scope and would add a ton of bloat

[OJFord]

An embedded editor is way out of Hyper's scope and would add a ton of bloat

Obviously it would be a plugin. But today I don't think it would even be possible? @dimitrieh's suggestion might be rephrased "make it possible to have electron apps be plugins" & "maybe someone would then create an Atom plugin".

If you imagine the two UXs, they really are quite different. If you're already a vim user, it's not at all out of the question that you might switch to a tab (or tmux window) which doesn't have any vim in it - an editor is part of your workflow, but not all of it;

Just imagine: editing something in atom, you save it, and change pane to the small one on Atom's left; deploy your changes. You switch tab - boom - no editor in sight, you have a couple of panes related to wherever you just deployed your code, SSH and htop say.

If Hyper was an Atom plugin, then there'd be no escaping Atom. Suddenly all of your shell activity is inexplicably inside a text editor. This is sort of okay, since Atom does support horizontal and vertical splits; there's no reason that any one of them need actually be editing text. _There'd still be no tabbing._ But it also just feels wrong.

TL;DR:

• You launch editors from your terminal; not the other way around.
• Hyper in Atom would destroy tabs and (Hyper's) panes.

[dimitrieh]

@controversial I think @OJFord makes an excellent case out of my point. Perhaps this isn't the issue for it and it should get its own issue.

Issue created: https://github.com/zeit/hyper/issues/1272

[controversial]

So now that Atom is on a modern electron version, are there any further obstacles to allowing Hyper to spawn with in Atom? I've used terminal-plus before but it's honestly not great

[gjtorikian]

I tried my hand at this a while back and found it extraordinarily difficult to embed an electron app within another electron app. Perhaps I went about it the wrong way?

[amilajack]

@gjtorikian I think getting feedback or recommendations from the atom and hyper authors would make the process a lot easier.

[RomanADavis]

How could we do that?

[purplecones]

Has there been any movement on this? It sounds like an awesome idea

[xeno]

Uh, yes please. I would really enjoy a PaaS or self-hosted atom/hyper/docker solution, especially with things like Samsung DeX out. Full mobile development!

[wende]

I can't wait to see it work. Let me know if you need any help. I'll gladly contribute to a project like that!

[MartyGentillon]

@OJFord @dimitrieh coming from Emacs, I don't find it at all strange that one would have a console in a buffer of their editor at all (see term.el), this workflow actually feels 100% natural to me. In fact, my text editor is more likely to know the current context of my work than a console. Features like "find symbol under cursor" can easily move me many directories away in my product structure. Tools to jump around the file system (like Z) can be helpful here, but they are nothing compared to M-x eshell followed by whatever commands are appropriate.

Furthermore, text editing features actually tend to be useful when working with a shell's history buffer. reverse-search, kill rings, and text aware navigation are wonderful for manipulating the output of a command line command.

Even more fun, once there is a good terminal emulator for your text editor, you can design a shell that gives you programmable access to editor functions in addition to system commands (see Emacs eshell). Then add in something like Tramp, and suddenly, working with remote computers is no different than working with local computers.

Also, given that Atom is essentially an Emacs written in JavaScript, this wouldn't be contrary to the design of Atom at all. In fact, it is a natural extension of the model. What's more, Atom supports tabbing and pains natively. It's window management capabilities are at least as good as Hyper's (in fact, they are a little better).

TLDR

• You are at least as likely to want a terminal in the same directory as the file as you are to want to edit a file from the terminal.
• Terminal support in an editor is a wonderful feature that enables the development of other killer features.
• Eshell and Tramp are Emacs' killer features.

[davidsharp]

In regards to the "Atom-in-Hyper" vs "Hyper-in-Atom" discussion, I can't see a benefit to having Atom within Hyper. I can't see a use-case where opening Atom out into its own window would not be the desired behaviour, as it would block terminal use. I can see the appeal of quickly running vi, but for anything else you're opening a new tab/pane to dedicate to your editor, as opposed to a new window. Opening Atom as it's own Hyper pane sounds somewhat appealing, but it means cramming all the Atom chrome into the pane, or excluding it either completely or in part. Which, to me, both options render it a little pointless.

Hyper within Atom on the other hand sounds really useful (as a double-pane Atom user), as I could run Hyper at the bottom and watch automated live-reloading actions, reference files I'm viewing for commands to use, or quickly run make commands, etc. It gives me a more IDE-like environment for building web/hybrid apps. And while web/hybrid apps aren't the only use cases for either Hyper or Atom, it's certainly in keeping with their respective origins and plugin communities.

I also feel there'd be a lot of headscratching about how Atom's plugin ecosystem is supposed to exist within Hyper, but not with Hyper's plugin ecosystem within Atom.

[sayingandparsing]

I'd love to see this happen.

Supposing the primary use-case is to quickly edit individual files accessed in the command line without switching contexts, opening a new atom instance within hyper would likely be impractical, especially given atom's startup time.

However, an alternative solution would be to utilize an existing atom instance by opening a single atom text-editor pane in hyper rather than atom's main window. I don't know whether that's feasible within the electron or atom apis, but it might be accomplished by creating an new editor inside atom from hyper, then mirroring that editor pane in the terminal. Once the user's finished editing and the file's been saved, work could resume in the command line, and the temporary editor pane would close. Presumably plugins for both atom and for hyper would be required, communicating over a socket or something. Admittedly, it sounds like a good bit of work.

Nevertheless, I assume an atom editor pane is represented by a DOM tree, which if accessible, could be reproduced in hyper's electron instance and updated as changes are made. The question then is how to handle input. In the case of keypresses, input could just be forwarded to atom while the mirrored editor is open in hyper, though repositioning the cursor by clicking the mouse on the mirrored version might be less straightforward but still possible.

I haven't worked extensively with ether project, so I'm just outlining a speculative solution. No idea whether something like that's feasible.

[mdeboer]

This would be amazing and would provide a much better experience than terminal-plus. Hopefully some wizard ⚡️ stands up and embed hyper in Atom (not the other way around).

With Atom I work with projects which I open with Alfred using my alfred-atom workflow. I like to keep doing this and still be able to utilize hyper without having to switch between two windows, embedding it 👍

[AdityaChoudhary]

MAKE THIS HAPPEN. PLEASE.

[sangdth]

I could pay or donate for this feature/package/plugin. Pleaseeeeeee!

[dimitrieh]

I have seen comments for and against this feature and understand both of them. Perhaps the scope of this issue is not well defined, as it's a lot to say.. hey please put the entirety of atom into a terminal application.

However if this thing is to be built, the thing we really need to begin with is: a hyper performant, native feeling editor experience, resembling some of atoms features (meaning mouse gestures, key board short cuts, etc), which spawns as vim.

Something that comes close, but is still a terminal hack of an editor is https://github.com/zyedidia/micro

Perhaps this feature is a stretch.. as it will only be possible in electron based terminals.. but its also a chance to have a more native feeling editor, with better UX, spawn just as fast as vim.

[wende]

@dimitrieh I think what people in this thread mean is to have Hyper inside Atom, rather than the other way around

[dimitrieh]

@wende ha I see, ah well there are use cases for both ways!

[wende]

@dimitrieh Both ways look cool though. But having hyper in atom seems much more doable

[sangdth]

Yeah, @wende was right. I hope that Hyper will have another option, like Atom package, because I still love how I can "hack" with Hyper, but also I don't want to switch between Atom and Hyper.

I'm learning VueJS, and I saw the instructor he has WebStorm with terminal intergrated below, it makes me jealous. 😸

[wende]

@sangdth Right now I'm using ITerm2 + Spacemacs. I really liked Atom with Proton but having to switch between terminal and editor wasn't that nice of an experience.
Having Atom and Hyper in one window with a shortcut like Shift+arrow would be amazing to have, no matter which one contains which

[dimitrieh]

i do have to say that the native terminal in VScode is pretty great

[MartinMuzatko]

I couldn't find any repo with existing effort other than https://github.com/gjtorikian/atom-hyperterm. by @gjtorikian .

Is there a way to use webviews like https://atom.io/packages/atom-webbrowser ?
I mean the defaults electron view is also "drop your application here". This should be possible.

[Onfire7]

They both have their merits.

For development and other project based workflows, Hyper being available inside Atom would be invaluable as you test applications, and manage parts of your project.

For server administration and other CLI based workflows, having a proper and fast GUI editor that spawns in your console when you need to edit something (without having to wait for 30 seconds for an editor to load to change 2 lines of a file and close it again...) is equally invaluable.

I think both should be provided, and ideally, Hyper should provide a way for other applications to embed a console window, while Atom should provide a way for other applications to embed a striped down editor. Both should use their main installs settings and plugins.

I wonder if you could spawn a process that manages the content of an iframe or something... Then you could just launch either one with a command line flag telling it that it is getting embedded, it would react appropriately, (Like only loading Atom packages that have an embeddable flag or something...) and it controls whatever you give it... I'm fairly confident that it's possible to do, I'm just not sure if Electron would need a lot of changes to make it happen...

[Stanzilla]

https://atom.io/packages/terminal-tab or https://atom.io/packages/platformio-ide-terminal work quite well.

[sangdth]

I have tried Terminal that comes with Nuclide a while, then I backed to Hyper.

[max-sixty]

https://github.com/jsmecham/atom-terminal-tab by @jsmecham is highly recommended

[kyovo]

Windows:
First you should: Bash on Ubuntu on Windows
Bash on Ubuntu on Windows

Use Atom - platformio-ide-terminal.

Settings: Shell Override:
C:\\Windows\\System32\\bash.exe

Nice alternative for me.