[TxMt] Re: document tabs redux / wish list [in a new thread ?]

[David Lee]

On 01/04/2005, at 7:09 PM, Mats Persson wrote:

>
> On 1 Apr 2005, at 04:06, David Lee wrote:
>> I think it's twice I've been chewed out for threading before...
> Apologies David didn't mean to "chew you out", but Sune - the list's 
> thread-keeper extraordinarie - has gone awol lately, so I'm just 
> trying to fill his very big boots for a short while until I too give 
> up ;-)
>

No probs. I'll try to behave.

>> My apologies to Allan for misspelling his name too - It was 3.30 am 
>> or so when i wrote this and I was well overdue for a nap.
>
> I didn't mean to attack you personally, but being a Swede with an 
> 'unusual' name and having lived in the UK for the past 15 years I have 
> found that unfortunately the vast majority of English speaking 
> clients/'friends' just cannot accept learning a new name. Most insist 
> on calling me Mark (WTF!!!!). I personally had two separate instances 
> of that yesterday, and your 'mistake' made my cup overflow, I guess.

it's better than being called David.

>> Still i think they're good ideas, and some of them worth discussion. 
>> Bad moods and basic table manners aside, do you have any reactions to 
>> the content?
> Yes, and here they come.
>
>
> On 31 Mar 2005, at 17:44, David Lee wrote:
>> 1) < and > arrows appear when more tabs are open than fit. You scroll 
>> all the tabs left or right to see tabs offscreen. It scrolls one tab 
>> at a time.
>>
>> 2) When you use the keyboard to move through open files, the 
>> arrangement of tabs move to keep the currently open file's tab 
>> visible at all times.
>>
>> 3) The drop-down list of offscreen tabs should stay.
>
> I think Allan's reply to you earlier identified what is in the works 
> and how the general consensus was regarding handling many open doc's 
> in tabs and so on. Perhaps I don't fully understand your points above, 
> but I don't see them as any better than Allan's existing proposals.

I have complete faith in Allan's ability to get it right, and these 
three points probably didn't add anything to my thesis.

I think the document switching 'problem' goes beyond tab handling, and 
those aspects of it are probably the most fruitful to explore at this 
point ...

>
>> 4) Make people aware that you can hit ctrl-cmd-n to get a new project 
>> window, drag the files you're currently working on in there and use 
>> the project drawer to flip between them. I just extrapolated this 
>> from one of Allen's other posts and it feels very promising.
>
>> Can we be able to 'open these tabs in new project' with a menu 
>> command / shortcut? It's not the perfect long term solution but will 
>> always be useful whatever is.
>
> Not sure I get your point there either.  The way I (and others ?) work 
> is I create a TM project window for each project that I'm working on 
> and save the <ProjectName>.tmproj file into the root of that project 
> folder. As for flipping through files in the project drawer via 
> shortcuts much of that exist today, and the missing parts will be 
> improved in a future revision of the project drawer already planned.

I mean when working on a large project with many files (Ruby on Rails 
Rails apps for example), I'm usually switching between only a small 
subset of the files in the project.

It's a convenient thing to be able to start a project and drag files 
from the old project sidebar to the new one to set yourself up for a 
certain task.

Mostly i think people should know things like this are possible, so i 
saw some value in making it marginally more convenient by adding a 
feature which also serves to document its doability.

>
>> Oh yeah. I'm a split view junkie. Up-down, left-right, any 
>> combination. Just the way nature intended.
> Discussed till boredom almost, and is planned.
>
>> I'd love to see a good regular expression composer (Komodo does this 
>> superbly, Kdevelop well too).
>
> Never used either of those, so don't grep what's so special about 
> them.  But what would be nice to have is a simple Command (can be a 
> bundle) that takes the selected text - with some kind of identifiers 
> in there and then returns the regex for it. Sort of like this:
>
> input:
> <key>:[capture1]:</key>
> <string>:[capture2]:</string>
>
> output (on clipboard): (<key>(.+)</key>(?s:.*?)<string>(.+)</string>)
>
> Slightly crude idea I know, but still lovely to have and would spare 
> my single 'brain'cell for other things ;-)

