For Trac wiki formatting, I want make the simplest trac link that points to a changeset in the repo browser. I'm able to get changeset:<sha>/<repo> to work as a traclink, for example changeset:df12aa9/foo_repo, however [<sha>/<repo>], for example, [df12aa9/foo_repo] doesn't seem to resolve into a traclink. I expect the square bracketed format to work the same as the changeset: format. Am I doing something wrong here?
You'll need to use 8 characters for the hash, at least until #11992 is resolved.
Related
Wrote a plugin to handle some custom format stuff in yaml files that I've written for a huge project. It's a chat bot that can respond in a huge number of ways. There is a lot of slang and non-standard words in the yaml.
I don't want to disable spellchecking as I want to fix legitimate speeling errors. But the annotations under the "misspelled" slang words are conflicting with the annotations in my plugin, and causing issue.
One yaml file has 349 "typos". 10% or so are legit. The rest are slang and custom words.
I need to do one of two things. Either add those words to the dictionary (I've found the method to do that - SpellCheckManager.getInstance(project).acceptWordAsCorrect()) OR get a list of the words and create a custom dictionary from them. Both approaches require me to grab a list of all typos in the document/editor/project.
That's the part I can't find. Looked everywhere. (List of current Annotations? List of current Problems?) Googled my fingers off. Anyone able to point me in the right direction?
This is not the IDEAL solution, but it worked for my means, and I'm leaving the answer in case this is googled.
In DaemonCodeAnalyzerImpl, there is a method:
DaemonCodeAnalyzerImpl.getHighlights(Document document, HighlightSeverity minSeverity, Project project);
This returns a list of all highlights in the document. The method is Annotated with #TestOnly, and docs state that it should only be used in Test code because it breaks/shortcuts the normal way to access that. It still works in non-test code however.
Since the only thing I wanted was the strings of the typos, I pulled the list, then looped through the HighlightInfo's in the list, and pulled the .getText()s.
No danger of screwing anything up.
Then pushed all those strings into:
SpellCheckerManager.getInstance(project).acceptWordAsCorrect(word, project);
Viola! All current highlighted typos are now added to the dictionary.
Proper solution? No. Good enough for what I needed to accomplish? Yup.
I have reinstalled the last version of IntelliJ IDEA and then when I try to format an SQL file, it orders all the lines as shown on the image.
However, I have not made any settings for SQL formatting in the previous versions and the format was OK as shown on my current setting preview as shown below:
So, is there anything default to format SQL properly? There are lots of choices in the settings, but I just want to use a default one available on the settings (I tried but it format almost the same).
Faced same issue. Settings/Languages&Frameworks/SQL Dialects, there you can find the dialect of file. Change it to what you use.
That's how I solved problem, even though you apply global or project SLQ Dialect, somehow the file may not be updated.
As you see from the image, Generic SQL causes problem here.
We are running Ektron 8.50 SP2(Build 8.5.0.356) / eWebEditPro.
The issue we are seeing is when a smart form text field is left blank it is randomly filled with the following...
<Body>
<p title="temporary paragraph, click here to add a new paragraph"> </p
</Body>
Anyone else come across this?
I realize the most obvious 'next step' would be to upgrade. Unfortunately for many reasons this is not an option.
Any advice would be appreciated.
Thanks,
ozmo
You're right, the obvious answer is to upgrade. Ektron moved from eWebEditPro to Aloha as the editor of choice precisely because of issues like this that cropped up as they fought to strike the right balance between cleanliness and usability (prior to this issue, editors would complain that they couldn't get the cursor into the blank space as they wanted... it was a mess).
So my first question is: why can't you upgrade? Is it a business problem or a technology problem?
No other editor is going to be embeddable into the workarea besides, perhaps, their old ActiveX plugin that only works in IE and probably not some of the later versions.
So without an upgrade on the table, your only other options are to:
Edit outside of the workarea. This would require you to create and secure your own admin pages, but it would allow you to set up the form for input however you like and with whatever editor you like, as long as you XML encode any special characters (which is different from HTML encoding; note the 'space' above is and not ).
Create an extension (aka "Content Strategy") which would do the clean-up you want as the item is being saved or published. Documentation for creating a strategy is in the Ektron docs, accessible through http://documentation.ektron.com (redirects to Episerver World, but to the page with links to the docs). You would have to create the strategy, insert your own logic, then add it to the site.
Let me know if there's more info I can provide. But I can't solve for this specific case since I don't have a comparable version of Ektron installed anywhere.
In this question (https://stackoverflow.com/questions/15097501/can-uncrustify-be-prevented-from-modifying-certain-sections-of-code) i learned that i can use *INDENT-OFF* to exclude uncrustify action on certain parts of code.
Unfortunately i was not able to find this information anywhere else.
Does anybody know where i can look this up? Are there other comments which control uncrustifiy behaviour?
The *INDENT-ON* and *INDENT-OFF* are defined in the uncrustify_types.h file in the source code
See also Ben Gardner's comment: https://sourceforge.net/p/uncrustify/bugs/343/#0394
After I do a git rebase, the code lines I have added/modified are indented four spaces or more to the left of the respective code block. This is incredibly annoying and time-consuming to fix, not to mention it makes it unreadable for Objective-C (imagine if I was coding in python...?)
Xcode (or whatever, git?) adds in tabs in place of the spaces, and my Xcode is set to make tabs spaces.
No one at my work seems to have a good answer for why it occurs. I made trustctime false, but that did not help. Any help?
This could be a whitespace setting. Check out the options for core.whitespace on the git-config man page. If you have that set as well as apply.whitespace, then git will do things to your whitespace, probably including during a rebase.
Try finding out what git config core.whitespace and git config apply.whitespace are and modify them in your ~/.gitconfig file or with something like:
git config --global apply.whitespace nowarn
UPDATE
I think this may be a duplicate of git whitespace woes
END UPDATE
Unless you've done some customization into your git post-commit hooks or to your git config core.whitespace settings (thanks for pointing that out jesse), git does not translate spaces to tabs or vice versa or anything like that. The changes are usually results of your environment/files and your merge activities.
Having dealt with this in various forms, my guess is that some of your peers are using tabs and some are using spaces. People will have flame wars all day long on whether you should use tabs or spaces, and depending on the day and language I hop sides. That's not something I will get into here.. However just about every rational participant in said war would agree that regardless of which you pick, you need to pick one and use it consistently throughout a project.
Most reasonable editors allow you to control whether tabs or spaces should be inserted, and I know XCode is no stranger to this.
I would suggest showing the whitespace or using briefly an editor which allows you to see the whitespace to see what the difference actually is. Seperately, after you correct a whole file you could also just use git diff -w -b to suppress white space changes. That said you should really figure out what the heck is causing your whitespace to go nuts on a rebase because that suggests to me most likely git is confused by mixed usages, and multiple people correcting it at multiple points with different resolutions.
Good luck to you, it's never easy, and someone is always unhappy when their cheese gets moved.
I don't know what about my git-config was the issue, but after clearing it out and re-doing my settings, the problem was fixed. I don't have my old git-config :( This occurred many months ago, but I thought I would express that this was not xcode related.