I have a weird problem in which the caret moved in an unexpected way. Let's say I have
test<caret>\n
and type command-], it becomes
<tab>tes<caret>t\n
where "<caret>" indicates the position of the cursor and "<tab>" indicates a tab. Basically the "shift-right" command moved the caret left a position unexpectedly. This problem only shows if there is at least a blank line beneath the "test" line. On the other hand, if I have
<tab>test<caret>\n
then I type command-[, then it becomes
test\n <caret>
where the caret jumps to the next line (while removing the tab correctly). Although it can be argued that this might be preferable under some situations, I would prefer it to remain in the same line. This happens in all syntaxes that I have tried. I renamed my ~/Library/Application Support/Textmate to something else but this is still happening. I imagine that a simple explanation is that the caret pointer stays at the same character count (within the document), without accounting for the newly inserted/removed tab. This might explain both command-] and command-[, but of course it is only a wild conjecture.
Any suggestions? Thanks!
On Feb 28, 2011, at 5:31 PM, Saiwing Yeung wrote:
then I type command-[, then it becomes
test\n
<caret>
for me it becomes:
test<caret>n
(while removing the tab correctly)
you mean behaving as you EXPECT it to behave.
when the <caret> is at the end of the line, the <caret> stays on the line end; when you SHIFT-RIGHT or SHIFT-LEFT.
Hmm, wondering if diff version of the Bundle (TextMate?) are affecting this?
sorry, by "\n" I meant that there is a new line at the end, not a slash followed by an "n". It seems like you are seeing the same behavior too (and not what I was expecting) because if the "\n" were a slash and an "n", instead of
test<caret>n
I would have expected
test<caret>\n
instead.
when the <caret> is at the end of the line, the <caret> stays on the line end; when you SHIFT-RIGHT or SHIFT-LEFT.
It is interesting because here it is behaving differently from mine. The <caret> is at the end of line for both of the scenarios I described in the original post.
Hmm, wondering if diff version of the Bundle (TextMate?) are affecting this?
I have 1.5.10 (1623). It was the same even when I moved all my bundles to a different location and restart Textmate.
Mark Jackson-162 wrote:
On Feb 28, 2011, at 5:31 PM, Saiwing Yeung wrote:
then I type command-[, then it becomes
test\n
<caret>
for me it becomes:
test<caret>n
(while removing the tab correctly)
you mean behaving as you EXPECT it to behave.
when the <caret> is at the end of the line, the <caret> stays on the line end; when you SHIFT-RIGHT or SHIFT-LEFT.
Hmm, wondering if diff version of the Bundle (TextMate?) are affecting this?
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Feb 28, 2011, at 6:21 PM, saiwingy wrote:
sorry, by "\n" I meant that there is a new line at the end, not a slash followed by an "n".
*lol* got it
I am on TM 1627. Strange in that it says that the latest cutting edge version is 1623. Hmm.
I tried SHIFT LINE with just "text" on a line.
text<caret here>
SHIFT RIGHT or LEFT and the <caret> stays at the line end.
<tab>text<caret here>
When I do this:
te<caret here>xt and SHIFT RIGHT I get this:
t<caret here>ext
which I believe is accepted behavior in some editors. I have seen this in other editors previously. I can not remember the explanation for it, though.
when i do this:
<caret here>text
and SHIFT RIGHT I get this
<caret here><tab>text
<tab> being 4 spaces wide. Again, I believe I have read somewhere this is accepted as normal in some text editors.
I want to say it's about the line moving, and the caret is stationary except when at EOL. However I can't place the reference right now. Sorry, I am in bed ill at the moment so I am a bit foggy. (yea like any of you would not have your laptop, coding, emailing, etc…)
Hope that helps a bit.
sorry in advance... this reply is extremely cluttered with the formatting. It's hard to communicate the behavior without inline style reply with quoting characters though...
I am on TM 1627. Strange in that it says that the latest cutting edge version is 1623. Hmm.
How did you get 1627? Super secret beta program of some sort?
I tried SHIFT LINE with just "text" on a line.
text<caret here>
SHIFT RIGHT or LEFT and the <caret> stays at the line end.
<tab>text<caret here>
yes, if the caret is at the end of the entire buffer then the caret follows the shift.
When I do this:
te<caret here>xt and SHIFT RIGHT I get this:
t<caret here>ext
if you meant "<tab>t<caret>ext" then yes I see that too.
which I believe is accepted behavior in some editors. I have seen this in other editors previously. I can not remember the explanation for it, though.
I imagine that this behavior is probably useful in some circumstances. It's just not what I would expect though.
when i do this:
<caret here>text
and SHIFT RIGHT I get this
<caret here><tab>text
<tab> being 4 spaces wide. Again, I believe I have read somewhere this is accepted as normal in some text editors.
this I can understand (better, at least).
I want to say it's about the line moving, and the caret is stationary except when at EOL.
for me the caret is stationary ONLY if it's at the beginning of the line. It's weird that we get different behavior. Thanks for the help!
On 2011-02-28 20:31, Saiwing Yeung wrote:
I have a weird problem in which the caret moved in an unexpected way. Let's say I have
test<caret>\n
and type command-], it becomes
<tab>tes<caret>t\n
I'm also seeing the behavior you describe. Funny, I never noticed it before... I think that's because I use ⌘] and ⌘[ almost exclusively to move multiple lines at a time. If I want to indent/outdent a single line I just go to the beginning of the line and insert/remove a tab.
Which suggests a solution. Maybe create a macro to select the line before moving it? It's not ideal, but it may be better than having the caret end up in an unexpected position.
FWIW, I think you're correct that it has something to do with using a single character (tab) to represent more than a single character width. The behavior changes somewhat if you use soft tabs.
I guess I will try to write a macro. I have been using TextMate for over 2 years and didn't notice it until recently. But once I saw it, I really do want it to behave differently.
Actually I just tried it with soft tabs and it is similar. I would argue that it is kind of harder to imagine why this would be useful in soft tabs (more so than the non-soft tabs case). For example, here I set TextMate to soft tabs: 4
soft tab testing<caret>
command-] moves it to
soft tab tes<caret>ting
I imagine this is useful if what you are writing depends on the absolute position of the characters (a hard-coded text table, ascii art, etc), but it is less useful if you are writing code.
Steve King-8 wrote:
On 2011-02-28 20:31, Saiwing Yeung wrote:
I have a weird problem in which the caret moved in an unexpected way. Let's say I have
test<caret>\n
and type command-], it becomes
<tab>tes<caret>t\n
I'm also seeing the behavior you describe. Funny, I never noticed it before... I think that's because I use ⌘] and ⌘[ almost exclusively to move multiple lines at a time. If I want to indent/outdent a single line I just go to the beginning of the line and insert/remove a tab.
Which suggests a solution. Maybe create a macro to select the line before moving it? It's not ideal, but it may be better than having the caret end up in an unexpected position.
FWIW, I think you're correct that it has something to do with using a single character (tab) to represent more than a single character width. The behavior changes somewhat if you use soft tabs.
-- Steve King Sr. Software Engineer Arbor Networks +1 734 821 1461 www.arbornetworks.com http://www.arbornetworks.com/
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
-
Mark Jackson -
Saiwing Yeung -
saiwingy
-
Steve King