So I'm using CodeMirror, and I'd like a way to omit certain edits from the undo state. In particular, I've got a situation where I want one keystroke to
Replace a portion of the mirror text AND
Auto-indent the fresh region
Doing this naively would mean that using the keystroke, then hitting undo would leave the mirror containing the new text without the indentation. I'd like a single undo to restore the initial text rather than going to the unindented version of the replaced text.
The only API-supported approach seems to be doing a .getHistory call before the indent, followed by a .setHistory call immediately afterwards, but the docs imply that this is a bad idea. Specifically, the effects of this are undefined if the contents of the mirror changed between .getHistory and .setHistory calls, which is the whole point in this situation.
There's also an addToHistory flag in the text marking API, but it's only available marking rather than arbitrary edits like indentation.
Is there a good way to do what I'm looking for here?
Changes made within a single operation will result in only a single history event.
If arranging for a single operation isn't viable, the origin field of a change (settable as an argument to replaceRange and replaceSelection, and in other cases a little more awkwardly by registering a beforeChange event handler) determines the type of history-event-combination that CodeMirror does. If you assign an origin that starts with an asterisk (*) character, subsequent changes with the same origin will be combined. If the origin starts with a +, subsequent same-origin changes will be combined when they occur within options.historyEventDelay milliseconds.
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
I want to make sure that every time I make a change to a document, a certain action is performed. For this I wanted to use OnBeforeStore or OnAfterSaveChanges.
Unfortunately, these two events are not triggered when I save a change via patch or add/delete an attachment.
We use the CQRS pattern and have several commands making changes to entities / collections. I need a central place to execute every change to a particular collection, no matter which command is used.
Is there such a thing in RavenDB?
There is no "central place" that track every change to collection.
About the OnAfterSaveChanges event, it should fire on those actions too.
https://issues.hibernatingrhinos.com/issue/RavenDB-13906
I've implemented a Dead Man Switch this way:
A script can be fired by an event. When the script starts it looks for a specific object on an S3 bucket. If that object can't be found for any reason (be it network issues to access the bucket, lack of permissions, the object was removed or any other reason) then the script will abort before doing any other actions.
I suppose this is a classic Dead Man Switch.
The idea is to let us remove this object in case we need to stop the script in an emergency.
My question is about terminology - I also supply a script to our team to create or remove that S3 object. I want it to be clear which actions means what (remove object - stop script from doing anything, create object - let the script continue with its work). I used "removed" and "reinstate" and was told this is too ambiguous. I now contemplate about "pushed" and "enabled" but this too sounds too vague. I'm also thinking about "pulled" (object removed) vs. "rearmed" (object created).
It's important that the terminology will be clear since if this script is used then this is expected to happen during emergency, so we want to minimize confusion as much as possible.
I suppose the problem is the inherent "double negative".
So far I didn't find any common name used to describe these actions. Wikipedia and other places describe what the switch is, but not actions of enabling or disabling it.
Any ideas?
I would say that the system would be:
Enabled if the object is present
Disabled if the object is absent
Placing the object would enable the script.
Removing (deleting) the object would disable the script.
You could even call the file enable-xxx-script to make it more obvious.
I need to do certain processing when a Scintilla editor first becomes 'dirty' before the document actually changes.
The SCN_SAVEPOINTLEFT notification seems like the obvious candidate, but unfortunately this is fired after the change that made the document dirty has occurred.
Looking through the other available notifications, SCN_MODIFIED also is fired after the change has happened (and the same is true of SCEN_CHANGE of course).
The best I can think of is to start macro recording in response to SCN_SAVEPOINTREACHED (i.e. when the document is saved or all changes are undone). Then when I detect the first change with SCN_MODIFIED, I stop recording, undo all changes until I get back to the save point, perform my custom processing (which happens to be modifying a date field in the document), then replay the recorded macros to restore the undone changes.
This seems horribly convoluted. Is there an easier way? (Maybe it would be simpler to create my own custom version of Scintilla with a SCN_BEFORECHANGE notification, but I'd prefer to avoid creating a fork. And a cursory glance through the source suggests that there are a great many points from where this notification would have to be sent, making it easy to miss some.)
Update: The real requirement was that when the user executes 'Undo' after first modifying the document, the 'automatic' edit and the user's first edit are not in the wrong order in the undo buffer. The simplest solution turned out to be, not to force the automatic update to be first, but to coalesce these two actions into a single undo action using SCI_BEGINUNDOACTION/SCI_ENDUNDOACTION. See my comment below on how I did this.
The SCN_MODIFIED notification does seem to fit your spec. The modificationType field provides information about what has been done, including:
SC_MOD_BEFOREINSERT 0x400 Text is about to be inserted into the document.
SC_MOD_BEFOREDELETE 0x800 Text is about to be deleted from the document.
So, I asked another question here:
How to tell the difference between a user-tapped keyboard event and a generated one?
One of the answers that came up was to use the "mouse pressure" field (unlikely to be used for a keyboard event) to mark the event as needed.
So, I'm trying:
CGEventSetIntegerValueField(myKeyboardEvent,
kCGMouseEventPressure,
0xFEEDFACE);
The problem is:
I don't know what 0xFEEDFACE means. What does that value default to? What should I set it to? How can I check whether it has been marked by me?
Running the above code gives me an error:
<Error>: kCGErrorIllegalArgument: CGEventSetIntegerValueField: invalid event
0xFEEDFACE is just a dummy value. It's one of a number of 4-byte numbers with silly hex spellings that will stand out when you're looking at memory.
The function takes three arguments: an event, a CGEventField (which is an enum), and an int64_t (8-byte signed integer) whose range of valid values probably depends on the field. I used 0xFEEDFACE to indicate that you could try putting an arbitrary "magic" value in there,* and then check for it when you received the event, using CGEventGetIntegerValueField. If your event tap receives a new event that has your "magic number", then it was (almost certainly) sent by you. Otherwise, it was sent by the system.
To sum up and answer your explicit questions: that argument doesn't default to anything; you should pass something arbitrary that is unlikely to be used by the events system (you might want to inspect a series of events sent by the system to see what "real" values look like); the idea is that your arbitrary value allows you to check that the event was marked by you.
As for the error, it looks like I was wrong. I thought that you might be able to set any field on any kind of event (e.g., using the "mouse pressure" field on a keyboard event, since the system almost certainly won't have set that) to pass along arbitrary information (and so identify the events that you've constructed yourself). It seems, however, that Event Services won't let you do that. There may be other fields that you can use, but I don't know for sure.
*I assumed you would understand that it was a junk value; sorry.