LiveCode Forums.

I do this two different ways.

1.Triple-click selects the whole line. Then put the cursor to the left of the line under the place where the line should go and paste.

2.Drag from the end of the line above (to catch the carriage return) down to the end of the target line. Cut. Place the cursor at the end of the line above where the insertion should go and paste.

Regardless of the method, the tab key will always reformat the handler. Shift-tab will reformat the entire script.

Aside from all those methods, you can also just drag the highlighted part of the script anywhere to move it while inside the script editor itself.

I get the feeling I must be missing something from the description of the problem

Bogs: you must have autoformatting on. When I do what I described, and then hit Tab, it inserts a tab character, and tab stops in the script editor are set at every eight characters, which is an excessive indentation level. Also, I see in one of your pictures that you select a line by dragging from the end of one line to the end of the next. That's a bit counterintuitive, but I've done it before, and it's easy enough to do with the mouse, but when I'm editing my hands are on the keyboard and a prefer cutting and pasting lines using the keyboard, which is easier to do in column one.

The reason I don't use autoformatting is that I don't always agree with its idea of correct formatting. While some might like to have a particular format enforced by the editor, LiveCode is the ONLY editor I've ever used that was so insistent on having its own way, that even turning off "Auto Format" doesn't actually turn it all off. I don't understand why there is so much resistance to the idea of just making that checkbox do what it says it does. If you like autoformatting, turn it on. I don't. I'd like to turn it off.

Paul-

Eight tabs *is* excessive. It's hard to believe that's the default. Mine's set to three, and it's configurable in the preferences panel.

Anything else you don't like about the script editor's choice of formatting? There may be a way to control it.

bogs wrote: Wed Sep 19, 2018 3:41 pm *Edit - might help to know which os / vers. your seeing this behavior in too.
*Edit 2 - is this your setup (found in the bug triage section) 9.0.1 on Windows 7 x64

On 'nix in v8.1.2 (latest I can run on this particular box) I wasn't able to duplicate your issue with auto-formatting off.

Since you never answered the first edit question, I'll assume your using the system you posted in bug triage. It may take me a bit of time to hunt that image down for testing, I'm not sure win10 is a close enough box and I can't run Lc 9.x on Xp (*I think*).

Some of the other points you made -

you must have autoformatting on.

Indeed, that was the part I was missing, I had to go re-check and turned it off for this testing. It probably answers your other previous point, though -

pderocco wrote: Wed Sep 19, 2018 8:03 am Doesn't anyone else do this? I can't believe that everyone doesn't have a problem with this

The answer is probably anyone that changes auto-format has been around long enough to have worked out a way to handle it, or just gotten used to whatever behavior your seeing and compensated for it, or doesn't use a version this happens on regularly enough to have noticed it (like me).

I see in one of your pictures that you select a line by dragging from the end of one line to the end of the next. That's a bit counterintuitive, but I've done it before, and it's easy enough to do with the mouse,

I'm not sure why that would be 'counter intuitive', it is an easy selection to make with the mouse or keyboard, and it automatically flows the next line on paste. I guess it must be an old technique, I learned it back in the 90s.

but when I'm editing my hands are on the keyboard and a prefer cutting and pasting lines using the keyboard, which is easier to do in column one.

My hands are usually on the keyboard as well, sure it is easy to go straight up and down, but haven't you ever explored the shortcuts for keyboard copying? It isn't that much of a strain to hit [shift +ctrl] and an arrow key, ( shift/ctrl = each word), or end, to get where you need to go before starting straight up or down before cutting/copying.

The reason I don't use autoformatting is that I don't always agree with its idea of correct formatting.

I've been there myself in various environments, I got no problem with that line of thought

Well, I think you must have something else going on there, pderocco.

