Always open in dev mode?


#1

Does anyone know how to hack Atom to always open in dev mode?


#2
alias atom="atom --dev"

:grinning:


#3

Duh. Thanks.

(Garbage to override discourse’s stupid 20-char minimum post).

I just found another stupid discourse rule. I tried to edit out the last edit because I was wrong and you post was 21 chars. Discourse wouldn’t let me do the edit because it made the post the same as an earlier one.


#4

Can you revert to an older version? If so, you could just revert the edit maybe?


#5

It’s not a problem worth pursuing.

Back to original post question about always opening in dev mode. Windows doesn’t have a persistent alias command. I guess I would have to hack something in Atom, if possible.


#6

There’s probably some way to do it. I would probably add a configuration option and build it as a PR.


#7

If you use the Project Manager package I actually just did a release that adds the option to open a project in dev mode :slight_smile: That way you can open your packages in dev mode, and all other projects normally.


#8

Unfortunately I can’t install Package Manager. I get a node-gyp error …

C:\apps\large-file-viewer>apm install Project-Manager
Installing Project-Manager to C:\Users\Administrator\.atom\packages failed

> runas@1.0.1 install C:\Users\ADMINI~1\AppData\Local\Temp\apm-install-dir-11482-5416-1khptwi\node_modules\project-manager\node_mo
dules\pathwatcher\node_modules\runas
> node-gyp rebuild

I think I may have seen this on other packages also. I’m in windows 8.0 with visual studio 10.

Why do you have a gyp build in an atom package?

Edit: Oh it is path-watcher. That is the one I got this error before. I wanted to use it in one of my packages and I had to drop back to the node built-in file watch which turned out to be easy.


#9

Try again. Removed pathwatcher and now use FS instead which I already use for other things :slight_smile:


#10

Just FYI, if you use PowerShell, you can define a function in your profile, something like:

function atom { C:\ProgramData\chocolatey\bin\atom.exe --dev $args }

#11

That install and the feature worked. Thanks.


#12

Completely stupid question: What is the benefit?

I thought that dev mode means that packages from the dev directory are active. But you can just put them into the plain directory instead…

I think I’m overlooking something.


#13

Yes, you could put them in the plain directory … but perhaps you want to have a known-good set of packages in the normal directory and then packages you’re experimenting with or working on in the dev directory. It’s generally good practice to firewall off things like this.

Also, there are some features that are enabled only in dev mode:

  • Right-click to Inspect Element
  • Extra logging in some packages
  • Window size readout on resize
  • More probably added as time goes on

Where to begin with contributing?
#14

I grok the last four bullet points. Thanks a lot for that.

As to firewalling experimental packages – if you always start Atom in dev mode, then there is no firewalling…


#15

What firewall feature are you referring to and what does it protect?


#16

Read @leedohm’s post above @kgrossjo’s reply :stuck_out_tongue_closed_eyes:


#17

Yes I saw his reference to firewalling. I just didn’t understand what it would protect against. I can’t think of any harm mixing them together. For that matter I don’t see any advantage of separating them.


#18

Let’s say that I have a package “foo” that I depend on for my workflow. Now let’s say that I am working on a new feature for “foo”, but it crashes frequently and I haven’t figured out when or why. Having the version that is under development in the dev directory and the production version in the normal directory allows me to flip back and forth between them with just a command-line switch or menu selection. This is what I meant by “firewalling” … keeping the development version separate so that it doesn’t disrupt your workflow when you aren’t actively working on it.


#19

I understand. I have been known to disable a project in progress.