make emacs can navigate codes in a jar file like vim did. #278
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Runs a configuration in the compilation buffer.
eclim-java-generate-getter generates a getter method for the symbol at point.
Allows moving a top level class or interface from one package to another.
Added eclim-project-setting-set which can assign an Eclim project setting.
…mode. Otherwise a bad Eclipse state can cause an Emacs session to get very unpleasant. I'm not sure exactly what the mechanism is, but basic stuff like find-file, switch-buffer and *the M-x prompt* (of all things) stop working with the Eclipse error. To reproduce, define eclim--project-dir to (error something), then open a managed Java file not already open. Have the real eclim--project-dir ready; fortunately, eval-expression still works. The user can run eclim-mode manually if they want to investigate the error, or try to do anything that needs project-dir. I think even printing a message would still be too unpleasant in that state, hence ignore.
was not selecting the source code buffer.
…icator. When we save, a lot of different messages zip by in the minibuffer and create a distraction. Instead, a '*' in the modeline right by the error counts that are about to be updated is discreet but noticeable. Removed an extraneous space.
This version fits my typical compilation-based workflow better than the
problems buffer.
* Fix an errant call to eclim--project-dir.
* Fix the counting of errors/warnings. Errors apparently get 'warning =
":json-false", not nil.
* Store the project-name in the buffer. This allows it to be called from
within itself ("refreshed") easily.
* Bind the standard "g" key to do just that. Otherwise compilation-mode will
happily start a new shell make that confuses eclipse (in my config).
* Use the standard "process status" part of the modeline to display
"refreshing" / results, the latter in red if there are errors.
* The local variables header text is unnecessary if we set it programatically.
* Instead, put the result text at beginning as well and tag with time.
* Try to not reposition the buffer upon refresh if possible.
Note that I don't think we should make compilation-buffer refresh automatically
when we get an updated list, even though it's quite easy. Other compilations
stay unchanged until manually refreshed and uniformity is nice.
…t file. These are entirely cursor based rather than dependent on position in the problems-buffer. They are intended to be navigational aids in the absence of Eclipse's scroll bar indicators, which we can't do in emacs. Otherwise, errors in long files can be hard to find.
This helps on Macbook. It's consistent with help-mode, for example.
Eclipse changed the relevant option to apply to camelCase only, and when completing a variable we get a *huge* selection of all classes that begin with that prefix. Try completing a variable that starts with "re" for example. Eclimd's sorting is not particularly good, either -- in Eclipse at least we get the lowercase matches first. Company-mode's view is that the backend is responsible for ensuring the prefix matches properly.
This matches the way it works in Eclipse -- complete the open call / type rather than going for a new identifier. beginning-of-thing does not by itself cross the open bracket.
Otherwise it's strange to accept a correction, see the buffer save & refresh, but the error highlight persist. I don't like automatic problem updates always (tried it!), but in this case I'm actively expecting Eclipse to fix one. Minor: remove an extraneous space from Eclim modeline. "Eclim: 0/13" looks nicer to me than "Eclim : 0/13", and modeline space is precious.
…tion. Eclipse is much better at it than we can hope to be. For example: * It imports the return type correctly, which eclim doesn't give us fully * It imports in the right place syntactically, even when called from within a method * It looks up argument names in javadoc if available [note] * Is much less fragile [note] which means that many times the reason we used yasnippet at all becomes unnecessary, since the javadoc names are something the user typically wants to keep in overrides. This whole thing started as a quest to expunge yasnippet which was being used unconditionally.
…sed. This allows the user to easily set up commands that disable highlights (e.g. temporarily, while writing a bunch of new code), globally or buffer-local (more common in my usage). Unlike a problem filter, the problem counts remain and the problems are navigable. Rename eclim--problems-clear-highlights to indicate it's not private.
I'm using this to help Emacs find the file from stack traces, which are basename only, via compilation-find-file advice.
And load cl-lib explicitly.
Some files already use cl-lib functions/macros.
- Global variables should be declared - Use defvar instead of setq for initializing global variable
The file name is passed as argument.
Improve company extension
Fix for free variables
Only fixed compiler warnings in code that could be manually tested. Other compiler warnings, in code that could not be tested, were left as is.
Added eclim--call-process-no-parse to call the eclim server process and not parse the output it returns. Can be called with a variable number of arguments.
- add optional argument to edit eclim command - track last command per class and save them in buffer local alist - allow format specs (currently %c - class, %p - project, %r - project root)
I found this distracting. The biggest culprit was the fact that we were running eclim import with point at the top of the buffer; also soft-revert-imports was reading a file in that state. Add a message to document that we imported, since it's now less noticeable.
…ues/250 The fix was twofold: 1) Fix regexp to allow jar:file:///Users... 2) Remove explicit filtering of results against archives. There was code to handle them, but it had been explicitly disabled presumably because of the problem above, which made it behave rather badly. This works beautifully when source jars if present, including all of the SDK. It also works with class files and autodisass-java-bytecode , though personally I don't find that very useful; better than bytecode, I suppose.
…chive. This is not ideal (user has to go find the actual file ), but it's about the best we can do without major compile-mode surgery. There are no hooks for find-file and no archive file handler, and it's overkill to write one for this purpose. Visiting files in archive still works just fine when there's only one result, which IMHO is the major use case.
The biggest offender for me was that eclim-accepted would trigger on autosave files (#Foo.java#), which in turn tripped up eclimd with an error. But in general: (eclim--accepted-filename-p "hello.csv") -> t can't be right.
The insertion can result in an import, which is a roundtrip to Eclipse. More often than not, the code is in bad shape at that point and it's annoying to have it underlined as you're writing it.
One was that nested parameters created a nested template, which did not make sense (filling template args before erasing the template altogether); it did not seem intended. The other was an empty arg list. Instead, use replace-regexp-in-string which takes care of some ugly details, and count levels to make sure we replace only on first. Added a test. The previous code fails the first two assertions.
I think yas is problematic for completion because: * Completion begins by spitting out a potentially long method signature * Aborting from yas can't resume, so you're left with above * The code can be in a non-sensical (for Eclipse) state for quite a long time. This can prevent further coding aids. * Yas is intrusive and wants to be a minor mode everywhere. The default insertion is hardly better. So one should at least have the option to do something different. I put in a simple (and sample) alternative that simply erases arguments, which is already an improvement, but I have something better for the next commit.
|
Can you please submit this pull request to emacs-eclim/emacs-eclim as well? This repo is no longer active and development has moved to emacs-eclim/emacs-eclim . |
|
ok, this is the new link: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I know that there is a solution here:
emacs-eclim/emacs-eclim#23
but it has issue when do a java_search in the file belongs to a archive file.
VIM has no such issue and I fixed it by the way of VIM has did.
Now it can do recursive java_search in source file belongs to a archive file without any issue.