To get as close as I can to your description, this is a fresh install of Win7 + Lc 9.0.1 stable. The first screen shot shows the preferences set, the second shows whats disabled in the editor window menu as well. I again could not reproduce the issue you seem to be having. I think it would be nice to add those 6 menu items to the prefs as a series of check boxes though, having to open that menu 6 times to uncheck them was a bore
As you can see in picture 1, I copied 'yib' using nothing but the keyboard. I initially [ ctrl+shift+<- ] to select the word from the end insertion point. I then went to line 5, pasted it, spaced, then pasted it again. On line 6, I tabbed and pasted it. The tab appears to be 4 spaces.

At no time did the cursor go anywhere I didn't expect it to be, so not sure what to tell you there. If you have an experiment you want me to do with specific directions (assuming this setup mirrors yours correctly) I'd be glad to give it a shot.

Well, given that Paul is having real problems with the script editor I think this is worth pursuing. When I (often) seem to have problems that nobody else can replicate, my first suspect (after my own code) is the preferences file. I especially had very weird problems moving up to LC7/8 because of incompatibilities in the prefs file that haven't yet been completely spelunked, but I'm not going backwards anyway.

So I'd start by moving the LC preferences file somewhere out of the way, relaunching LC (it will build a new preferences file for you) and see if that helps.

I think I'm being misunderstood. Bogs, you were pasting in a different situation, where there wasn't already an indented line.

The bug is simply this: clicking at the start of a line that already has indented text in it does not place the cursor in column 1, but on the first non-blank character. It absolutely refuses to place the cursor in the whitespace before the text, except if I drag into or out of that position, or if the cursor ends up there after deleting complete lines. Just clicking in that area always insists upon moving the cursor to the right as soon as I release the mouse button. It even does this if you move up or down into the line from a non-indented line with the cursor keys. The result is that it is difficult to paste complete lines where they belong.

This has been the situation since I started using LiveCode years ago, so it's obviously intended. Although I can't imagine why anyone would want the cursor to do that, and in my 40 years as a programmer I've never seen another editor that did that, I suppose it could be justified as part of "auto format", except that it really doesn't have anything to do with formatting.

If there are people who really like this behavior, then it should be optional. I'd be satisfied if it was turned off if auto format was turned off, although a separate checkbox would be preferable, because I think it's orthogonal to auto format.

Let me be clear: I'm not complaining about things like adding whitespace to match the current indentation on hitting Enter. That's a different issue, a reasonable part of auto format. I'm just saying that the inability to put the cursor at the start of an already indented line is a problem.

pderocco wrote: Fri Sep 21, 2018 11:56 pm I think I'm being misunderstood. Bogs, you were pasting in a different situation, where there wasn't already an indented line.

I'm sure willing to admit my understanding isn't always that great going in either direction, but I will certainly try again to see if I can get it right to confirm what your finding.

In this picture, I have set up an if then statement with a comment I will be copying. I have indented line 4 with a tab before copying anything. All formatting options are off, per the previous set of pictures.

The bug is simply this: [1] clicking at the start of a line that already has indented text in it does not place the cursor in column 1, but on the first non-blank character.

As you can see in this screen shot (do you know how hard it is to get a shot of a blinking cursor !?!) I clicked at the left most part of the line, and it put the cursor there. Now, let me add that if I clicked where the tab space was, it does indeed treat it as a block of space, and it will set the cursor to either the right or left depending on where you click on past the middle of that tab block.

I then pasted the copied comment there, and clearly it went to the first character and the tab remains splitting the comment and line that was previously there with the tabbed indent.

It even does this if you move up or down into the line from a non-indented line with the cursor keys. The result is that it is difficult to paste complete lines where they belong.

Since you said you were a keyboard user over mousing, I also tested moving that cursor with the keyboard only. I saw no issue with putting it where I expected it to be.

This has been the situation since I started using LiveCode years ago, so it's obviously intended.
<sic> I suppose it could be justified as part of "auto format", except that it really doesn't have anything to do with formatting.

