Please,
For the love of god, children and animals, can we please get indented soft wrapping as a standard feature of Textmate 2. I just don't understand why such a useful yet trivial feature that's common to just about every text editor has not been included in what is supposed to be the holy grail of text editors.
There's an 8 year old ticket for it, not to mention all the duplicates: http://ticket.macromates.com/show?ticket_id=4EFB31A8
Do a google search for this, and you find people applying the same dodgy fix to individual bundles; what a waste of time for everyone involves. Can we not just get this feature added and be done with it.
Thanks, Tom
On 29 Jan 2014, at 06:02, Tom Wardrop tom@tomwardrop.com wrote:
Please,
For the love of god, children and animals, can we please get indented soft wrapping as a standard feature of Textmate 2. (…)
AFAICT, it’s there for more than two years…
In the first item in the About box > Changes dated 2011-12-13:
Soft wrap can be indented. This is also based on scoped settings so list items in markup are indented differently than line comments in source.
Google "textmate indentedSoftWrap” or go here: http://blog.macromates.com/2012/the-layout-engine/
Perhaps my frustrations comes from the fact that there's not a simple menu item for it. There should be a soft-wrap sub-menu or something with the option to enable indented soft-wrapping. Enabling this global setting (which it should be by default) would apply the common "same indent level + 1" to all bundles. Bundles could then override this with grammar specific soft-wrapping where applicable. I shouldn't have to, with much frustration, Google for an example of soft-wrapping, and then be required to work out how it all works.
This is a matter of usability more than capability. I want to develop for my application, not for my text editor if I can at all avoid it. It's about having smart defaults (who doesn't prefer indented soft-wrap over ordinary soft-wrapping?) and easily accessible options for the most common toggles. Everything else can be done in the bundle editor.
Is that unreasonable?
Tom
On 29 January 2014 16:04, Fred ALB fredb7@gmail.com wrote:
On 29 Jan 2014, at 06:02, Tom Wardrop tom@tomwardrop.com wrote:
Please,
For the love of god, children and animals, can we please get indented
soft wrapping as a standard feature of Textmate 2. (...)
AFAICT, it's there for more than two years...
In the first item in the About box > Changes dated 2011-12-13:
Soft wrap can be indented. This is also based on scoped settings so list
items in markup are indented differently than line comments in source.
Google "textmate indentedSoftWrap" or go here: http://blog.macromates.com/2012/the-layout-engine/
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
I agree that enabling indented soft wrapping is more difficult than it should be. In other text editors (such as Xcode) it is either on by default or just a single command away, while TextMate requires setting up a custom bundle and defining a regular expression.
I would like to work on a patch to improve this situation, but I’m not even sure how it should be architected. For example, if a default indentedSoftWrap setting is added to the Text and Source bundles, how can it be turned on and off? Is there some existing setting that works like this?
Any guidance from the core TextMate devs would be appreciated, thanks!
Trevor
On Jan 29, 2014, at 2:52 AM, Tom Wardrop tom@tomwardrop.com wrote:
Perhaps my frustrations comes from the fact that there's not a simple menu item for it. There should be a soft-wrap sub-menu or something with the option to enable indented soft-wrapping. Enabling this global setting (which it should be by default) would apply the common "same indent level + 1" to all bundles. Bundles could then override this with grammar specific soft-wrapping where applicable. I shouldn't have to, with much frustration, Google for an example of soft-wrapping, and then be required to work out how it all works.
This is a matter of usability more than capability. I want to develop for my application, not for my text editor if I can at all avoid it. It's about having smart defaults (who doesn't prefer indented soft-wrap over ordinary soft-wrapping?) and easily accessible options for the most common toggles. Everything else can be done in the bundle editor.
Is that unreasonable?
Tom
On 29 January 2014 16:04, Fred ALB fredb7@gmail.com wrote:
On 29 Jan 2014, at 06:02, Tom Wardrop tom@tomwardrop.com wrote:
Please,
For the love of god, children and animals, can we please get indented soft wrapping as a standard feature of Textmate 2. (…)
AFAICT, it’s there for more than two years…
In the first item in the About box > Changes dated 2011-12-13:
Soft wrap can be indented. This is also based on scoped settings so list items in markup are indented differently than line comments in source.
Google "textmate indentedSoftWrap” or go here: http://blog.macromates.com/2012/the-layout-engine/
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 29 Jan 2014, at 23:34, Trevor Harmon wrote:
[…] I would like to work on a patch to improve this situation, but I’m not even sure how it should be architected. For example, if a default indentedSoftWrap setting is added to the Text and Source bundles, how can it be turned on and off? Is there some existing setting that works like this?
Bundle items can be disabled, so one could add a setting e.g. to the TextMate bundle and have it disabled by default.
Users would still have to go to the Bundle Editor and select to enable the iten.
There’s a few other things that fall in the same category, i.e. needs to be enabled/disabled via settings in bundles, and I haven’t yet figured out how I would like to go about better exposing these things. On hand I would like to introduce (more) GUI for common stuff, OTOH I would like to keep TextMate more of an engine with a lot of customization possibilities (which can’t always be captured by a single GUI switch).
On 31 Jan 2014, at 4:00 pm, Allan Odgaard mailinglist@textmate.org wrote:
[...] Users would still have to go to the Bundle Editor and select to enable the iten.
There’s a few other things that fall in the same category, i.e. needs to be enabled/disabled via settings in bundles, and I haven’t yet figured out how I would like to go about better exposing these things. On hand I would like to introduce (more) GUI for common stuff, OTOH I would like to keep TextMate more of an engine with a lot of customization possibilities (which can’t always be captured by a single GUI switch).
FWIW, here's an idea:
Would it be possible to expose an API for bundles to provide their own "preference pane", a la System Preferences? I'm imagining an interface something like Growl's Applications tab—a page in TextMate's Preferences window with a list of bundles in the sidebar, and an area on the right with settings for that bundle.
It wouldn't enable anything you can't already do with the Bundle Editor, but it would be much more *discoverable* for those who don't want to be required to hack on their bundles.
–Adam
On Jan 31, 2014, at 3:58 PM, Adam Sharp adsharp@me.com wrote:
Would it be possible to expose an API for bundles to provide their own "preference pane", a la System Preferences? I'm imagining an interface something like Growl's Applications tab—a page in TextMate's Preferences window with a list of bundles in the sidebar, and an area on the right with settings for that bundle.
It wouldn't enable anything you can't already do with the Bundle Editor, but it would be much more *discoverable* for those who don't want to be required to hack on their bundles.
Since we're dreaming / brainstorming, I'll argue just the opposite. What's needed is an interface that gives much better information both to beginners and to experts about *what* bundle is causing the phenomenon. All of my conversations with TextMate have been about tracking down phenomena caused in diverse places far away from the document-type bundle. For example:
Me: Why is this text italic?
TM: It is markup.italic.asciidoc.
Me: Yes but that's not what I mean. I mean why is it *shown* as italic? I can't find that anywhere in the current Theme.
TM: Oh, it's because of one of the Settings way off in the Text bundle.
That's a four-line conversation, but in real life, it took a week to unfold. I had to hunt up and down, hither and yon, before I finally discovered what was going on. Why doesn't TextMate just *tell* me?
Here's another:
Me: Why is this weird auto-indenting happening?
TM: It is text.html.asciidoc.
Me. But I've looked and looked, and there's nothing in the asciidoc bundle that would cause it to auto-indent. Why is it auto-indenting?
TM: Oh, that's because of the Miscellaneous settings way off in the HTML bundle.
Again, that took about a week.
Do you see what I'm getting at here? Maybe *you* (meaning Allan and a few other guys) were born knowing all the scopes of all the bundles and what's in all of them, but I was not. What's needed for normal people like me is an explanation of how TM is arriving at its decisions that are affecting me. For an example of how the interface might work, look at the Safari Web Inspector, which brilliantly tells you how the CSS for selected text is calculated from the cascade of style sheets. m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
On 1 Feb 2014, at 8:50, Matt Neuburg wrote:
[…] What's needed is an interface that gives much better information both to beginners and to experts about *what* bundle is causing the phenomenon.
The current Bundles → Select Bundle Item… (⌃⌘T) window is a query functionality that I would like to extend to allow querying settings and key bindings outside bundles.
Though it’s a challenge to get all the options squeezed into the window and still keep it simple.
Yes,
I am glad this topic came up. This morning, I was about to pull out my hair trying to figure out why some of my code was soft wrapping and other parts weren't in the same file. Turns out it was part of a bundle that was doing this. It was very frustrating.
To be honest, I don't see the point of bundle's overriding something that should be a global setting. If I have soft wrap disabled via [view -> Disable soft wrap], a bundle should not be able to override that setting and reenable it. This inconsistency (as a user) caused me to think that TxMt was just glitching out.
Bundles should only be suggestions of what to do.
-- Kyle Hanson
On Sat, Feb 1, 2014 at 9:21 PM, Allan Odgaard mailinglist@textmate.orgwrote:
On 1 Feb 2014, at 8:50, Matt Neuburg wrote:
[…] What's needed is an interface that gives much better information both
to beginners and to experts about *what* bundle is causing the phenomenon.
The current Bundles → Select Bundle Item… (⌃⌘T) window is a query functionality that I would like to extend to allow querying settings and key bindings outside bundles.
Though it’s a challenge to get all the options squeezed into the window and still keep it simple.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 3 Feb 2014, at 0:49, Kyle Hanson wrote:
[…] I don't see the point of bundle's overriding something that should be a global setting. If I have soft wrap disabled via [view -> Disable soft wrap], a bundle should not be able to override that setting and reenable it […]
The issue is that “soft wrap” is not a global boolean choice. For example I like comments to be soft wrapped in source code, where soft wrap is otherwise disabled. We also soft wrap list items in Markdown documents, etc., which is why these settings are in bundles, since they are sort of language specific.
That said, how to disable soft wrapped comments is one of the most frequently asked questions, so it’s likely a bad default that I’m considering changing.
I agree- it's a really useful feature and I love it, just surprised me at the start, especially coming from TM1 where soft wrap menu item controlled all soft wrapping.
Maybe a setting in the view menu by (the normal soft wrap menu item) that when turned off makes textmate ignore all bundle wrapping settings?
Sent from my iPhone
On Feb 2, 2014, at 6:32 PM, "Allan Odgaard" mailinglist@textmate.org wrote:
On 3 Feb 2014, at 0:49, Kyle Hanson wrote:
[…] I don't see the point of bundle's overriding something that should be a global setting. If I have soft wrap disabled via [view -> Disable soft wrap], a bundle should not be able to override that setting and reenable it […]
The issue is that “soft wrap” is not a global boolean choice. For example I like comments to be soft wrapped in source code, where soft wrap is otherwise disabled. We also soft wrap list items in Markdown documents, etc., which is why these settings are in bundles, since they are sort of language specific.
That said, how to disable soft wrapped comments is one of the most frequently asked questions, so it’s likely a bad default that I’m considering changing.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Feb 2, 2014, at 6:41 PM, Philippe Huibonhoa phuibonhoa@gmail.com wrote:
Maybe a setting in the view menu by (the normal soft wrap menu item) that when turned off makes textmate ignore all bundle wrapping settings?
There are two problems I'm having:
* A setting that causes a phenomenon I'm seeing could come from many different places (including a theme or a setting, as well as a language grammar) in a bundle different from the one I think I'm in.
* And then to confuse matters *still more* there are all these global settings, plus the .tm_properties files.
If we did what Philippe suggests, it would be *even more* confusing than it is already: "I'm saying to wrap so why aren't we wrapping?" One more undiscoverable thing off in one more undiscoverable location (the view menu or whatever).
It makes me want to argue for exactly the opposite of what Philippe is saying: there should be NO global settings, NO view menu settings. Everything should be in files that I can actually find, in order to govern and understand what's going on.
But at the same time there needs to be a way, as I suggested earlier, to ask TM2 to *tell* me what's going on - for any given phenomenon, *what* file is causing this behavior / phenomenon, including how it overshadows any other files that are trying to influence the same behavior.
It seems to me that this can't really be that hard to do, because TM2 must *have* a knowledge of this. It has a logic that *causes* any given aspect of what I'm experiencing. So it should surely be able to *tell* me that logic.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
That's fair. I was suggesting something in the view menu since that's where most users go to change the soft wrap to begin with and thus seems most discoverable.
If I change soft wrap via the view menu and see another soft wrap setting I might be inclined to try it or investigate if things aren't working as expected.
Messing with bundles or pref files isn't discoverable or user friendly and should only be reserved for things only power users care about and it sounds like this is bubbling up to he something most users care about.
Sent from my iPhone
On Feb 2, 2014, at 7:16 PM, Matt Neuburg matt@tidbits.com wrote:
On Feb 2, 2014, at 6:41 PM, Philippe Huibonhoa phuibonhoa@gmail.com wrote:
Maybe a setting in the view menu by (the normal soft wrap menu item) that when turned off makes textmate ignore all bundle wrapping settings?
There are two problems I'm having:
A setting that causes a phenomenon I'm seeing could come from many different places (including a theme or a setting, as well as a language grammar) in a bundle different from the one I think I'm in.
And then to confuse matters *still more* there are all these global settings, plus the .tm_properties files.
If we did what Philippe suggests, it would be *even more* confusing than it is already: "I'm saying to wrap so why aren't we wrapping?" One more undiscoverable thing off in one more undiscoverable location (the view menu or whatever).
It makes me want to argue for exactly the opposite of what Philippe is saying: there should be NO global settings, NO view menu settings. Everything should be in files that I can actually find, in order to govern and understand what's going on.
But at the same time there needs to be a way, as I suggested earlier, to ask TM2 to *tell* me what's going on - for any given phenomenon, *what* file is causing this behavior / phenomenon, including how it overshadows any other files that are trying to influence the same behavior.
It seems to me that this can't really be that hard to do, because TM2 must *have* a knowledge of this. It has a logic that *causes* any given aspect of what I'm experiencing. So it should surely be able to *tell* me that logic.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
This a good discussion, but getting back to the original question, what is the current “best practice” for an end user wanting to enable intended soft wrap globally?
I remember asking this question years ago, and the response was to create my own personal bundle (e.g., “Trevor’s Bundle”) and add to it a setting like the following:
{ indentedSoftWrap = { match = '\A[ \t]*'; format = '$0\t'; }; }
I certainly agree this procedure is not very user-friendly, but is it still the way to go? Or have things changed in TextMate 2? Thanks,
Trevor
On Feb 2, 2014, at 7:21 PM, Philippe Huibonhoa phuibonhoa@gmail.com wrote:
That's fair. I was suggesting something in the view menu since that's where most users go to change the soft wrap to begin with and thus seems most discoverable.
If I change soft wrap via the view menu and see another soft wrap setting I might be inclined to try it or investigate if things aren't working as expected.
Messing with bundles or pref files isn't discoverable or user friendly and should only be reserved for things only power users care about and it sounds like this is bubbling up to he something most users care about.
Sent from my iPhone
On Feb 2, 2014, at 7:16 PM, Matt Neuburg matt@tidbits.com wrote:
On Feb 2, 2014, at 6:41 PM, Philippe Huibonhoa phuibonhoa@gmail.com wrote:
Maybe a setting in the view menu by (the normal soft wrap menu item) that when turned off makes textmate ignore all bundle wrapping settings?
There are two problems I'm having:
A setting that causes a phenomenon I'm seeing could come from many different places (including a theme or a setting, as well as a language grammar) in a bundle different from the one I think I'm in.
And then to confuse matters *still more* there are all these global settings, plus the .tm_properties files.
If we did what Philippe suggests, it would be *even more* confusing than it is already: "I'm saying to wrap so why aren't we wrapping?" One more undiscoverable thing off in one more undiscoverable location (the view menu or whatever).
It makes me want to argue for exactly the opposite of what Philippe is saying: there should be NO global settings, NO view menu settings. Everything should be in files that I can actually find, in order to govern and understand what's going on.
But at the same time there needs to be a way, as I suggested earlier, to ask TM2 to *tell* me what's going on - for any given phenomenon, *what* file is causing this behavior / phenomenon, including how it overshadows any other files that are trying to influence the same behavior.
It seems to me that this can't really be that hard to do, because TM2 must *have* a knowledge of this. It has a logic that *causes* any given aspect of what I'm experiencing. So it should surely be able to *tell* me that logic.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Feb 2, 2014, at 7:38 PM, Trevor Harmon trevor@vocaro.com wrote:
I certainly agree this procedure is not very user-friendly, but is it still the way to go? Or have things changed in TextMate 2?
My ideas are very inchoate and I appreciate the discussion of the opposing point of view, so please keep countering me.
My thought here is: It is wrong to look for user-friendliness in TM2.
Non-power users of TM2 are probably not going to be capable or desirous of changing _anything_; they will love the text editing features and will learn to use them, in the same way that I use TM for editing and running Ruby or writing Markdown without worrying about _how_ it works behind the scenes, but they won't do any tweaking.
Anyone, on the other hand, who does _any_ tweaking is promoted to a power user! And such a person, I argue, _will_ have to make these sorts of non-user-friendly adjustments. To make a non-user-friendly way to let non-power users do what power users do would dilute and confuse the program. TM2 is like emacs: you can take what you're given or you can make adjustments, but there is no naive user-friendly way to make those adjustments, nor should there be. TM2 is like Flammarion's woodcut:
http://en.wikipedia.org/wiki/File:Flammarion.jpg
Either stay on your side of the universe and enjoy the beauty of nature, or peek behind the curtain and blow your mind. There is no middle course.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
Hmm. I disagree.
User-friendliness is not, as many self-proclaimed power users seem to think, a newbie feature. It is a matching of the control over the capabilities to the user’s workflow, no matter the level of user and/or complexity of workflow.
Saying “we don’t need user-friendliness” is throwing the baby out with the bath water, and belies a lack of user experience design, IMO.
For any workflow, even, no, *especially* power user workflows, there is a sweet spot of providing control over that workflow in ways that make that control simple, elegant, and effective.
Power user != just throw me into the guts of a system. If it were that, the only true power users would be flipping bits directly.
Now, you can say that user-friendliness is not a strongly required feature for a particular application or system. That’s a systems design choice. But to say that power users don’t need user-friendliness? Naw, that’s just taking the easy way out. UX design is hard, absolutely, but to say “oh, we don’t need that, we’re *power users*” quickly leads to the preference panels in many Linux apps that look like the dashboard of a 747. Everything-is-an-option is chaos.
Instead, TM2 should be looking at ways of making the common tasks of power users simpler and more direct. I think it does a remarkable job of this as it is. At the risk of contradicting myself above, perhaps a “Global preferences take precedence” switch. Turn it on, the pref you set at the global level trumps all. Turn it off, and the pref you set at the global level is the default, to be overridden by bundles.
I can easily see scenarios where either is rational and reasonable, and neither jumps out as a clear winner. Therefore, a power user workflow decision is promoted to a discoverable, clear checkbox. Voila. User friendly for the power user.
And just as a datapoint? I finally ran screaming from emacs back in the great 19.27/28 schism of ‘94, and haven’t looked back. Got tired of dealing with the ongoing breakage of basic power user scripts. That may not be the best model to aspire to, from a user perspective. :) I take the description of TM2 as “emacs for Macs” to mean that it has the Mac usability baked in, and has the same level of attention to detail and design as other Mac apps. Otherwise, it’s just “emacs with Python and Ruby” and I don’t think anyone wants that. We can do *way* better than that, and I think Allan has.
On Feb 2, 2014, at 8:27 PM, Matt Neuburg matt@tidbits.com wrote:
On Feb 2, 2014, at 7:38 PM, Trevor Harmon trevor@vocaro.com wrote:
I certainly agree this procedure is not very user-friendly, but is it still the way to go? Or have things changed in TextMate 2?
My ideas are very inchoate and I appreciate the discussion of the opposing point of view, so please keep countering me.
My thought here is: It is wrong to look for user-friendliness in TM2.
Non-power users of TM2 are probably not going to be capable or desirous of changing _anything_; they will love the text editing features and will learn to use them, in the same way that I use TM for editing and running Ruby or writing Markdown without worrying about _how_ it works behind the scenes, but they won't do any tweaking.
Anyone, on the other hand, who does _any_ tweaking is promoted to a power user! And such a person, I argue, _will_ have to make these sorts of non-user-friendly adjustments. To make a non-user-friendly way to let non-power users do what power users do would dilute and confuse the program. TM2 is like emacs: you can take what you're given or you can make adjustments, but there is no naive user-friendly way to make those adjustments, nor should there be. TM2 is like Flammarion's woodcut:
http://en.wikipedia.org/wiki/File:Flammarion.jpg
Either stay on your side of the universe and enjoy the beauty of nature, or peek behind the curtain and blow your mind. There is no middle course.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
I suppose there needs to be more global settings, and for each of them, perhaps provide four settings instead of two. Using soft-wrap as an example, they would be:
- Forced on - Forces soft-wrapping to be ON regardless of bundle-specific settings. - Default on - Respects bundle-specific settings, but defaults to ON where bundle does not specify. - Default off - Respects bundle-specific settings, but defaults to OFF where bundle does not specify. - Forced off - Forces soft-wrapping to be OFF regardless of bundle-specific settings.
I agree with most of the other discussion also.
Regarding identifying why a line is styled as it is (e.g. orange and in italics), perhaps a simple solution would be to simply show the style information for the current cursor position by holding down a modifier key, or by providing an option in the context-menu called "Show style information" that displayed in a tooltip or window overlay all inherited styles at the position of the cursor. This I imagine would be much less work than providing something equivalent to the inspector in most web browsers.
Tom
On 3 February 2014 14:27, Matt Neuburg matt@tidbits.com wrote:
On Feb 2, 2014, at 7:38 PM, Trevor Harmon trevor@vocaro.com wrote:
I certainly agree this procedure is not very user-friendly, but is it
still the way to go? Or have things changed in TextMate 2?
My ideas are very inchoate and I appreciate the discussion of the opposing point of view, so please keep countering me.
My thought here is: It is wrong to look for user-friendliness in TM2.
Non-power users of TM2 are probably not going to be capable or desirous of changing _anything_; they will love the text editing features and will learn to use them, in the same way that I use TM for editing and running Ruby or writing Markdown without worrying about _how_ it works behind the scenes, but they won't do any tweaking.
Anyone, on the other hand, who does _any_ tweaking is promoted to a power user! And such a person, I argue, _will_ have to make these sorts of non-user-friendly adjustments. To make a non-user-friendly way to let non-power users do what power users do would dilute and confuse the program. TM2 is like emacs: you can take what you're given or you can make adjustments, but there is no naive user-friendly way to make those adjustments, nor should there be. TM2 is like Flammarion's woodcut:
http://en.wikipedia.org/wiki/File:Flammarion.jpg
Either stay on your side of the universe and enjoy the beauty of nature, or peek behind the curtain and blow your mind. There is no middle course.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 3 Feb 2014, at 12:52, Tom Wardrop wrote:
I suppose there needs to be more global settings, and for each of them, perhaps provide four settings instead of two. Using soft-wrap as an example, they would be: […]
I think for soft wrap, one could split it into “soft wrap” and “semantic soft wrap”. The latter would turn all the bundle soft wrap settings on/off, but even that is not really perfect, as one user may dislike the wrapped comments, but would still want list items to be wrapped in Markdown.
The solution is probably just to disable the default wrapping of comments, as this is what people generally want to disable.
[…] Regarding identifying why a line is styled as it is […]
Matt was actually talking about “behavior”, which is a little bit more abstract. Like “why does it indent after a open brace?”. But as I previously replied, the current Select Bundle Item… tool can be extended to allow querying more things, which would go a long way.
I disagree that TM2 is like Emacs. A big reason I use TextMate, and not Emacs or Vi, is because it has the same power-user features wrapped in a much friendlier user interface. And if I do want to make power-user tweaks, I find this easier in TextMate than Emacs. (I use OS X instead of Linux for similar reasons.)
To continue your Flammarion analogy, intended soft-wrap in TextMate is on the outside of the bubble. Enabling it globally requires a lengthy trip to the circling clouds, suns, and fires of power-user land. But it’s such a commonly requested feature that it should be more accessible, right from inside the pretty garden.
I think one way to accomplish this is to have it enabled by default, and allow those who dislike it to disable it using the Bundle Editor.
Trevor
On Feb 2, 2014, at 8:27 PM, Matt Neuburg matt@tidbits.com wrote:
On Feb 2, 2014, at 7:38 PM, Trevor Harmon trevor@vocaro.com wrote:
I certainly agree this procedure is not very user-friendly, but is it still the way to go? Or have things changed in TextMate 2?
My ideas are very inchoate and I appreciate the discussion of the opposing point of view, so please keep countering me.
My thought here is: It is wrong to look for user-friendliness in TM2.
Non-power users of TM2 are probably not going to be capable or desirous of changing _anything_; they will love the text editing features and will learn to use them, in the same way that I use TM for editing and running Ruby or writing Markdown without worrying about _how_ it works behind the scenes, but they won't do any tweaking.
Anyone, on the other hand, who does _any_ tweaking is promoted to a power user! And such a person, I argue, _will_ have to make these sorts of non-user-friendly adjustments. To make a non-user-friendly way to let non-power users do what power users do would dilute and confuse the program. TM2 is like emacs: you can take what you're given or you can make adjustments, but there is no naive user-friendly way to make those adjustments, nor should there be. TM2 is like Flammarion's woodcut:
http://en.wikipedia.org/wiki/File:Flammarion.jpg
Either stay on your side of the universe and enjoy the beauty of nature, or peek behind the curtain and blow your mind. There is no middle course.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
-
Adam Sharp -
Allan Odgaard -
Fred ALB -
Jason McC. Smith -
Kyle Hanson -
Matt Neuburg -
Philippe Huibonhoa -
Tom Wardrop -
Trevor Harmon