Most major usability problem with the current editor
I believe the most major usability problem with the current editor shows up when u say start typing 'statements' in java code.
So lets say if i want to type System.out, i first gotta select 'static field' from a list. This seems to be a very major usability problem with the current editor, as one would just like to type the text naturally and not select it from a list.
But then again a system like MPS needs editor which have prior info about what the user wants to enter, so that they can display the appropriate editor(or cell) for the 'concept'.
So what exactly are u guys doing about this? Personally i dont see how this can be fixed, cause one has to tell the editor beforehand which concept needs to be used, and thus which editor needs to be displayed for that.
Please sign in to leave a comment.
Hello, Prashant,
To get rid of this bug in MPS introduced operation that we call right
tranform. Imagine we have code like this :
a = b;
when we select b and press space new cell created and popup menu with
right transform options appears.
This thing can be further improved if we put all fields, static fields
and methods in the same popup menu (like in IntelliJ IDEA now). In
future build we will fix this.
I dont seem to get you.
>when we select b and press space new cell created and popup >menu with
>right transform options appears.
Do you mean that i first type the expression and then select the right hand value?
Also what i am saying is not about a bug. It is about how your cell based editor functions in general.
As each cell in the editor is basically a new editor itself for the 'concept' which i need to edit, the cell based editor needs to be told before hand which 'concept' i want to type, so that it can show the appropriate 'cell' or editor for that concept.
So for example if i need to type a while loop, the editor needs to be somehow told before hand that i want to type a while loop, so that it can show me a 'cell' or 'editor' containing -
while(){
}
Now i believe you are suggesting a sort of workaround for java language, but i am talking about the mps system in general. The whole idea of telling the editor beforehand about what i want to type is a major usability problem.
And thats where a simple text editor beats you, cause its tries to guess what u have typed after you have typed it, so it doesnt need to be told anything beforehand and i can type normally, while it parses the code in the background.
What are u doing about it?
Hello, Prashant,
Yes. You can write it the same way you type it in text editor.
This is a good idea to have more information about things in popup menu.
This thing is most usable in expression typing, but it is good idea to
reuse expressions sublanguage of baseLanguage or formulaLanguage in you
language. we will try to make this utility languages as much easy to use
as possible.
Again you dont seem to answer my question well (or maybe i am the one not getting ur answer).
>> Do you mean that i first type the expression and then >>select the
>> right hand value?
>Yes. You can write it the same way you type it in text >editor.
Well, if i have to first write the expression, then select the right hand expression and press ctrl+space and tell the editor what it is then how is that similar to typing in a text editor, where i just have to type the expression???????
>This is a good idea to have more information about things >in popup menu.
Again you seem to be answering a totally different question altogether??????
I was talking about the problem of the editor needing to know beforehand about each concept and u are talking something about popups???? Why dont u answer my questions right to the point?
Sure you build a huge popuplist for all the classes in the java lnaguge which will tell the editor that say i want to access a member field when i type System, but how will it work for custom languages.
>This thing is most usable in expression typing, but it is >good idea to
>reuse expressions sublanguage of baseLanguage or >formulaLanguage in you
>language. we will try to make this utility languages as >much easy to use
>as possible.
Here again you dont answer my question and are talking about a different thing altogether???
Which thing are u talking about? I asked a general question about the usability problem and u are talking about base languages, formula languages, etc???
Hello Prashant
Well, and what do you think about text editors, don't they need to parse your input? They do, and so does MPS. The difference between text editors and MPS is that text editors always reparse on input a whole text or a large piece of text, while MPS "reparses" a small subtree.
It isn't that MPS does not parse nothing and just creates cells for concepts which are for user to choose. Well, if MPS editors had had only such behaviour, you would not have been able to write, f.ex., "23" in baseLanguage just like in text editor. But you can write in MPS baseLanguage expressions like "23", "239" or "int i = 42" just by typing these symbols, like in text editor.
Konstantin tried to explain you how this feature could be implemented in MPS. Well, your editor for some concept has some keymaps, i.e. actions executed on certain key press. When you type "+" or "-" or something, the appropriate action executes, which usually does the following: roughly speaking, it takes your partly-written tree and creates a new tree and replaces your tree with the new tree.
F.ex., if your expression was "int"(cell for type indentifier) and you pressed "space", the machine thinks you want to write a variable declaration and creates a new variable declaration tree with type identifier "int" and empty cell for variable name and empty initializer, builds appropriate cell collection and sets caret into the cell for the variable name. The cell for variable name in declaration, in turn, has a keymap which maps "=" key to the action which creates an empty cell for the initializer.
Each cell has a default keymap from "space" to the action called "right transform", which is for editor designer to implement.
Other keymaps, should also be defined and implemented by new language editor designer.
Maybe such technique of implementing usable editors in MPS takes more time than you could have expected, and that's understandable, but it's not that there's general principle or something which prohibits a design of usable MPS editors, or to make such designing itself more usable, too.
I thought I'd jump in here. I agree with what JetBrains guys are saying -- there shouldn't be any problem with post-calculating/pruning the tree as one types. Though it seems that things might kind of jump around as the editor figures out what kind of cell is appropriate.
But that brings me to the larger point where I really agree with the objection. I just find this whole cell-editing idiom incredibly unnatural. I just want to type in plain text but still have the power of a domain-specific language! Is that somehow not possible? Or just soemthing that isn't part of the current vision. Sure, I could eventually adapt to such a way of entering in code, but my eventual target is neophyte developers who have some familiarity with general programming concepts and are have used traditonal languages before. There is no way I can see presenting this kind of coding interface without totally and uneccesarily confusing them.
I don't mean to be negative, but I also see this as a big adoption problem.
Agree, as for grammar-based languages cell-editing is unnatural.
But grammars don't allow to freely integrate languages and there is no way to formalize building of editor for the pure textual language.
Thats why plain text bad for LOP,
....but plain cells bad for typing :-(
Perhaps, there is acceptable solution at midpoint.
The very vague idea is that the editor would allow to transform certain local groups of cells (like expressions or statements in base language) to plain text and plain text back to cells basing on some "local" grammar.
This way, designer of the language can add "plain-text" behavior when needed and gradually.
Igor.
Well, I'm glad I'm not the only one who thought so. :-) And yes, I am more or less thinking along the same lines..
What I was thinking of is perhaps there could be a mechanism for freezing a DSL so that an 'end-user' for lack of a better word could simply use that language as they would any other language. It would seem to me to be possible to do so, as then you would have something that would be very similar to a traditional BNF grammer.
It would be kind of analagous to 'sealing' a method in a dynmic language so that that method could then be statically dispatched. Somehow there would be a mechanism to say "within this particular DSL, now treat all text as an expression of that DSL alone". I am sure that there are some subtleties I'm missing here..