This repo is a pedagogical example of an IDEA plugin. To learn more about plugins please read the tutorial that accompanies this code example on developerlife.com - Introduction to creating IntelliJ IDEA plugins.
To find the IDEA log look at the $PROJECT_DIR/build/idea-sandbox/system/log /idea.log file. A
simple command to do this (from the project directory) is:
find . -name "idea.log" | xargs tail -f | grep MyPluginTo find the "logServiceData.xml" take a look at the
$PROJECT_DIR/build /idea-sandbox/config/options/logServiceData.xml file. A simple command to do
this (from the project directory) is:
find . -name "logServiceData.xml" | xargs subl -nAlso, to delete this file, if it gets too big:
find . -name "logServiceData.xml" | xargs rmGetting started w/ writing your first plugin
- Writing your first plugin
- Organizing and using icons in plugins
- github issues thread on IDEA icons
- List of default icons in IDEA, AllIcons.java
- IDEA plugin services and components
- Details about actions
- JetBrains official code samples for plugins
Extension Points and extensions
Services
Notifications
Logging
Tutorials on writing plugins
Icons
Git
The Internet Engineering Task Force (IETF) points out that "Master-slave is an oppressive metaphor that will and should never become fully detached from history" as well as "In addition to being inappropriate and arcane, the master-slave metaphor is both technically and historically inaccurate." There's lots of more accurate options depending on context and it costs me nothing to change my vocabulary, especially if it is one less little speed bump to getting a new person excited about tech.
You might say, "I'm all for not using master in master-slave technical relationships, but this is clearly an instance of master-copy, not master-slave" but that may not be the case. Turns out the original usage of master in Git very likely came from another version control system (BitKeeper) that explicitly had a notion of slave branches.