At the end of this tutorial: https://www.youtube.com/watch?v=ICxMZGLKEbU the author makes it look like the Incremental Find (CTRL+I) is somehow a quicker way to get one's cursor from anywhere in the edited document to some specified place than when using the Regular Find (CTR+F), but I fail to see any difference in the number of steps required. You hit the keys, type a word to which you want to get to, and then either press ENTER (Incremental) or ESCAPE (Regular).
Also, I don't quite see why it's called incremental.
There is a slight difference in between the two functions. With Find (CtrlF), you type in what you're looking for, and each time you hit Enter the next occurrence of the pattern is shown, but it is not a selection in that you can begin typing right away - you need to hit Esc first, and the highlighting is changed to a selection.
With Incremental Find (CtrlI), on the other hand, you start typing in your pattern, and when you hit Enter, the Find highlighting is turned into a selection, the dialog box disappears, and you are immediately able to begin editing the selection. This saves a grand total of one keystroke over the Find method, but has the disadvantage that, unless you hit F3 (Find Next), you are only editing the first instance of the pattern found.
It's kind of a subtle difference, and each one can be used in different situations. Play around with them both and see how each fits into your workflow.
The only functional difference (other than using different keys) is that with incremental search you have the option of either going back to the original (pre-search) cursor position by hitting ESC or staying on the found result by hitting RETURN... whereas the full Find function does not give you the ability to go back to the original position (although you can easily do so with the Goto > Jump Back command after exiting your search).
So in the one very limited use-case of "I want to save 1 keystroke in the event that I want to go back to my original cursor position after searching and seeing what I found but not changing it at all", incremental search has the normal find functionality beat. However, to me this is a detriment because whenever I try incremental search, I wind up hitting that ESCAPE key by accident (because my muscle memory is so used to it from the normal Find functionality) and having to do the search over again.
Hence, practically speaking I think it's best to ignore the existence of Incremental Search. Why bother trying to teach your fingers a separate sequence of keyboard commands and an ever-so-slightly different mental model of how it works (but with no practical difference other than saving 1 keystroke in an edge-case at the expense of triggering it accidentally more often than you want it to actually happen on purpose)?
Historically speaking, I think incremental search is a holdover from older text editors that didn't have search functionality as well-done (IMO) as Sublime. (Actually I think Sublime v2's search interface didn't work as smoothly as v3 does, so maybe it was more helpful back in the old days of Sublime as well?)
The behavior of Ctrl+F copies the behavior of the Find dialog as implemented in the majority of mainstream software. The Incremental search copies Emacs' Incremental search functionality.
The biggest advantage of incremental search is, it shortens the search operation in most cases. Say you want to find "shakespeare". With regular search you must type the whole 11 letters, while with incremental you will most possibly get to the word after typing the first few letters.
Related
I am a web developer and use git and other small commands all the time in terminal. I know git goodies, how to use aliases, etc., but I was wondering whether it is possible to do it with keyboard layouts?
(1. Just for fun, 2. There might be other uses of it)
I managed to create keylayout file and substitute a character by a word, but I cannot get further than 20 (or so) characters. Does somebody know whether there is some limit on it? I played with maxout variable but it had no effect.
I hope I was clear on my question, might be a bit abstract. https://developer.apple.com/library/content/technotes/tn2056/_index.html
Thanks in advance!
Not sure if you ended up figuring this out, but I'm right there with you—couldn't figure out a solution, trying to input 30 or so keys seems to crash whatever application is open, and relaunch Finder. Bit of a shame, although you could try using text replacement? It's under System Preferences > Keyboard > Text, I've been using that for misc things that I was too lazy to slap on my keyboard.
Key replacement doesn't seem to have a limit, although it might and I just didn't notice. Bit of a bummer, seeing as I'd prefer to hit "Alt-B" instead of typing something like :replaceme:, but it seems to get the job done. Doing some quick testing revealed no problems outputting 2,000 chars via text replacement, although after that it seems to hit some sort of limit (2048, maybe). For now, though, this seems to be the best solution.
Part of my project is to write a text editor that is used for typing some rules, compiling my application and running it. Writing compiler was end and release beta version. In the final version we must add undo and redo to the text editor. I use a file and save it periodically for the text editor. How to design undo and redo to my text editor? What is changed in the structure of persistent of file?
You can model your actions as commands, that you keep in two stacks. One for undo, another for redo. You can compose your commands to create more high-level commands, like when you want to undo the actions of a macro, for example; or if you want to group individual keystrokes of a single word, or phrase, in one action.
Each action in your editor (or a redo action) generates a new undo command that goes into the undo stack (and also clears the redo stack). Each undo action generates the corresponding redo command that goes into the redo stack.
You can also, as mentioned in the comments by derekerdmann, combine both undo and redo commands into one type of command, that knows how to undo and redo its action.
There are basically two good ways to go about it:
the "Command" design pattern
using only OO over immutable objects, where everything is just immutable objects made of immutable objects made themselves of immutable objects (this is less common but wonderfully elegant when done correctly)
The advantage of using OO over immutable objects over the naive command or the naive undo/redo is that you don't need to think much about it: no need to "undo" the effect of an action and no need to "replay" all the commands. All you need is a pointer to a huge list of immutable objects.
Because objects are immutable all the "states" can be incredibly lightweight because you can cache/reuse most objects in any state.
"OO over immutable objects" is a pure jewel. Probably not gonna become mainstream before another 10 years that said ; )
P.S: doing OO over immutable objects also amazingly simplifies concurrent programming.
If you don't want anything fancy, you can just add an UndoManager. Your Document will fire an UndoableEdit every time you add or remove text. To undo and redo each change, simply call those methods in UndoManager.
The downside of this is UndoManager adds a new edit each time the user types something in, so typing "apple" will leave you with 5 edits, undoable one at a time. For my text editor, I wrote a wrapper for edits that stores the time it was made in addition to text change and offset, as well as an UndoableEditListener that concatenates new edits to previous ones if there is only a short period of time between them (0.5 seconds works well for me).
This works well for general editting, but causes problems when a massive replace is done. If you had a document with 5000 instances of "apple" and you wanted to replace this with "orange", you'd end up with 5000 edits all storing "apple", "orange" and an offset. To lower the amount of memory used, I've treated this as a separate case to ordinary edits and am instead storing "apple", "orange" and an array of 5000 offsets. I haven't gotten around to applying this yet, but I know that it'll cause some headaches when multiple strings match the search condition (eg. case insensitive search, regex search).
Wow, what a conicidence - I have literally in the last hour implemented undo/redo in my WYSIWYG text editor:
The basic idea is to either save the entire contents of the text editor in an array, or the difference between the last edit.
Update this array at significant points, i.e. every few character (check the length of the content each keypress, if its more than say 20 characters different then make a save point). Also at changes in styling (if rich text), adding images (if it allows this), pasting text, etc. You also need a pointer(just an int variable) to point at which item in the array is the current state of the editor)
Make the array have a set length. Each time you add a save point, add it to the start of the array, and move all of the other data points down by one. (the last item in the array will be forgotten once you have so many save points)
When the user presses the undo button, check to see if the current contents of the editor are the same as the latest save (if they are not, then the user has made changes since the last save point, so save the current contents of the editor (so it can be redo-ed), make the editor equal to the last save point, and make the pointer variable = 1 (2nd item in array ). If they are they same, then no changes have been made since the last save point, so you need to undo to the point before that. To do this, increment the pointer value + 1, and make the contents of the editor = the value of pointer.
To redo simply decrease the pointer value by 1 and load the contents of the array (make sure to check if you have reached the end of the array).
If the user makes edits after undoing, then move the pointed value array cell up to cell 0, and move the rest up by the same amount (you dont want to redo to other stuff once they've made different edits).
One other major catch point - make sure you only add a save point if the contents of the text editor have actually changed (otherwise you get duplicate save points and it will seem like undo is not doing anything to the user.
I can't help you with java specifics, but I'm happy to answer any other questions you have,
Nico
You can do it in two ways:
keep a list of editor states and a pointer in the list; undo moves the pointer back and restores the state there, redo moves forward instead, doing something throws away everything beyond the pointer and inserts the state as the new top element;
do not keep states, but actions, which requires that for every action you have a counteraction to undo the effects of that action
In my (diagram) editor, there are four levels of state changes:
action fragments: these are part of a larger action and not separately undoable or redoable
(e.g. moving the mouse)
actions: one or more action fragments that form a meaningful change which can be undone or redone,
but which are not reflected in the edited document as changed on disk
(e.g. selecting elements)
document changes: one or more actions that change the edited document as it would be saved to disk
(e.g. changing, adding or deleting elements)
document saves: the present state of the document is explicitly saved to disk - at this point my editor throws away the undo history, so you can't undo past a save
This is a job for the command pattern.
Here is a snippet that shows how SWT supports Undo/Redo operations. Take it as practical example (or use it directly, if your editor is based on SWT):
SWT Undo Redo
Read a book Design Patterns: Elements of Reusable Object-Oriented Software. As far as I remember, there is a pretty good example.
What I'm Doing
I am currently working on creating a SWI-Prolog module that adds tab-completion capability to the swipl-win window. So far I've actually gotten it to where it reads a single character at a time without stopping/returning anything until a tab character is typed. I have also already written a predicate that returns all possible completions of an incompletely typed term by using substring-matching on a list of current terms (obtained via current_functor/2, current_arithmetic_function/1, current_predicate/2, etc [the predicate used will eventually be based off of context]).
If you want to see my code, it is here...just keep in mind that I'm not exactly a Prolog master yet (friendly tips are more than welcome).
What I'm Thinking
I've long abandoned any efforts at using XPCE to do popup-dropdown-completion in the swipl-win window (I'll eventually try to get that into Pce-Emacs [it won't be as polished as Visual Studio --picture something more like Python's IDLE], but I don't know if that's really even practical since I'm starting to use actual Emacs a lot more nowadays anyway), but is there any way to modify the output color in the swipl-win window? I know syntax highlighting has already been implemented in other Prolog systems' command-prompt windows, but I really just want to have it so that when tabber.pl suggests a completion, it also shows the arity (and perhaps the rest of the partially-typed term) of the suggested term in light gray. I know there is already color output from the system (like when it starts up), but I don't know how to hook into output stuff to control it myself. (Obviously, I'd probably define print/1 but...)
I know I could write my own SWI-Prolog console like one guy has done with C#, but I really wanted it so people (including me) could just load the tabber module somewhere in their config file and continue to use the swipl-win window, rather than having it be a completely different executable... Would I have to use some kind of C API?
Note:
The actual implementation will likely be influenced by the answers that I get to this question, because I'm going to base my decision on the use of strings and/or atoms in this project off of them.
What I'm Asking
Is there a way or something (even if it's really low-level) I can implement to colorize output in the swipl-win window?
AFAIU the question you have to deal with is to avoid calling the fontify-function every seconds as common buffers do. I.e. call it only once when output arrived and restrict fontification to previous prompt in buffer.
It seems like three ways to approach detecting unsaved changes in a text/image/data file might be to:
Update a boolean flag every time the user makes a change or saves, which would result in a lot of unnecessary updates.
Keep a cached copy of the original file and diff the two every time a save operation needs to be checked.
Keep a stack of all past operations and push/pop operations as needed, resulting in a lot of extra memory usage.
In general, how do commercial applications detect whether unsaved changes exist and what are the advantages/disadvantages of each approach? I ran into this issue while writing a custom application that has special saving behavior and would like to know if there is a known best practice.
As long as you need an undo/redo system, you need that stack of past operations. To detect in wich state the document is, an item of the stack is set to be the 'saved state'. Current stack node is not that item, the document is changed.
You can see an example of this in Qt QUndoStack( http://doc.qt.nokia.com/stable/qundostack.html ) and its isClean() and setClean()
For proposition 1, updating a boolean is not something problematic and take little time.
This depends on the features you want and the size/format of the files, I guess.
The first option is the simplest, and it gives you just what you want with minial overhead.
The second option has the advantage that you can detect when changes have been manually reverted, so that there is no real change after all (although that probably doesn't happen all too often). On the other hand it is much more costly to make a diff just to check if anything was modified. You probably don't want to do that everytime the user presses a key.
The third option gives the ability to provide an undo-history. You could limit the number of items in that history by grouping changes together that were made consecutively (without moving the cursor in between), or something like that.
It happens sometimes that one feature seems to belong to more than one place.
Trivial example, let's say I've got the following menus :
File
Pending orders
Accepted orders
Tools
Help
I've got a search feature, and the same search window work for both pending and accepted orders (it's just an 'order status' combo you can change)
Where does this search feature belongs?
The Tools menu seems to be a good choice, but I'm afraid the users may expect the search accepted orders to be in the accepted orders menu, which would make sense
Duplicating the menu entry in both pending and accepted order seems wrong to me.
What would you do? (And let's pretend we cannot merge the two orders menu into one single menu)
I think the problem you've run into is that you're thinking like a programmer. (code duplication bad). I'm not faulting you for it, I do the same thing. Multiple paths to the same screen, or multiple ways to handle the same process can actually be extremely beneficial. I would guess that more than one person is going to use your program and each probably have slightly different job functions. In essence, they have different needs for the application and will approach using it different ways. If you stick to the all items have one way of being accessed, some people will find the application beneficial and others won't. Sure all people can learn to do a task a certain way, but it won't make sense to some users. It's not intuitive (read familiar) to they way they are used to processing information, which means the application will ultimately be less beneficial to them. When people find a process (program etc.) frustrating, they won't adopt it. They find reasons why the process will need to be changed or abandoned.
An excellent example of the multiple approaches to a problem is with Adobe Photoshop. Normally there are at least 2 different ways to access a function. Most users only know of one, because that's all they are concerned with, but most users are really comfortable with using one, because it makes the most sense to them. With a little extra work, Adobe scored a huge win, because more people find their product intuitive.
Having a feature in multiple locations is not a bad thing. Consider the overall workflow for viewing both pending orders and accepted orders, and think of your new feature as a component, rather than a one-off entity.
After you map out exactly what tasks a user completes in the pending and accepted order viewing process, see where having the ability to search would provide value (by shortening the workflow or otherwise). This is where your search component belongs.
The main thing to remember about UI is that all that really matters in the end is whether your design makes using your application or site a better experience for your users.
In the search example you list above you'll commonly see apps take two approaches:
Put the search feature in a single location and allow the user to filter the search by selecting pending or accepted, or
Put the search feature in both menus, already configured for the type of search to be done based on the menu it was launched from.
If you repeat the above choice for a number of factors you'll see a much more advanced (aka 'complicated') search interface for number one, and a much simpler (aka 'restrictive') search interface for number two.
Which one is best completely depends on your users. This is why many general applications have a simple search by default and a link to a more advanced search for those that want or need the additional capabilities; they're attempting to make everyone happy. There is absolutely nothing wrong with that if you're writing for a wide variety of people with different needs. If you're writing for a set of users with a restricted set of needs however, you can make some better choices.
In my experience your best bet is to work with one or two of your primary users and map out all of the steps they need to take to get each of the tasks the application will be helping them with accomplished. If there aren't a lot of branching points in that sequence of steps there shouldn't be a lot of choices or settings to make in the application; otherwise the users may feel that the app is harder to work with than it needs to be.
For the search example above, if the user has already navigated into the Pending Orders menu, the likelihood that they'll want to launch a search for Accepted Orders is very small and having to make that choice, or go elsewhere to do the search, will be an extra decision or action they'll need to take. Basic principle is if your user has already made a decision, use it; don't make them tell you again.
Use the UI you come up with as a first cut. Let your users, or a subset of them, try it out and make suggestions. If you have the option, watch them use it. You'll learn far more about how to improve the interface by seeing how they work with it than you will from what they tell you.
Generally you do not want the same menu item appearing in different menus. It adds complexity and clutter to the menu, and users will wonder if the two menu items are really the same or not. When it appears that a menu item belongs in two places, then you may have a more basic problem with your menu organization.
For instance, your example shows a menu bar that is organized by the class or attribute of the object the commands within act on. In general, the menu bar should be organized by category of action not type of object. For example, you could have a Retrieval menu for commands like Search and other means of displaying orders, and a Modify menu for processing the orders (e.g., updating, accepting, forwarding). Both menus would have menu items that apply to both types of objects, although some commands may apply to only one.
Organizing commands by object type is actually a good idea but it is better accomplished with a context menu (right click) than the menu bar.
I would try the search in both the Accepted Orders and Pending Orders menus. However, user testing will show if this is a good idea or not. But it also depends on your user base.
You are doing user testing right?
...you may already know this, but this is a good place to use the command\action pattern IMHO.
So to answer your question: IMO, yes, it is ok :) This situation is definitely warranted.
Just put it under both menus and have it open your search window, pre-configured for the order type who's menu it was launched from. Name them accordingly and voila they're actually two different actions - even though they use the same code/component.
Keep the user-selectable "status combo you can change" in the search window active though so the user still can adjust the settings without relaunching it from the other menu... and then perhaps rethink the structure, see some of the great answers in here for ideas ^^