Sunday, March 25, 2018, 10:24:44 AM, Hussein Shafie wrote:
> On 03/24/2018 11:43 AM, Daniel Dekany wrote:
>>
>> It often happens that XXE doesn't do what I meant, because after so
>> much PC usage I do many things motorically, and XXE breaks conventions
>> where the different logic of XXE doesn't warrant that (as far as I
>> see). I guess these are mostly just subtle bugs, and I guess they make
>> XXE feel less handy for many others too. Here they are:
>>
>> - When you type into the element type or attribute name filter text
>> input, and the list below highlights an entry, the text input where
>> you type isn't auto-filled right to to the cursor. It's what such
>> controls (combo boxes) used to do, at least on Windows. So that's
>> maybe the thing to fix, but if you can't/won't, then my real issue
>> is that if I start to type an attribute name, and the correct
>> attribute is highlighted in the list under, and then I hit Tab to
>> navigate to the attribute value field, the attribute name field will
>> contain the incomplete value (it's not auto-completed). I have
>> discovered that I can press Down before Tab to work that around, but
>> it's not how our (my?) reflexes has evolved, also it's one more key
>> to press.
>
> Please change this setting ("Options|Preferences", "Edit" section):
>
> "Append mode"
>
> to:
>
> "Automatic".
>
> See
> http://www.xmlmind.com/xmleditor/_distrib/doc/help/editOptions.html
Wow... wasn't expecting such a thing to be configurable. Maybe
"Automatic" should be the default though, at least on places where the
set of valid values is known. If not, then note that even with the
default "Append mode", I don't have this problem when
inserting/wrapping/convering to element, because there, even if only
type the first few letters, the highlighted element will be used when
I hit Enter. Can't the attribute editor work like that as well? The
set of valid attribute names is also known after all.
>> - An edge case of the previous auto-filling strangeness: Let's say I
>> have `<emphasis>foo</emphasis>` that I want to change to just `foo`.
>> So I move the cursor inside "foo", Ctrl+Up, Ctrl+Up, Ctrl+t (so now
>> the cursor is in the element type selector panel), and there I want
>> to select "(text)", which is the top entry. So I just press Down,
>> and "(text)" is highlighted as expected. But, as the text input
>> itself will be still empty (despite that this time I did press
>> Down), when I hit Enter, nothing happens (and I have to start over).
>> To work that around, I have to hit Down twice. The first Down
>> selects "(text)", the second one actually puts it into my text box.
>
> Same answer as above. First of all, please give a try to
>
> "Append mode" = "Automatic".
It doesn't work in this case, as I type nothing (because "(text)" is
on the top). So the confusing thing is that after Down you see
"(text)" being highlighted, so you expect Enter to do its thing.
>>
>> - After converting/wrapping a text range selection into an element,
>> undo (Ctrl+z) will not only revert the conversion/wrapping, but also
>> select the the *whole* text node, and you lose the original text
>> section range. So you can't select a range of text, then
>> convert/wrap into element, then undo, then convert/wrap the same
>> text selection into a different element. Even the cursor position is
>> lost, as the cursor jumps at the first character of the text node,
>> so you need to mouse/arrow back to where it was.
>
> Indeed. Sorry but we currently don't see (technically) how to improve this.
MS could do it! <-;
>> - Ctrl+C in the attribute value editor cancels the attribute entry.
>> You instinctively press Ctrl+C to copy. Note that the alternative,
>> Ctrl+Ins is not copying in XXE for known reasons, so Ctrl+C is your
>> only option, but it's overloaded in that context. If I really want
>> to cancel the attribute entry, I can press Esc.
>
> That's right. We'll *try* to fix this annoying behavior in the next version.
>
>
>
>>
>> - Scrolling with mouse wheel or the scroll bar on the side shouldn't
>> move the cursor. When the cursor is off screen, and it's moved by
>> some operation (typically keyboard), the view should jump back to a
>> position where it's visible from. Then usually the cursor is at the
>> top row if we had to jump upwards, and at the bottom row if we had
>> to jump downwards. This is just how it works in pretty much all
>> editors, and I find it a more useful behavior too.
>>
>
> Sorry but we are not going to change this.
>
> In our opinion, the behavior you describe is not adapted to a styled (no
> visible tags) XML editor where after scrolling, you almost always want
> to learn *immediately* about what you are looking at:
>
> cursor automatically moved while scrolling ==> node path bar
> automatically updated while scrolling
OK...
> Anyway thank you for your feedback.
>
>
> --
> XMLmind XML Editor Support List
> xmleditor-support@xmlmind.com
> http://www.xmlmind.com/mailman/listinfo/xmleditor-support
>
--
Thanks,
Daniel Dekany
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
