#496 Query Window Editor Enhancements

[Anonymous]

Originally created by: mikeschinkel

Both of these sounds trivial, but I notice their lack every time I use
HeidiSQL:

1.) Selection Indentation -- ability to use tab to indent (and shift-tab
to un-indent) a multi-line selection.

2.) Ability to cursor vertically down past the end of the current content
in the query window.  Not having this, in particular, is constantly
annoying because I want to cursor below a statement in order to highlight
it and it always fails so I have to interrupt my rhythm, reposition the
cursor, add a new, and sometimes after I've lost my train of thought
(okay, so I have a short attention span... :)

3.) Allow switching of F9 and Ctrl-F9 function.  Shouldn't the run option
with the least scope and the least potential damage be on the least effort
(F9), and the extra effort be required (Ctrl-F9) when you want to run
everything?

[Anonymous]

Originally posted by: mikeschinkel

Sorry, after writing "both" I added  a 3rd... ;-)

[Anonymous]

Originally posted by: rosenfie...@gmail.com

(No comment was entered for this change.)

Labels: -priority-medium Severity-Broken

[Anonymous]

Originally posted by: rosenfie...@gmail.com

1) Good suggestion.  Maybe SynEdit already has an option to do this..

2) Cursor down or scroll down?  I personally dislike virtual cursors, but if someone
likes them enough to implement them, it can always be done as a preference.  What's
wrong with pressing Enter after a line, by the way?

3) It's been like this since the DOS days and Turbo Pascal, so definitely not if you
ask me.  (If you rephrase the RFE to "allow custom keymappings" instead of "switch
the defaults to my preference", then it sounds like a fine suggestion ;-).)

Labels: -Type-Defect -Severity-Broken Type-Enhancement Severity-Default
Status: Accepted

[Anonymous]

Originally posted by: a...@anse.de

1) There are shortcuts for block indent + unindent: Ctrl+Shift+I and Ctrl+Shift+U .
Although they seem a bit uncommon to me, there is a reason to stick to them: SynEdit
seems to need the Tab + Shift+Tab hotkeys for the "normal" Tab operation and I
cannot assign the same hotkey for different keystrokes. I also tried Ctrl+Tab and
Ctrl+Shift+Tab but that didn't work at all for some reason.

[Anonymous]

Originally posted by: mikeschinkel

>> What's wrong with pressing Enter after a line, by the way?

It completely disrupts my flow when using HeidiSQL to do lots of data
transformations. 

For example, I have lots of SQL in the query window and then paste a copy of a
statement to the end of the buffer, let's say it's 25 lines of SQL. I edit the code
to get the exact statement I want, and then I position my cursor at col 1 of the row
before the statement, hold the shift key and hold the down-arrow to highlight the
statement, get ready to press F9, then realize that it only selected 24 of 25 lines.
How I have to press the end key, then hold the shift key again while pressing the up
arrow again for 25 lines. Very annoying.

And it can be solved not by a full virtual cursor but just by letting the cursor go
one line past the last line, nothing more.

BTW, my scenario above is just one example of this problem, but I won't remember the
others until I run into them again next time I use HeidiSQL.

>> It's been like this since the DOS days and Turbo Pascal, so definitely not if you
ask me. 

As a Turbo Pascal v3 beta tester, I always hated that about TP. '-)

(BTW, I've never programmed in Delphi otherwise I might be able to help with some of
these. But I don't, and don't have the time to learn it, so unfortunately I can't
help implement.)

But seriously, how about I rephrase the RFE to "allow custom keymappings" instead
of "switch the defaults to my preference?" '-)

FYI, I only suggested swapping because I thought it would be much easier to
implement than a full-on key remapping infrastructure.

As an aside, is it valid to allow a UI convention from a developer's tool that most
end users probably don't use as a definer for a UI standard?  Shouldn't UI
conventions come from more mainstream apps?  Just a thought...

BTW, thanks for all the attention to my suggestions.

>> There are shortcuts for block indent + unindent: Ctrl+Shift+I and Ctrl+Shift+U.

Ah, I'm happy with those, just didn't know they existed. Thanks for the instruction!

So that brings me to a another request: How about a help dialog that simply lists
the keymappings?  Should I post as independent suggestion item?

[Anonymous]

Originally posted by: rosenfie...@gmail.com

