Lot of documents about UML and how to write use cases, focuses only the how part. Here is one document that seems to be best answer your question.
Read this : Writing Effective Use Cases. (Write to me if you want a copy) The same author have the book which is an extended form. See the book here.
In essence, as the books puts up, you first need to define the scope of the overall system at different levels. For example, it starts with An Organization X serving its client organization. The use case is defined of the organization at that scale. Further down, now individual functions are then done at (one or more Products) say a client application (that the client application as well as administrators use) will talk to server and so on.
The level of details increases as you go down, but the scope becomes narrow. Understand that the purpose is not to repeat things but to organize things in the form of different levels hierarchy.
This way, you keep refining the scope and go deeper. So when do you stop? Probably the simple answer is: when it is trivial not to write the question. Essentially, (as per the book) you write use cases of each entity separately. - The organization, various systems (or products) being consumed, At some point writing use cases of an entire UI application could be enough; But if you do have a major component which does seems of far more important than use case at that level of is more important; at that level you probably have to write use case at the level of forms/inputs at that level.
Now coming to your question - as i said, it depends on the scope. From the UI (also when you are treating word processor or rich text editor within a very larger system), you expect that UI provides many messages back to core (each formatting command as a simple message). However, from the point of view of the actual model object which implements this - each command is a unique item. Hence, for the back-end object, each command is unique functionality and hence they are unique different use cases.