I generate scaladoc by using the sbt command doc. The generated scaladoc has default ordering set to Alphabetic. I can manually change it to By inheritance, but when I visit another class documentation, the ordering reverts back to alphabetic.
Is there a way to generate scaladoc with default ordering set to By inheritanace?
At present there is no way to generate scaladoc with default ordering set to By Inheritance.
The page template hard codes the initial value and switching is handled by some jQuery event listeners.
It should be possible to write a simple script and attach it with TamperMonkey or similar that will run the equivalent to click() for you.
Related
I'm currently looking for a way to capture only svelte components on the DOM tree during development mode. I can see that we I run npm run dev all elements and conponents have the "class='svelte-somerandomID'". Does this only happen in development mode?
Yes, it's only in during development that all elements get a scoping class -- and only with some tools. Actually it's a hack we've added in vite-plugin-svelte to enable more power CSS only HMR.
The classes you're referring to are what Svelte uses to make the CSS in a component apply only to the elements of this component. It adds a class that is unique to the component to all elements that can be affected by the component's CSS, and it also modifies your CSS rules to add the same class to them.
Normally the compiler only adds the scoping class to elements that can actually be targeted by the existing CSS rules in your component. If you really want all the elements in a component to have the scoping class, you can use the same trick that I linked to above: add the following rule to your component's CSS.
* {}
By default the generated class names are a hash of the component's CSS content. But you can also customize them with the cssHash compiler option. Note that vite-plugin-svelte also changes how the class names are generated, to be based on the file name instead of the content.
Since every element in the component would be targeted by this roule, this will cause the Svelte compiler to add the scoping class to all the elements.
If you wanted to automatically generalize this to every element of every component, you may want to do it with a preprocessor (if you need some inspiration, the code I've linked too actually implement this with a preprocessor).
I'm not sure if this is what you really want though. For one thing, only elements get a scoping class: components don't get a scoping class, because components don't have dedicated elements in the DOM (only the ones you may or may not add via the component's markup). The above trick would only give you a mean to select every element of a Svelte component. There might probably be easier or cleaner ways to achieve what you really want. For example, a simple wrapping component, or an action, that would use wrappingElement.querySelectorAll('*') or something...
My intention is to have own naming rules in eclipse editor for C programming
Ex: a function should start with File name, it shall contain maximum of 20 character- FILENAME_MaxOf20Char().
When it is violated has to show an warning.
To do this tried to extend org.eclipse.cdt.core.IErrorParser. But this one is parsing from compilor output.
IErrorParser is not the right extension point to use for this.
You want to use the Code Analysis (CodAn) framework and write a custom checker. See this page for documentation.
Is there any way I can use the format_number_choice function inside of a actions file. In fact I need to use it for a Form error message.
'max_size' => 'File is too large (maximum is %max_size% bytes).',
In English it's simply "bytes", but in other languages the syntax changes after a certain value (for example if the number is greater than 20 it's: "20 of bytes").
I can use parenthesis, of course, but if the framework offers support for doing this specific thing, why not to use it?!
The way it's currently implemented in the 1.4 branch, you can define only one translation per message using il18n XML files.
What you could do is create a custom validator which inherits the current validator (sfValidatorFile in your example) and does the size checking in the doClean method before calling its parent's method.
I suggest you take a look at the source to see how it works : sfValidatorFile
The correct way to handle number ranges for translation is explained here in the Definitive Guide. I won't reproduce it here as the documentation itself is clear and concise. Note however that the string is not extracted automatically by the i18n-extract task, so you need to add it manually - again, the documentation explains this.
So yes, you can use the format_number_choice() function inside an action - you just need to load the helper inside the action like this:
sfContext::getInstance()->getConfiguration()->loadHelpers('I18N');
When using the objectContribution-element (which is part of the org.eclipse.ui.popupMenus-extension point), I often (practically always) want to delegate to some command instead of implementing some action myself (since usually, I have the command and a handler already implemented). I'm doing this by using ICommandService and IHandlerService, but it feels there should be a way to achieve this programmatically. I could use viewerContribution instead of objectContribution, but then I would lose the easy way of showing the menu entry only when certain object types are selected. Ideally, I would like to use the enablement-checks that already exist for my handlers to apply to the menu entry defined by the objectContribution.
Ok, here's what I was missing: instead of using the org.eclipse.ui.popupMenus-extension point, I had to use the org.eclipse.ui.menus-extension point with a menuContribution that has its locationURI-attribute pointing to popup:org.eclipse.ui.popup.any?after=additions. This menuContribution can include a command-element (achieving the goal of binding directly to an existing command), and this command-element´s visibleWhen-element can be bound to the activation status of the bound command's handler via the checkEnabled-attribute (achieving the goal of having the popup-menu entry visible only when the enablement for the command handler is satisfied).
What's bad is that the documentation of the org.eclipse.ui.menus-extension point states that the org.eclipse.ui.popupMenus-extension point is to be considered deprecated, but the documentation of org.eclipse.ui.popupMenus does not mention this fact.
I'm a big fan of GhostDoc's automatic comment generation in Visual Studio so am looking for an plugin that does the same job with my Java code in Eclipse. Any recommendations?
You can check JAutodoc (http://jautodoc.sourceforge.net/)
From the author:
JAutodoc is an Eclipse Plugin for
automatically adding Javadoc and file
headers to your source code. It
optionally generates initial comments
from element name by using Velocity
templates for Javadoc and file
headers.
This one is the one I've found closest to GhostDoc.
It is basically the equivalent of Javadoc, which can be generating in eclipse with the shortcut:
ALT+Shift+J
(when you are within the Java function you wish to add javadoc for)
From there, if you really want XML format, you can try and use a JELDoclet
GhostDoc has a nice extra feature that infers a description of what the method does by parsing the method name and providing this as skeletal documentation. For example, using GhostDoc on a method named GetDocumentName() might return the phrase "Gets the document name". While this is hardly more information than provided by the method name, it adds method documentation where previously none existed. Some might argue that this is barely useful. I argue to the contrary because it supports generating documentation from the source code (e.g., for tools like NDoc or SandCastle).
In my opinion the greatest benefit of GhostDoc over eclipse's "Generate Element Comment" is that it encourages programmers to begin adding documentation comments by adding an extremely fast and reliable way create this. The programmer can accept the inferred text, (suitable in 50 - 80% of cases), or expand on this for more complex methods. For the junior programmer who is not as familiar with how documentation comments are used, this can quickly shorten the learning curve and encourage good programming practices.
Javadoc is not like GhostDoc my friend. Javadoc only creates the structure so one can write the documentation from scratch. GhostDoc actually fills up the information according to the Method/Property name.
Example:
/// <summary>
/// Gets the user from id.
/// </summary>
/// <param name="id">The id.</param>
/// <returns></returns>
private string GetUserFromId(string id);
JAutoDoc is the closest I've found so far but it's not as magical as GhostDoc.
Never used GhostDoc, so not sure what extra functionality it gives, but if it's about generating type and method comments based on the name, parameters, return type etc. then eclipse has it built in, so no extensions needed.