The cool thing is that it interactively validates your RX, highlights 
the matches, shows you what's been captured and in what order. I find 
it much more useful than that sounds.

http://aspn.activestate.com/ASPN/docs/Komodo/3.0/komodo-doc-regex.html

I don't know if a script which returns regexps would become useful at a 
lower level of complexity than it became impossibly painful to its 
author.

this would do more or less what you said from the command line, but 
uses [*] in place of [capture1]:

#!/usr/local/bin/ruby

class RX_writer
	def initialize
		while in_string = gets
			parts = in_string.split('[*]')
			slash = %w/^ $ [ ] ( ) \/ \ . ? + * /
			parts.each { |part|
				slash.each { |ch| part.gsub!(ch, '\\'+ch) }			
			}
			puts parts.join('(.+)')
		end
	end
end; RX_writer.new
___________

but
a) I don't know how to turn that into a textmate script yet; i should 
read the docs
b) That returned regex will be very inflexible, as (.+) will gobble up 
more than it should if unwatched. E.g., if you put '<tag>foo</tag>' in 
and get back '<tag>(.+)><\/tag>', then use that RX on 
'<tag>foo</tag><tag>bar</tag>' , it will match 'foo</tag><tag>bar' .

I'd much rather have a better environment for writing my own.

>
>> And a well considered 'intellisense' implementation which can include 
>> your own completion items (and later, those in included files) in 
>> heaps of languages.
>
> In what way does not snippets take care of this at the moment ?

If any snippets do autocompletion with an intelligent (context 
sensitive) dropdown list of completion items, narrowing as you complete 
a word, then I've really missed something.

Autocompletion, when it works really well (knows the available methods 
of the object you've just typed; knows the classes & variables you've 
defined on this page and elsewhere in the project) is one of the best 
things an editor can do for you.

It's also probably insanely involved and language-specific, so the best 
we could hope for is a well-considered, powerful way for bundles to get 
this done with a minimum of overhead or inconsistency. I'm not sure 
what's currently possible or planned here but it's not doing what i 
wished for out-of-the-box.

>> Multiple 'paste previous' / 'paste next' commands rewrite the last 
>> ones' output (which can probably be hacked by leaving it selected 
>> after each paste, but thats not ideal).
>
>
> Not getting your point there, sorry. Have a look at Windows->Show 
> Clipboard History and explain what's missing in there ?

If i wish to paste the second-last thing i copied, I should be able to 
tap cmd-shift-v twice and end up only with the thing i wanted to paste 
on the screen.

It's quicker and much more convenient than anything else. The clipboard 
viewer is great, but not in that context.

>> A function / class browser.
> Have you seen Kumar McMillan's excellent "Special Items..." in the 
> Default.tmbundle up on the SVN repos ?? It gives you most of what you 
> need, but can still be improved further by Allan inside TM rather than 
> as a bundle. (which I
> think is planned anyway)

no I haven't, i'll certainly grab it, and it's awesome to hear Allan is 
likely planning something.

>
>> Better print output (allow choice of different font for printing; 
>> programmer fonts look terrible) & optionally include syntax 
>> highlighting & line numbers.
>
> This printing business was a big thing back in Oct/Nov last year, and 
> Allan asked for the basic requirements from us users then. As a fairly 
> vocal supporter of printing then I have since only used the printing 
> features of TM twice. When I was working with <other leading Mac 
> editor> I used to print my code almost daily. Now I don't mainly due 
> to a change in workstyle/workflow, but also because of some of TM's 
> features.  Try open document in new window, make fullscreen and then 
> increase the font size to suit, now lean back in your comfy chair 
> (reclining armchair that is ;-) ) and peruse your code screen by 
> screen.  It's what I used to do on paper before, but now does on 
> screen. Much faster as well.
>
> But yes, all of those printing features could/would be good to have as 
> well someday, and I'm 100% certain we will get them, but there's more 
> important things for Allan to address before then.
>

my main issue is that the programming fonts i use look like utter shit 
at larger than their set size. I'd like for print to be able to print 
in another (user selected) font & size.

It's not a biggie though as we can always paste it to another program 
first.

cheers

D