I spend a lot of time in the earlier versions of Lc and Mc, I have never noticed this behavior there either with all formatting off, but in all honesty, I wasn't ever looking for it either. I certainly will now though Well, later anyway, when I have some time to spend on it

Let me be clear: I'm not complaining about things like adding whitespace to match the current indentation on hitting Enter. That's a different issue, a reasonable part of auto format. I'm just saying that the inability to put the cursor at the start of an already indented line is a problem.

IF you have all formatting options off, you shouldn't see any of that behavior, and I certainly did not see white-space matching or any other formatting behavior with the options I previously showed off being off, which leads me to think you may be having one of several possibilities going on.

..1. You've obviously been using this for years, perhaps you have a plugin hanging around that is creating this issue?
..2. You missed a formatting setting somehow?
..3. As mentioned earlier, maybe try deleting your prefs? ( and yes, I know its a right pain to go re-set up everything ).
..4. Something I missed? (again? )

What you might try is setting up a small vm like I did and installing win7 and Lc fresh, no plugins, no nothing, and try testing it that way. I just couldn't reproduce your issue, sorry

bogs wrote: Sat Sep 22, 2018 3:58 pm In this picture, I have set up an if then statement with a comment I will be copying. I have indented line 4 with a tab before copying anything. All formatting options are off, per the previous set of pictures.


As you can see in this screen shot (do you know how hard it is to get a shot of a blinking cursor !?!) I clicked at the left most part of the line, and it put the cursor there.


Now, let me add that if I clicked where the tab space was, it does indeed treat it as a block of space, and it will set the cursor to either the right or left depending on where you click on past the middle of that tab block.

So you're saying that the space before the "set" is actually a tab character? That would account for the difference. If I indent with a tab, I get the behavior you're seeing. But I indent with blanks, not tabs, and that's where the annoying behavior occurs.

The reason I use blanks instead of tabs is twofold. First, when I insert a tab, it occupies eight columns, even though I've set the indentation level in Preferences to 2. Second, since I often copy and paste into my preferred text editor if I'm going to do a lot of code writing, I don't want to have to set up tabs in that editor as well. I always set up my editor to insert blanks when I hit tab.

But the indentation in your image also suggests you're using a proportional font. I use Lucida Console, which is fixed spacing. Maybe that's why your tabs look so small. Or is there a way to change the tab character width in LiveCode?

First, when I insert a tab, it occupies eight columns, even though I've set the indentation level in Preferences to 2.

That's pretty bizarre. It's still sounding to me like your preferences file is borked.

I use Lucida Console, which is fixed spacing

I use SourceCode Pro, which is also a fixed-spacing font, so I don't think that's a data point to worry about.

pderocco wrote: Sat Sep 22, 2018 6:50 pm So you're saying that the space before the "set" is actually a tab character?
...<sic>...

Yes, the space before 'set' on line 4 is a tab character. I believe Comic Sans MS (the only font I use on Windows) is not a fixed space font. I don't use it because of any of the really big philosophical reasons, though, it is because of my sense of humor and because it reads nicely (imho) I changed it in this picture to match what you are using, and as you can see, changing nothing else, you get the 8 spaces look for the tab - The indentation level in preferences has nothing to do with tab settings, it is solely for indentation of the lines of code, when you are using auto-formatting. I've never seen anything to do with setting tab space widths, maybe someone else knows differently.

mwieder wrote: Sat Sep 22, 2018 7:09 pm

First, when I insert a tab, it occupies eight columns, even though I've set the indentation level in Preferences to 2.

That's pretty bizarre. It's still sounding to me like your preferences file is borked.

I use Lucida Console, which is fixed spacing

I use SourceCode Pro, which is also a fixed-spacing font, so I don't think that's a data point to worry about.

The good news is, I think you have a legitimate bug here, the problem understanding what it was is over! Your profile, preferences, plugins, etc are all probably fine, since I was able to recreate it with a fresh install