1) (Anse covered this one. Cool! We really need a help file to explain these common
things, though. I had no clue there was a block indentation feature.)

2) I'm still not convinced.  At that point, with 24 of 25 lines selected, just press
Ctrl+Shift+End to include the last line.  Much easier than having us implement
virtual cursor if you ask me, even if it's only some of the time.

In fact..  Use Ctrl+Shift+End from the get-go, and you'll also be relieved of having
to hold shift while pressing down-arrow 25 times.

Help book/whatever:
Good suggestion.  Yeah, this issue is getting crowded.

rephrase the RFE to "allow custom keymappings":
Sure, if you still feel it's relevant.  Probably wants a new issue too.

> As an aside, is it valid to allow a UI convention
> from a developer's tool that most end users probably
> don't use as a definer for a UI standard?

Sure it is.  Developers are not really like humans, but not really like robots
either.  They're some sort of thing in the middle, a super-being of kinds.  They
stand firmly on top of human evolution, their standards being of the most true kind
and crisp quality.

Everyone else will adapt eventually.  Or die.  Whatever.

> Shouldn't UI conventions come from more
> mainstream apps?  Just a thought...

No.
Ok, glad we've covered that topic.

[Anonymous]

Originally posted by: mikeschinkel

>> I'm still not convinced.  At that point, with 24 of 25 lines selected, just press
Ctrl+Shift+End to include the last line.  Much easier than having us implement
virtual cursor if you ask me, even if it's only some of the time.

If you appreciate the concept of "flow" (http://en.wikipedia.org/wiki/Flow_%
28psychology%29) then hopefully you can just accept that the current situations
breaks the flow for me personally. And things that are constantly breaking flow are
things that one really notices and soon gets frustrated by.

It's okay to say no, but at least I would like it acknowledged that it is suboptimal
for me.

>> and you'll also be relieved of having to hold shift while pressing down-arrow 25
times.

Sigh. That's the problem with giving examples for a more complex issue; the person
on the other end picks apart the example as opposed to understanding the underlying
problem. I guess that means I'll need to start paying close attention each time it
breaks my flow and then document each scenario in-depth.

>> In fact..  Use Ctrl+Shift+End from the get-go,

But I will see if that can resolve my flow issues. I'll report back if not.

>> Sure it is.  Developers are not really like humans, but not really like robots
either.  They're some sort of thing in the middle, a super-being of kinds.  They
stand firmly on top of human evolution, their standards being of the most true kind
and crisp quality.

I respectfully disagree, not on your reply which I think is off-topic, but on how UI
standards should be established.  IMO they should be that the simplest case should
do less harm than the more complex case, and that UI standards should come from
those things that other systems are most often doing.

>> Shouldn't UI conventions come from more
>> mainstream apps?  Just a thought...
>No.
>Ok, glad we've covered that topic.

Maybe I've just been influenced by too much reading of useit.com from Jakob Nielsen,
for example: http://www.useit.com/alertbox/990822.html
And: http://www.useit.com/alertbox/application-mistakes.html 
Better yet: http://www.useit.com/alertbox/

>> Developers ... stand firmly on top of human evolution, their standards being of
the most true kind and crisp quality.

Okaaaay. With those opinions I guess me bringing up references to UI best-practices
is moot, so never mind.

[Anonymous]

Originally posted by: mikeschinkel

As soon as I posted that I realized one problem with Ctrl-Shift-End; it can't be
used when there is code at the end I don't want to highlight, so it requires me to
constantly shift between different mental "modes" depending on where the snippet it
located, and in many cases I don't know if it is at the end of the query window
until after I try to select it.

Make in 1985 I studied software human factors and one of the things we studied was
auto-tab fields; i.e. fields that would tab when the user filled them but for which
the user had to tab if the field was not filled. The professor argued and we all
agreed that auto-tab was a very bad UI design because it requires the user to get
out of flow and make a conscious decision on what key to press next.

The Ctrl-End-Shift vs. Shift-Down arrow is the same for me. To use Ctrl-End-Shift I
would constantly have to get out of flow to make a decision if it was appropriate to
use at the moment or not, especially considering that I often don't know or remember
if the snippet I want to highlight is the last snippet or not. I only find out when
I try to select it with a Shift-Down Arrow only to realize that I have to switch
modes and start again.

