I am looking to make vim function more closely to an IDE in specific situations. To do this I plan to write a Perl script called jvim that is passed a workspace path and have it open a java specific instance of my modified vim. I would then extend this for other file types.
What I would like to do is have a .jvimrc that is loaded in preference to the standard .vimrc. this would then lead to me having plvim with a .plvimrc and pyvim with a .pyvimrc.
This should be fairly straight forward. I would also be looking to map commands to run scrips such as :newclass, :newinterface, :newproject and :newpackage but i think you get the idea.
Any advice you could give as well as the .vimrc overriding would be great.
Related
I am developing a Node.js project in IntelliJ.
The only way to rename files seems to be Shift+F6 which attempts to find all usages which takes too long (~30s - 1min).
Is there a way to simply rename the file without searching for usages?
This only happens when code is stored in Modules (which is necessary to be able to compact empty middle packages).
Best way I have found is to map ALT+SHIFT+F6 to Reveal in Finder. Then just press enter and type in new name.
It's good because its very similar to SHIFT+F6 rename refactor.
No.
IntelliJ must find the usages to rename them, otherwise you're just renaming the file, not refactoring. If you only want to rename the file, use the mv command from a terminal. You can also tell IntelliJ not to look in strings and text, which speeds things up somewhat, but is probably a bad idea in a javascript project (where almost everything is string or text).
I use rename a lot, and on my codebase, which is pretty big, it only takes a couple of seconds. Maybe intellij needs more memory to operate in, so you could try increasing that.
If You are doing it many times, You can create a custom scope for the refactoring:
There You can narrow the scope to few files/folders/modules etc. And for very narrow scope it will work as normal rename.
Some colleagues, now departed, had the habit of adding new classes within a related class file.
This makes refactoring painful.
Is there a tool, perhaps within XCode or AppCode or just a simple script, that will split up these monster files?
It appears there is a tool to help with this in AppCode, but it only semi-automates the process.
I'm using AppCode 2.0, I don't know if the same tool is available in AppCode 1.x.
To extract one class from a file to a new file, right-click the#interface or #implementation line and select Refactor > Move. Alternatively press F6 on that line. You can now enter a new file name, though you probably want to copy+paste the class name in here. At this point you can also select any defines you want to move.
I have done some work on a script to extract all classes in a file. I'd love to share this one day, when I get the chance to remove our clients code from the unit tests!
I don't think so there is any tool for this. However you can write your own osx application for doing the same.
The application will ask to browse the file, and it will search for #interface....#endand#implementation....~#end` and will create a file from this. If a single file contains two classes then it will result in for files (two headers and two implementation). Then the original file can be deleted manually or automatically.
I think this above task can be completed in few hours.
Here you can go for save the original file in a folder, just in case you want to rollback.
I’ve spent some time researching this and though I’ve found some relevant info,
Here’s what I’ve found:
SO question: “What is the clojure equivalent of the Python idiom if __name__ == '__main__'?”
Some techniques at RosettaCode
A few discussions in the Cojure Google Group — most from 2009
but none of them have answered the question satisfactorily.
My Clojure source code file defines a namespace and a bunch of functions. There’s also a function which I want to be invoked when the source file is run as a script, but never when it’s imported as a library.
So: now that it’s 2012, is there a way to do this yet, without AOT compilation? If so, please enlighten me!
I'm assuming by run as a script you mean via clojure.main as follows:
java -cp clojure.jar clojure.main /path/to/myscript.clj
If so then there is a simple technique: put all the library functions in a separate namespace like mylibrary.clj. Then myscript.clj can use/require this library, as can your other code. But the specific functions in myscript.clj will only get called when it is run as a script.
As a bonus, this also gives you a good project structure, as you don't want script-specific code mixed in with your general library functions.
EDIT:
I don't think there is a robust within Clojure itself way to determine whether a single file was launched as a script or loaded as a library - from Clojure's perspective, there is no difference between the two (it all gets loaded in the same way via Compiler.load(...) in the Clojure source for anyone interested).
Options if you really want to detect the manner of the launch:
Write a main class in Java which sets a static flag then launched the Clojure script. You can easily test this flag from Clojure.
Use AOT compilation to implement a Clojure main class which sets a flag
Use *command-line-args* to indicate script usage. You'll need to pass an extra parameter like "script" on the command line.
Use a platform-specific method to determine the command line (e.g. from the environment variables in Windows)
Use the --eval option in the clojure.main command line to load your clj file and launch a specific function that represents your script. This function can then set a script-specific flag if needed
Use one of the methods for detecting the Java main class at runtime
I’ve come up with an approach which, while deeply flawed, seems to work.
I identify which namespaces are known when my program is running as a script. Then I can compare that number to the number of namespaces known at runtime. The idea is that if the file is being used as a lib, there should be at least one more namespace present than in the script case.
Of course, this is extremely hacky and brittle, but it does seem to work:
(defn running-as-script
"This is hacky and brittle but it seems to work. I’d love a better
way to do this; see http://stackoverflow.com/q/9027265"
[]
(let
[known-namespaces
#{"clojure.set"
"user"
"clojure.main"
"clj-time.format"
"clojure.core"
"rollup"
"clj-time.core"
"clojure.java.io"
"clojure.string"
"clojure.core.protocols"}]
(= (count (all-ns)) (count known-namespaces))))
This might be helpful: the github project lein-oneoff describes itself as "dependency management for one-off, single-file clojure programs."
This lets you define everything in one file, but you do need the oneoff plugin installed in order to run it from the command line.
I'm writing tests for an OCaml module. Some of the functions in the module are not meant to be publicly visible, and so they're not included in the signature (.mli file).
I can't call these functions from my tests, because they're not visible outside of the module. So I'm having a hard time testing them. Is there a good way to get around this? For example, a way to tell ocamlc not to read the signature from the .mli file when it's compiling tests?
Some ideas:
Actually export the test functions, but use ocamldoc's stop comment (**/**) feature to avoid displaying the exports in the documentation.
Put all of your tests entirely in another module. However, this is difficult if you have abstract types because your tests may very well need access to the internal implementation.
Create a submodule Test, where all your tests go. That way it is clear what functions are just for testing. Possibly combine this with the (**/**) feature to also hide the sub-module from documentation.
I've heard that people sometimes separate their .mli files from their .ml files (in a different directory) so that they can compile with or without them (by telling ocamlc to look in the separate directory or not). I just tried a few experiments with this. I think it can be made to work, but it seems a little bit error prone to me. Maybe you could put the tests of the internal functions into the module. Exporting the test functions might not violate the modularity too badly. (Though of course it clutters up the module.)
When your script gets to be thousands of lines long, finding a particular function or variable declaration gets to be a real pain. Are there any methods you can use to avoid this?
It really depends on the language and the editor you use.
If the language supports importing from external files, as most of them do, you should refactor your script into smaller modules and import/include them into your main script.
Also, most editors have some means of searching within a file and some, such as 'TextMate' (on Mac) or 'e', its Windows clone, provide a special view displaying all the symbols within the source which you can click on to immediately reorient the editor to the chosen target.
You split your code into separate files/modules/etc., generally organized by similar functionality, and require them in your main script.