Open qindapao opened 12 months ago
@nkh
For example, z
-e
-c
changes the type of the current element to the third type it supports.
@qindapao I'm not sure I really understand what you mean.
if you mean having the possibility to have more than one level of indirection, IE: insert - box - unicode - type_3 by typing "ibu3" then that's already implemented.
for the example above you proposed "zec" to change the type of the selected elements, I propose "etc" instead as we have already an element group in the bindings -> element - type - c.
The only thing left is the function to do the change, alternatively we make the elements more object oriented and add class function.
'<< element leader >>' =>
{
SHORTCUTS => '000-e',
'Shrink box' => ['000-s', \&App::Asciio::Actions::ElementsManipulation::shrink_box ],
'Make element narrower' => ['000-1', \&App::Asciio::Actions::ElementsManipulation::resize_element_offset, [-1, 0] ],
...
@nkh What I mean is changing the type of an existing element, which may already have text inside it. Functions like box_type
or arraw_type
in the right-click menu.
@nkh e
-t
-c
also good
@qindapao
z is more for global "display" feature like showing the grid or not while I believe we should keep e for element related operations
given that you already can bind e-t-c to any function you want, what is preventing you from changing an element type?
@qindapao
z is more for global "display" feature like showing the grid or not while I believe we should keep e for element related operations
given that you already can bind e-t-c to any function you want, what is preventing you from changing an element type?
@nkh Okay, I understand what you mean, I will do this binding when I have free time.
@qindapao When you write the bindings, I think it would be good to have a binding that changes the selected elements to ASCII <-> Unicode, that binding doesn't exist. I also noticed that at least two elements need to be selected which is not practical.
@nkh Converting to unicode can be for multiple elements. But changing the type is still for a single element.
@qindapao I think it's better to write code that changes type for all selected elements, that works with single element too.
In the case the multiple elements cannot be changed because the elements are not from the same type, then nothing should be done.
@nkh Ok, I see.
@qindapao I need to revise my opinion.
I still thing that changes should apply to all selected elements and not require that a single element is selected.
I wrote that if multiple elements are selected and that they are not the same type then nothing should be done; I think that is wrong. Say ten elements are selected,5 are boxes and 5 are arrows, if the command is to transform boxes into, say, unicode, boxes type 3, then the five boxes should be changed and the 5 arrows simply ignored.
@nkh
Well, this is better.
Inspired by vim's 26-character register.
We now have key combinations and key completion prompts. Then we can make the type of the current element appear in the completion prompt. The type starts from
a
and supports up toz
.There should not be an element that provides as many as 26 types.When there are many types, it should be the work of the stencils, and the software should no longer provide default types to support it.Currently, the element with the most types is the ordinary box, with 13 types.At most, add one more unicode dashed line, no more.
@nkh what do you think about this? Using the context menu to change types is now inefficient.