Is it possible to specify a value for help-echo in the arguments passed to font-lock-add-keywords?
If not, is there an efficient and reliable place to add this property via Font Lock's normal operation?
I've read through "Search-Based Fontification" and "Customizing Keywords" in the elisp manual, and I'm implementing a minor mode by adapting fic-mode.el .
Thanks.
While font-lock was designed to manage the face property, it can also set any other property. To set a given property, just use (face <face> <prop1> <val1> <prop2> <val2> ...) as the face to apply (if you don't want to apply any face at all, use nil for <face>). In order to make it work reliably, you also need to tell font-lock that it manages those extra properties by adding <prop1>, <prop2> etc to font-lock-extra-managed-props. If you don't, those properties will not be correctly removed when they do not apply any more.
Related
I want to make the editor experience better and more visually pleasing when filling in content on a page (In all properties view). Could be a simple divider or a heading..
I am already using tabs, whenever it makes sense. Also, I have been experimenting with using blocks as properties. This adds a nice separation with at clear heading, but it is so much more code to maintain and a bit of a mess to be honest when the properties truly belong to the page type.
Out-of-the-box, it is not possible to decorate properties with headlines, unless you use block-properties, as you mention yourself.
However, I thought your question was quite interesting, and I discovered that extending Episerver to accommodate this behavior is surprisingly easy. I have written an example solution, which you're free to use as you like: https://arlc.dk/grouping-properties-with-headlines-without-property-blocks.
If you dislike the solution, an alternative approach would be to introduce your own Property-type (Headline), and create a 1) a custom dojo-widget to simply display a headline, and 2) an EditorDescriptor to set the ClientEditingClass.
Linus wrote an excellent blog post on this here: https://world.episerver.com/blogs/Linus-Ekstrom/Dates/2012/7/Creating-a-custom-editor-for-a-property/.
EDIT:
I see, I have skipped too quickly over the overriding part.
You don't have to override any files by replacing them, and you won't have to extract Shell.zip (unless you're curious how Episerver has implemented their widgets). The part that overrides the specific component is define("epi/shell/form/Field". As long as your definition of this widget is loaded after shell, dojo will use your implementation, whenever something is requiring "epi/shell/form/Field". The thing that ensures your implementation is loaded after, is in module.config, under 'This injects our field-implementation [...]'.
The path ~/ClientResources/Scripts/Shell/Field/Field.js is simply the location I have chosen to put the overriden version of Field.js. You can put it wherever you like, as long as you update module.config accordingly, with the new path.
It works like this: First, Episerver defines widget A. Then you define a widget with the same name, A. When anything tries to fetch A, it returns your implementation, rather than Episerver's.
I am trying to create a new GUI element within DrRacket's text window, like picts or syntax objects. As far as I can tell, the most standard way of doing this is with a snip%.1
Unfortunately, the documentation for creating new snips, while comprehensive, is a bit impenetrable and leaves some questions to be answered.
For starters, what is the difference between a snip% and a snip-class%? Why do these need to be separated out into two classes, rather than simply being combined into one class? Is it because multiple snips will use one snip class?
Second off, what is snip-reader<%>? Not only why does it need to be a separate class, but why is the module providing it supposed to be installed?2 If it does need to be a new class, why can't it just be referred to directly. Why go through this whole process of constructing and then parsing a string of the form: "(lib ...)\n(lib ...)"?
I mean, there might now be any reason for this design, and it might just be a remnant of an old API. If so, has anyone thought of making a new more consistent API? Or if there is a reason for this design, can you please tell me what it is, as the docs don't seem to make that clear.
I mean, as of right now, I can copy/paste the sample given in the docs on creating a new snip. But I'm having a hard time understanding the design going on here, so I can use them properly.
1I know there are other ways to do it, but I also want to have interactive buttons and whatnot.
2I know it doesn't need to be installed as a library per se, but the documentation seems to strongly push you in that direction.
Okay, I think I finally found the answer. Broadly speaking:
The snip% class includes the methods for drawing the snip, telling the editor how much space to reserve for the picture, and handling events such as mouse clicks.
Next, the snip-class% class is used for encoding and decoding snips. This must be a separate class because when saved to a file, the editor needs to encode what type of snip it is, and for obvious reasons it can't just put the literal snip% class in there. The value it stores in the file is the snip-class%'s 'class name'. This can be anything, and as long as the editor has the classname associated to a snip-class%, it can be loaded. Additionally, if it is of the form "(lib ...)" or "(lib ...) (lib ...)" Racket will just automatically load it into the list for you.
Nothing 'needs' to be installed per se, its just the easiest way to go about it. Otherwise you manually need to tell the editor how to handle the snip before actually loading the file.
Is it possible to use variables in the creation of objects in AutoCAD? For example, I would like to create a number of circles and have their diameter property determined by a custom variable. This would allow me to easily change the value of multiple objects after creation.
It seems like an easy thing to do, but I can't seem to find an answer to this question.
Clarification:
I simply want to have easy programmatic control over the defining characteristics of a number of objects for easy modification at a later date.
It doesn't seem possible do this in just one step, but using the parameteric tools allows some degree of programmatic change after object creation.
In the example of the circle, diameter control can be achieved using the DIMCONSTRAINT command in conjunction with a user defined parameter. Use PARAMETERS command to access all of the drawing's parameters.
If you're planning on using the in-process libraries, you can create a custom command that takes a parameter from the AutoCAD command line, which you could use to create your circles.
in my system "compare modifications" and "save image" are optional activities. but they are presented to the user. user may or may not use them. is this the correct form showing the scenario in use case diagram? Imstill new to UML , if I'mnot wrong i think extend keyword can be used to show optional activities.
Are Save Image and Compare Modifications separate use cases? If they are i wonder what user scenario they describe?Too generic IMHO. But i dont know the domain under study so cant really drive my point there. Extend is applied to scenarios where extending use cases are specialized versions of the parent use cases. So to translate that into your scenario, whenever the actor encounters Save Image functionality(assuming Save Image has some real business functionality rather than just a Save Image screen) he might choose to Store the image to disk(and thereby execute Store Image to Disk's Normal Flow, Alternative flow,BRs etc) or he might not, in which case the flow might continue with Save Image use case's Alternative Flow(AFs). If my assumptions are right, then the answer to your questions is YES.
<<extend>> use cases are used when you want to provide point in a use case where you can later add new functionality, and not to show optional operations.
Any use case can be optional, they only show functionality that the system provides to the user and do not show ordering or causality. The <<include>> use cases do show some causality relation but this is also minor and nor compulsory.
In the most simple terms Includes is something which is mandatory and Extends is optional, this is a very simple explanation which helped me understand.
I'm trying to play with the new syntax coloring capabilities of VS2010 based on Noah Richards' diff coloring sample. The goal is to create syntax coloring for SpecFlow (http://www.specflow.org).
In my case, finding the syntax elements are fairly complex and not line-level. Therefore, when I implement the GetClassificationSpans I don't want to re-parse the entire file, but rather take the state of the beginning of the changed text and parsing the content from that point on.
I thought that I can get the previous classifications as ClassificationTags. I did this using the IBufferTagAggregatorFactoryService class.
It works, but I'm not sure whether this is the best way to go. Shall I create only tag aggregator for the entire classifier class or I can create it every time when GetClassificationSpans is called? Shall I create a special tag to remember the parsing state?
Maybe this is anyway not the right way to go, I'm also interested in other suggestions.
Br,
Gaspar
Edit: I've found a good article series in the topic: http://www.hill30.com/MikeFeingoldBlog/index.php/2009/07/31/django-editor-in-vs-2010-part-1-colors/
Essentially, you'll have to remember the state yourself. Most VS language services keep a state cookie for the beginning of each line that they update on text change.
At any point, getting classifications (through either a classifier aggregator or tag aggregator) will always result into a call into the current classifiers/taggers, so it won't be returning any type of cached state (or the "last" classifications returned). The editor doesn't really cache this information, and just acts as a dumb pass-through for the information your classifier provides to the visible lines being formatted.
Also, If you do it from a classifier (provided by either an IClassifierProvider or ITaggerProvider), you are setting yourself up for some nasty recursion, especially if your classifier responds to GetClassificationSpans by calling into the aggregator (which then calls back into your classifier for some earlier text, etc.). If your classifier needs to consume other classifications to work correctly (and not its own classifications), the only safe way to write that is to:
Implement your "classifier" as an ITagger<IClassificationTag>, and provide it from an IViewTaggerProvider.
Grab an ITagAggregator<IClassificationTag> from an IBufferTagAggregatorFactoryService, but only once.
Implement IDisposable on your tagger and dispose the tag aggregator in Dispose().