My problem is when comparing a branch with the trunk (or vice-versa), using the option Compare With → Branch/Tag the Eclipse I'm using (Neon) points many special characters like ç, ã, õ ... as changed, but I really didn't changed anything there. This makes harder to see the real differences.
Is there an option to disable this check?
Related
I have this in my .install4j file:
<mediaSets>
<windows ...
mediaFileName="${compiler:product.name} ${compiler:edition.name} Win32 ${compiler:sys.version}" ...>
<mediaSets>
The issue is with the name of the generated media file.
I get: Our-Product_Enterprise_Win32_6.0.36-SNAPSHOT.exe
I want: Our-Product Enterprise Win32 6.0.36-SNAPSHOT.exe
I switched off the "Convert dots to underscores" setting, which helped clean up the version number, but how do I prevent Install4J from replacing all blanks with underscores?
I could live with using some other character, but:
_ (underscore) is confusing since the name already has dashes in it (it should be possible to read out a name over the telephone).
- (dash) is even more confusing since there are more dashes in it.
~ (tilde) looks weird - the installer is seen by non-tech people, and I don't want to confuse them.
en-space and em-space might work, but could cause character set weirdness, particularly since we're building Linux and Windows installers (and maybe Mac installers in the future). I.e. I'll want to stick with ASCII-7 if at all possible.
Currently this is not possible. For 8.0.3, I have now implemented an option "Convert spaces to underscores" so you can disable the replacement.
Please contact support#ej-technologies.com to get a build where this is already implemented.
When working on different projects, with different people and using different frameworks you often struggle to keep your code compliant to their conventions. Some teams get very strict about naming variables/methods/classes and other things the others make holy wars around the topic. I understand them and I fully support, but as any developer I have my own preference I wish I could code with comfortably. This makes me think whether there is a simple solution.
Are there any tools or editors that can automatically convert code to follow a different standard? I imagine there can be no such smart tool that will support naming conversions, so I'm ok with that, but I really wish to see
foreach($lala as $lalala) {
and not
foreach($lala as $lalala)
{
same goes with statements:
if(I_LIEK_COOKIES) {
eat_cookie();
} else {
toss_cookie();
}
and not
if ( I_LIEK_COOKIES ) {
eat_cookie();
}
else
{
toss_cookie();
}
(note the spaces between and around the parenthesis too)
I won't even mention spaces/tabs, I can convert it in my IDE with a shortcut but it would be awesome.
So the things I would like to get customized are
spaces between parenthesis
tabs/spaces and spaces per tab
mustache brackets on the end of the line or on the new line
always attach mustache brackets to any if/ifelse/else/for/foreach etc.
Some of the extras anyone would appreciate:
Line ending style
Delete extra spaces on the line endings (like sublime text 2 can do on save, but would be great for other IDE/editors)
The perfect workflow would be like this:
I pull from git
The code gets converted to my style
I code stuff
I commit and push
Before everything gets pushed(or even commited) code gets converted to the convention style
Of course, someone may wish not to use git, then it would be simply converted when opening and after saving the file but as I understand it's impossible to do outside of an IDE/editor with a tool of some kind.
Has someone stumbled upon something like that? Could not find anything anywhere but tab/space conversion.
P.S. I wish to mention I'm working with PHP/JS so it's prioritized but I code using other languages on my spare time.
You could store configurations (e.g. vim .vimrcs, Eclipse preferences etc.) in each project's version control repository.
However, I think there's a big problem wrt. converting code when pushing/pulling to/from repositories. If someone reports an issue with your code (e.g. exception at line 100), converting the code when pulling from your repository is going to give you a different line 100. I don't think you can practically operate without working on the exact code that your compatriots are working with.
I am using Eclipse 3.6.1 Build id: M20100909-0800 and Aptana Studio 2.0.5 which is based on Eclipse 3.5.2 (both on OS X) and in both programs the external tools feature seems to swallow double quotes and whitespace for the ${selected_text} variable.
Isn't the ${selected_text} variable essentially useless with the mentioned behaviour?
Is there a way around that or maybe a hidden setting somewhere?
Thanks for reading.
This could easily be considered a safety/security feature.
I suggest "${selected_text}".
...but if it's eating ALL whitespace, that won't really help. Huh. Maybe it's clever enough to detect the quotes and preserve the whitespace... but probably not.
Okay, I did a little poking around. Quotes within the argument list itself are preserved, as per my initial suggestion above. I found the following auto-generated argument list that was working Just Fine:
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog
-debug "${workspace_loc:/com.cardiff.bpm.ide.webforms.ui/debug.options}"
But if your text selection contains quotes, I'd expect it to be handled as per the underlying OS. Windows "cmd" does some... creative things with them for example. My *nix-fu is Not Mighty, so I couldn't tell you what OS X will do under the covers, but I suspect that's where you'll find your solution.
You may have to do something goofy like URL-encode your selection, and use some command line tool to un-encode it before passing it to your desired external tool once the text is out of Eclipse's clutches.
A (very) quick look around my 3.6.1 UI didn't turn up that would do this automagically for you, but there's probably a plugin out there somewhere that'll add that feature to an editor's context (right click) menu.
I'd expect the HTML editor to have this ability already... but I don't see anything other than "smart insert mode" that sounds promising, and I don't see that working either.
That doth bloweth goats, most heartily, yay for weeks on end. E'en till yon goat hath a rash, most unpleasant in both severity and locality. Verily.
I don't think you're getting my proposed solution:
Set up your tool so it'll de-url-encode-ificate the incoming string with some proposed command line tool.
In your editor (in eclipse), URL-encode the text you wish to select and pass to the tool. Manually.
Run the tool on the selected (url-encoded) text.
Revert the selected text. Also manually. Probably just "undo".
"1" is why I was looking for some eclipse UI way of url-encoding a selection. The HTML Editor won't even do it when you paste into an attribute string. Sheesh.
Two Other Options:
Fix the bug yourself. Open Source and all that.
Write a plugin that exposes it's own version of ${selected_text} that doesn't strip out all the strings.
Hey! SED! Replace the quotes with some random (unused in any selection you might make) high-ascii character and sed it back to a double quote instead of the proposed de-url-encode-ificationizer. You'd still have to manually edit/undo the text, but at least you won't have to """ Actually search/replace over a given selection makes that less painful than one might think.
I'm not sure what the scope of #2 is, but I'd image if you don't have any eclipse plugin experience the thought might be rather daunting. There might even be a sample plugin that exposes such a variable, though I haven't checked.
I don't think we're communicating.
You don't select text with quotes in it. You select mangled text, and sed demangles it back into quotes for you.
For example, you have the string print("hello world"); in your editor and want to send that to your tool.
change it to print(~hello world~); in your editor. Manually or via a script or whatever.
select it
run your tool, maybe wrapped in a script that'll sed the ~s back to "s.
change it back to print("hello world");.
This is a manual process. It's not pretty. Bug workarounds are like that. You can probably come up with a monkey script to convert quotes to Something Else, and "undo" is easy. You might even be able to get your script attached to a keyboard short cut... dunno. And ~ is a lousy choice for a replacement character, it's just the first thing I could think of that was rare enough to be a decent example.
Are we communicating yet?
For the record, I put together a patch using some guidance from a gentleman in the bug comments.
I don't know if it will be accepted, but it fixes things for me so maybe someone else may find it useful.
Again, this is only for Mac OS X Eclipse.
Start Eclipse.
Go to Import > Plug-ins and Fragments.
Import From: Active Platform
Fragments to import: Select from all plug-ins
Import As: Projects from a repository
Next >
Pick org.eclipse.debug.ui and org.eclipse.debug.core
Once the projects are in your workspace, apply the two patches that compose proposed patch v1, found at the bug tracker page for bug 255619
Go to Export > Deployable plug-ins and fragments and make a jar out of your changed packages.
Hope it helps.
What source control products have a "diff" facility that ignores white space, braces, etc., in calculating the difference between checked-in versions? I seem to remember that Clearcase's diff did this but Visual SourceSafe (or at least the version I used) did not.
The reason I ask is probably pretty typical. Four perfectly reasonable developers on a team have four entirely different ways of formatting their code. Upon checking out the code last changed by someone else, each will immediately run some kind of program or editor macro to format things the way they like. They make actual code changes. They check-in their changes. They go on vacation. Two days later that program, which had been running fine for two years, blows up. The developer assigned to the bug does a diff between versions and finds 204 differences, only 3 of which are of any significance, because the diff algorithm is lame.
Yes, you can have coding standards. Most everyone finds them dreadful. A solution where everyone can have their cake and eat it too seems far more preferable.
=========
EDIT: Thanks to everyone for some great suggestions.
What I take away from this is:
(1) A source control system with plug-in type diffs is preferable.
(2) Find a diff with suitable options.
(3) Use a good source formatting program and settle on a check-in standard.
Sounds like a plan. Thanks again.
Git does have these options:
--ignore-space-at-eol
Ignore changes in whitespace at EOL.
-b, --ignore-space-change
Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more
whitespace characters to be equivalent.
-w, --ignore-all-space
Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has
none.
I am not sure if brace changes can be ignored using Git's diff.
If it is C/C++ code, you can define Astyle rules and then convert the source code's brace style to the one that you want, using Astyle. A git diff will then produce sane output.
Choose one (dreadful) coding standard, write it down in some official coding standards document, and get on with your life, messing with whitespace is not productive work.
And remember you are a professional developer, it's your job to get the project done, changing anything in the code because of a personal style preference hurts the project - it wont only make diff-ing more difficult, it can also introduce hard to find problems if your source formatter or compiler has bugs (and your fancy diff tool won't save you when two co-worker start fighting over casing).
And if someone just doesn't agree to work with the selected style just remind him (or her) that he is programming as a profession not as an hobby, see http://www.ericsink.com/entries/No_Great_Hackers.html
Maybe you should choose one format and run some indentation tool before checking in so that each person can check out, reformat to his/her own preferences, do the changes, reformat back to the official standard and then check in?
A couple of extra steps but they already use indentation tools when working. Maybe it can be a triggered check-in script?
Edit: this would perhaps also solve the brace problem.
(I haven't tried this solution myself, hence the "perhapes" and "maybes", but I have been in projects with the same problems, and it is a pain to try to go through diffs with hundreds of irrelevant changes that are not limited to whitespace, but includes the formatting itself.)
As explained in Is it possible for git-merge to ignore line-ending differences?, it is more a matter to associate the right diff tool to your favorite VCS, rather than to rely on the right VCS option (even if Git does have some options regarding whitespace, like the one mentioned in Alan's answer, it will always be not as complete as one would like).
DiffMerge is the more complete on those "ignore" options, as it can not only ignore spaces but also other "variations" based on the programming language used in a given file.
Subversion apparently supports this, either natively in the latest versions, or by using an alternate diff like Gnu Diff.
Beyond Compare does this (and much much more) and you can integrate it either in Subversion or Sourcesafe as an external diff tool.
At least two brilliant programmers, Linus Torvalds and Guido von Rossum, disparage the practice of putting keywords into a file that expand to show the version number, last author, etc.
I know how keyword differences clutter up diffs. One of the reasons I like SlickEdit's DiffZilla is because it can be set to skip leading comments.
However, I have vivid memories of team-programming where we had four versions of a file (two different releases, a customer one-off, and the development version) all open for patching at the same time, and was quite helpful to verify with a glance that each time we navigated to an included header we got the proper one, and each time we pasted code the source and destination were what we expected.
There is also the where-did-this-file-come-from problem that arises when a hasty developer copies a file from one place to another using the file system, rather than checking it out of the repository using the tool; or, more defensibly, when files under control in locations A, B, and C need to be marshalled (with cherry-picking) into a distribution location D.
In places where VCS keywords are banned, how do you cope?
I've never used VCS keywords in my entire career, over 30 years. From the most primitive VCS system I've used, up to the present (TFS), I've used some other structure to understand "where I am".
I am rarely in a situation where I've only got one file to work with. I've usually got all the other files necessary to build the project or set of projects. I usually use branching (or streams on one occasion), and I'm working on some slice of the given branch or stream.
If I'm working on multiple branches or streams, I'll have one directory tree for each. All I need to do to know what file I'm working on is check the file path, at the very worst.
At the very best, the version control system will tell you exactly which version of the file you're working on, what the change history is, who else is working on different versions of the file, and anything else you'd care to know.
This doesn't exactly answer your question, but I imagine Linus and Guido have reasons for disliking keywords that don't apply to small-team corporate development.
An $Id$ tag for instance, has what you could consider to be a global version number. Linux and I guess also Python development is fragmented enough that no number can be global. Lots of people have their own repositories all over the place that would fill in their own $Id$ values and then those patches might be sent to Linus or Guido's repositories where they don't make any sense.
However, in your environment, you probably have one central repository which would assign these and it would be fine. Sounds like you're using git. I wonder if it's possible to configure the central git repository to do tag substitution while the local developer repositories don't. Or perhaps it's better to get the commit hash in the tag.