Here is a screen shot of what he is actually describing - If anyone wants to try recreating it (other than me ) here are the steps to recreate -

1. Turn off all formatting
2. Indent a line with the tab key, and type something.
3. Indent a line with 5 spaces, and type something.
4. The cursor can be placed at the 1st character of any line that does not have a space in it.
5. If pasting formatted text that contains spaces, the formatting is broken in the script editor.

I'd submit this if it isn't already in the bug db, feel free to use the picture posted above.

*Edited to include copy / paste to another text editor steps in screen shot.
*Edit 2 - issue doesn't appear to be present on Linux.
~ correction, doesn't appear on *some* distributions, appears on others though.
*Edit 3 - mixed results on Mac 10.6.5, using the mouse, you *can* get to the beginning of a spaced line, but not with the keyboard.

I'm glad we're converging toward some sort of answer. But let me be clear: the bug isn't in the pasting, that's only a situation where the behavior causes a problem. The bug is in the automatic moving of the cursor.

In my opinion, the best thing to do would simply be to abolish the behavior of automatically moving the cursor to the first non-blank character in the line, when the cursor is placed somewhere. I've never seen an editor do that before, and I don't understand why anyone would want it to do that ever. And it's a half-hearted "feature", given that it doesn't do it if the leading whitespace is made of tab characters. If anyone actually finds that behavior is useful, I'd be interested to hear why.

pderocco wrote: Sun Sep 23, 2018 7:22 pm I'm glad we're converging toward some sort of answer. But let me be clear: the bug isn't in the pasting, that's only a situation where the behavior causes a problem. The bug is in the automatic moving of the cursor.

Oh yah, I get it now I just put the pasting thing to cover what happens *when* you paste multiple lines for completeness.

My thoughts on this run this way - I don't think the behavior is intended, so I do think it is a 'bug'. What I'm guessing from the behavior I see is that when you turn off formatting, and insert spaces instead of a tab, there is no handler setup to correctly handle that. In that case, it defaults to the handler used for auto-formatting.

Whether it will be fixed or not is a lot harder to say. I think the great majority of people using this environment will probably never notice it, since I think turning off auto-formatting is probably something only a minority of people use.

The rest are probably using the default or a very minor customization of the default, or if they have turned off auto-formatting, are using tabs and not spaces as the lead in to the line. I know I would be because a tab is so much faster than a space (And no, I'm not trying to re-start the 'spaces vs. tabs flamewar of forums past)

*If* that is the case, then it isn't likely to be fixed anytime soon would be my guess, if there is even a bug report about it listed in the quality db, I'll leave that for you to check on and submit.

For a workaround though, you could (as mentioned previously) do any number of things differently such as -
...selecting from the end of the line previous to the one you want to start copying with the mouse, since it seems you use the mouse sometimes anyway.
...use tabs instead of spaces. If the 8 characters in thing bothers you, change the font to one such as in my picture up there.
...some of the other stuff Jacque and mwieder said, like use the auto-formatting even if you don't like it, which will allow you to correct these things by hitting the tab key.
... only use an outside editor, there are at least 3 plugins that let you use anything from notepad to sublime to edit the scripts and apply them back.

I know it isn't what you wanted to hear but I hope it is helpful anyway

My thoughts on this run this way - I don't think the behavior is intended, so I do think it is a 'bug'. What I'm guessing from the behavior I see is that when you turn off formatting, and insert spaces instead of a tab, there is no handler setup to correctly handle that. In that case, it defaults to the handler used for auto-formatting.

Whether it will be fixed or not is a lot harder to say. I think the great majority of people using this environment will probably never notice it, since I think turning off auto-formatting is probably something only a minority of people use.

Agreed on both counts. There's probably a tab key handler in the script editor that isn't looking for leading spaces. That said, the script editor is... er... editable. So if someone wants to find where to patch this and submit a pull request, I don't see any reason why it wouldn't be accepted.