Even if you don't have this issue, I really hope that you can at least appreciate
that it is a legitimate issue for me.

is different than the Shift-up or Shift-Down arrow and

[Anonymous]

Originally posted by: rosenfie...@gmail.com

> I really hope that you can at least appreciate
> that it is a legitimate issue for me.

Definitely.  Your explanation is clear and concise, I have no trouble understanding
it.

I personally have no problem switching modes, but then again my workflow is
obviously different from yours.  For example, I also have no clue how large each/any
query is.

Either way, I just happen to think that either solution is just about equally sub-
optimal.  A proper solution in my mind could for example be multiple query tabs. 
That should put an abrupt end to the "how many lines" part of the discussion?

> I respectfully disagree

No need to be respectful, I wasn't ;-)

> IMO they should be that the simplest case should
> do less harm than the more complex case

Okay, fair enough.  Let's go see what my query window contains today...

=============== SQL ===============
-- truncate table log;
select * from log order by id;
===================================

Hard to represent visually, but the words "truncate table log" are marked/selected.

As per your own argument, since the query as a whole is harmless, but the marked
code is nasty, F9 should run the whole query and CTRL-F9 should run the selected
part.

I'll entertain with another example (because I'm not even remotely tired at this
time of day..)

Consider a BEGIN TRANSACTION ... blah blah blah ... END TRANSACTION.  Mark any
random piece inside the transaction, accidentally execute it, and you might have
caused data to penetrate to persistent storage (given that auto commit is enabled). 
Not good.

[Anonymous]

Originally posted by: mikeschinkel

>> Definitely.  Your explanation is clear and concise, I have no trouble
understanding it.

Thanks.

>> A proper solution in my mind could for example be multiple query tabs. 
That should put an abrupt end to the "how many lines" part of the discussion?

Not for me. One really nice thing about the "execute selection" model is it gives
lots more flexibility than to have to create a new windows for each separate query.
It's like the difference between having to enter IP address into four fields
(Microsoft style) vs. being allowed to enter as a single string with dots
separating; a free-form text editor like the query window is infinitely more
flexible than a collection of fields.  BTW, as MS SQL tools evolved, many of them
lost the "execute selection" functionality and instead gained more structured
functionality, and IMO it was a huge step backwards.

IF there were multiple query windows I'd still see use lots of independent queries
in my main query window, and execute the selected one. SQL is just not a language
that compartmentalizes well, so one is always coding new statements. At least that's
how I operated with MS SQL Query Analyzer which did have multiple query windows.
Isn't it ironic how as technology evolves we often loose what we had before and then
must clamor to regain it?  Nature of the beast, I know.

>> Okay, fair enough.  Let's go see what my query window contains today...

Okay, your points are well taken regarding F9/Ctrl-F9.  I'd prefer the F9 to do that
selection because that's my 99 percentile case and it is easier to press F9 (one
finger) than Ctrl-F9 (two fingers.)  But that's just my opinion and I won't belabor
it beyond this.

>> Let's go see what my query window contains today...

I'd show you mine too, but you reaaally *don't* want to see what's in my query
window today. :-0

[Anonymous]

Originally posted by: rosenfie...@gmail.com

> I'd show you mine too

HARharha..
*pirate laugh*

> but you reaaally *don't* want to see what's in
> my query window today. :-0

Heck, with 5 or 6 completely hypothetical discussions already, I think we've passed
the point where this discussion belongs in a bar with a couple of pints rather than
in a bug tracker already, so why not.

(Mine contains code to achieve cold fusion using only SWF files, stored procedures
and toenail clippings from an emu.)

--

On a more serious note, Anse knows the GUI controls much better than I do, there is
a possibility that he can see a simple way to do this mini-virtual-cursor thing that
I'm completely missing.  We'll see.

[Anonymous]

Originally posted by: mikeschinkel

>> so why not.

Really, it's just hundreds of lines of rote SQL code for importing data into a
Drupal database. Nothing at all interesting, it's just an awful lot to get (and
keep) one's head around, hence my please for things to keep from break my trains of
though.

[Anonymous]

Originally posted by: mikeschinkel

Some more thoughts on the virtual vertical cursor.

