Some goodies / fixes I found after a few weeks of use. #238
Conversation
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.
|
Thanks. Some things will definitely be helpful, but I need some time to digest them. Could you elaborate a little about the different use cases/issues for each of the commits? |
|
I've added some comments to the commits (if you click through), except a couple that were self-explanatory. I'm not as fond of the compilation buffer as I was when I started, so you can discard that if you want. On the other hand, it does fix some broken-ness and it doesn't touch anything else, so why not. |
…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.
|
@ovy thank you for all hard work. Can you not push any new commits to this PR and create new ones instead. It will be easier to handle. |
|
@jchochli could you help me with this somehow? There's plenty of commits. We can split them or something |
|
@kleewho Thanks for looking! The problem with making little feature branches (which I do in other situations) is that I only really run with one Emacs state and my session is very long-lived. So other branches would contain commit states that I've never actually run as published, and it would be real easy for a bug (e.g. dependency) to sneak in. So what I'll do is I'll stop pushing to this PR, but wait until you tell me which commits you want to keep, back out the rest and make sure it all works, then put further changes on top of that state. It's a little hard to do this for very long, though :) Best, P.S: sent this much earlier, but flaky wifi stops github rather unnoticeably. I'm watching this with interest, rest assured :) |
|
Would it be possible to merge this and other pulls soon? I I would like to contribute some stuff but having all these outstanding PR's makes it difficult to judge what is there and what is not. |
The last [non-merge] commit might be the most interesting to you. Please pick what you want. In order of importance:
ovy@f684c86
ovy@6c57759
ovy@33c0ef4
The others are use-case-y.