I just spent a few hours using HeidiSQL to update some data and found myself using
Ctrl-End-Shift frequently w/o actually thinking about it. So that use-case is
covered, at least for me.

Where I still found the need for a virtual vertical cursor was when I was editing
the where clause in a many line query, and then wanted to cursor down a few lines to
get to the end so I could select it. Here I was stopped by the fact there was no
\r\n at the end of the query. In that case it was a lot more work to use Ctrl-Shift-
End for my hypothetical 25 line query because I was already on line 22. Better to
arrow down three and then shift-page-up then shift-arrow to select exactly what I
need. And having to move the selection point to the beginning of the query using the
mouse/trackpad would be even more distracting.

Like I said in my earlier email, it's not always easy to give an example that
someone else can't pick apart, especially in UI. It's sometimes hard to document
*exactly* where the issue occurs and if very time consuming to document it exactly
too. In summary, I'm hoping that you could just respect my stated need for a virtual
cursor past the vertical end in the query window.

If my need for a virtual cursor is easy to accommodate, I'd love to see it added. 
If it's not easy, I can of course just put up with it. Whatever the case, I still
love the fact that HeidiSQL is such a powerful tool made it freely available via
Open Source, and I thank the authors repeatedly for this! :-)

[Anonymous]

Originally posted by: a...@anse.de

Mike, just found a way to activate Tab and Shift+Tab for block (un)indentation.
Implemented in [r1420].

And even two more related things:
- [r1422] implements the option eoKeepCaretX which I called "Remember X position of
cursor while moving the cursor up and down through short and long lines"
- [r1423] hides unused, deactivated scrollbars by activating eoHideShowScrollbars.
Only show them when they're needed. Seemed reasonable in some way.

Now searching for an option for this virtual cursor.

[Anonymous]

Originally posted by: a...@anse.de

Mike, I found the SynEdit option "eoScrollPastEof" which is described as "Allows the
cursor to go past the end of file marker". This is my understanding of your request
nr. 2), correct?

I would love to make it a preference option so it would be user customizable. But
unfortunately SynEdit does not what I thought it should do if I activate this
option. Hmm. Probably some side effect of other activated options.

[Anonymous]

Originally posted by: a...@anse.de

Is this eoScrollPastEof thing still of any interest?

[Anonymous]

Originally posted by: mikeschinkel

It is to me.  Sorry, I forgot to follow up on your prior comment.

[Anonymous]

Originally posted by: a...@anse.de

eoScrollPast*Eof*:
Extends the scrollbars to let the SynMemo content scroll out of view until only the
last line is visible. It does not enable you setting the cursor below the last line
(which was the request here if I understood right).

eoScrollPast*Eol*:
Allows the cursor right besides the last character in a line + enables scrolling to
the right until the content is out of view.

However, I'll send a question to the synedit-devel mailinglist and return here if
I'll get a reply.

[Anonymous]

Originally posted by: spero.sh...@gmail.com

Instead of a Virtual cursor to allow it to go paste the EOF Marker... why not check
to see if the cursor can go down any further and if not to put the cursor to the end
of line if down key is pushed again?

[Anonymous]

Originally posted by: rosenfie...@gmail.com

That's a pretty good idea!

[Anonymous]

Originally posted by: mikeschinkel

Not sure I understand comment #19.  Is that a user action or a code action? 

If the latter it would hopefully include a CR/LF to get the cursor to the next time
as cutting from beginning of line n to beginning of line n-1 makes for much more
consistent pasting thank cutting from beginning of line n to end of line n.

[Anonymous]

Originally posted by: rosenfie...@gmail.com

A code change.

The change would avoid modifying the contents of the editor (with a CRLF), and avoid
placing the cursor in a "virtual" location (where no text actually exists).

The change would allow you to arrow-down and grab all of your SQL, including the
last line (as requested ;-)).

[Anonymous]

Originally posted by: mikeschinkel

Now that I understand it I agree, a pretty good idea.  Cool! 

[Anonymous]

Originally posted by: spero.sh...@gmail.com

Sorry it would help if I didn't have any typos :)

but glad you liked the Idea... I find it is a very common characteristic in many
programs, but doesn't often get noticed until it is not there and is needed/wanted.

[Anonymous]

Originally posted by: rosenfie...@gmail.com

(No comment was entered for this change.)

Summary: Query Window Editor Enhancements